NEWS
Test Adapter snmp v3.3.x
-
Aktuelle Test Version 3.3.0 Veröffentlichungsdatum 17.8.2025 Github Link https://github.com/iobroker-community-adapters/ioBroker.snmp Beschreibung / Infos
Der Adapter snmp hat seit dem letzten Test Topic einige neue Versionen bekommen die hier nie gelistet wurden. Inhaltlich hat sich allerdings nicht viel getan. Im Wesentlichen wurden in V3.x.x
Changelog
3.3.0 (2025-08-17)
- (mcm1957) Adapter requires node.js 20, js-controller >= 6.011 and admin >= 7.6.17 now.
- (mcm1957) Dependencies have been updated
3.2.0 (2024-03-29)
- (mcm1957) Adapter requires node.js 18 and js-controller >= 5 now
- (mcm1957) Dependencies have been updated
3.1.0 (2023-10-13)
- (mcm1957) Requirements have been updated. Adapter requires node.js 18 or newer now
- (mcm1957) Packages have been update to cleanup open dependabot PRs
3.0.0 (2023-10-12)
- (bluefox) updated packages. Minimal node.js version is 16
Hinweis:
Die Diskussion zur letzten 2.x.x Version ist hier zu finden :https://forum.iobroker.net/topic/63244/test-adapter-snmp-2-4-x-github-latest -
Aktuelle Test Version 3.3.0 Veröffentlichungsdatum 17.8.2025 Github Link https://github.com/iobroker-community-adapters/ioBroker.snmp Beschreibung / Infos
Der Adapter snmp hat seit dem letzten Test Topic einige neue Versionen bekommen die hier nie gelistet wurden. Inhaltlich hat sich allerdings nicht viel getan. Im Wesentlichen wurden in V3.x.x
Changelog
3.3.0 (2025-08-17)
- (mcm1957) Adapter requires node.js 20, js-controller >= 6.011 and admin >= 7.6.17 now.
- (mcm1957) Dependencies have been updated
3.2.0 (2024-03-29)
- (mcm1957) Adapter requires node.js 18 and js-controller >= 5 now
- (mcm1957) Dependencies have been updated
3.1.0 (2023-10-13)
- (mcm1957) Requirements have been updated. Adapter requires node.js 18 or newer now
- (mcm1957) Packages have been update to cleanup open dependabot PRs
3.0.0 (2023-10-12)
- (bluefox) updated packages. Minimal node.js version is 16
Hinweis:
Die Diskussion zur letzten 2.x.x Version ist hier zu finden :https://forum.iobroker.net/topic/63244/test-adapter-snmp-2-4-x-github-latest -
Hallo!
Vielen Dank für den tollen Adapter.
Ich habe jedoch folgende Frage bzgl. des Einlesens von Octett-Strings von einem Brother Drucker.
Im MIB Browser bekomme ich folgenden Octett-String:Name/OID: brInfoMaintenance.0; Value (OctetString): 0x76 01 04 00 00 00 01 79 01 04 00 00 27 10 73 01 04 00 00 00 1F 77 01 04 00 00 00 01 7A 01 04 00 00 27 10 74 01 04 00 00 00 1F 78 01 04 00 00 00 01 7B 01 04 00 00 27 10 75 01 04 00 00 00 1F 7F 01 04 00 00 00 01 80 01 04 00 00 27 10 7E 01 04 00 00 00 1F 68 01 04 00 00 00 01 55 01 04 00 00 00 01 32 01 04 00 00 00 01 70 01 04 00 00 26 48 82 01 04 00 00 00 64 33 01 04 00 00 00 01 71 01 04 00 00 26 48 83 01 04 00 00 00 64 34 01 04 00 00 00 01 72 01 04 00 00 26 48 84 01 04 00 00 00 64 31 01 04 00 00 00 01 6F 01 04 00 00 26 48 81 01 04 00 00 00 64 69 01 04 00 00 27 10 66 01 04 00 00 00 01 6C 01 04 00 00 27 10 54 01 04 00 00 00 01 6A 01 04 00 00 27 10 FF
Leider liest er SNMP Adpater die Daten kryptisch ein:
vy'swz'tx{'u�'~hU2p&H�d3q&H�d4r&H�d1o&H�di'fl'Tj'�
Kann man das irgendwie einstellen?
Das Format steht auf Automatisch, bei String sieht es aber genauso aus.
Viele liebe Grüße
Otti -
Hallo!
Vielen Dank für den tollen Adapter.
Ich habe jedoch folgende Frage bzgl. des Einlesens von Octett-Strings von einem Brother Drucker.
Im MIB Browser bekomme ich folgenden Octett-String:Name/OID: brInfoMaintenance.0; Value (OctetString): 0x76 01 04 00 00 00 01 79 01 04 00 00 27 10 73 01 04 00 00 00 1F 77 01 04 00 00 00 01 7A 01 04 00 00 27 10 74 01 04 00 00 00 1F 78 01 04 00 00 00 01 7B 01 04 00 00 27 10 75 01 04 00 00 00 1F 7F 01 04 00 00 00 01 80 01 04 00 00 27 10 7E 01 04 00 00 00 1F 68 01 04 00 00 00 01 55 01 04 00 00 00 01 32 01 04 00 00 00 01 70 01 04 00 00 26 48 82 01 04 00 00 00 64 33 01 04 00 00 00 01 71 01 04 00 00 26 48 83 01 04 00 00 00 64 34 01 04 00 00 00 01 72 01 04 00 00 26 48 84 01 04 00 00 00 64 31 01 04 00 00 00 01 6F 01 04 00 00 26 48 81 01 04 00 00 00 64 69 01 04 00 00 27 10 66 01 04 00 00 00 01 6C 01 04 00 00 27 10 54 01 04 00 00 00 01 6A 01 04 00 00 27 10 FF
Leider liest er SNMP Adpater die Daten kryptisch ein:
vy'swz'tx{'u�'~hU2p&H�d3q&H�d4r&H�d1o&H�di'fl'Tj'�
Kann man das irgendwie einstellen?
Das Format steht auf Automatisch, bei String sieht es aber genauso aus.
Viele liebe Grüße
Otti -
@Homoran
Sorry... wusste nicht, das ihr eure Augen überall habt 😊
Ich dachte, da die Thematik verschiedene Adpater betrifft, es sinnvoll wäre "doppelt" zu posten.Ich habe gerade einen Workaround mittels Javascript erstellt:
Damit wird das kyrptische wieder in ASCII lesbar Hex-Folge umgeschrieben und schreibe die Daten dann in einen neuen Datenpunkt.
// Umwandlung in Hex-Folge
for (let i = 0; i < input.length; i++) {
let hex = input.charCodeAt(i).toString(16).toUpperCase();
hexResult += (hex.length < 2 ? "0" + hex : hex) + " ";
}
Ciao Otti -
Anstelle die das Ausgabeformat STRING oder DEFAULT zu verwenden wäre es besser das Ausgabeformat auf JSON umzustelle und die dort als sauberes Array verfügbaren Daten auszuwerten (und ggF. in einen HEX STring umzuwandeln).
Zusaätzlich habe ich Issue https://github.com/iobroker-community-adapters/ioBroker.snmp/issues/623 erstellt um die Ausgabe bei Octetstrings anzupassen.
-
Prima.
Aber leider liest der Adapter bei Umstellung auf JSON die Daten nicht sauber ein:Hier JSON:
[Brother MFC-L8390CDW] update Brother MFC-L8390CDW.ATTR_MAINTENANCE_Octett: {"type":"Buffer","data":[118,1,4,0,0,0,1,121,1,4,0,0,39,16,115,1,4,0,0,0,31,119,1,4,0,0,0,1,122,1,4,0,0,39,16,116,1,4,0,0,0,31,120,1,4,0,0,0,1,123,1,4,0,0,39,16,117,1,4,0,0,0,31,127,1,4,0,0,0,1,128,1,4,0,0,39,16,126,1,4,0,0,0,31,104,1,4,0,0,0,1,85,1,4,0,0,0,1,50,1,4,0,0,0,1,112,1,4,0,0,38,72,130,1,4,0,0,0,100,51,1,4,0,0,0,1,113,1,4,0,0,38,72,131,1,4,0,0,0,100,52,1,4,0,0,0,1,114,1,4,0,0,38,72,132,1,4,0,0,0,100,49,1,4,0,0,0,1,111,1,4,0,0,38,72,129,1,4,0,0,0,100,105,1,4,0,0,39,16,102,1,4,0,0,0,1,108,1,4,0,0,39,16,84,1,4,0,0,0,1,106,1,4,0,0,39,16,255]}Hier MIB-Browser:
Name/OID: brInfoMaintenance.0; Value (OctetString): 0x76 01 04 00 00 00 01 79 01 04 00 00 27 10 73 01 04 00 00 00 1F 77 01 04 00 00 00 01 7A 01 04 00 00 27 10 74 01 04 00 00 00 1F 78 01 04 00 00 00 01 7B 01 04 00 00 27 10 75 01 04 00 00 00 1F 7F 01 04 00 00 00 01 80 01 04 00 00 27 10 7E 01 04 00 00 00 1F 68 01 04 00 00 00 01 55 01 04 00 00 00 01 32 01 04 00 00 00 01 70 01 04 00 00 26 48 82 01 04 00 00 00 64 33 01 04 00 00 00 01 71 01 04 00 00 26 48 83 01 04 00 00 00 64 34 01 04 00 00 00 01 72 01 04 00 00 26 48 84 01 04 00 00 00 64 31 01 04 00 00 00 01 6F 01 04 00 00 26 48 81 01 04 00 00 00 64 69 01 04 00 00 27 10 66 01 04 00 00 00 01 6C 01 04 00 00 27 10 54 01 04 00 00 00 01 6A 01 04 00 00 27 10 FFZum einen werden Teilstrings wie 00 als 0 abgespeichert. Buchstaben werden gar nicht erkannt.
Der MIB Browser den ich verwende: iReasoning MIB Browser verwendet für die Characters Encoding: ISO-8859-1.
Vielleicht hilft dir diese Infos.
Ciao Otti -
Welches Byte liest er nicht sauber ein?
Kannst du das mal markieren? Ich hab mal nur die ersten Bytes vergleichen und die stimmen alle mit den Daten des MIB Browsers überein.EDIT:
Zum einen werden Teilstrings wie 00 als 0 abgespeichert. Buchstaben werden gar nicht erkannt.
Du unterliegst da anscheinend einem Irrtum. Die Daten werden als BINARE BYTES gesendet. Der MIB Browser stellt diese als HEX String dar. Das Json stellt die Bytes einzeln numerisch als Array Elemente dar - so wie sie auch gesendet werden. Führende Nullen sind bei einer numerischen Darstellung nicht notwendig und Buchstaben gibt es bei dezimalzahlen nicht :-). Das JSON ist kein heaxadezimal kodierter String, die einzelnen Bytewerte werden numerisch im Zehnersystem dargestellt.
Hexadezimal (MIB Bowser) 0x76 01 04 00 00 00 01 79 ... Dezimal (JSON) 118, 1, 4, 0, 0, 0, 1, 121 ...76 (hex) == 118 (dez)
79 (hex) == 121 (dez)
...