USV per SNMP auslesen

[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

[JB_Sullivan]

@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.

[mcm1957]

@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" gesetzt

Muss 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...

[mcm1957]

@jb_sullivan

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

[JB_Sullivan]

@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

[mcm1957]

@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.

[mcm1957]

@jb_sullivan

Der Fehler wurde eingegrenzt und behoben. Der Absturz sollte unter folgenden Umständen auftreten:
-) snmp V1 verwendet
-) irgendeine Fehler ausgenommen Timeout tritt auf

Ich 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).

[JB_Sullivan]

@mcm57

Leider immer noch/wieder "Too Big" bei 20/20 unter v1

Hier 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

[mcm1957]

@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.

[JB_Sullivan]

@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

[mcm1957]

@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?
Danke

Nachtrag: 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.

[JB_Sullivan]

@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)

[mcm1957]

@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.

[JB_Sullivan]

@mcm57 - ICH muss mich für deine Geduld bedanken !!! - also die "15" ist der Schlüssel zum Glück Jetzt werden alle 20 DP`s mit Werten gefüllt und der Adapter bleibt grün. Also ist die Version 2.1.4, zumindest bezogen auf mein Endgerät, "Stable" fähig

[mcm1957]

@jb_sullivan
Ok, zur Erklärung:
Wahrscheinlich würden jene 19 OIDs sie migt Parameter 19 nicht funktionieren auch alleine angehakt (also nur genau diese 19) nicht funktionieren. Ich vermute, dass sich die 19 die funktionieren knapp ausgehen. Allerdings kommt mir die Seriennummer als disablete OID nicht gerade lange vor - wenn das eine Modellbeschreibung wäre wärs einsichtiger. Andrerseits ist die Seriennummer ziemlich sicher ein String - und Datum Integers etc. sind ein paar Byte kürzer.

Egal ich bin froh, dass es jetzt mal für dich funktioniert. Melde dich bitte (hier oder im Testerforum oder via Github Issue ) wenn noch was auftritt.

Ich hab mal einen Issue geschrieben, damitd er Adapter allenfalls selbst die Größe reduziert. Wenn ich das umstze könnte es sein, dass ich dich versuche zu erreichen ob du ev. das testen kannst. Ich kanns zumindest derzeit nur im Simulationsbereich / Debugger testen.

[RoddiEF]

Nabend, mal eine Frage dazu:
Der Adapter läuft aber mich würde an der Stelle mal interessieren:
Warum setzt der Adapter die Onlinezeit zurück, wenn das "überwachte" Gerät offline ist.
Ist das so gewollt oder eine Einstellungssache ?
Danke....

Mario

P.S. Fällt mir gerade noch ein. Bevor ich den Thread hier gelesen habe, lief bei mir noch die Version 1.0.0
Warum wurde mir kein Update angezeigt in den Adaptern ?