^

Themabewertung:
  • 123 Bewertung(en) - 2.63 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
openHAB-Binding: Fehler in "sendDynamicText"?
#1
Exclamation 
Hallo zusammen,

wie schon erwähnt habe ich auf das neue Binding umgestellt, bin auch sehr zufrieden, habe bislang nur eine Auffälligkeit:
Wenn ich mit sendDynamicText einen String ans GT4D schicke, wird der reproduzierbar nicht angezeigt, wenn er 12, 24, oder 36 Zeichen enthält.
Es gibt keine Fehlermeldung im openHAB-Log, positive Quittung auf dem LCN-Bus, aber der Text wird nicht angezeigt.
Mit allen anderen Zeichenkettenlängen gibts kein Problem...  Huh

Gibt es dafür eine Erklärung?

Gruß
Simon
Zitieren
#2
(03.12.2020, 00:03)harteknut schrieb: wie schon erwähnt habe ich auf das neue Binding umgestellt, bin auch sehr zufrieden, habe bislang nur eine Auffälligkeit:
Wenn ich mit sendDynamicText einen String ans GT4D schicke, wird der reproduzierbar nicht angezeigt, wenn er 12, 24, oder 36 Zeichen enthält.
Es gibt keine Fehlermeldung im openHAB-Log, positive Quittung auf dem LCN-Bus, aber der Text wird nicht angezeigt.
Mit allen anderen Zeichenkettenlängen gibts kein Problem...  Huh

Gibt es dafür eine Erklärung?

Vermutlich ja. Ich hatte das gleiche Problem mit pypck (https://github.com/alengwenus/pypck). Die software muss bei strings mit 12, 24, etc bytes nach dem letzten vollen Part einen leeren Part hinterherschicken. Wenn ich mir aber die entsprechende Funktion ansehe (https://github.com/openhab/openhab-addon....java#L118) dann wird das aber nicht gemacht.

Hintergrund: LCN teilt die dynamischen Texte in Parts zu je 12 bytes auf. Also 24 ASCII Zeichen sind 2 Parts. Allerdings braucht es auch noch ein 0 byte als Terminator. Also muss man einen 3. Part mit 0 bytes hinterherschicken. openhab scheint das nicht zu machen.

Ich denke du kannst dort einfach einen Issue aufmachen. Oder falls du keinen github Account hast oder willst, kann ich das auch erledigen.
Zitieren
#3
Hab bei github einen Issue aufgemacht (#9208), Fabian hat auch schon geantwortet und das Thema bestätigt, Workaround gibts auch schon (#9232).
Zitieren
#4
... und schon in OH 3.0.0 MS5 integriert: pull 9232
Thumbup
Zitieren


Gehe zu: