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