Monatsrückblick Januar/Februar 2026 ist online!

[McCavity]

Einen habe ich doch noch, den ich nicht vorenthalten wollte - ich habe gerade gesehen, daß im Battery Status auf einmal "okOK" steht - da hat der Parser etwas mißverstanden. Den dafür verantwortlichen Empfang habe ich im Log finden können:

2022-12-23 14:10:41.380  - debug: jeelink.0 (18237) data received: OK VALUES DAVIS 0 20=3,22=-66,21=okOK VALUES DAVIS 0 20=4,22=-6 DAVIS 0 20=1,22=-67,21=ok,4=0.00,5=228,8=39,
2022-12-23 14:10:41.385  - debug: jeelink.0 (18237) Sensor ID    : 0
2022-12-23 14:10:41.386  - debug: jeelink.0 (18237) splice       : 20=3,22=-66,21=okOK,VALUES,DAVIS,0,20=4,22=-6,DAVIS,0,20=1,22=-67,21=ok,4=0.00,5=228,8=39,
2022-12-23 14:10:41.387  - debug: jeelink.0 (18237) something is wrong in stream 20=3,22=-66,21=okOK strange part ->VALUES
2022-12-23 14:10:41.389  - debug: jeelink.0 (18237) Channel   :   3
2022-12-23 14:10:41.389  - debug: jeelink.0 (18237) RSSI     : -66
2022-12-23 14:10:41.392  - debug: jeelink.0 (18237) Battery   : okOK
2022-12-23 14:10:41.440  - debug: jeelink.0 (18237) state jeelink.0.DavisVantage_1.rssi changed: -66 (ack = true)
2022-12-23 14:10:41.443  - debug: jeelink.0 (18237) state jeelink.0.DavisVantage_1.battery changed: okOK (ack = true)

Man sieht, daß das mal wieder eine "vermackelte" Zeile war:

2022-12-23 14:10:41.380  - debug: jeelink.0 (18237) data received: OK VALUES DAVIS 0 20=3,22=-66,21=okOK VALUES DAVIS 0 20=4,22=-6 DAVIS 0 20=1,22=-67,21=ok,4=0.00,5=228,8=39,

Es scheint, als würde der Adapter momentan nur dann anfangen zu arbeiten, wenn das Zeilenpräfix "OK VALUES DAVIS" nicht am Anfang der Zeile steht - zumindest läßt die Log-Zeile

2022-12-23 14:10:41.386  - debug: jeelink.0 (18237) splice       : 20=3,22=-66,21=okOK,VALUES,DAVIS,0,20=4,22=-6,DAVIS,0,20=1,22=-67,21=ok,4=0.00,5=228,8=39,

darauf schließen. Trotzdem scheint er, wenn er die Zeile verarbeitet, richtigerweise von vorne anzufangen. Er hat auch bemerkt, daß irgendetwas nicht stimmt, was die nächste Logzeile bestätigt:

2022-12-23 14:10:41.387  - debug: jeelink.0 (18237) something is wrong in stream 20=3,22=-66,21=okOK strange part ->VALUES

Im Prinzip müßte der Parser pro empfangener Zeile folgendes prüfen:

• Das Präfix lautet fix "OK VALUES DAVIS"
• Die ID besteht aus einer einzelnen Ziffer zwischen zwei Leerzeichen
• Ein Meßwert besteht aus einem Schlüssel, dem Gleichheitszeichen, dem Wert und einem Komma
• Schlüssel bestehen aus einer ein-oder zweistelligen Nummer, optional einem Punkt plus einer weiteren Ziffer
• Werte können verschiedene Datentypen enthalten: unsigned int (z.B. WindDirection) signed int (z.B. RSSI), signed float (z.B. Temperature, Dezimaltrennzeichen ist der Punkt), String (z.B. Battery)
• alle möglichen Schlüssel sind bekannt

Datentypen (vermutlich):

 Schlüssel  | Name                   | Datentyp       |  Beispielwert | Werteliste / Anmerkungen
------------+------------------------+----------------+---------------+-------------------------------------------------------------------------------------
* 1         | Temperature            | signed float   | -9.67         |
* 2         | Pressure               | ?              | ?             | Sensor nur in Basisstation
* 3         | Humidity               | unsigned float | 98.00         | (max. 100.00)
* 4         | WindSpeed              | unsigned float | 1.61          |
* 5         | WindDirection          | unsigned int   | 151           | (max. 360)
* 6         | WindGust               | unsigned float | 1.61          |
* 7         | WindGustRef            | int(?)         | 2             | (vermutlich int; ich weiß aber auch nicht, was dieser Wert genau bedeutet)
* 8         | RainTipCount           | unsigned int   | 39            | (max. 127 (vermutlich)
* 9         | RainSecs               | signed int     | -1            | Wert ist entweder -1 (es ist derzeit kein Niederschlag festgestellt) oder (vermutlich) >=0; max. unbekannt. Ist der Wert >=0, dann bedeutet das, daß derzeit Niederschlag vorliegt (wird in der Basisstation mit einem Schirmsymbol angezeigt). Ich weiß aber nicht, wie sich das genau manifestiert, das muß ich mal bei einer längeren Regenphase mitloggen
* 10        | Solar                  | ?              | ?             | Sensor nicht vorhanden
* 11        | VoltageSolar           | ?              | ?             | Sensor nicht vorhanden
* 12        | VoltageCapacitor       | ?              | ?             | Sensor nicht vorhanden
* 13        | SoilLeaf               | ?              | ?             | Sensor nicht vorhanden
* 14        | UV                     | ?              | ?             | Sensor nicht vorhanden
* 15.[1..4] | SoilTemperature.[1..4] | ?              | ?             | Sensor nicht vorhanden
* 16.[1..4] | SoilMoisture.[1..4]    | ?              | ?             | Sensor nicht vorhanden
* 17.[1..2] | LeafWetness.[1..2]     | ?              | ?             | Sensor nicht vorhanden
* 20        | Channel                | unsigned int   | 3             | [0..4]
* 21        | Battery                | string         | ok            | vermutlich {ok,nok}
* 22        | RSSI                   | signed int     | -66           |
* 255       | PacketDump             | ?              | ?             | vermutlich eh nur, wenn Debugging im Stick eingeschaltet wird, keine Ahnung, wie das dann aussieht :-)

Annahmen / Beobachtungen:

• Die Meßwerte beginnen mit einer fixen Folge (Schlüsselnummer in Klammern): <Channel (20)><RSSI (22)><Battery (21)><WindSpeed (4)><WindDirection (5)>
• nach den fixen Meßwerten folgen i.d.R. 0 bis 2 weitere Meßwerte
• Die Meßwerte <Temperature (1)>, <Humidity (3)>, <RainTipCount (8)> und <RainSecs (9)> werden einzelnen übertragen
• Die Meßwerte <WindGust (6)> und <WindGustRef (7)> werden in der gleichen Zeile direkt nacheinander übertragen
• Werte mit einem float Datentyp haben zwei Nachkommastellen
• Eine optimale Zeile sieht wie folgt aus:
  <Präfix><ID><Channel (20)><RSSI (22)><Battery (21)><WindSpeed (4)><WindDirection (5)>[<Meßwert (x)>...]

Weitere Meßwerte kann ich ohne weiteres auch leider nicht beurteilen, da mir dazu die Sensoren fehlen (der Drucksensor der Station ist in die Basisstation eingebaut und die funkt nicht, die empfängt nur... ;-)

Fehlerfälle und Ausnahmen:

• Das Präfix kann unvollständig sein, möglicherweise auch falsche Zeichen enthalten
• Das Präfix kann auch weiter hinten in der Zeile erscheinen, das ist zwingend ein Zeichen dafür, daß die vorherige Zeile unvollständig war - möglicherweise fehlt nur der Zeilenumbrauch, möglicherweise aber auch ein oder mehrere vollständige Meßwerte oder ein Teil eines Meßwertes
• Meßwerte ohne abschließendes Komma sind möglicherweise unvollständig und sollten ggf. verworfen werden und nur im Log erwähnt werden, zumindest als debug - eine höhere Stufe könnte man ggf. überdenken.

Ich weiß nicht, ob es möglich ist, daß Zeilen auch ohne das Präfix beginnen können; so gut kenne ich den JeeLink-Sketch nicht, aber da sowohl das Funkprotokoll als auch das serielle Protokoll als unzuverlässig eingestuft werden müssen, würde ich damit rechnen, daß es überall zu fehlenden Bytes kommen kann und daher ein paar Sanity-Checks einbauen. Zusammen mit den Datentypen sollten sich zumindest ein paar Grundchecks durchführen lassen, genauso damit, daß es im Prinzip nur das Präfix aus Großbuchsteben und den (vermutlich) einzigen String Wert in Kleinbuchstaben gibt. Merkt sich der Adapter eigentlich die zuletzt gemessenen Werte? Falls ja, könnte man überlegen, ob man da ggf. noch Änderungen über die Zeit prüfen möchte - aber ich denke, das sollte dann schon extern in der Auswertung geschehen, je weniger der Adapter voraussetzt, umso besser. Wenn der Adapter gut erkennt, und wenn es die Feststellung "schlechter Empfang" ist, dann ist schon viel gewonnen :-)

[McCavity]

Ach ja, fast vergessen... wird der Channel (Schlüssel 20) eigentlich als Datenpunkt gespeichert? Ich sehe im Log, daß er erkannt wird, wenn er erkannt wird, aber ich finde den Datenpunkt irgendwie nicht in den Objekten des IoBroker...?

[foxthefox]

@mccavity
Hab das mit der Adaption glatt aus den Augen verloren. Hatte irgendwie erwartet, daß es ein PullRequest kommt.
Bin nur wieder darauf gekommen, weil jemand nach dem Setzen der Parameter des Sticks fragte.
Das hatte ich gedacht, daß diese Sequenz unter Kommando eingetragen werden kann und dann wird der Stick damit parametriert.
Ging das schon einmal? In deinem Produktivsystem schien es nicht zu gehen oder evtl. wegen anderer Dinge übersehen ?

Jetzt zu dem Thema daß nicht alle Telegramme ausgewertet werden.
Das liegt höchstwahrscheinlich an dem was der Stick übergibt.
Im Adapter wird die Zeichenfolge ausgewertet. Dazu zerteile ich anhand der Leerzeichen den Anfang. Als erstes muß zwingend ein "OK" kommen und danach an übernächster Stelle ein "DAVIS".
Wenn das beides kommt, dann springt er in die Bearbeitung. Dort wird auch anhand der Komma die Zeichenketten extrahiert und eine solche Zeichenkette wird dann über das "=" in den Datenpunkt und Wert aufgeteilt. Wenn dann etwas drin ist, was nicht sinnvoll ist, kommt "..strange.."-Meldung.

An vierter Stelle steht ohne "=" die ID, die mit der Konfig im Adapter zusammenpassen muß.
Wenn das nicht konfiguriert ist, kommt "received ID : ?? is not defined in the adapter or not unique received address"

"OK VALUEK VALUES DAVIS 0 20=3,22=-66,21=ok,4=0.00,5=196,1=9.50," wird quasi direkt verworfen, da der dritte Teil nicht "DAVIS" ist.

Der Datenpunkt 20 wird derzeitig nur im debug log sichtbar. Hat noch keinen Datenpunkt im IOB.
Da er nicht weiter verwendet wird, werden die übermittelten Werte immer abgelegt, unabhängig der channel# (vorausgesetzt das Telegramm war gemäß obigen Regeln OK).

Es wird alles übernommen was zwischen "=" und "," den Wert darstellt. Ein "okOK" geht damit durch.

Meist kommt durch das letzte Komma verursacht noch ein "submitted value pair is unknown =undefined", da hatte ich bei der schnellen Hilfe für dich noch keine Muße das wegzufiltern.

Ich hoffe das hilft ein wenig zum Verständnis.

Gruß
Klaus

[foxthefox]

@mccavity sagte in IoBroker.Jeelink + Davis geht teilweise - Hilfe beim Rest?:

Ach ja, fast vergessen... wird der Channel (Schlüssel 20) eigentlich als Datenpunkt gespeichert? Ich sehe im Log, daß er erkannt wird, wenn er erkannt wird, aber ich finde den Datenpunkt irgendwie nicht in den Objekten des IoBroker...?

Nachdem scheinbar ja die gleichen Daten unabhängig der channel# drin sind, mach das Wegspeichern kein sinn, dann würde sich der Datenpunkt nur ständig ändern.
Falls DeviceID + channel unterschiedliche Daten wären, müsste man anhand von channel zuordnen

[foxthefox]

@mccavity sagte in IoBroker.Jeelink + Davis geht teilweise - Hilfe beim Rest?:

Einen habe ich doch noch, den ich nicht vorenthalten wollte - ich habe gerade gesehen, daß im Battery Status auf einmal "okOK" steht - da hat der Parser etwas mißverstanden. Den dafür verantwortlichen Empfang habe ich im Log finden können:

Man sieht, daß das mal wieder eine "vermackelte" Zeile war:

2022-12-23 14:10:41.380  - debug: jeelink.0 (18237) data received: OK VALUES DAVIS 0 20=3,22=-66,21=okOK VALUES DAVIS 0 20=4,22=-6 DAVIS 0 20=1,22=-67,21=ok,4=0.00,5=228,8=39,

Bis zu okOK ist die Zeile in Ordnung und wurde auch weiter bearbeitet

Es scheint, als würde der Adapter momentan nur dann anfangen zu arbeiten, wenn das Zeilenpräfix "OK VALUES DAVIS" nicht am Anfang der Zeile steht - zumindest läßt die Log-Zeile

2022-12-23 14:10:41.386  - debug: jeelink.0 (18237) splice       : 20=3,22=-66,21=okOK,VALUES,DAVIS,0,20=4,22=-6,DAVIS,0,20=1,22=-67,21=ok,4=0.00,5=228,8=39,

darauf schließen. Trotzdem scheint er, wenn er die Zeile verarbeitet, richtigerweise von vorne anzufangen. Er hat auch bemerkt, daß irgendetwas nicht stimmt, was die nächste Logzeile bestätigt:

2022-12-23 14:10:41.387  - debug: jeelink.0 (18237) something is wrong in stream 20=3,22=-66,21=okOK strange part ->VALUES

Nicht ganz richtig vermutet, wegen OK VALUES DAVIS springt er überhaupt in die Bearbeitung und "spliced" den Rest auf. Das ist auch soweit gut bis keine Wertepaare mehr enthalten sind -> VALUES DAVIS..
Das erkennt er und meckert "VALUES" an.

Im Prinzip müßte der Parser pro empfangener Zeile folgendes prüfen:

• Das Präfix lautet fix "OK VALUES DAVIS"

Ich prüfe auf OK und DAVIS an übernächster Stelle ab.

• Die ID besteht aus einer einzelnen Ziffer zwischen zwei Leerzeichen
• Ein Meßwert besteht aus einem Schlüssel, dem Gleichheitszeichen, dem Wert und einem Komma
• Schlüssel bestehen aus einer ein-oder zweistelligen Nummer, optional einem Punkt plus einer weiteren Ziffer
• Werte können verschiedene Datentypen enthalten: unsigned int (z.B. WindDirection) signed int (z.B. RSSI), signed float (z.B. Temperature, Dezimaltrennzeichen ist der Punkt), String (z.B. Battery)

wird genauso verarbeitet

• alle möglichen Schlüssel sind bekannt
  Bis auf Channel und PacketDump dürfte alles drin sein.

Annahmen / Beobachtungen:

• Die Meßwerte beginnen mit einer fixen Folge (Schlüsselnummer in Klammern): <Channel (20)><RSSI (22)><Battery (21)><WindSpeed (4)><WindDirection (5)>
• nach den fixen Meßwerten folgen i.d.R. 0 bis 2 weitere Meßwerte
• Die Meßwerte <Temperature (1)>, <Humidity (3)>, <RainTipCount (8)> und <RainSecs (9)> werden einzelnen übertragen
• Die Meßwerte <WindGust (6)> und <WindGustRef (7)> werden in der gleichen Zeile direkt nacheinander übertragen
• Werte mit einem float Datentyp haben zwei Nachkommastellen
• Eine optimale Zeile sieht wie folgt aus:
  <Präfix><ID><Channel (20)><RSSI (22)><Battery (21)><WindSpeed (4)><WindDirection (5)>[<Meßwert (x)>...]

ob die Reihenfolge so ist oder auch nicht, ist in der Auswertung egal. Wenn OK VALUES DAVIS 0 am Anfang steht, wird alles danach zwischen den Kommas über das = als Wertepaar identifiziert und anhand der Schlüsselnummer richtig weggeschrieben.

Fehlerfälle und Ausnahmen:

• Das Präfix kann unvollständig sein, möglicherweise auch falsche Zeichen enthalten
• Das Präfix kann auch weiter hinten in der Zeile erscheinen, das ist zwingend ein Zeichen dafür, daß die vorherige Zeile unvollständig war - möglicherweise fehlt nur der Zeilenumbrauch, möglicherweise aber auch ein oder mehrere vollständige Meßwerte oder ein Teil eines Meßwertes
• Meßwerte ohne abschließendes Komma sind möglicherweise unvollständig und sollten ggf. verworfen werden und nur im Log erwähnt werden, zumindest als debug - eine höhere Stufe könnte man ggf. überdenken.

Alles was nicht passt wird verworfen, die "strange" Meldungen sind nur debug. Wenn der Anfang nicht passt, führt halt zu einer Meldung das Konfig nicht richtig ist. Könnte man auch unter debug laufen lassen, bisher sah ich es als hilfreich für die Inbetriebnahme bzw. als Hinweis bei ID-Wechsel nach Batteriewechsel (da der Adapter ja auch die LaCrosse/Technolink verarbeitet).

Ich weiß nicht, ob es möglich ist, daß Zeilen auch ohne das Präfix beginnen können; so gut kenne ich den JeeLink-Sketch nicht, aber da sowohl das Funkprotokoll als auch das serielle Protokoll als unzuverlässig eingestuft werden müssen, würde ich damit rechnen, daß es überall zu fehlenden Bytes kommen kann und daher ein paar Sanity-Checks einbauen. Zusammen mit den Datentypen sollten sich zumindest ein paar Grundchecks durchführen lassen, genauso damit, daß es im Prinzip nur das Präfix aus Großbuchsteben und den (vermutlich) einzigen String Wert in Kleinbuchstaben gibt. Merkt sich der Adapter eigentlich die zuletzt gemessenen Werte? Falls ja, könnte man überlegen, ob man da ggf. noch Änderungen über die Zeit prüfen möchte - aber ich denke, das sollte dann schon extern in der Auswertung geschehen, je weniger der Adapter voraussetzt, umso besser. Wenn der Adapter gut erkennt, und wenn es die Feststellung "schlechter Empfang" ist, dann ist schon viel gewonnen :-)

Ich bin hier für KISS (keep it simple und stupid), einfach auf das nächste saubere Telegramm warten und dieses auswerten und wegschreiben. Großartig rumorakeln was von einem String noch auswertbar ist oder nicht, bringt bei so schnell ankommenden Telegrammen nichts. Eher wäre der sketch auf dem Stick gefragt um die Telegramm richt zu separieren und nicht ein "...=okOK VALUES..." zu bekommen. Sonst kommt da als letztes immer ein Komma. Und wenn wir an den Daten an sich zweifeln (vergleich mit letzten Wert) :dizzy_face: