Unerwuenschte Aenderungen von Heizungseinstellungen per ebusd & smarthome.py

[olicat]

Zuerst einmal vielen Dank fuer Euer Engagement und die Arbeit am smarthome.py, dem ebusd und dem entsprechenden Plugin sowie die Hilfen hier im Forum!

Ich habe aktuell ein Problem in Verbindung mit dem ebusd bei dem ich nicht recht weiss, wo ich mit der Fehlersuche anfangen sollte und hoffe auf einen "Wegweiser".

Kernproblem:
Hin und wieder verstellen sich ein paar Einstellungen meiner Heizung wie von Geisterhand ohne fuer mich erkennbaren Grund.
Vor einiger Zeit schon verstellte sich die Solltemperatur und die Bivalenztemperatur. Das hielt ich noch fuer einen Zufall und war kein Drama weil ich das wohl zeitnah feststellte und revidieren konnte.

Gestern hat sich nun die Heizkurve verstellt. Von 0,25 auf 64 (!) - was meine Familie heute Morgen durch "heisse" Fuesse und stark aufgeheizte Raeume feststellte. Ich selbst war nicht vor Ort; konnte jedoch remote die Heizkurve wieder auf einen normalen Wert aendern und bin nun beim Pruefen der Log-Files und dem Suchen einer Erklaerung.
Keine schoene Vorstellung, wenn das waehrend einer laengeren Abwesenheit passiert ...
Aber der WAF ist auch jetzt schon stark reduziert - "man" erwartet also eine Loesung.
:-#

Alle Werte, die sich bisher "von selbst" verstellten sind tatsaechlich "write"-Werte; also Werte die ich ueber die Visu anzeigen lasse, ggf. aber auch aendern koennen moechte. Damit dies nicht versehentlich passiert, sind Aenderungen ueber die KNX-Visu (Loxone) mit einem Password geschuetzt - ein unbewusstes Aendern sollte so ausgeschlossen sein.

Ausloeser der Heizkurven-Aenderung war tatsaechlich ein KNX-Telegramm vom eibd des Raspis, auf dem smarthome.py mit dem ebusd laeuft:

11:47:46.421 LPDU: BC 10 04 66 9C F3 00 80 16 40 88 :L_Data low from 1.0.4 to 12/6/156 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write 16 40

Vermutlich hat das smarthome.py oder das Plugin oder der ebusd veranlasst. Aber warum? Und wie kann ich das zukuenftig verhindern?

Den Inhalt der items.conf habe ich hier aus dem Forum zusammengeklaubt:

items/ebusd.conf:
[...]
  [[HeatingCurve]]
    type = num
    knx_dpt = 9
    knx_send = 12/6/156
    knx_reply = 12/6/156
    knx_listen = 12/6/156
    ebus_cmd = "mc HeatingCurve"
    ebus_type = "write"
    ebus_value_type = "float"
    comment = eingestellte Heizkurve
[...]

Stimmt das soweit?
Sollte man ggf. fuer das Lesen und das Schreiben getrennte GAs nutzen?
Grundsaetzlich funktioniert das Konstrukt ja bereits seit 8 Monaten. Ich habe im Februar haeufiger an der Heizkurve gespielt (erster Winter im Haus) und auch heute Morgen konnte ich den Wert so aendern wie gewuenscht.

Koennten Probleme in der Ebus-Buskommunikation zu so einem Verhalten fuehren? Die Kommunikation ist offenbar recht wackelig; ich erhalte haeufiger Fehler im ebusd.log. Etwa auch in zeitlicher Naehe zum oben geschilderten Problem:

2016-09-29 11:46:31.564 [bus error] poll ehp ApplianceCode failed: ERR: arbitration lost
2016-09-29 11:47:45.801 [bus error] send to 50: ERR: read timeout, retry

Sollte ich da versuchen, den eService-eBus-Koppler (USB) noch etwas nachzujustieren?
Aber duerften sich etwaige Kommunikationsprobleme so auswirken, dass ungewollt Aktionen ausgeloest oder Werte veraendert werden?

In der smarthome.log stehen leider keine wesentlichen Hinweise:

root@raspberrypi:/usr/local/smarthome/plugins/ebus# cat /usr/local/smarthome/var/log/smarthome.log.2016-09-29
2016-09-29 16:00:26 WARNING  eBusd        error receiving answer: timeout
2016-09-29 16:00:29 WARNING  eBusd        Item ebus.BackupHoursHc: value 2

248 does not match type num. Via eBus refresh

Aber auch hier koennte ich auf eine gestoerte eBus-Kommunikation schliessen.

Welche Logfiles sollte ich mir noch ansehen?
Habt ihr noch Ideen zur weiteren Fehlersuche?

Sowohl der ebusd (2.0.568e2df) als auch smarthome.py (v1.0) sind nicht die allerneuesten Versionen; ist dieses Verhalten eventuell bekannt und ggf. in einer neueren Version behoben worden?

Vielen Dank im Voraus,

Oliver

[johnm]

Hin und wieder verstellen sich ein paar Einstellungen meiner Heizung wie von Geisterhand ohne fuer mich erkennbaren Grund.

Also aus ebusd Sicht kann ich Dir versichern, dass nicht irgendwelche Werte von Geisterhand verstellt werden.
Unabhängig davon ist es denkbar, dass ab einer gewissen Menge von Geräten am Bus, die sich teilweise evtl. nicht spezifikationskonform verhalten, so etwas grundsätzlich passieren kann. Vor einigen Jahren, noch bevor ich meine Anlage mit ebusd überwacht habe, kam es etwa einmal pro Jahr vor, dass der Controller komplett alle Daten verloren hat und frisch auf die Anlage konfiguriert werden musste. Das ist also selbst ohne externen Einfluss via ebusd passiert.

In Deinem Fall schätze ich eher, dass eine der anderen Komponenten hier reinspielt, also bspw. die Kopplung mit dem KNX System oder smarthome (das ist genau der Grund, warum ich das bisher noch nicht getan habe).

Ich würde versuchen, die Potokollierung zu erhöhen und dann bei einem erneuten Vorfall den Verursacher zu finden. Oder lässt sich das aufgrund Deines KNX-Telegramms schon sagen?

Koennten Probleme in der Ebus-Buskommunikation zu so einem Verhalten fuehren? Die Kommunikation ist offenbar recht wackelig; ich erhalte haeufiger Fehler im ebusd.log. Etwa auch in zeitlicher Naehe zum oben geschilderten Problem:

2016-09-29 11:46:31.564 [bus error] poll ehp ApplianceCode failed: ERR: arbitration lost
2016-09-29 11:47:45.801 [bus error] send to 50: ERR: read timeout, retry

Also das ist für ein Bussystem mit Arbitrierung nicht ungewöhnlich, es sei denn solche Einträge kommen im Sekundentakt.

Den Read Timeout würde ich mal etwas beobachten. Es gibt auch hier hin und wieder Geräte, die etwas mehr Zeit für eine Antwort brauchen. Das könntest Du dann mit ebusd Aufrufparameter "--receivetimeout" (siehe Wiki: https://github.com/john30/ebusd/wiki...n#ebus-options) justieren.

VG John

[olicat]

Hallo John,

Ich würde versuchen, die Potokollierung zu erhöhen und dann bei einem erneuten Vorfall den Verursacher zu finden.

vielen Dank fuer Deine Unterstuetzung.
Ich habe das jetzt mal ein paar Tage anhand der Logs ueberprueft und mehrere Beispiele gefunden, die das Problem verdeutlichen.
Die Ursache liegt wohl wirklich im ebusd begruendet.

Hin und wieder - offenbar bei Problemen auf dem Bus - erhaelt der ebusd falsche Werte, die er an die nachgeordneten Systeme weitermeldet. smarthome.py erhaelt diese Wertaenderungen, befuellt die entsprechenden KNX-GAs und schreibt (bei "write"-Werten) diese dann bei per ebusd in die Heizungsanlage.

In zeitlicher Naehe zu obskuren Wertaenderungen habe ich im ebusd.log Meldungen wie "notify request: ERR: read timeout" oder "ERR: arbitration lost".

Ein Beispiel fuer fehlerhafte Werte vom ebusd:

2016-10-18 04:58:26.134 [network debug] [00011] wait for result
[B]2016-10-18 04:58:26.134 [main debug] >>> read -c omu -f DeicingRuntimeMinutes[/B]
2016-10-18 04:58:26.134 [bus info] send message: ffe0b509030d5200
2016-10-18 04:58:26.150 [bus debug] switching from ready to send command
2016-10-18 04:58:26.206 [bus debug] switching from send command to receive command ACK
2016-10-18 04:58:26.210 [bus debug] switching from receive command ACK to receive response
2016-10-18 04:58:26.276 [bus debug] notify request: ERR: read timeout
2016-10-18 04:58:26.276 [bus debug] ERR: read timeout during receive response, switching to skip
2016-10-18 04:58:26.276 [bus error] send to e0: ERR: read timeout, retry
2016-10-18 04:58:26.319 [bus debug] ERR: arbitration lost during ready, retry
2016-10-18 04:58:26.327 [update info] update BC cmd: 10feb505034a0100
2016-10-18 04:58:26.327 [update notice] unknown BC cmd: 10feb505034a0100
2016-10-18 04:58:26.419 [bus debug] switching from ready to send command
2016-10-18 04:58:26.475 [bus debug] switching from send command to receive command ACK
2016-10-18 04:58:26.480 [bus debug] switching from receive command ACK to receive response
2016-10-18 04:58:26.504 [bus debug] switching from receive response to send response ACK
2016-10-18 04:58:26.511 [bus debug] notify request: done
2016-10-18 04:58:26.511 [bus debug] read res: 04be050000
2016-10-18 04:58:26.511 [bus debug] switching from send response ACK to send SYN
2016-10-18 04:58:26.513 [main info] read omu DeicingRuntimeMinutes: 67110334
[B]2016-10-18 04:58:26.514 [main debug] <<< 67110334[/B]

eine Minute spaeter klappt es dann besser:

[B]2016-10-18 04:59:27.834 [main debug] >>> read -c omu -f DeicingRuntimeMinutes[/B]
2016-10-18 04:59:27.835 [bus info] send message: ffe0b509030d5200
2016-10-18 04:59:27.845 [bus debug] switching from ready to send command
2016-10-18 04:59:27.902 [bus debug] switching from send command to receive command ACK
2016-10-18 04:59:27.907 [bus debug] switching from receive command ACK to receive response
2016-10-18 04:59:27.931 [bus debug] switching from receive response to send response ACK
2016-10-18 04:59:27.938 [bus debug] notify request: done
2016-10-18 04:59:27.939 [bus debug] read res: 04be050000
2016-10-18 04:59:27.940 [bus debug] switching from send response ACK to send SYN
2016-10-18 04:59:27.942 [main info] read omu DeicingRuntimeMinutes: 1470
[B]2016-10-18 04:59:27.942 [main debug] <<< 1470[/B]

Fragen:
Macht der ebusd irgendwelche Plausibilitaetspruefungen? Er muesste doch bei CRC-Fehlern die entsprechende Nachricht verwerfen, oder?

Was kann ich tun, um die Buskommunikation zu stabilisieren? Ich habe hier - im Debug-Modus des ebusd - innerhalb eines Tages 65 Meldungen "ERR: read timeout, retry" (fuer 08, 50 und 0E) und 3717 (!) "ERR: arbitration lost"-Fehler.
Deuten die Fehlermeldungen eher auf schlechte Justage des eBus-Adapters, die Verkabelung oder zuviel Traffic hin?

Ich frage etliche Werte (ca. 50) der Heizungsanlage ab - gibt es beim ebusd eine max. Anzahl von Abfragen, die man nicht ueberschreiten sollte?

Kann ich per eval innerhalb von smarthome.py eine Plausibilitaetspruefung durchfuehren, so dass die durch den ebusd gelieferten fehlerhaften Werte verworfen werden?

Viele Gruesse, Oliver