Test Adapter snmp V2.0.x
-
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
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.
-
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
