USV per SNMP auslesen

[Homoran]

@jb_sullivan was bitte hat das mit dem Thread (NUT Adapter) zu tun?

[Holger Etzel]

@jb_sullivan
DIe Werte kommen doch alle über den NUT-Adapter ?

[JB_Sullivan]

@holger-etzel Nein über den SNMP Adapter - ich dachte das es da Ähnlichkeiten gibt weil du oben in Beitrag #52 auch über OID`s gesprochen hast, die ebenfalls im SNMP Adapter eingegeben werden müssen.

Das zweite Problem sind die Werte die ausgegeben werden. Mal passen sie, mal wird nicht alles dargestellt - Also auf der Webinterface Seite der USV z.b. 236,7V in ioB sind es dann nur 236V oder im Webinterface 5,5A in ioB 55A.

Kennst du dich damit aus? (auch wenn es hier ein NUT Thread ist)

[Homoran]

@jb_sullivan sagte in USV per SNMP auslesen:

(auch wenn es hier ein NUT Thread ist)

ich habe es mal abgespalten, damit es passt

[Holger Etzel]

@jb_sullivan
bin da auch kein Profi.

DIe OID´s habe ich von der APC-Seite. Die OID´s sind soweit mögliche Werte, so wie ich es verstanden habe. Ob diese aber bei deiner USV zur Verfügung stehen kann ich nicht beurteilen,
Für meine USV habe ich kein Web-Interface, deshalb nehme ich die Werte vom NUT-Adapter

[JB_Sullivan]

@holger-etzel

Ich habe mich mal in das Thema eingelesen und habe über einen MIB Browser alle Werte ausgelesen, welche die USV auch ausgeben KANN. Mit anderen Worten, das sind keine willkürlichen OID`s, sondern sind welche die es auch tatsächlich gibt.

Wie ich oben schongeschrieben habe, bekomme ich bei extrem vielen dieser Werte ein Error session.get: RequestFailedError: TooBig als LOG Eintrag zurück - mit anderen Worten, obwohl das OID einen Wert liefern würde, legt der SNMP Adapter kein Datenpunkt Objekt an - eben wegen jener Fehlermeldung.

Das was der MIB Browser liefert, schau dann z.B. so aus. Ist also mit realen und aktuellen Werten aus der USV gefüllt. Oben in der Kopfzeile gibt es dann das entsprechende OID zu dem Eintrag, welcher aber vom SMNP Adapter oftmals scheinbar nicht interpretiert werden kann.

Ist halt die Frage, wer von dem Thema Ahnung haben könnte. Auf GIT sind @Bluefox und @apollon77 zumindest in der ChangeLog History aufgeführt. Ob der Fehler überhaupt von dem Adapter kommt, vermag ich z.B. überhaupt nicht zu sagen.

Du hast da auch keine Ahnung davon - oder?

[mickym]

@jb_sullivan Ich habe auch erst mit dem SNMP Adapter versucht und habe dann Fehlermeldungen bekommen beim Auslesen, deswegen bin ich auf die NodeRed Nodes ausgewichen, da das für mich sowieso die präferierte Logikmaschine unter iobroker ist. Das der Fehler meines Erachtens vom Adapter kommt ist doch ersichtlich. Glaube nicht, dass wenn snmp.0 vorne dran steht, dass das woanders her kommt. Wenn die OID nicht direkt dem Wert entspricht - der Adapter kann nicht "walken" - insofern ist der Request Too Big weil die OID ggf. eine Menge untergeordneter OIDs hat.
Sieht ja so aus, als ob Deine Abfrage das Ergebnis mit allen untergeordneten Werten ist.

Der Adapter kommt auch nicht mit Tabellen zu recht.

Abgeschreckt hat mich aber auch, dass der SNMP Adapter seit 3 Jahren nicht mehr gepflegt wurde:

und deshalb wollte ich nicht warten. Auch auf GitHub wenn man sich die Issues anschaut, dann kann man da nicht von Aktivität sprechen.

Wenn Du NodeRed nutzen kannst, kann ich nur sagen, dass diese gut funktionieren. Und wenn Du Dich damit nicht beschäftigen willst, dann lass NodeRed Dir alle Datenpunkte in den iobroker schreiben.

[JB_Sullivan]

@mickym Ich sage mal so, ca. 90% der Werte die mir wichtig sind, bekomme ich ja schon. Was ich aber nicht verstehe sind so Sachen wie die beiden blau markierten Datenpunkte.

Es sind beides OID`s die die Werte im gleichen Datumsformat bereitstellen. Das Herstellungsdatum kann der SNMP Adapter darstellen, das Datum des letzten Akku Wechsel, wird mit dem "TooBig" Fehler beantwortet.

[mickym]

@jb_sullivan

Ich kann es Dir nicht beantworten - ich dachte es liegt an dem Buffer und dem Octet String - hab den Adapter bei mir gerade nochmal installiert und dieses Mal gab er das problemlos aus. Daran liegt es aber nicht.

Der Adapter ist für mich aber trotzdem unbrauchbar.

Hier mal die Tabelle der Tintenpatronen:
Die ersten 3 Werte gibt er mir aus:

Wenn man sich die Ausgaben mit der OID ansiehst ist das wie folgt:

Die Objekt Id ermittle ich ganz einfach:

die steht ja unten drunter .

Wenn ich nun den SNMP Adapter wie folgt konfiguriere:

Man sieht das funktioniert auch wunderbar und die Datenpunkte werden auch aktualisiert:

bis auf den Magenta Punkt - OK der ist nicht aktiviert.

Aktiviere ich den Punkt - dann ist der Adapter wieder GRÜN - es gibt folgenden Eintrag im Log:

und es geht gar nichts mehr zu bzw. von diesem HOST:

Und das ist NUR ein Index weiter 0.4
Nur wie gesagt ich habe folgendes Problem und sowas mach ich nicht mehr mit:
Da denke ich nicht mal mehr darüber nach, ob der Fehler bei mir liegen könnte.
Was nützt mir wenn ich 75% der Füllstände bekomme ??? - So was fliegt bei mir sofort wieder raus. Insbesondere wenn der Adapter seit 3 Jahren nicht mehr gepflegt wurde und auch bei allen neuen Issues - nie ein Kommentar oder sonstwas kommt.

Du kannst ja ein Issue aufmachen - aber ich behaupte mal - es liegt nicht an DIR sondern an DEM Adapter.

Ich kann Dir nur die NodeRED SNMP Nodes empfehlen. Auch wenn Du Dich mit NodeRed sonst nicht beschäftigen willst, die können Dir einfach die fehlenden Werte in einen Datenpunkt schreiben und Du kannst sie nutzen!

[apollon77]

Hhmmm .... ein Adapter der tut und außer (nach kurzem Scan) einem Bug issue nur weitere feature requests und andere unkritische issues hat ist schlecht nur weil er 3 Jahre nicht mehr aktualisiert wurde?? Der Logik kann ich nicht so ganz folgen Leute.

Wenn ich frech bin als Entwickler sage ich: kein issue? Kein issue!

Mit so einer Einstellung von obigem Text steht Ihr euch selbst (und anderen Usern) im Weg. Schade.

Ingo

[JB_Sullivan]

@apollon77 Bitte keine Verallgemeinerungen "Ihr" und "Leute" - das ist die Meinung von mickym.

Ich bin der Meinung, wenn ein Adapter auch mehrere Jahre alt ist und er nur in der Version 0.2 vorliegt, aber das macht was er soll, dann hat der Entwickler gut gearbeitet und alle Eventualitäten schon bedacht - ist doch Super.

Wenn der Adapter aber aus nicht nachvollziehbaren Gründen (siehe das Beispiel oben mit den beiden Daten - eins funktioniert / eines nicht) Dinge nicht tut, die er an andere Stelle gemacht hat, dann muss es doch erlaubt sein, im Forum mal nach zu fragen ob sich einer damit auskennt und ggf. etwas zu der Ursache eines solchen Verhaltens sagen kann.

..... da braucht man nicht den Colt zücken und pauschal gegen alle User hier wild um sich schießen ....

[mickym]

@jb_sullivan Glaube das war auch mehr an mich adressiert. Wobei mich @apollon77 eigentlich soweit kennen müsste, das ich schon issues aufmache. Aber ich gebe zu, wenn es so gar nicht nachvollziehbar ist, dann gestaltet sich meist die Fehlersuche schwierig und da bin ich etwas sensibel. Das hat mich halt auch schon viel Zeit gekostet, weil man die Fehler immer erst bei sich sucht.

Also nehme gerne alles - was undankbar oder unverschämt klang zurück.

[apollon77]

@jb_sullivan sagte in USV per SNMP auslesen:

@apollon77 Bitte keine Verallgemeinerungen "Ihr" und "Leute" - das ist die Meinung von mickym.

fair enough Sollte nicht so rüberkommen

Macht Issues auf bitte. Der Fehler sieht mir so aus als ob diese snmp id inkorrekt ist ... ggf Debug log hilft vllt.

[mcm1957]

@apollon77
@JB_Sullivan

Hallo,
Nur mal zur Info.

Ich habe mir vor Kurzem den snmp Adapter vorgenommen. Zwischenzeitlich ist er Danke der Hilfe von @apollon77 als 1.0.0 im lastest Repo verfügbar. Gefixed wurde hier zunächst mal issues #73 (timeout bei abgeschalteten Geräten) und #14 (Leerzeichen im Namen).

Ich bin allerdings dran die anderen Bugs - soweit ich es schaffe - zu analysieren und zu beheben. Derzeit erfolgt eine Codeumstellung (weitestgehend ReWrite auf aktuelle sync/await Codestyle).

Bezüglich des hier beschriebenen Problems bitte ggF das existierende Issue #72 beachten.

Falls mir jemand sagen kann wie ich den Fehler ev. reproduzieren kann, wäre mir sehr geholfen. Anbieten kann ich als snmp Targets Drucker (Lexmark, Synology NAS, Netgear "Home" Switch (GS308T).

Und noch was - ich kann nichts versprechen. Ich möchte nur sagen, dass ich dran bin.

McM

[mcm1957]

Ich greife hier mal den alten Therad auf.

Zwischenzeitlich gibt es eine Version 2.0.1 des snmp Adapters. Diese steht im latest zur Verfügung. Allerdings wird diese das hier beschrieben Problem nict fixen.

Im Moment arbeite ich an einer Version 2.1.x. Diese unterstützt dann snmp v2c. Weiters hat diese im Bereich der Konvertierung der retournierten Daten einen Filter erhalten. Derzeit wird dort mal der Counter64 snmp Typ abgefangen und "zu Fuß" konvertiert, da die .toString() des net-snmp bei diesem Typ Schrott konvertiert. Zusätzlich loggt der Adapter (im Debug Mode) nun das gesammte retournierte Paket, d.h. Typ und Buffer. Damit sollte ev. auch das ToBig Problem eingegrenzt werden können.

Ich persönlich kann als snmp Quellen derzeit nur anbieten:
Synology NAS (DSM 6 und DSM 7), einen managed Netgear Switch sowie einen Lexmark Drucker.

Wenn möglich lasst mir bitte Infos zukommen welche OID GENAU das Problem auslöst. Dazu sollte unbedingt nur genau eine OID bei dem Gerät aktiv sein, da snmp v1 keine Unterscheidung liefert welche der OIDs das Problem hat.

Alternativ kann ich auch eine snmp v2.1.0-beta.x via Github zur Verfügung stellen. Die V2.1.0 via lastest wird noch ein wenig dauern, da ich noch mehr testen muss bevor ich sie auf "Opfer" loslassen kann bzw. will.

McM

Version 2.1.0-beta.1 gibts hier:
https://github.com/mcm1957/ioBroker.snmp/tree/v2.1.0-beta.1
ABER ACHTUNG - V2.1.0-beta.x ist mehr alpha denn beta. So bitte wirklich nur auf Spielwiesensystemen oder mit sehr gutem Backup und Erfahrung im Einspeilen des Backups installieren.

Falls wer riskiert 2.1.0-beta.x zu installieren und das ToBig Problem auslösen kann, bitte:
snmp v2c verwenden (V1 liefert keine Detailinfos)
logging auf debug stellen
so wenig oids wie notwendig enablen
und den log hier posten oder am Issue anhängen:
https://github.com/iobroker-community-adapters/ioBroker.snmp/issues/72

DANKE

JBSullivan created this issue in iobroker-community-adapters/ioBroker.snmp

closed Error session.get: RequestFailedError: TooBig #72

[mcm1957]

Release 2.1.0 wurde (auf Latest) released.

Siehe: https://forum.iobroker.net/topic/56816/test-adapter-snmp-v2-1-x-github-lastest

[JB_Sullivan]

Ich hoffe ich habe verstanden was du für Infos in welchem Zustand brauchst.

Hier mein Error Log von der Adapter Version 2.1 - einmal in der SNMP V1 Einstellung und einmal als V2c

Die beiden nicht aktivierten Einträge sind meine Problemkandidaten, welche immer ein Too Big ausgeben, wobei das Datum des letzten Selbsttest in den Objekt Daten einen Eintrag bekommen hat. Sobald ich den Eintrag jedoch aktiviere, wird der Adapter Gelb.

snmp.0
9540	2022-07-31 08:40:33.267	error	[10_122_60_87] session.get: RequestFailedError: TooBig

snmp.0
12232	2022-07-31 08:38:25.251	error	[10_122_60_87] session.get: RequestFailedError: AuthorizationError: 1.3.6.1.4.1.318.1.1.1.1.1.1.0

snmp.0
11468	2022-07-31 08:38:01.825	error	[10_122_60_87] session.get: RequestFailedError: AuthorizationError: 1.3.6.1.4.1.318.1.1.1.1.1.1.0

snmp.0
13948	2022-07-31 08:37:05.088	error	[10_122_60_87] session.get: RequestFailedError: AuthorizationError: 1.3.6.1.4.1.318.1.1.1.1.1.1.0

snmp.0
9924	2022-07-31 08:36:26.289	error	[10_122_60_87] session.get: RequestFailedError: TooBig

snmp.0
12368	2022-07-31 08:35:54.835	error	[10_122_60_87] session.get: RequestFailedError: TooBig

[mcm1957]

@jb_sullivan said in USV per SNMP auslesen:

snmp.0 9540 2022-07-31 08:40:33.267 error [10_122_60_87] session.get: RequestFailedError: TooBig

Danke für die Hilfe.
Leider hab ich mich zu unklar ausgedrückt. Wenn möglich, bitte den Test wiederholen u.zw. mit
SNMP V2c und DEBUG Protokollierung.

Bei aktiviertem Debug Logging kommt (hoffentlich ) für jede OID eine Detailmeldung was das net-snmp Api zurück gelifert hat. Hier als Beispiel der Output meines Druckers:

snmp.0
2022-07-31 11:07:07.669 debug [10_17_2_2] update 10_17_2_2.console.message.1: Not Ready

snmp.0
2022-07-31 11:07:07.668 debug [10_17_2_2] 10_17_2_2.console.message.1(OctetString){"oid":"1.3.6.1.2.1.43.16.5.1.2.1.1","type":4,"value":{"type":"Buffer","data":[78,111,116,32,82,101,97,100,121]}}

snmp.0
2022-07-31 11:07:07.667 debug processVarbind - [10_17_2_2] 10_17_2_2.console.message.1

Der mittlere Log listet den retournierten Buffer. Hier wäre es interessant was das snmp-api liefert damit allenfalls die Konvertierung korrigiert werden kann.

Leider kann ich nicht ausschließen, dass das smnp api (net-snmp im npm) gar keine Daten zurückliefert sondern nur den Fehler. Dann wirds "spannend" - sprich, dann müssten eigentlich die snmp Entwickler helfen. Wenn das aber mal klar ist, dann such ich mal ob es bei net-snmp irgendwas zu den Fehler gibt.

Wenn ich den Thread hier richtig lese spiest es sich bei den beiden Datums-OIDs. Richtig?
Ev. liegt das am Datumsformet (mm/dd/yy). Aber das ist ne reine Hypothese. Bitte mal testen, ob das Api an sich Werte liefert und die Konversion fehl schläg - oder ob schon vom Api nur mehr "Error" kommt..

DANKE
McM

[JB_Sullivan]

@mcm57 sagte in USV per SNMP auslesen:

Wenn ich den Thread hier richtig lese spiest es sich bei den beiden Datums-OIDs. Richtig?
Ev. liegt das am Datumsformet (mm/dd/yy). Aber das ist ne reine Hypothese. Bitte mal testen, ob das Api an sich Werte liefert und die Konversion fehl schläg - oder ob schon vom Api nur mehr "Error" kommt..

Also der eine Wert ( Akku gewechselt) geht auf meine Kappe - ich könnte aber schwören, das da damals ein Wert drin stand. Heute habe ich den MIB Browser nochmal bemüht und da stand dann "Unavailable".

Am Datumswert generell liegt es meiner Meinung nach auch nicht, da nur diese beiden hier Probleme mit "too Big" machen.

Der Wert des Herstellungsdatums, welcher ja genauso aufgebaut ist, aber einwandfrei ausgegeben wird.

Ich mache gleich nochmal ein Posting mit den DEBUG Meldungen fertig

[mcm1957]

Ich hätte da auch noch was gefunden:
https://community.helpsystems.com/forums/intermapper/snmp-probes/2f7f53db-fa83-e511-80cf-0050568460e4

Kann es sein, dass du mehr als 50 OIDs (e. auch nurmehr als 20 OIDs) abfrägst?
Kannst du bitte testweise NUR die kritischen OIDs abfragen (und alle anderen disablen)? Kommt da der Fehler noch immer?

Die Frage zielt nur mal auf die Eingrenzung des Problems. Wenn es an der Anzahl der OIDs liegt sollte / müsste das Splitting dann natürlich der Adapter machen.

McM