Erweiterung Helios / Vallox Plugin

[Tom Bombadil]

Hilfe für Troubleshooting erhältst Du ggf. auch im Wiki. Das Widget für die Visu ist nach wie vor noch Baustelle/unvollständig (insbesondere das Popup für die Einstellungen - die Hauptseite ist aber im Grunde fertig und funktioniert).
/tom

[Marcov]

hi tom - danke für Deine Antwort. Vom visualisieren bin ich noch etwas entfernt.
Ich erhalte unplausible Werte. Wenn ich es richtig verstehe, ist das hier die Abfrage für die Temperatur:

2017-12-09  17:45:22 DEBUG    Main         KNX[default]: 1.2.57 set 3/0/8 to 007575c4
2017-12-09  17:45:22 DEBUG    Helios       Helios: Sending telegram '0x01 0x2F 0x11 0x00 0x33 0x74' 

die Antwort darauf:

2017-12-09  17:45:22 DEBUG    Helios       Telegram received '0x01 0x11 0x2F 0x33 0x33 0xA7'
2017-12-09  17:45:22 DEBUG    Helios       Value for exhaust_temp (0x33) received: 0x33|00110011|51 --> converted = -18 

Ich habe nich nachgemessen, es ist aber in jedem Fall wärmer!
Das gleiche bei den anderen Temperaturwerten.

Ich habe kein Netzwerkkabel verwendet, daran sollte es aber meiner Meinung nach nicht liegen, ggf. verwendet meine Anlage ein anderes Protokoll? Ist so etwas bekannt?

[Tom Bombadil]

Am Kabel sollte es nicht liegen - ich hab A/B bei mir sogar eine Zeitlang problemlos über 1.5er NYM am Laufen gehabt.
ie Kommunikation scheint grundsätzlich zu laufen, sonst wären Errors im Logfile.
Ist alles richtig verkabelt? Evtl. Sensor defekt? Was sagen die Werte im Backend?
Und: Über welche Anlage reden wir hier überhaupt?

/tom

[Marcov]

Hi Tom,
also es ist nichts angeschlossen außer der USB Schnittstelle, da ich über keinen Raumcontroller / Fernbedienung verfüge, ist dieser auch nicht angeschlossen.
Es ist eine Vallox 130D, hierfür finde ich so gut wie keine Dokumentation, die zum Serienumfang gehörende Fernbedienung ist die FBD 370 (die ist auch bei der digit SE dabei).
Im FHEM Forum gibt es hierzu auch eine Diskussion, das schient aber ein anderes Problem zu sein:
https://forum.fhem.de/index.php?topic=71325.0
Also die Werte im Backend sind konstant und bei jeder Abfrage falsch und zwar von allen Temperaturangaben.
_device_error ist 6 ("CO2-Alarm:CO2-Wert >5.000 ppm seit mehr als 3 Minuten:Ursache ermitteln oder ggf. Sensor überprüfen lassen.")

ggf. liegt es daran, dass er von der Fernbedienung keinen CO2 Wert erhält (bin aber nicht sicher, ob die FBD 370 überhaupt einen Co2 Sensor hat).
Ich kann folgende Dinge tun:
Anlage an/aus (_power_state)
Ventilationsstufen (_fanspeed)

[Tom Bombadil]

Wenn ich den FHEM-Beitrag beim Querlesen richtig verstanden habe, gibt es bei einigen älteren Anlagen ein anderes Protokollverhalten.
Leider werden keine Details geliefert, was genau zu tun ist, um das Problem zu beheben.
Das muss ich erstmal sacken lassen - keine Ahnung, ob ich dafür kurzfristig eine Lösung finde (kann es halt hier nicht sniffen/testen) ...
/tom

[Marcov]

hi Tom, danke, ich habe es auch nicht genau rausgefunden, frage dort aber mal nach

[Marcov]

hi, aus dem FHEM Forum habe ich folgende Infos:

"29" => "FanSpeed" - Passt

"A3" => "Select" - Sieht gut aus. Das Symbol für den "Wärmetauscher" sieht eher nach der Heizung im Gerät aus. Dazu würden die Readings HeatingState und HeatingIndicator (links die Taste und Rechts die LED) und das A4 passen. Was sagt das Handbuch der Fernbedienung denn genau?

"A4" => "HeatingSetPoint" - Hier hat man die Interpretation der Werte geändert. Das sind keine Temperaturen sondern Stufen wie beim FanSpeed:
01: 1 (10°)
03: 2
07: 3
0F: 4
1F: 5 (20°)
3F: 6
7F: 7
FF: 8 (27°)

folgende Werte sind dort noch unbekannt:

"49" => "Legacy49", # Unknown legacy Reading
"4A" => "Legacy4A", # Unknown legacy Reading
"4C" => "Legacy4C", # Unknown legacy Reading
"53" => "Legacy53", # Unknown legacy Reading
"54" => "Legacy54", # Unknown legacy Reading
"58" => "Legacy58", # Unknown legacy Reading
"5A" => "Legacy5A", # Unknown legacy Reading
"5B" => "Legacy5B", # Unknown legacy Reading
"5C" => "Legacy5C", # Unknown legacy Reading

dank Heißluftfön habe ich die Temperaturwerte identifizieren können:
58 -> Zuluft von Außen
5A -> Abluft Wohnung
5B -> Zuluft Wohnung
5C -> Außen Abluft

[Tom Bombadil]

Hast Du die Register 58...5C mal in der __init__.py des Plugins geändert (dort: 32...35)? Hinterher bitte __pycache__ löschen. Die Temperaturen sind ja eh read-only, kann also eigentlich nix kaputtgehen. A4 klingt auch nicht weiter wild, sind halt Temperatursprünge von 2.5°C ...
/tom

[Marcov]

Hi Tom,

ja habe ich gemacht und es so abgeändert (läuft so):

"outside_temp"    : {"varid" : 0x58, 'type': 'temperature',  'bitposition': -1, 'read': True, 'write': False },#working
"exhaust_temp"    : {"varid" : 0x5c, 'type': 'temperature',  'bitposition': -1, 'read': True, 'write': False },#working
"inside_temp"     : {"varid" : 0x5A, 'type': 'temperature',  'bitposition': -1, 'read': True, 'write': False },#working
"incoming_temp"   : {"varid" : 0x5B, 'type': 'temperature',  'bitposition': -1, 'read': True, 'write': False },#working 

Ich versuche noch mal die anderen Variabeln usw. herauszufinden und gebe dann Bescheid, dann könnte man in der Plugin.conf ggf. neben der Standardversion auch eine andere Version einstellen und so die alten Anlagen steuern / auslesen.

[Tom Bombadil]

Danke für die Rückmeldung - meine Überlegung ist, dann wie bei FHEM die Sache über einen Parameter in der plugin.conf zu steuern, so dass die Werte auf den dafür vorgesehenen Variablen landen. Sofern da keine Überlappungen sind (hab beim Überfliegen keine gesehen), braucht es vielleicht nicht einmal den Parameter, sondern nur ein paar case bzw if-Anweisungen ...
/tom

[Marcov]

Ja, ich habe auch bei Vallox nach der Dokumentation gefragt, bin aber nicht sicher, ob sie sie rausrücken. Da ich ja leider keine Fernbedienung mehr habe, kann ich es nur begrenzt mitlesen und daraus ableiten, ich glaube aber im FHEM Forum ist man da schon weiter, weil dort jemand mit Fernbedienung ist.

[ballaballa1556]

Hallo zusammen,

ich habe eine Vallox ValloPlus 510 SE, die ich gerne an meine Hausautomation anbinden würde. Ich habe einen Raspberry Pi mit einem RS485-shield, an die ich die KWL angeschlossen habe (siehe auch hier). Mit Hilfe der __init__.py aus Toms Projekt funktioniert die Kommunikation auch grundsätzlich. Hier ein Beispiel:

python __init__.py -r fanspeed
Verwendeter Port: /dev/ttyAMA0
DEBUG:test:Helios: Connecting...
DEBUG:test:Helios: Reading value: fanspeed
DEBUG:test:Helios: Sending telegram '0x01 0x23 0x11 0x00 0x29 0x5E'
DEBUG:test:Telegram received '0x01 0x11 0x22 0x29 0x03 0x60'
DEBUG:test:Value for fanspeed (0x29) received: 0x03|00000011|3 --> converted = 2
fanspeed = 2
DEBUG:test:HeliosBase: Disconnecting...

Allerdings bin ich nicht in der Lage, Werte zu setzen. Setze ich z. B. folgenden Befehl ab:

python __init__.py -w fanspeed -v 3
Verwendeter Port: /dev/ttyAMA0
DEBUG:test:Helios: Connecting...
DEBUG:test:Helios: Sending telegram '0x01 0x23 0x20 0x29 0x07 0x74'
DEBUG:test:Helios: Sending telegram '0x01 0x23 0x10 0x29 0x07 0x64'
DEBUG:test:Helios: Sending telegram '0x01 0x23 0x11 0x29 0x07 0x65'
DEBUG:test:Helios: Sending telegram '0x65'
DEBUG:test:HeliosBase: Disconnecting...

und frage anschließend die Schnittstelle ab, bekomme ich dasselbe Ergebnis wie oben. Ich war bisher nicht in der Lage, irgendeine Einstellung der KWL auf diesem Weg zu ändern. Um auf dem Bus zu horchen, habe ich die __init__.py um eine Funktion erweitert, die eine vorgegebene Zeit lang alle Telegramme ausgibt, die mit 0x01 beginnen und an 5. Stelle eine zum Telegramm passende Checksumme haben. Dann habe ich die Lüfterstufe über das Bedienteil geändert. Die mitgeschnittenen Telegramme entsprechen exakt denen, die im Beispiel oben verschickt werden. Trotzdem ändert sich die Lüfterstufe nicht, wenn ich das ganze vom RasPi aus sende. Interessant an dem ersten Beispiel ist, dass ich als Sender '0x23' eingestellt habe, die Anlage aber mit '0x22' antwortet (Bei Absenderadresse 0x22 antwortet die Anlage mit 0x21). Könnte es sein, dass sich das shield erstemal irgendwie bei der Anlage anmelden muss? Es funktioniert übrigens auch nicht, wenn das Bedienteil mit der Adresse 0x22 aus ist und ich dann die Adresse des shields auf 0x22 setze...

Hat irgendjemand die gleiche Anlage wie ich und ist in der Lage, Werte zu setzen? Falls ja, wie? Oder hatte jemand mit einer anderen Anlage das gleiche Problem und es gelöst? Die Werte der Anlage auszulesen ist zwar ganz nett, aber ich wäre gerne in der Lage, die Anlage z. B. 2 Tage vor Rückkehr aus dem Urlaub auf 8 zu drehen... :-) Ich hoffe, Ihr seid noch aktiv, obwohl der letzte Kommentar fast 1 Jahr alt ist. Ich bin für jeden Hinweis dankbar!

Ich habe übrigens 2 Bedienteile. Hier kam schon mal die Frage auf, was passiert, wenn man nacheinander die beiden Bedienteile einschaltet. Ich hatte deswegen mal bei Vallox nachgefragt und die folgenden Abläufe beschrieben, wie sie tatsächlich sind:

• Die Anlage und beide Bedienteile sind aus.
• Bedienteil A wird eingeschaltet.
• Bedienteil B bleibt komplett aus (LED und Display).
• An Bedienteil A kann die Anlage nun beliebig eingestellt werden (z. B. auf Stufe 4), ohne dass Bedienteil B dadurch aktiviert wird.
• Bedienteil B wird eingeschaltet. Dadurch wird die Anlage automatisch auf Stufe 1 zurückgestellt. Bedienteil A übernimmt die Stufe 1 im Display.
• Wird nun an einem der beiden Bedienteile die Stufe verändert, übernimmt das andere Bedienteil die eingestellte Stufe.
• Wird die Anlage an einem der Bedienteile ausgeschaltet, schaltet sich das andere Bedienteil ebenfalls aus und der Ablauf beginnt von vorn.

• Die Anlage und beide Bedienteile sind aus.
• Bedienteil A wird eingeschaltet.
• Die Anlage wird mit Bedienteil A z. B. auf Stufe 3 gestellt.
• Die Anlage wird an Bedienteil A abgeschaltet.
• Bedienteil B wird eingeschaltet.
• Die Anlage startet auf der zuvor mit Bedienteil A eingestellten Stufe.

Als Antwort habe ich Folgendes erhalten: "Ihre Beschreibung entspricht dem was auch wir im Test bei uns auch festgestellt haben, somit liegt bei Ihnen kein Fehler vor." Ich habe dann nochmal nachgehakt und geschrieben, dass das Verhalten der beiden Bedienteile im Zusammenspiel ja so nicht korrekt sei und was sie gedenken, dagegen zu tun. Daraufhin erhielt ich folgende Antwort: "dieses Verhalten lässt sich leider nicht ändern, es ist Systembedingt". Falls immer noch Informationsbedarf besteht, ich probiere gerne alles nach Wunsch aus. Einfach schreiben, was ich ausprobieren soll...

Vielen Dank im Voraus und viele Grüße

Andreas

[Tom Bombadil]

Hallo Andreas,
zuerst einmal vielen Dank für die Bestätigung des Einschaltverhaltens. Nun ist also auch offiziell, was immer vermutet wurde.

Zum Script: Nutzt Du das Skript im Rahmen von smarthomeNG oder solo? Letzteres dürfte seit der Umstellung auf SmartPlugin recht tricky bzw. kaum noch möglich sein (ist eine Weile her, dass ich das getestet habe - müsste zu Hause nachsehen, was da genau damals los war, irgendwie kamen mir diverse Fehler um die Ohren geschossen).

/tom

[ballaballa1556]

Hallo Tom,

ich benutze das Skript aus der Kommandozeile heraus. Meine Hausautomation basiert ja auf einer WAGO-SPS, die ich per Modbus von einem RasPi aus anspreche. Auf dem läuft ein Webserver mit entsprechender Schnittstelle, die ich von einer Android-App aus anspreche. Ist alles komplett selbst programmiert. So kann ich auch vom Ende der Welt aus im Keller das Licht an- und ausknipsen... ;-) Und die Steuerung der KWL würde ich gerne in die App integrieren. Darum brauche ich eine Programmierung, die ich von PHP aus ansteuern kann. Ich hab mich noch nicht entschieden, ob ich - falls die Steuerung meiner Anlage irgendwann tatsächlich funktioniert - einfach Dein Skript von PHP aus aufrufe oder ob ich es nach PHP portiere. Darum kümmere ich mich, wenn es soweit ist. Es gibt auch für die SPS eine RS485-Schnittstelle, aber die ist teuer und dann müsste ich die Programmierung in der SPS machen. Und da brauche ich die Anbindung nicht, weil ich die KWL nicht über die SPS steuern will, sondern über die App. Darum die Anbindung direkt vom Webserver des RasPi aus. Ist ein Glied in der Steuerkette weniger...

Beim Start des originalen Skripts kamen mehrere Fehlermeldungen. Um es zum Laufen zu bringen, habe ich folgende Änderungen gemacht:

• Das Sonderzeichen aus dem Namen 'René' entfernt ;-)
• Die folgenden Zeilen eingefügt:
  

  logging.basicConfig(level=logging.DEBUG)
  logger = logging.getLogger('test')

• Den Parameter "SmartPlugin" aus Konstruktor entfernt:
  

   class HeliosBase():

• Überall '/dev/ttyUSB0' gegen '/dev/ttyAMA0' ersetzt
• Im 'getLogger'-Befehl '__name__' gegen 'test' ersetzt

Darüber hinaus habe ich noch die Bedingung entfernt, dass beim Lesen eines Telegramms die Zieladresse der Adresse des Senders entsprechen muss, da die KWL bei mir ja immer an die Adresse "Sendeadresse - 1" antwortet, wenn die Anfrage vom Shield kommt. Besonders aufwendig war es also nicht.

Später habe ich dann noch den Timeout in _readTelegram auf 3 Sekunden erhöht und den 'self._port.timeout' auf 0.007 gesetzt. Du hattest im Kommentar "Lets go with 7ms!" geschrieben, tatsächlich aber 70 ms verwendet. Ich bin nicht sicher, was das genau für Auswirkungen hat, aber Deine Berechnung ist ja korrekt (bis auf "1 Parity bit", oder?), darum habe ich das geändert. Und dann habe ich noch zwei Funktionen hinzugefügt, mit denen ich für eine vorgegebene Zeit einfach auf dem Bus lauschen kann und eine Ausgabe bekomme, wenn das empfangene Telegram mit 0x01 beginnt und die Checksumme des gesamten Telegramms passt. Das Folgende habe ich z. B. mitgeschnitten, als ich die Anlage vom Bedienteil aus abgeschaltete habe:

DEBUG:test:Telegram received '0x01 0x21 0x11 0x00 0xA3 0xD6'
DEBUG:test:Telegram received '0x01 0x11 0x21 0xA3 0x09 0xDF'
DEBUG:test:Telegram received '0x01 0x21 0x20 0xA3 0x08 0xED'
DEBUG:test:Telegram received '0x01 0x21 0x10 0xA3 0x08 0xDD'
DEBUG:test:Telegram received '0x01 0x21 0x11 0xA3 0x08 0xDE'
DEBUG:test:Telegram received '0x01 0x21 0x11 0xA3 0x08 0xDE'
DEBUG:test:Telegram received '0x01 0x21 0x11 0x00 0x29 0x5C'
DEBUG:test:Telegram received '0x01 0x11 0x21 0x29 0x01 0x5D'
DEBUG:test:Telegram received '0x01 0x21 0x11 0x00 0x35 0x68'
DEBUG:test:Telegram received '0x01 0x21 0x11 0x00 0x35 0x68'
DEBUG:test:Telegram received '0x01 0x11 0x21 0x35 0x9E 0x06'
DEBUG:test:Telegram received '0x01 0x21 0x11 0x00 0xA3 0xD6'
DEBUG:test:Telegram received '0x01 0x21 0x11 0x00 0xA3 0xD6'
DEBUG:test:Telegram received '0x01 0x11 0x21 0xA3 0x08 0xDE'
DEBUG:test:Telegram received '0x01 0x21 0x11 0x00 0x71 0xA4'
DEBUG:test:Telegram received '0x01 0x21 0x11 0x00 0x71 0xA4'
DEBUG:test:Telegram received '0x01 0x11 0x21 0x71 0x00 0xA4'
DEBUG:test:Telegram received '0x01 0x22 0x11 0x00 0xA3 0xD7'
DEBUG:test:Telegram received '0x01 0x11 0x22 0xA3 0x08 0xDF'
DEBUG:test:Telegram received '0x01 0x22 0x11 0x00 0x29 0x5D'
DEBUG:test:Telegram received '0x01 0x22 0x11 0x00 0x29 0x5D'
DEBUG:test:Telegram received '0x01 0x11 0x22 0x29 0x01 0x5E'
DEBUG:test:Telegram received '0x01 0x22 0x11 0x00 0x35 0x69'
DEBUG:test:Telegram received '0x01 0x22 0x11 0x00 0x35 0x69'
DEBUG:test:Telegram received '0x01 0x11 0x22 0x35 0x9E 0x07'
DEBUG:test:Telegram received '0x01 0x22 0x11 0x00 0xA3 0xD7'
DEBUG:test:Telegram received '0x01 0x22 0x11 0x00 0xA3 0xD7'
DEBUG:test:Telegram received '0x01 0x11 0x22 0xA3 0x08 0xDF'
DEBUG:test:Telegram received '0x01 0x22 0x11 0x00 0x71 0xA5'
DEBUG:test:Telegram received '0x01 0x22 0x11 0x00 0x71 0xA5'
DEBUG:test:Telegram received '0x01 0x11 0x22 0x71 0x00 0xA5'

Wie gesagt, abfragen lässt sich die Anlage, nur setzen kann ich keine Werte. Irgendeine Idee, woran das liegen kann?

Beim Befehl 'cat /dev/ttyAMA0' bekomme ich übrigens keine Ausgabe. Ist das normal oder muss da immer was kommen? Wie gesagt, grundsätzlich antwortet die Anlage ja auf meine Lese-Anfragen, auch wenn ich oft erst beim 2. oder 3. Versuch etwas zurückbekomme. Aber ich glaube, das liegt an meiner Verdrahtung (KWL auf dem Dachboden, RasPi mit Shield im Keller). Darum würde ich auf Dauer auf den hier im Thread erwähnten Ethernet-Adapter umsteigen. Aber nur, wenn ich es schaffe, die Anlage auch darüber zu steuern statt sie nur abzufragen...

[Tom Bombadil]

Das Script wurde schon mal nach php (oder war's Java?) portiert, einfach mal die Sufu bemühen. Das dürfte Dir einiges an Arbeit sparen.

Ansonsten ist es im Moment schwer, mich in individuelle Modifikationen eines etliche Jahre alten Scriptes reinzudenken, dafür bräuchte ich mal ein paar ruhige Minuten echter 'Freizeit' (die ich derzeit mal wieder nicht habe).

Zum LAN-Adapter: Habe vor ca. 2 Monaten diesen Adapter in Betrieb genommen. Hierzu habe ich auf der Debian-Maschine, auf dem shNG läuft, zusätzlich von Hand einen socat-Daemon eingerichtet. Einziges Problem: Beide (socat-Daemon und shNG-Daemon) werden beim reboot gestartet, aber irgendwie bekomme ich keine automatische Verbindung zwischen den beiden. Erst nach einem manuellen "service smarthome stop" + "service smarthome start" wird die Verbindung sofort und problemlos aufgebaut (ist natürlich für Stromausfall & Co nicht sonderlich schön, sowas von Hand starten zu müssen). Ursache leider noch unbekannt ...

/tom