USV per SNMP auslesen
-
@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überkommenMacht Issues auf bitte. Der Fehler sieht mir so aus als ob diese snmp id inkorrekt ist ... ggf Debug log hilft vllt.
-
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
-
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/72DANKE
-
Release 2.1.0 wurde (auf Latest) released.
Siehe: https://forum.iobroker.net/topic/56816/test-adapter-snmp-v2-1-x-github-lastest
-
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 -
@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 Readysnmp.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.1Der 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 -
@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
-
Ich hätte da auch noch was gefunden:
https://community.helpsystems.com/forums/intermapper/snmp-probes/2f7f53db-fa83-e511-80cf-0050568460e4Kann 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
-
@mcm57
Hammer !!
Es sind genau 20 Werte. Wenn ich einen Wert disable - kommt kein Too Big mehr und die beiden Datumswerte der Problem OID`s werden in die Datenpunkte geschrieben.
Also scheint sich "Too Big", auf die einem Rutsch abgefragten OID`s zu beziehen. Schade das er alles was abgwählt ist mit "null" überschreibt. So Sachen wie eine Seriennummer, wird sich kaum ändern und könnte nach dem ersten auslesen wieder deaktiviert werden - wenn, tja wenn sie danach nicht "null" heißen würde.
Habe es eben nochmal getestet - nur 18 OID`s werden ohne Adapter Fehler in einem Rutsch ausgelesen.
-
@jb_sullivan
OK. DANKE mal fürs Testen.Warum der Wert NULL wird muss ich mir ansehen. An sich sollte das nur passieren, wenn beim Lesen eine Fehler auftritt. Bist du dir sicher, dass das null schon beim Abwählen auftritt?
Implementiert sein sollte:
-) Timeout Error
"alte Werte" bleiben aber Quality wird auf "timeout problem" gesetzt
-) Anderer Error
"null" wird eingetragen und Quality auf "error" gesetztMuss mir das aber nochmal ansehen. An sich wäre es aus meiner Sicht auch OK werte zu löschen deren OID nicht (mehr) gelesen werden. Aber das ist sicher nicht so im Code :-).
ICh werd mit deiner letzten Info jedenfalls versuchen das zu Problem zu reproduzieren und ev. eine Lösung im Adapter umzusetzen. Allerdings erfordert ein Splitten der Requests ein bisserl Codeumbau. Kann gut dein, dass das erst in der übernächte Release drinnen ist...
-
Ich habe nun v2.1.3 im latest zur Verfügung gestellt. Damit sollte auch das TOOBIG Problem gefixed sein.
Es gibt nun einen neuen Paramter (am Optionen Tab) mit dem eingestellt werden kann wieviele OIDs in einem Request maximal gesendet werden dürfen. Sollen mehr OIDs abgefragt werden, dann werden mehere Requests gesendet,
Da ich den Fehler bei meinen Sytemen (Synology NAS, Netgear smart Switch) NICHT reproduziren konnte (auch mehr als 50 OIDs waren da OK) würde ich dich höflich bitten die noch unstable Version zu testen - wenn du es mit deinen Kenntnissen / Backups verantworten kannst. Ich muss aber explizit drauf hinweisen, dass die 2.1.3 noch um latsest / unstable Zustand ist - ergo wenig gestestet und ein Einsatz auf produktiven Systemen ggF mit Risiko behaftet ist !
Bitte ggF um Feedback oder im Tester Thread
McM
-
@mcm57 sagte in USV per SNMP auslesen:
Ich habe nun v2.1.3 im latest zur Verfügung gestellt. Damit sollte auch das TOOBIG Problem gefixed sein.
Leider nicht bei mir
- In der neuen Einstellmöglichkeit habe ich 21 gewählt und 20 OID`s in der Liste markiert. Ging leider nicht - Siehe Fehlermeldung. Das gleiche passierte bei 20/20 , auch da blieb der Adapter rot- bei 20/19 wurde der Adapter wieder grün.snmp.0 13840 2022-08-07 18:23:33.805 warn Terminated (UNCAUGHT_EXCEPTION): Without reason snmp.0 13840 2022-08-07 18:23:33.804 info terminating snmp.0 13840 2022-08-07 18:23:33.573 error Cannot read property 'length' of undefined snmp.0 13840 2022-08-07 18:23:33.572 error TypeError: Cannot read property 'length' of undefined at Req.responseCb (C:\iobroker\GLT\node_modules\iobroker.snmp\main.js:634:52) at Req.Session.onSimpleGetResponse [as onResponse] (C:\iobroker\GLT\node_modules\net-snmp\index.js:2170:8) at Session.onMsg (C:\iobroker\GLT\node_modules\net-snmp\index.js:2153:7) at Socket.emit (events.js:315:20) at Socket.EventEmitter.emit (domain.js:467:12) at UDP.onMessage (dgram.js:919:8) snmp.0 13840 2022-08-07 18:23:33.572 error uncaught exception: Cannot read property 'length' of undefined snmp.0 13840 2022-08-07 18:23:33.492 info adapter initializing, chunk size set to 20 snmp.0 13840 2022-08-07 18:23:33.438 info starting. Version 2.1.3 in C:/iobroker/GLT/node_modules/iobroker.snmp, node: v14.16.0, js-controller: 4.0.23 -
@jb_sullivan
Na ja ... einen TOOBIG Fehler seh ich nicht mehr :-).Aber offensichtlich hat sich ein fehler eingeschlichen wenn das Chunklimit ind die Anzahl der oids (fast) ident ist (20/20).
Schau ich mir an.
-
Der Fehler wurde eingegrenzt und behoben. Der Absturz sollte unter folgenden Umständen auftreten:
-) snmp V1 verwendet
-) irgendeine Fehler ausgenommen Timeout tritt aufIch vermute mal, du hast SNMP v1 eingestellt und der Fehler TOOBIG trat auf.
Das Problem ist in 2.1.4 behoben. Die neue Release ist auf github und npm verfügbar und sollte ab ca 14:00 / 15:00 vom latest angeboten werden (- ev. manuelles Repo refresh auslösen, ich weiß nicht wie of der Admin die Listen ladet).
-
@mcm57
Leider immer noch/wieder "Too Big" bei 20/20 unter v1Hier das vollständige Debug Log
snmp.0 10588 2022-08-08 14:13:03.621 debug [10_122_60_87] processing oid chunk index 0 completed snmp.0 10588 2022-08-08 14:13:03.620 debug [10_122_60_87] session.get: RequestFailedError: TooBig snmp.0 10588 2022-08-08 14:13:03.619 debug [10_122_60_87] session.get completed for chunk index 0 snmp.0 10588 2022-08-08 14:13:03.615 debug readChunkOIDs - device "10_122_60_87" (10.122.60.87), chunk idx 0 snmp.0 10588 2022-08-08 14:13:03.614 debug [10_122_60_87] processing oid chunk index 0 snmp.0 10588 2022-08-08 14:13:03.614 debug readOIDs - device "10_122_60_87" (10.122.60.87) snmp.0 10588 2022-08-08 14:12:53.648 debug handleConnectionInfo snmp.0 10588 2022-08-08 14:12:53.647 debug handleConnectionInfo snmp.0 10588 2022-08-08 14:12:53.642 debug [10_122_60_87] processing oid chunk index 0 completed snmp.0 10588 2022-08-08 14:12:53.642 info [10_122_60_87] device disconnected snmp.0 10588 2022-08-08 14:12:53.641 error [10_122_60_87] session.get: RequestFailedError: TooBig snmp.0 10588 2022-08-08 14:12:53.639 debug [10_122_60_87] session.get: RequestFailedError: TooBig snmp.0 10588 2022-08-08 14:12:53.638 debug [10_122_60_87] session.get completed for chunk index 0 snmp.0 10588 2022-08-08 14:12:53.627 debug startup completed snmp.0 10588 2022-08-08 14:12:53.626 debug startconnection info updater snmp.0 10588 2022-08-08 14:12:53.625 debug session for device "10_122_60_87" (10.122.60.87) created snmp.0 10588 2022-08-08 14:12:53.616 debug readChunkOIDs - device "10_122_60_87" (10.122.60.87), chunk idx 0 snmp.0 10588 2022-08-08 14:12:53.615 debug [10_122_60_87] processing oid chunk index 0 snmp.0 10588 2022-08-08 14:12:53.614 debug readOIDs - device "10_122_60_87" (10.122.60.87) snmp.0 10588 2022-08-08 14:12:53.610 debug createSession - device 10_122_60_87 (10.122.60.87) snmp.0 10588 2022-08-08 14:12:53.609 debug starting reader threads snmp.0 10588 2022-08-08 14:12:53.609 debug initialization completed snmp.0 10588 2022-08-08 14:12:53.595 debug initobject 10_122_60_87.Datum_Kalibrierung snmp.0 10588 2022-08-08 14:12:53.595 debug initOidObjects (10_122_60_87.Datum_Kalibrierung) snmp.0 10588 2022-08-08 14:12:53.586 debug initobject 10_122_60_87.Kommunikation_USV snmp.0 10588 2022-08-08 14:12:53.586 debug initOidObjects (10_122_60_87.Kommunikation_USV) snmp.0 10588 2022-08-08 14:12:53.573 debug initobject 10_122_60_87.Datum_letzter_Selbsttest snmp.0 10588 2022-08-08 14:12:53.573 debug initOidObjects (10_122_60_87.Datum_letzter_Selbsttest) snmp.0 10588 2022-08-08 14:12:53.567 debug initobject 10_122_60_87.Selbsttest_Resultat snmp.0 10588 2022-08-08 14:12:53.566 debug initOidObjects (10_122_60_87.Selbsttest_Resultat) snmp.0 10588 2022-08-08 14:12:53.561 debug initobject 10_122_60_87.Ausgangsstrom snmp.0 10588 2022-08-08 14:12:53.561 debug initOidObjects (10_122_60_87.Ausgangsstrom) snmp.0 10588 2022-08-08 14:12:53.528 debug initobject 10_122_60_87.Angeschlossene_Last snmp.0 10588 2022-08-08 14:12:53.528 debug initOidObjects (10_122_60_87.Angeschlossene_Last) snmp.0 10588 2022-08-08 14:12:53.516 debug initobject 10_122_60_87.Ausgangs_Frequenz snmp.0 10588 2022-08-08 14:12:53.515 debug initOidObjects (10_122_60_87.Ausgangs_Frequenz) snmp.0 10588 2022-08-08 14:12:53.422 debug initobject 10_122_60_87.Ausgangs_Spannung_AC snmp.0 10588 2022-08-08 14:12:53.421 debug initOidObjects (10_122_60_87.Ausgangs_Spannung_AC) snmp.0 10588 2022-08-08 14:12:53.390 debug initobject 10_122_60_87.Selbsttest_Resultat snmp.0 10588 2022-08-08 14:12:53.389 debug initOidObjects (10_122_60_87.Selbsttest_Resultat) snmp.0 10588 2022-08-08 14:12:53.351 debug initobject 10_122_60_87.Eingangs_Frequenz snmp.0 10588 2022-08-08 14:12:53.351 debug initOidObjects (10_122_60_87.Eingangs_Frequenz) snmp.0 10588 2022-08-08 14:12:53.346 debug initobject 10_122_60_87.Eingangs_Spannung_AC snmp.0 10588 2022-08-08 14:12:53.345 debug initOidObjects (10_122_60_87.Eingangs_Spannung_AC) snmp.0 10588 2022-08-08 14:12:53.337 debug initobject 10_122_60_87.Ausgangs_Spannung_DC snmp.0 10588 2022-08-08 14:12:53.337 debug initOidObjects (10_122_60_87.Ausgangs_Spannung_DC) snmp.0 10588 2022-08-08 14:12:53.326 debug initobject 10_122_60_87.Akku_Status_(1_OK)_(2_NG) snmp.0 10588 2022-08-08 14:12:53.326 debug initOidObjects (10_122_60_87.Akku_Status_(1_OK)_(2_NG)) snmp.0 10588 2022-08-08 14:12:53.312 debug initobject 10_122_60_87.Autonomie_Zeit snmp.0 10588 2022-08-08 14:12:53.311 debug initOidObjects (10_122_60_87.Autonomie_Zeit) snmp.0 10588 2022-08-08 14:12:53.309 debug initobject 10_122_60_87.Akku_Kapazität snmp.0 10588 2022-08-08 14:12:53.308 debug initOidObjects (10_122_60_87.Akku_Kapazität) snmp.0 10588 2022-08-08 14:12:53.300 debug initobject 10_122_60_87.Akku_Temperatur snmp.0 10588 2022-08-08 14:12:53.300 debug initOidObjects (10_122_60_87.Akku_Temperatur) snmp.0 10588 2022-08-08 14:12:53.295 debug initobject 10_122_60_87.Seriennummer snmp.0 10588 2022-08-08 14:12:53.295 debug initOidObjects (10_122_60_87.Seriennummer) snmp.0 10588 2022-08-08 14:12:53.289 debug initobject 10_122_60_87.Herstellungs_Datum_USV snmp.0 10588 2022-08-08 14:12:53.288 debug initOidObjects (10_122_60_87.Herstellungs_Datum_USV) snmp.0 10588 2022-08-08 14:12:53.283 debug initobject 10_122_60_87.Firmware_Version snmp.0 10588 2022-08-08 14:12:53.282 debug initOidObjects (10_122_60_87.Firmware_Version) snmp.0 10588 2022-08-08 14:12:53.278 debug initobject 10_122_60_87.USV_Version snmp.0 10588 2022-08-08 14:12:53.277 debug initOidObjects (10_122_60_87.USV_Version) snmp.0 10588 2022-08-08 14:12:53.272 debug initobject 10_122_60_87.online snmp.0 10588 2022-08-08 14:12:53.255 debug initobject 10_122_60_87 snmp.0 10588 2022-08-08 14:12:53.254 debug initdeviceObjects (10_122_60_87/10.122.60.87) snmp.0 10588 2022-08-08 14:12:53.253 debug initAllObjects - initializing objects snmp.0 10588 2022-08-08 14:12:53.252 debug oid "1.3.6.1.4.1.318.1.1.1.7.2.7.0" (10_122_60_87.Datum_Kalibrierung) snmp.0 10588 2022-08-08 14:12:53.252 debug oid "1.3.6.1.4.1.318.1.1.1.8.1.0" (10_122_60_87.Kommunikation_USV) snmp.0 10588 2022-08-08 14:12:53.252 debug oid "1.3.6.1.4.1.318.1.1.1.7.2.4.0" (10_122_60_87.Datum_letzter_Selbsttest) snmp.0 10588 2022-08-08 14:12:53.251 debug oid "1.3.6.1.4.1.318.1.1.1.7.2.3.0" (10_122_60_87.Selbsttest_Resultat) snmp.0 10588 2022-08-08 14:12:53.251 debug oid "1.3.6.1.4.1.318.1.1.1.4.2.4.0" (10_122_60_87.Ausgangsstrom) snmp.0 10588 2022-08-08 14:12:53.250 debug oid "1.3.6.1.4.1.318.1.1.1.4.2.3.0" (10_122_60_87.Angeschlossene_Last) snmp.0 10588 2022-08-08 14:12:53.250 debug oid "1.3.6.1.4.1.318.1.1.1.4.2.2.0" (10_122_60_87.Ausgangs_Frequenz) snmp.0 10588 2022-08-08 14:12:53.250 debug oid "1.3.6.1.4.1.318.1.1.1.4.2.1.0" (10_122_60_87.Ausgangs_Spannung_AC) snmp.0 10588 2022-08-08 14:12:53.249 debug oid "1.3.6.1.4.1.318.1.1.1.7.2.3.0" (10_122_60_87.Selbsttest_Resultat) snmp.0 10588 2022-08-08 14:12:53.249 debug oid "1.3.6.1.4.1.318.1.1.1.3.2.4.0" (10_122_60_87.Eingangs_Frequenz) snmp.0 10588 2022-08-08 14:12:53.248 debug oid "1.3.6.1.4.1.318.1.1.1.3.2.1.0" (10_122_60_87.Eingangs_Spannung_AC) snmp.0 10588 2022-08-08 14:12:53.248 debug oid "1.3.6.1.4.1.318.1.1.1.2.2.8.0" (10_122_60_87.Ausgangs_Spannung_DC) snmp.0 10588 2022-08-08 14:12:53.248 debug oid "1.3.6.1.4.1.318.1.1.1.2.2.4.0" (10_122_60_87.Akku_Status_(1_OK)_(2_NG)) snmp.0 10588 2022-08-08 14:12:53.247 debug oid "1.3.6.1.4.1.318.1.1.1.2.2.3.0" (10_122_60_87.Autonomie_Zeit) snmp.0 10588 2022-08-08 14:12:53.247 debug oid "1.3.6.1.4.1.318.1.1.1.2.2.1.0" (10_122_60_87.Akku_Kapazität) snmp.0 10588 2022-08-08 14:12:53.246 debug oid "1.3.6.1.4.1.318.1.1.1.2.2.2.0" (10_122_60_87.Akku_Temperatur) snmp.0 10588 2022-08-08 14:12:53.246 debug oid "1.3.6.1.4.1.318.1.1.1.1.2.3.0" (10_122_60_87.Seriennummer) snmp.0 10588 2022-08-08 14:12:53.246 debug oid "1.3.6.1.4.1.318.1.1.1.1.2.2.0" (10_122_60_87.Herstellungs_Datum_USV) snmp.0 10588 2022-08-08 14:12:53.245 debug oid "1.3.6.1.4.1.318.1.1.1.1.2.1.0" (10_122_60_87.Firmware_Version) snmp.0 10588 2022-08-08 14:12:53.245 debug oid "1.3.6.1.4.1.318.1.1.1.1.1.1.0" (10_122_60_87.USV_Version) snmp.0 10588 2022-08-08 14:12:53.244 debug oid chunk index 0 created snmp.0 10588 2022-08-08 14:12:53.243 debug adding device "10.122.60.87" (10_122_60_87) snmp.0 10588 2022-08-08 14:12:53.242 debug setupContices - initializing contices snmp.0 10588 2022-08-08 14:12:53.241 info adapter initializing, chunk size set to 20 snmp.0 10588 2022-08-08 14:12:53.241 debug validateConfig - validation completed (checks passed) snmp.0 10588 2022-08-08 14:12:53.240 debug validateConfig - verifying devices snmp.0 10588 2022-08-08 14:12:53.240 debug validateConfig - verifying authorization data snmp.0 10588 2022-08-08 14:12:53.238 debug validateConfig - verifying oid-sets snmp.0 10588 2022-08-08 14:12:53.186 debug onReady triggered snmp.0 10588 2022-08-08 14:12:53.165 info starting. Version 2.1.4 (non-npm: iobroker-community-adapters/ioBroker.snmp) in C:/iobroker/GLT/node_modules/iobroker.snmp, node: v14.16.0, js-controller: 4.0.23 snmp.0 10588 2022-08-08 14:12:52.690 debug Plugin sentry Initialize Plugin (enabled=true) snmp.0 10588 2022-08-08 14:12:52.344 debug States connected to redis: 127.0.0.1:9000 snmp.0 10588 2022-08-08 14:12:52.278 debug States create User PubSub Client snmp.0 10588 2022-08-08 14:12:52.277 debug States create System PubSub Client snmp.0 10588 2022-08-08 14:12:52.245 debug Redis States: Use Redis connection: 127.0.0.1:9000 snmp.0 10588 2022-08-08 14:12:52.202 debug Objects connected to redis: 127.0.0.1:9001 snmp.0 10588 2022-08-08 14:12:52.188 debug Objects client initialize lua scripts snmp.0 10588 2022-08-08 14:12:52.065 debug Objects create User PubSub Client snmp.0 10588 2022-08-08 14:12:52.064 debug Objects create System PubSub Client snmp.0 10588 2022-08-08 14:12:52.061 debug Objects client ready ... initialize now snmp.0 10588 2022-08-08 14:12:51.958 debug Redis Objects: Use Redis connection: 127.0.0.1:9001 host.GLTGLT) 2022-08-08 14:12:50.043 info host.GLT(GLT) instance system.adapter.snmp.0 started with pid 10588 -
@jb_sullivan
Wieviele OIDs hast du insgesamt eingetragen / aktiviert? - OK steht eh im Log, 20 OIDs insgesammt eingetragen und Paketgröße auf 20.Bist du sicher. dass 20 OIDs gehen? Oder das 20 OIDs gerade nicht mehr gehen?
Kannst du bitte mit Paketgröße 19 oder ev. 15 testen? Geht das?
Ev sind 20 OIDs einfach zu viel. Es kommt - wenn ich das richtig verstenden habe - auf des Gerät an wieviel Buffer es hat. Kann daher durchaus auch sein, dass 20 OIDs mal gehen und mal nicht wenn sich die Größe des Inhalts der OIDs ändert. -
@mcm57
Ich habe genau 20 OID`s. Mit 20 geht es gerade NICHT mehr - mit 19 geht es (Seriennummer deaktiviert)
Wie gesagt, ich könnte damit leben wenn man z.B. Daten die man in der Regel nur 1x ausliest (wie die Seriennummer) im Datenpunkt erhalten bliebe wenn man den OID im Nachgang abwählt.
Wie du aber bei mir an der Seriennummer sehen kannst wir der DP Wert nach der Abwahl des OID auch gelöscht, bzw. auf null gesetzt.
Hier am Beispiel der Seriennummer
-
@jb_sullivan
Wenn es mit 20 nicht geht, dann ist es klar (und erwartet) dass du nen Fehler bekommt.Bitte stell den Parameter Paketgröße auf 19 (oder kleiner).
Dann solltest du durchaus alle 20 OIDs enabled haben können und alle OIDs die enabled sind sollten auch ausgelesen werden - nur eben mit 2 getrennten Requests.Kannst du das bitte mal testen?
DankeNachtrag: Der Parameter stellt keine Paketgröße ein (das kann er nicht, da es um die Größe des Buffers am Gerät geht) sondenr defniiert nur, nach wievielen OIDs ein weiterer extra Reqeust geschickt wird.
-
@mcm57
OK, dann habe ich das offensichtlich missverstanden. Ich dachte wenn ich 20 OID`s abholen will, muss in der Instanz Einstellung auch mindestens 20 eingetragen sein.
So weit so gut. nun habe ich 19 eingetragen und alle 20 OID`s angeharkt. Der Adapter wird nun nach einem Neustart wieder grün ................... aber, die Datenpunkte füllen sich nicht mehr mit Werten und das Log wirft auch einen Fehler - alles bei grüner Instanz
BtW: Der einzige Datenpunkt der einen Wert hat, hat von ioB ein Ordner Symbol verpasst bekommen welches leer ist. Alle anderen DP`s haben Ordnersymbole mit kleinen Schlössern darin.
snmp.0 10264 2022-08-08 16:52:58.652 debug handleConnectionInfo snmp.0 10264 2022-08-08 16:52:58.636 debug info.connection set to true snmp.0 10264 2022-08-08 16:52:58.636 info instance connected to at least one device snmp.0 10264 2022-08-08 16:52:58.633 debug handleConnectionInfo snmp.0 10264 2022-08-08 16:52:58.632 debug [10_122_60_87] processing oid chunk index 1 completed snmp.0 10264 2022-08-08 16:52:58.632 debug [10_122_60_87] update 10_122_60_87.Datum_Kalibrierung: 7/23/22 snmp.0 10264 2022-08-08 16:52:58.632 debug [10_122_60_87] 10_122_60_87.Datum_Kalibrierung(OctetString){"oid":"1.3.6.1.4.1.318.1.1.1.7.2.7.0","type":4,"value":{"type":"Buffer","data":[55,47,50,51,47,50,50]}} snmp.0 10264 2022-08-08 16:52:58.631 debug processVarbind - [10_122_60_87] 10_122_60_87.Datum_Kalibrierung snmp.0 10264 2022-08-08 16:52:58.631 info [10_122_60_87] device (re)connected snmp.0 10264 2022-08-08 16:52:58.631 debug [10_122_60_87] session.get completed for chunk index 1 snmp.0 10264 2022-08-08 16:52:58.629 debug info.connection set to false snmp.0 10264 2022-08-08 16:52:58.629 info instance disconnected from all devices snmp.0 10264 2022-08-08 16:52:58.629 debug handleConnectionInfo snmp.0 10264 2022-08-08 16:52:58.627 debug readChunkOIDs - device "10_122_60_87" (10.122.60.87), chunk idx 1 snmp.0 10264 2022-08-08 16:52:58.626 debug [10_122_60_87] processing oid chunk index 1 snmp.0 10264 2022-08-08 16:52:58.626 debug [10_122_60_87] processing oid chunk index 0 completed snmp.0 10264 2022-08-08 16:52:58.626 info [10_122_60_87] device disconnected snmp.0 10264 2022-08-08 16:52:58.625 error [10_122_60_87] session.get: RequestFailedError: TooBig snmp.0 10264 2022-08-08 16:52:58.624 debug [10_122_60_87] session.get: RequestFailedError: TooBig snmp.0 10264 2022-08-08 16:52:58.624 debug [10_122_60_87] session.get completed for chunk index 0 snmp.0 10264 2022-08-08 16:52:58.621 debug readChunkOIDs - device "10_122_60_87" (10.122.60.87), chunk idx 0 snmp.0 10264 2022-08-08 16:52:58.621 debug [10_122_60_87] processing oid chunk index 0 snmp.0 10264 2022-08-08 16:52:58.620 debug readOIDs - device "10_122_60_87" (10.122.60.87) snmp.0 10264 2022-08-08 16:52:48.636 debug info.connection set to true snmp.0 10264 2022-08-08 16:52:48.635 info instance connected to at least one device snmp.0 10264 2022-08-08 16:52:48.635 debug handleConnectionInfo snmp.0 10264 2022-08-08 16:52:48.633 debug [10_122_60_87] processing oid chunk index 1 completed snmp.0 10264 2022-08-08 16:52:48.633 debug [10_122_60_87] update 10_122_60_87.Datum_Kalibrierung: 7/23/22 snmp.0 10264 2022-08-08 16:52:48.633 debug [10_122_60_87] 10_122_60_87.Datum_Kalibrierung(OctetString){"oid":"1.3.6.1.4.1.318.1.1.1.7.2.7.0","type":4,"value":{"type":"Buffer","data":[55,47,50,51,47,50,50]}} snmp.0 10264 2022-08-08 16:52:48.632 debug processVarbind - [10_122_60_87] 10_122_60_87.Datum_Kalibrierung snmp.0 10264 2022-08-08 16:52:48.632 info [10_122_60_87] device (re)connected snmp.0 10264 2022-08-08 16:52:48.632 debug [10_122_60_87] session.get completed for chunk index 1 snmp.0 10264 2022-08-08 16:52:48.630 debug info.connection set to false snmp.0 10264 2022-08-08 16:52:48.630 info instance disconnected from all devices snmp.0 10264 2022-08-08 16:52:48.630 debug handleConnectionInfo snmp.0 10264 2022-08-08 16:52:48.627 debug readChunkOIDs - device "10_122_60_87" (10.122.60.87), chunk idx 1 snmp.0 10264 2022-08-08 16:52:48.627 debug [10_122_60_87] processing oid chunk index 1 snmp.0 10264 2022-08-08 16:52:48.627 debug [10_122_60_87] processing oid chunk index 0 completed snmp.0 10264 2022-08-08 16:52:48.626 info [10_122_60_87] device disconnected snmp.0 10264 2022-08-08 16:52:48.626 error [10_122_60_87] session.get: RequestFailedError: TooBig snmp.0 10264 2022-08-08 16:52:48.625 debug [10_122_60_87] session.get: RequestFailedError: TooBig snmp.0 10264 2022-08-08 16:52:48.624 debug [10_122_60_87] session.get completed for chunk index 0 snmp.0 10264 2022-08-08 16:52:48.620 debug readChunkOIDs - device "10_122_60_87" (10.122.60.87), chunk idx 0 snmp.0 10264 2022-08-08 16:52:48.620 debug [10_122_60_87] processing oid chunk index 0 snmp.0 10264 2022-08-08 16:52:48.620 debug readOIDs - device "10_122_60_87" (10.122.60.87) mqtt.0 3624 2022-08-08 16:52:46.118 info Client [Poolsteuerung] connected with secret 1659970366118_6179 snmp.0 10264 2022-08-08 16:52:43.653 debug handleConnectionInfo snmp.0 10264 2022-08-08 16:52:38.644 debug info.connection set to true snmp.0 10264 2022-08-08 16:52:38.643 info instance connected to at least one device snmp.0 10264 2022-08-08 16:52:38.643 debug handleConnectionInfo snmp.0 10264 2022-08-08 16:52:38.641 debug [10_122_60_87] processing oid chunk index 1 completed snmp.0 10264 2022-08-08 16:52:38.641 debug [10_122_60_87] update 10_122_60_87.Datum_Kalibrierung: 7/23/22 snmp.0 10264 2022-08-08 16:52:38.641 debug [10_122_60_87] 10_122_60_87.Datum_Kalibrierung(OctetString){"oid":"1.3.6.1.4.1.318.1.1.1.7.2.7.0","type":4,"value":{"type":"Buffer","data":[55,47,50,51,47,50,50]}} snmp.0 10264 2022-08-08 16:52:38.640 debug processVarbind - [10_122_60_87] 10_122_60_87.Datum_Kalibrierung snmp.0 10264 2022-08-08 16:52:38.640 info [10_122_60_87] device (re)connected snmp.0 10264 2022-08-08 16:52:38.639 debug [10_122_60_87] session.get completed for chunk index 1 snmp.0 10264 2022-08-08 16:52:38.632 debug info.connection set to false snmp.0 10264 2022-08-08 16:52:38.631 info instance disconnected from all devices snmp.0 10264 2022-08-08 16:52:38.631 debug handleConnectionInfo snmp.0 10264 2022-08-08 16:52:38.627 debug readChunkOIDs - device "10_122_60_87" (10.122.60.87), chunk idx 1 snmp.0 10264 2022-08-08 16:52:38.627 debug [10_122_60_87] processing oid chunk index 1 snmp.0 10264 2022-08-08 16:52:38.627 debug [10_122_60_87] processing oid chunk index 0 completed snmp.0 10264 2022-08-08 16:52:38.626 info [10_122_60_87] device disconnected snmp.0 10264 2022-08-08 16:52:38.626 error [10_122_60_87] session.get: RequestFailedError: TooBig snmp.0 10264 2022-08-08 16:52:38.625 debug [10_122_60_87] session.get: RequestFailedError: TooBig snmp.0 10264 2022-08-08 16:52:38.625 debug [10_122_60_87] session.get completed for chunk index 0 snmp.0 10264 2022-08-08 16:52:38.619 debug readChunkOIDs - device "10_122_60_87" (10.122.60.87), chunk idx 0 snmp.0 10264 2022-08-08 16:52:38.619 debug [10_122_60_87] processing oid chunk index 0 snmp.0 10264 2022-08-08 16:52:38.618 debug readOIDs - device "10_122_60_87" (10.122.60.87) -
@jb_sullivan
Danke für deine Geduld udn die toll vollständigen Infos.Der Adapter splittet jetzt in 2 Requests mit 19 und mit 1 OID. Das ist das erwartetet Verhalten. Beim Processing von des ersten Requests (chunk 0, 19 OIDs) raised er noch immer ein TooBig. Daher werden diese 19 OIDs auch nicht befüllt. Beim 2ten Request gibts keinen Error - daher sind da daten da.
Kannst du mal den Paramater Paketsize drastisch runtersetzen? Auf z,B 15?
Leider kann ich das TooBig Problem hier absolut nicht nachstellen.Ich kann nur vermuten, dass 19 doch noch zu groß ist für die Zusammenstellung dieser 19 OIDs.
