Autor Thema: Kleinere (?) Probleme mit dpt16  (Gelesen 504 mal)

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Kleinere (?) Probleme mit dpt16
« am: 07 Januar 2018, 23:07:00 »
Hallo liebes Forum,

ich möchte eine Textmeldung auf einem MDT Glastaster ausgeben und habe mir hierfür ein knx Device definiert. Es macht noch ein paar andere Dinge, deshalb hat es mehrere GAs. Hier die Definition:

defmod Diele.HVAC.MDT KNX 1/1/60:dpt9.001:taste.kurz 1/1/61:dpt5:taste.lang 1/1/62:dpt5:mdt.status 1/1/63:dpt16:mdt.text 1/1/64:dpt9.001:temp.anzeige
attr Diele.HVAC.MDT IODev myTUL
attr Diele.HVAC.MDT room HVAC,KNX

setstate Diele.HVAC.MDT 21.30 °;C
setstate Diele.HVAC.MDT 2018-01-07 21:58:20 last-sender 0/0/3
setstate Diele.HVAC.MDT 2018-01-07 21:58:20 mdt.status-get 0
setstate Diele.HVAC.MDT 2018-01-07 21:58:20 mdt.status-set 0
setstate Diele.HVAC.MDT 2018-01-07 21:58:20 mdt.text-get Raum
setstate Diele.HVAC.MDT 2018-01-07 21:58:20 mdt.text-set Raum
setstate Diele.HVAC.MDT 2018-01-07 21:58:20 state 21.30 °;C
setstate Diele.HVAC.MDT 2018-01-07 21:58:20 taste.kurz-get 0.50 °;C
setstate Diele.HVAC.MDT 2018-01-07 21:58:20 taste.lang-get 255
setstate Diele.HVAC.MDT 2018-01-07 21:58:20 temp.anzeige-get 21.30 °;C
setstate Diele.HVAC.MDT 2018-01-07 21:58:20 temp.anzeige-set 21.30 °;C

Wenn ich nun einen Text ausgebe mittels
set Diele.HVAC.MDT string Hallo g4

dann ändert sich die Textanzeige wie gewünscht und der ETS Gruppenmonitor zeigt ein valides Paket an.

Aber:
Im Fhem-Log gibt es bei jeder Textausgabe einen Eintrag der Form
2018.01.07 22:26:07 3: check value: input-value Hallo  was casted to Hallo
Man beachte das 2. Leerzeichen hinter dem ersten Hallo. Der String "Hallo " wurde auf "Hallo" gecasted.
Vermutlich kein Problem(?) Ich nehme an, durch die Angabe der Gruppe (g4) wird der Input-String in 10_KNX.PM nicht richtig zerlegt.

Was mich mehr besorgt, ist, dass jetzt die Raw-Definition anders aussieht.
...
setstate Diele.HVAC.MDT 2018-01-07 22:26:07 mdt.text-set #Hallo
...
Da, wo ich den # geschrieben habe, steht tatsächlich kein #, sondern ein kryptisches Sonderzeichen, das ich nicht hier einfügen kann.
Sieht mir nach einem Bug aus.

Bei der allerersten Ausgabe eines Textes nach dem Booten von FHEM, erscheint im Log noch eine weitere Ausgabe
2018.01.07 22:26:07 1: PERL WARNING: Illegal hexadecimal digit ' ' ignored at ./FHEM/10_KNX.pm line 1612.
Bei weiteren Textausgaben kommt diese Warning nicht mehr. Das Schmutzzeichen am Anfang des Readings bleibt aber.
Im Bustelegramm ist laut ETS kein Schmutzzeichen enhalten.

Wäre schön, wenn sich das einer von den Experten mal anschauen würde. Ich habe erst kürzlich mit Textausgaben begonnen und hatte heute ein paar merkwürdige Instabilitäten mit FHEM. Ob da ein Zusammenhang besteht??

Viele Grüße
Andreas

Offline Andi291

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 981
Antw:Kleinere (?) Probleme mit dpt16
« Antwort #1 am: 08 Januar 2018, 17:18:24 »
Servus!

Das mit dem Leerzeichen schau ich mir mal an. Kann ein Seiteneffekt vom "Tuning" der Regexes sein.
Bezüglich Sonderzeichen eier ich da auch immer böse rum - HTML, Unicode und wie sie alle heißen...

#Hallo sollte tun, was Du willst...

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Kleinere (?) Probleme mit dpt16
« Antwort #2 am: 08 Januar 2018, 22:11:03 »
Hallo Andi291,

es war vermutlich von mir nicht klar genug dargestellt.

Ausgeben will ich "Hallo"
Auf dem Bus ausgegeben wird "Hallo"  :)
Das Reading mdt.text-set hat anschließend den Wert "<komisches Sonderzeichen>Hallo"  :(

Welches Sonderzeichen genau, konnte ich nicht ermitteln.
Im Web-Frontend wird es nicht angezeigt.
Aber wenn man auf "Raw Definition" geht, sieht man, dass da etwas komisch ist.
100% reproduzierbar, egal welcher Text gesendet wird, immer steht vorne dran im Reading-set das Müllzeichen.

Morgen Abend habe ich vermutlich wieder Zugang zum System und werde mir mal ein kleines Skript schreiben, dass das Reading ausliest und die Hexwerte ausgibt. Dann sollte ich zumindest sagen können, welches Zeichen vorne dran gestellt ist.

Vielen Dank auf jeden Fall schon einmal fürs anschauen.
Viele Grüße
Andreas

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Kleinere (?) Probleme mit dpt16
« Antwort #3 am: 08 Januar 2018, 23:20:32 »
Hallo Andi291,
habe mich etwas in den Code von 10_KNX.pm gegraben und glaube, ich bin dem Problem mit dem Schmutzzeichen auf der Spur.

Beim set Befehl wird in sub KNX_SET in Zeile 620 der übergebene String mittels KNX_encodeByDpt() in eine Hex-Folge umgewandelt. Diese wird auf den Bus geschickt. Weiterhin wird sie in Zeile 638 mittels KNX_decodeByDpt() wieder in einen String zurückgewandelt, der dann in Zeile 650 in das -set Reading geschrieben wird.

Für den dpt16 fügt KNX_encodeDpt() ein 0-Byte vorne an, Zeile 1308. KNX_decodeDpt() schreibt aber in der Schleife Zeilen 1610 - 1623 sämtliche Zeichen zurück in den String inklusive dem führenden 0-Byte!

Mir ist noch nicht klar, ob bei einem über den Bus empfangenen dpt16 auch ein 0-Byte vorne dran ist. Dann müsste man einfach die Schleife in Zeile 1610 von 1 bis 15 laufen lassen, statt von 0 bis 14. Könnte aber auch sein, dass beim Empfang kein 0-Byte vorne dran sitzt. Dann müsste man ein führendes 0-Byte ignorieren. So wie es im Moment codiert ist, ist da auf alle Fälle ein Bug. Denn es wird nicht nur das führende 0-Byte in das -set Reading geschrieben, sondern zudem, wenn der Ausgabetext exakt 14 Chars hat, das letzte Zeichen abgeschnitten.

Viele Grüße
Andreas 
« Letzte Änderung: 08 Januar 2018, 23:22:37 von docm »

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Kleinere (?) Probleme mit dpt16
« Antwort #4 am: 09 Januar 2018, 23:59:54 »
Hallo Andi291,
es gab zwei Probleme mit dpt16. Eines führt zu einem zusätzlichen Leerzeichen am Ende des Ausgabestring, der dann in Folge die "was casted to" Logausgaben zur Folge hat.
Das zweite Problem war das Handling des 0-Byte, wie bereits vermutet.

Habe beides mit kleinen Änderungen an 10_KNX.pm gelöst. Siehe #docm im Sourcecode.
Das Modul enthält noch eine Erweiterung: Mich hat immer genervt, dass wenn man vom KNX-Bus eine GA eines in FHEM modellierten KNX-Devices ausliest, der Wert von STATE zurückgeliefert wird anstelle des korrespondierenden Readings.

Schau es dir mal an. Ich werde die Erweiterung in den nächsten Tagen noch einmal in einem separaten Posting erläutern. Sie hat nichts mit dem hier geschilderten und gelösten Bug zu tun, war nur in meinem aktuellen 10_KNX.pm Source bereits enthalten.

Viele Grüße
Andreas

Offline Andi291

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 981
Antw:Kleinere (?) Probleme mit dpt16
« Antwort #5 am: 10 Januar 2018, 21:07:20 »
Servus!

Also die dpt16-Änderungen schauen plausibel aus.
Die Erstimplementierung war damals eine Frickelei. Gefühlt hat es sich auf jedem System anders Verhalten. Der aktuell eingecheckte Stand war ein guter Kompromiss.

Ich übernehme Deine Ändeurngen mal in eine neue Version bei mir. Wenn das einige Tage sauber läuft, checke ich nur dafür eine Version ein. Die lässt sich dann im Bedarfsfalle schnell wieder wegwerfen :-)

Grüße, Andi