NEWS
Test Adapter snmp V2.0.x
-
Aktuelle Test Version 2.0.1 Veröffentlichungsdatum 22.7.2022 Github Link https://github.com/iobroker-community-adapters/ioBroker.snmp Hier Adapter Beschreibung, Changelog etc.
Ich habe wie in anderen Topics erwähnt den snmp Adapter überarbeitet und nunmehr als 2.0.0 im latest zum Test released.
ACHTUNG
Vor einem Upgrade bitte UNBEDINGT eure Konfiguration sichern damit ein Rückstieg auf die stable 1.0.0 im Bedarfsfall möglich ist!Was ist neu / geändert:
Primär verweise ich dazu auf README.md im Git Repo; dort sollte alles stehen.Hier nochmal in deutsch:
Der Code wurde zu einem guten Teil neu geschrieben und von callback auf awaits umgestellt.
Die Config wurde grundlegend geändert und mit jsonConfig umgesetzt. Admin V5 ist daher zwingend erforderlich.
Unterschiedliche Devices können nun unterschiedliche Timer erhalten
Ein paar Bugs wurden behoben.
Im Kern ist die 2.0.0 mal die Umstellung auf die neue Config. Weitere Überarbeitungen (snmpv2, snmpv3, IPv6, ... sind in Planung und kommen sobald mal der 2.0.0 Code keinen Mega Aufschrei wegen noch nicht entdeckte Probleme auslöst. Ob die 2.0.0 in stable kommt oder erst 2.1.x ... kann ich derzeit noch nicht sagen.
Bei der Installation sollte die gesamte existierende Konfiguration migriert werden. Dabei werden die OIDs in Gruppen zusammengefasst. Jedem Device wird dann eine solche OID Gruppe zugewiesen. I Zukunft kann man dann z.B. eine OID Gruppe NetgearSwitch oder SynoNas machen und mehreren Geräten diese Gruppe zuweisen um z.B. die oids meherer (fast) identer Geräte abzufragen.
Bitte um Rückmeldung hier und ggF Issue direkt im Repo.
DANKE an alle die die neue Version probieren wollen. Aber bitte wie schon oben geschrieben:
NUR MIT BACKUP DER CONFIG oder auf einem Spiel-/Testsystem upgraden -
@mcm57 sagte in Test Adapter snmp V2.0.0:
ACHTUNG
Vor einem Upgrade bitte UNBEDINGT eure Konfiguration sichern damit ein Rückstieg auf die stable 1.0.0 im Bedarfsfall möglich ist!Wo und Wie?
Edit:
Hab einfach drüber installiert, habe ja nicht so viele.
Mit neuer Version ist jetzt auch ein Export der Json möglich. -
gelöscht
-
@sigi234
Mit Sichern meinte ich:Expert Modus
Objekte - System - Adapter - snmp - instanz (z.B. 0)
dort den Bleistift anklicken und den Json Objektbaum in ein Textfile sichern.Wichtig ist der Bereich native
Wenn du auf 1.0.0 zurücksteigen willst / musst, musst du
-) den snmp Adapter deinstallieren
-) die version 1.0.0 installieren
-) ggf weitere Instanzen als 0 anlegen
-) Unter Objekte den gesicherten Native Bereich reinkopieren und abspeichern.
Damit hast du wieder deine alte Config drinnen -
@sigi234 said in Test Adapter snmp V2.0.0:
Mit neuer Version ist jetzt auch ein Export der Json möglich.
Ich vermute mal dass soll eine Frage sein.
Im SNMP Adapetr selbst ist kein Export dazu gekommen. Das steht noch auf der Wunschliste.
Wie im letzen Post beschrieben kannst du aber die Konfig via system Object exportieren und daher prinzipiell auch eine extern zusammenstellen und importieren. Das ist aber nicht snmp spezifischNachtrag:
Hat die Migration bei dir zufriedenstellend funktioniert? Zumindest soweit du das nach ein paar Minuten sagen kannst -
@mcm57 sagte in Test Adapter snmp V2.0.0:
@sigi234 said in Test Adapter snmp V2.0.0:
Nachtrag:
Hat die Migration bei dir zufriedenstellend funktioniert? Zumindest soweit du das nach ein paar Minuten sagen kannstJa
-
Grad einen Fehler selbts gefunden - damit ihr nicht umsonst sucht post ich das mal da:
Wenn eine Instanz nicht online geht (grün wird) kann es sein, dass eine oid ungültig ist. Die entsprechende Meldung kommt aber nur wenn ihr logging auf debug gestellt habt. (= falsche Severity der Meldung)
https://github.com/iobroker-community-adapters/ioBroker.snmp/issues/134
Sorry
-
@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? -
@bommel_030
Jupp, bei mir ist es auch so -
@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 !
-
Sorry
Grad gesehen dass du eh einen Gerätenamen vergeben hast. Damit sollte es gehren.Bin z.z. offline. Check das am Abend u geb Bescheid.
-
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.
-
@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)
-
@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.
-
@mcm57
Danke, jetzt kommt der Name statt der IP Adresse -
-
@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
24C
fü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.