NEWS
Test Adapter snmp V2.0.x
-
@mcm57
V2 einfach über die V1 drüber, hat fehlerfrei funktioniert. Habe eine Temperaturbox (IP192.168.20.60) mit 4 OID´s (Sensoren). Instanz gestoppt, Objekte gelöscht, dann in der Konfiguration den Sensoren die OID-Gruppe "temperatur" zugewiesen, auf der Registerkarte Gerät dem ganzen den Klarnamem "Temp_Box" gegeben und die gleiche OID Gruppe zugewiesen. Unter Optionen Kompatibilätsmmodus nicht angehakt. Und dann neu gestartet.
Erwartungshaltung war unter den Objekten sinngemäß snmp.5.OID-Gruppe oder snmp.5.Klarname als Struktur zu finden.
Es wird aber analog zur v1 unter snmp.5.192_168_20_60.xxx die Struktur angelegt. Hab ich den Sinn der OID Gruppen nicht verstanden oder funktioniert der Haken mit "ohne" Kompatibilität nicht?Sorry, muss leider bestätigen dass ihr einen Fehler gefunden habt. DANKE fürs Bescheidgeben.
Das Flag funktioniert genau verkehrt rum, ihr müßt es anhaken, wenn ihr den Compatibility Mode NICHT haben wollt.
https://github.com/iobroker-community-adapters/ioBroker.snmp/issues/135
ACHTUNG: Ich werde (wahrscheinlich) den Code in 2.0.1 anpassen da es mir sinnvoll scheint, dass das Flag im GUI normalerweise nicht angehakt ist. Das wird Auswirkungen auf eure jetzige Testversion haben. Eine explizite Migration 2.0.0 auf 2.0.1 ist den Aufwand m.E. nicht wert.
-
@bommel_030
Hi
Ev. Ist die Doku da noch zu dünn.Der Name der Stares wird vom DEVICENAME abgeleitet. Du musst also im Tab Geräte in Spalte Name etwas eintragen/ändern, zB TempBox-Garten.
Im Zuge der Migation wird der Gerätename aus der IP gebildet.
Die OID Gruppe hat keinen Einfluss auf die Staenamen. Die OID Gruppe dient als Link zwischen dem Deviceeintrag und den zu prüfenden OIDs. Jedes Gerät fragt die OIDs ab die ihm über die OID Gruppe zugeordnet wurden.
In V1 musste man bei 3 identen Geräten, z.B. NAS od Networkswitches, die OIDs 3x eintippen. Ab v2 kann man eine OID Gruppe auch mehreren Geräten zuordnen. Wer also 10 Drucker oder 5 NAS hat erspart sich konfig Tipperei.
Hoffe ich konnte es ein wenig erklären. Wenn noch was unklar ist bitte fragen. Bin allerdings z.z. nur via mobilphone im Forum ...
DANKE fürs Testen !
@mcm57 sagte in Test Adapter snmp V2.0.x:
Die OID Gruppe hat keinen Einfluss auf die Staenamen. Die OID Gruppe dient als Link zwischen dem Deviceeintrag und den zu prüfenden OIDs.
Hallo, nachdem ich jetzt auf 2.0.0 upgedatet habe (lief ohne Probleme) hat er eine OID Gruppe "set-1" angelegt. Als "Startwert" ok, ich habe die im Reiter GERÄTE abgeändert auf einen sprechenden Namen (hier: Drucker_Arbeitszimmer).
Danach musste ich den Namen der OID Gruppe im Reiter OID-SETS in allen Zeilen manuell eintragen. Wäre es hier nicht sinnvoll statt freier Eingabe ein Auswahlmenu mit den definierten OID Gruppen anzubieten?
Und dann noch eine Verständnisfrage: Wenn die OID Gruppe als Link zwischen dem Deviceeintrag und den verschiedenen IOD dient (habe ich verstanden
) wäre es dann nicht für Visualisierung o.ä. sinnvoll, die Gruppe auch in den Datenpunkten mit abzulegen?Ich weiß, dass so Anfragen eigentlich als Request in Github gehören, aber ich wollte es in diesem Thread mal zur Diskussion stellen (vielleicht mache ich ja einen Denkfehler und meine Vorschläge sind Unsinn...)
iobroker auf proxmox container
-
@mcm57 sagte in Test Adapter snmp V2.0.x:
Die OID Gruppe hat keinen Einfluss auf die Staenamen. Die OID Gruppe dient als Link zwischen dem Deviceeintrag und den zu prüfenden OIDs.
Hallo, nachdem ich jetzt auf 2.0.0 upgedatet habe (lief ohne Probleme) hat er eine OID Gruppe "set-1" angelegt. Als "Startwert" ok, ich habe die im Reiter GERÄTE abgeändert auf einen sprechenden Namen (hier: Drucker_Arbeitszimmer).
Danach musste ich den Namen der OID Gruppe im Reiter OID-SETS in allen Zeilen manuell eintragen. Wäre es hier nicht sinnvoll statt freier Eingabe ein Auswahlmenu mit den definierten OID Gruppen anzubieten?
Und dann noch eine Verständnisfrage: Wenn die OID Gruppe als Link zwischen dem Deviceeintrag und den verschiedenen IOD dient (habe ich verstanden
) wäre es dann nicht für Visualisierung o.ä. sinnvoll, die Gruppe auch in den Datenpunkten mit abzulegen?Ich weiß, dass so Anfragen eigentlich als Request in Github gehören, aber ich wollte es in diesem Thread mal zur Diskussion stellen (vielleicht mache ich ja einen Denkfehler und meine Vorschläge sind Unsinn...)
snmp 2.0.1 wurde released.
Sollte ab 23.7.2022 im latest verfügbar sein.Dies ist eine Bugfix Release, gefixed wurde:
2.0.1 (2022-07-22)
- (McM1957) Faulty handling of compatibility mode flag has been corrected (#135)
- (McM1957) Logging of errors for invalid OIDs corrected (#134)
-
@mcm57 sagte in Test Adapter snmp V2.0.x:
Die OID Gruppe hat keinen Einfluss auf die Staenamen. Die OID Gruppe dient als Link zwischen dem Deviceeintrag und den zu prüfenden OIDs.
Hallo, nachdem ich jetzt auf 2.0.0 upgedatet habe (lief ohne Probleme) hat er eine OID Gruppe "set-1" angelegt. Als "Startwert" ok, ich habe die im Reiter GERÄTE abgeändert auf einen sprechenden Namen (hier: Drucker_Arbeitszimmer).
Danach musste ich den Namen der OID Gruppe im Reiter OID-SETS in allen Zeilen manuell eintragen. Wäre es hier nicht sinnvoll statt freier Eingabe ein Auswahlmenu mit den definierten OID Gruppen anzubieten?
Und dann noch eine Verständnisfrage: Wenn die OID Gruppe als Link zwischen dem Deviceeintrag und den verschiedenen IOD dient (habe ich verstanden
) wäre es dann nicht für Visualisierung o.ä. sinnvoll, die Gruppe auch in den Datenpunkten mit abzulegen?Ich weiß, dass so Anfragen eigentlich als Request in Github gehören, aber ich wollte es in diesem Thread mal zur Diskussion stellen (vielleicht mache ich ja einen Denkfehler und meine Vorschläge sind Unsinn...)
@amg_666 said in Test Adapter snmp V2.0.x:
Wäre es hier nicht sinnvoll statt freier Eingabe ein Auswahlmenu mit den definierten OID Gruppen anzubieten?
Ja, Auswahlmenues wären sicher sinnvoll. ABER
...
a) An sich würde man zuerst die OIDs mit ihrer Gruppenbezeichnung anlegen - zumindest wenn man das ganze neu anlegt. Das Auswahlmenue wäre dann primär am Tab Devices möglich bzw. sinnvoll. Umgekehrt (d.h. Auswahlmenu bei den OIDs) würde eine (derzeit noch nicht implementierte) Konsistenzprüfung, d.h. bei einem Gerät darf nur eine OID Gruppe stehen die es auch gibt, blockieren. OID Gruppen die kein Gerät benutzt sind un wären im Gegensatz kein Problem.Aber im Prinzip kann man da über vieles reden (abgesehen v Punkt b der noch kommt). Mal schaun was da sonst noch als Feedback kommt.
b) Die derzeit verfügbare jsonConfig bietet - nach meinem Wissensstand - keine Dropdown Menues an die rein auf den Daten anderer Tabs basieren. Es gibt zwar - soweit ich wieß - die Möglichkeit Callbacks in den Adaptercode aufzurufen; nur das würde einen laufenden Adapter voraussetzen (was bei einer initialen Config nicht vorausgesetzt werden sollte) und andrerseits würde der Adapter wohl nur jede OID Grupen sehen die auch schon gespeichert sind. Kurz: Im Moment scheint diese Anforderung technisch mittels jsonConfig nicht trivial umsetzbar. Falls wer mehr dazu sagen kann, können wir das gerne diskutieren - im Moment möchte ich allerdings weitere Zeit primär in die Funktion (SNMP V2 / v3 / Iv6 / ...) stecken und nicht unbedingt in GUI. Muss aber sagen, dass ich kein GUI Entwickler bin und sicher kein React Plugin o.ä. mal so dazwischen schriebn könnte.
@amg_666 said in Test Adapter snmp V2.0.x:
Und dann noch eine Verständnisfrage: Wenn die OID Gruppe als Link zwischen dem Deviceeintrag und den verschiedenen IOD dient (habe ich verstanden
) wäre es dann nicht für Visualisierung o.ä. sinnvoll, die Gruppe auch in den Datenpunkten mit abzulegen?Ich bin da nicht sicher, ob ich den Wunsch richtig interpretiere:
Im Prinzip soll der Adapter seine Configdaten (oder einen Teil, hier die OID Gruppe) auch als Datenpunkt anbieten? Also z.B. als snmp.o.config.oid-group mit Wert Drucker_Buero. Hab ich das richtig verstanden?Technisch ginge das sicher. Man / ich müsste dazu aber zuerst mal die "alten Hasen" (= ioBroker Kernentwickler) fragen ob das gewunschen wäre. Und ob es nicht sowieso eine triviale Möglichkeit gibt. die Config abzufragen. Wir sollten ja nicht unbedingt Unmengen an Datenpunkten generieren die nur selten gebraucht werden. Neben der OID Gruppe gibts da ja dann gleich noch die diversen Timer und die snmp Version und, und und ...
Wie gesagt - technisch sicher machbar. Ich wart mal ob dazu Feedback kommt. Schreib ggF einen issue dazu wenn es dir wichtig ist. Versprechen möcht uch aber nichts.
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer Danke sagen will, kann nen Kaffee spendieren: https://paypal.me/mcm1957atiobroker
-
snmp 2.0.1 wurde released.
Sollte ab 23.7.2022 im latest verfügbar sein.Dies ist eine Bugfix Release, gefixed wurde:
2.0.1 (2022-07-22)
- (McM1957) Faulty handling of compatibility mode flag has been corrected (#135)
- (McM1957) Logging of errors for invalid OIDs corrected (#134)
@mcm57
Danke, jetzt kommt der Name statt der IP Adresse
-
@amg_666 said in Test Adapter snmp V2.0.x:
Wäre es hier nicht sinnvoll statt freier Eingabe ein Auswahlmenu mit den definierten OID Gruppen anzubieten?
Ja, Auswahlmenues wären sicher sinnvoll. ABER
...
a) An sich würde man zuerst die OIDs mit ihrer Gruppenbezeichnung anlegen - zumindest wenn man das ganze neu anlegt. Das Auswahlmenue wäre dann primär am Tab Devices möglich bzw. sinnvoll. Umgekehrt (d.h. Auswahlmenu bei den OIDs) würde eine (derzeit noch nicht implementierte) Konsistenzprüfung, d.h. bei einem Gerät darf nur eine OID Gruppe stehen die es auch gibt, blockieren. OID Gruppen die kein Gerät benutzt sind un wären im Gegensatz kein Problem.Aber im Prinzip kann man da über vieles reden (abgesehen v Punkt b der noch kommt). Mal schaun was da sonst noch als Feedback kommt.
b) Die derzeit verfügbare jsonConfig bietet - nach meinem Wissensstand - keine Dropdown Menues an die rein auf den Daten anderer Tabs basieren. Es gibt zwar - soweit ich wieß - die Möglichkeit Callbacks in den Adaptercode aufzurufen; nur das würde einen laufenden Adapter voraussetzen (was bei einer initialen Config nicht vorausgesetzt werden sollte) und andrerseits würde der Adapter wohl nur jede OID Grupen sehen die auch schon gespeichert sind. Kurz: Im Moment scheint diese Anforderung technisch mittels jsonConfig nicht trivial umsetzbar. Falls wer mehr dazu sagen kann, können wir das gerne diskutieren - im Moment möchte ich allerdings weitere Zeit primär in die Funktion (SNMP V2 / v3 / Iv6 / ...) stecken und nicht unbedingt in GUI. Muss aber sagen, dass ich kein GUI Entwickler bin und sicher kein React Plugin o.ä. mal so dazwischen schriebn könnte.
@amg_666 said in Test Adapter snmp V2.0.x:
Und dann noch eine Verständnisfrage: Wenn die OID Gruppe als Link zwischen dem Deviceeintrag und den verschiedenen IOD dient (habe ich verstanden
) wäre es dann nicht für Visualisierung o.ä. sinnvoll, die Gruppe auch in den Datenpunkten mit abzulegen?Ich bin da nicht sicher, ob ich den Wunsch richtig interpretiere:
Im Prinzip soll der Adapter seine Configdaten (oder einen Teil, hier die OID Gruppe) auch als Datenpunkt anbieten? Also z.B. als snmp.o.config.oid-group mit Wert Drucker_Buero. Hab ich das richtig verstanden?Technisch ginge das sicher. Man / ich müsste dazu aber zuerst mal die "alten Hasen" (= ioBroker Kernentwickler) fragen ob das gewunschen wäre. Und ob es nicht sowieso eine triviale Möglichkeit gibt. die Config abzufragen. Wir sollten ja nicht unbedingt Unmengen an Datenpunkten generieren die nur selten gebraucht werden. Neben der OID Gruppe gibts da ja dann gleich noch die diversen Timer und die snmp Version und, und und ...
Wie gesagt - technisch sicher machbar. Ich wart mal ob dazu Feedback kommt. Schreib ggF einen issue dazu wenn es dir wichtig ist. Versprechen möcht uch aber nichts.
-
@amg_666
Ich hab mal im dDeveloper Kreis nachgefragt. An sich gibt es derzeit keine standardisierte Zugriffsvariante auf die Konfigdaten via DPs.Bitte daher falls der Wunsch nach einem (teilweisen) duplizieren der Konfigdaten stark ist um einen PR (Featurerequest) auf Github. Ich würde dann mal abwarten ob da mehr als ein Einzelinteresse (= Votes, Kommentare, ...) besteht. Bitte auch den Use Case möglichst klar beschreiben.
Versprechen möchte ich allerdings eine Umsetzung nicht.
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer Danke sagen will, kann nen Kaffee spendieren: https://paypal.me/mcm1957atiobroker
-
@amg_666
Ich hab mal im dDeveloper Kreis nachgefragt. An sich gibt es derzeit keine standardisierte Zugriffsvariante auf die Konfigdaten via DPs.Bitte daher falls der Wunsch nach einem (teilweisen) duplizieren der Konfigdaten stark ist um einen PR (Featurerequest) auf Github. Ich würde dann mal abwarten ob da mehr als ein Einzelinteresse (= Votes, Kommentare, ...) besteht. Bitte auch den Use Case möglichst klar beschreiben.
Versprechen möchte ich allerdings eine Umsetzung nicht.
@mcm57 falls du mal Langeweile hast ... ein Feature welchen die Werte nachbehandelt wäre "nett"
=> Ich über wache am Switch den Port der FritzBox um Up- und Download zu ermitteln. Den Wert den der Switch liefert muss ich immer nacharbeiten:
Rechnet den Downloadwert in Bit/s und MBit/s um.
Ok, vorheriger Wert ist fies ... aber mal, geteilt etc wäre nett. Oder einige HP-Switche liefern die Temperatur als
24Cfür 24 Grad, also Zeichen abschneiden wäre nett damit man das im Datenpunkt als Zahl speichern kann usw.Dann müsste man aber auch auswählen können welchen Typ er speichern soll, ich sehe gerade das er wohl immer String nimmt? Ist schlecht für den History oder SQL Adapter.
Also nur wenn du mal Langeweile hast ... kriegt man ja auch alles so in ioBroker gelöst ...
ioBroker@Ubuntu 24.04 LTS (VMware) für: >260 Geräte, 5 Switche, 7 AP, 9 IP-Cam, 1 NAS 42TB, 1 ESXi 15TB, 4 Proxmox 1TB, 1 Hyper-V 44TB, 14 x Echo, 5x FireTV, 5 x Tablett/Handy VIS || >=157 Tasmota/Shelly || >=88 ZigBee || PV 8.1kW / Akku 14kWh || 2x USV 900/750W kaskadiert || Creality CR-10 SE 3D-Drucker
-
@mcm57 falls du mal Langeweile hast ... ein Feature welchen die Werte nachbehandelt wäre "nett"
=> Ich über wache am Switch den Port der FritzBox um Up- und Download zu ermitteln. Den Wert den der Switch liefert muss ich immer nacharbeiten:Rechnet den Downloadwert in Bit/s und MBit/s um.
Ok, vorheriger Wert ist fies ... aber mal, geteilt etc wäre nett. Oder einige HP-Switche liefern die Temperatur als
24Cfür 24 Grad, also Zeichen abschneiden wäre nett damit man das im Datenpunkt als Zahl speichern kann usw.Dann müsste man aber auch auswählen können welchen Typ er speichern soll, ich sehe gerade das er wohl immer String nimmt? Ist schlecht für den History oder SQL Adapter.
Also nur wenn du mal Langeweile hast ... kriegt man ja auch alles so in ioBroker gelöst ...
@bananajoe
Danke f.d. Anregung.Ich sehe es aber nicht als Aufgabe des Adapters hier Umrechnungen durchzuführen. Der snmp Adapter sollte die Werte so ablegen wie sie das jeweilige Gerät liefert. Umrechnungen oder Manipulationen sollten entweder via javascript/blockly oder im Bereich der Anzeige (vis) erfolgen.
Bezüglich Datentyp bin ich offen. Da kann man überlegen bzw. überleg ich eh grad(*). Problematisch ist hier nur, dass die DPs (zumindest derzeit) bereits beim Start angelegt werden. Und den Typ bekommt der Adapter erst nach der ersten (erfolgreichen) Abfrage. Dne Datentyp in der Config eintragen zu lassen - ich glaub da lös ich keine Jubelschreie aus, weil die OID Konfiguration sowieso schon soooo lang ist.
McM
(*) Support für Counter64 ist in Arbeit und da muss sowieso eine extra Bearbetung rein weil toString auf das return value des net-snmp nicht funktioniert.
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer Danke sagen will, kann nen Kaffee spendieren: https://paypal.me/mcm1957atiobroker
-
@bananajoe
Danke f.d. Anregung.Ich sehe es aber nicht als Aufgabe des Adapters hier Umrechnungen durchzuführen. Der snmp Adapter sollte die Werte so ablegen wie sie das jeweilige Gerät liefert. Umrechnungen oder Manipulationen sollten entweder via javascript/blockly oder im Bereich der Anzeige (vis) erfolgen.
Bezüglich Datentyp bin ich offen. Da kann man überlegen bzw. überleg ich eh grad(*). Problematisch ist hier nur, dass die DPs (zumindest derzeit) bereits beim Start angelegt werden. Und den Typ bekommt der Adapter erst nach der ersten (erfolgreichen) Abfrage. Dne Datentyp in der Config eintragen zu lassen - ich glaub da lös ich keine Jubelschreie aus, weil die OID Konfiguration sowieso schon soooo lang ist.
McM
(*) Support für Counter64 ist in Arbeit und da muss sowieso eine extra Bearbetung rein weil toString auf das return value des net-snmp nicht funktioniert.
Version 2.1.0 wurde released (Github / Latest)
Test Thread: https://forum.iobroker.net/topic/56816/test-adapter-snmp-v2-1-x-github-lastest
McM
Support us
638
Online32.4k
Users81.4k
Topics1.3m
Posts