Erweiterung Helios / Vallox Plugin

[Tom Bombadil]

Habe beide Fälle noch nicht ausprobiert, da diese für die bis jetzt programmierten Logiken noch nicht relevant waren.

Sowohl Vallox als auch Helios beschreiben unabhängig voneinander die Register B0 und B1 als "DC type fan adjustment %" und als r/w-Register.

Die Sache mit dem on/off ist hier auch komisch - evtl. ist das nicht für alle Anlagen verfügbar. Register 08 ist auch nur in der Vallox-Doku erwähnt, in der von Helios fehlt es (wie so vieles andere auch). Bit 3 Zuluftventilator, Bit 5 Abluftventilator.

Werd da demnächst auch mal ein wenig rumspielen, das erfordert wohl noch etwas Forschungsarbeit ...

/tom

[philipp80]

So, noch kurz zu den beiden Punkten:

zu 1) inzwischen tut es. Ich hab beim ersten Test 128 in das Register geschrieben, weil ich davon ausgegangen bin das 100%=255. Wenn ich 50 reinschreibe funktioniert es.

zu 2) Der Befehl funktioniert schon, beim Auslesen von dem Register ist Flag entsprechend gesetzt. Nur ist eben nach dem Schreiben eine kurze Gedenkpause angesagt.

[Tom Bombadil]

Nur ist eben nach dem Schreiben eine kurze Gedenkpause angesagt.

Evtl. setzt die Anlage den Bus für alle Teilnehmer kurze für Zeit auf 'Listen only', um weitere Kommandos während des Ausschaltvorganges zu blocken. Das wird beim Auslesen der CO2-Sensoren auch so gemacht.

Hierzu werden die Register 0x91 (Ruhe am Bus!) und 0x8F (Weiterreden!) benutzt ...

Hast Du eine ungefähre Zeitdauer, wie lange der Bus schweigt? Das werde ich dann in der Logik entsprechend berücksichtigen ...

/tom

[volvog]

Also ich kann definitiv bestätigen, dass die FB mit eingeschaltet wird, wenn die Lüftung per KNX eingeschaltet wird.
Wenn z.B. ein Fenster länger als 30s geöffnet ist, schalte ich die Lüftung komplett ab. Dann wird auch die FB dunkel. Ich kann dann die Anlage per KNX oder FB wieder einschalten, führt zum gleichen Ergebnis.

Viele Grüße,
Volker

[gkwlm]

Hallo,
ist zwar noch nicht Weihnachten - trotzdem hier mal für alle, die mit ihrer Helios / Vallox herumspielen wollen, ein vollständiger Stand von Plugin und Widget.

Mittlerweile war Weihnachten, und über das geschenkte __init__.py habe ich mich schonmal sehr gefreut - es macht bereits fast alles, was ich glaubte, erst noch selbst basteln zu müssen. Da ihr hier schon ganze Arbeit geleistet habt (Danke!), muss ich das Rad nun nicht nochmal neu erfinden.

Ein paar Dinge verstehe ich aber noch nicht, hier mal zunächst der Output meiner KWL:

bypass_disabled = 1
max_fanspeed = None
inside_temp = 22
fan_out_percent = 90
incoming_temp = 20
boost_setting = 1
boost_remaining = 0
min_fanspeed = 2
fan_out_on_off = 0
outside_temp = 3
fan_in_percent = 100
clean_filter = 3
fan_in_on_off = 0
bypass_temp = 10
power_state = 1
exhaust_temp = 8
fanspeed = 2
device_error = 0
boost_status = 0
boost_on = 0

und nun meine Fragen:

Was bedeutet da z.B. eine max_fanspeed mit Wert "None"? Das taucht auch bei fanspeed selbst gelegentlich auf.

Gehen die fan_XXX_on_off (es lässt sich nicht ganz so leicht überprüfen), oder muss ich über die Prozente z.B. den Kaminbetrieb (Abluft aus, Zuluft an) realisieren? Bei mir laufen derzeit sicherlich beide Fans, aber da steht als Status 0?

fan_XXX_percent kann ich lesen, aber beim schreiben kriege ich "Exception in writeValue() occurred: unsupported operand type(s) for +: 'int' and 'str'".
-Was mache ich falsch (oder ist das noch ein Bug)?

Was bedeuten boost_setting/status/on? (remaining ist klar, zählt 45min runter)

[Tom Bombadil]

Was bedeutet da z.B. eine max_fanspeed mit Wert "None"? Das taucht auch bei fanspeed selbst gelegentlich auf.

Eventuell ist max_fanspeed in Deiner Anlage nicht gesetzt. In den allermeisten Fällen dürfte der Wert wohl auf 8 stehen.

Warum NONE allerdings auch beim fanspeed auftaucht, kann ich nicht erklären - das könnte nur der Fall sein, wenn die Anlage ausgeschaltet ist.

Gehen die fan_XXX_on_off (es lässt sich nicht ganz so leicht überprüfen), oder muss ich über die Prozente z.B. den Kaminbetrieb (Abluft aus, Zuluft an) realisieren? Bei mir laufen derzeit sicherlich beide Fans, aber da steht als Status 0?

Siehe Beitrag von Phillip weiter oben - scheint zu funktionieren, wurde aber von mir noch nicht weiter getestet, da diese erst bei der geplanten "Sommerlüftung" eine Rolle spielen werden.

fan_XXX_percent kann ich lesen, aber beim schreiben kriege ich "Exception in writeValue() occurred: unsupported operand type(s) for +: 'int' and 'str'".
-Was mache ich falsch (oder ist das noch ein Bug)?

Welche Werte versuchst Du genau zu schreiben? Funktionieren sollten 0 ... 100 (als reiner Int, ohne % dahinter).

Was bedeuten boost_setting/status/on? (remaining ist klar, zählt 45min runter)

Boost_Setting (AA, bit 5): 0=Kaminlüftung, 1=Stoßlüftung (original Helios-Mode)
Boost_Status (71, bit 6): Stoßlüftung ist aus/an - read only
Boost_on (71, bit 5): Stoßlüftung aktivieren (write only, Anlage setzt selbst zurück)

Hoffe, das hilft Dir ein wenig weiter. Wenn ich mich auf der Zielgeraden zur Beta befinde, gibt's auch eine entsprechende Doku dafür.

/tom

[gkwlm]

Eventuell ist max_fanspeed in Deiner Anlage nicht gesetzt. In den allermeisten Fällen dürfte der Wert wohl auf 8 stehen.
Warum NONE allerdings auch beim fanspeed auftaucht, kann ich nicht erklären - das könnte nur der Fall sein, wenn die Anlage ausgeschaltet ist.

Beide haben eigentlich gesetzte Werte - muss nochmal genau schauen, wann das NONE auftaucht. Ich habe hier übrigens eine Helios KWL EC 300 Pro.

Siehe Beitrag von Phillip weiter oben - scheint zu funktionieren, wurde aber von mir noch nicht weiter getestet, da diese erst bei der geplanten "Sommerlüftung" eine Rolle spielen werden.

Sie (fan_XXX_on_off) gehen anscheinend, aber eben invertiert (1=aus). Jedenfalls geht "fan_out_on_off" auf 1 bei Kamintaster.

Welche Werte versuchst Du genau zu schreiben? Funktionieren sollten 0 ... 100 (als reiner Int, ohne % dahinter).

z.B. so:
__init__.py -w fan_out_percent -v 90
2014-12-29 01:10:13,420 - root - ERROR - Helios: Exception in writeValue() occurred: unsupported operand type(s) for +: 'int' and 'str'

Boost_Setting (AA, bit 5): 0=Kaminlüftung, 1=Stoßlüftung (original Helios-Mode)
Boost_Status (71, bit 6): Stoßlüftung ist aus/an - read only
Boost_on (71, bit 5): Stoßlüftung aktivieren (write only, Anlage setzt selbst zurück)

Danke, das klärt einiges. Gibt es eine Möglichkeit, den Boost abzubrechen, oder die Zeit zu verkürzen?
Außer jetzt manuell fanspeed und/oder fan_out_on_off zu setzen, was offenbar durchaus geht - aber nicht den Timer stoppt.

[Tom Bombadil]

Ich habe hier übrigens eine Helios KWL EC 300 Pro.

Passt, hier auch.

Sie (fan_XXX_on_off) gehen anscheinend, aber eben invertiert (1=aus). Jedenfalls geht "fan_out_on_off" auf 1 bei Kamintaster.

Ja, dieses Verhalten wurde schon früher bestätigt. Geht der Bus bei Dir nach Schaltung dieser Register auch kurzeitig in der Ruhezustand?

z.B. so:
__init__.py -w fan_out_percent -v 90
2014-12-29 01:10:13,420 - root - ERROR - Helios: Exception in writeValue() occurred: unsupported operand type(s) for +: 'int' and 'str'

Hmmm, das sollte nicht passieren. Grundsätzlich scheint es zu gehen, siehe Post #17. Allerdings nutze ich die Konsole äußerst selten - vielleicht muss hier noch ein Typ spezifiziert werden, oder der Parameter muß im Plugin explizit nach Int gewandelt werden. Muss ich mir bei Gelegenheit mal anschauen ...

Danke, das klärt einiges. Gibt es eine Möglichkeit, den Boost abzubrechen, oder die Zeit zu verkürzen?
Außer jetzt manuell fanspeed und/oder fan_out_on_off zu setzen, was offenbar durchaus geht - aber nicht den Timer stoppt.

Meines Wissens nicht - daher wird das Plugin bzw. Widget ja auch 3 Möglichkeiten der Stoßlüftung enthalten (Original Helios, einfache Logiksteuerung über simplen Button/sh.py-Timer (abschaltbar), erweiterte Logiksteuerung mittels Popup (inkl. Kaminfunktion, abschaltbar).

/tom

[gkwlm]

Geht der Bus bei Dir nach Schaltung dieser Register auch kurzeitig in der Ruhezustand?

Weiß nicht, woran würde ich das bemerken?

Hmmm, das sollte nicht passieren. Grundsätzlich scheint es zu gehen, siehe Post #17. Allerdings nutze ich die Konsole äußerst selten - vielleicht muss hier noch ein Typ spezifiziert werden, oder der Parameter muß im Plugin explizit nach Int gewandelt werden. Muss ich mir bei Gelegenheit mal anschauen ...

Ich werd mal in den Code schauen, aber Python ist leider nicht so mein Spezialgebiet.

Meines Wissens nicht - daher wird das Plugin bzw. Widget ja auch 3 Möglichkeiten der Stoßlüftung enthalten (Original Helios, einfache Logiksteuerung über simplen Button/sh.py-Timer (abschaltbar), erweiterte Logiksteuerung mittels Popup (inkl. Kaminfunktion, abschaltbar).

Ich bin ja hier mehr so von der Back-End-Seite dazugestoßen und habe mir das Front-end noch gar nicht so genau angesehen.
Soll heißen, auf der Suche nach Dokumentation des Protokolls bin ich über dieses Skript gestolpert. Das habe ich jetzt mal auf meinem RaspberryPi mit dem Webserver verbunden, so dass ich es mit URL-Parametern steuern kann. Der PI ist per USB/RS485-ADAPTER mit der KWL verbunden. Dazu habe ich noch eine rudimentäre iPhone-App gestrickt. Im Prinzip funktioniert's schon ganz gut, aber die Reaktionszeiten sind ziemlich lang. Ist das durch die niedrige Baudrate bedingt, oder läuft das auf'm PC schneller? Hier auf dem PI braucht ein einzelner Lesebefehl rund 0.85s, der komplette Statusabruf 2,5s. Daher überlege ich bereits, zumindest die Temperaturen zu cachen, denn die ändern sich ja nur langsam.... Wenn's hingegen nur die schlechte Performance des Python-Skriptes auf dem PI sein sollte, müsste ich das wohl nochmal in C nachbilden.

[philipp80]

Ich werd mal in den Code schauen, aber Python ist leider nicht so mein Spezialgebiet.

In dem Script in Zeile 258

rawvalue = value

durch

rawvalue = int(value)

ersetzen.

Gruss
Philipp

[gkwlm]

rawvalue = int(value)

Grrrr, jetzt hatte ich es gerade selbst gefunden und wollte genau dasselbe posten. :-)

Damit geht es dann natürlich auch. Was hattest Du/Ihr denn als Kaminfunktion geplant - fanspeed auf max und fan_out_percent auf null?

Die original Heliosfunktion ändert die fanspeed ja anscheinend nicht.

Mit fan_in_percent muss man übrigens aufpassen: wenn das auf null gehen sollte, dann saugt man sich Abgase aus dem Kaminofen in die Wohnung - bzw. in meinem Fall schaltet dann theoretisch der Druckwächter die KWL stromlos, und ich weiß noch nicht, wie ich die dann wieder an kriege. Möglicherweise nur durch umstecken in eine andere Steckdose und dann sofortiger Umprogrammierung, denn sobald sie wieder Strom kriegt, läuft sie ja mit den letzten Einstellungen wieder an - ein Teufelskreis....

[gkwlm]

Beide haben eigentlich gesetzte Werte - muss nochmal genau schauen, wann das NONE auftaucht. Ich habe hier übrigens eine Helios KWL EC 300 Pro.

Jetzt habe ich gerade den (realen) Stoßlüftungstaster gedrückt, und danach gingen beide Werte auf NONE. Die Fernbedienung zeigt aber weiterhin die richtigen an (Stufe 7 in diesem Fall). Dass beide bei Stosslüftung gleich sind, ist ja immerhin konsistent, nur NONE sollte es eigentlich nicht sein.

Im Debugmodus sehe ich folgendes:

2014-12-30 00:47:29,649 - root - DEBUG - Value for fanspeed (0x29) received: 0x7F|01111111|127 --> converted = None

2014-12-30 00:49:39,572 - root - DEBUG - Value for max_fanspeed (0xA5) received: 0x7F|01111111|127 --> converted = None

Das sollte eigentlich auf Stufe 7 abgebildet werden. Im Skript ist da tatsächlich ein Fehler:

            elif rawvalue == 0x7F: 
                rawvalue = 7

Das muss so lauten:

            elif rawvalue == 0x7F: 
                value = 7

Und dann geht es auch.

[Tom Bombadil]

Da macht man mal einen Tag Pause, und schon gibt's 2 Bugs - weiter so.

Anbei das gefixte Plugin.

In Sachen fan_in_percent: Den will ich für die Kaminfunktion eigentlich gar nicht anfassen. Ziel der Sache ist, die Abluft für eine vorgegebene Zeit zu reduzieren, damit ein Überdruck im Haus aufgebaut wird.

Geplant (und teilweise umgesetzt) ist folgendes: Grundsätzlich werden für die 'interaktive' Stoßlüftungs-/Kaminfunktion mehrere Items verwendet:

         [[[logics]]]
            name = Logikgesteuerte Stosslueftung
 
             [[[[switch]]]]
                name = Stosslueftung an aus
                type = bool
                visu_acl = rw
 
             [[[[level]]]]
                name = Stufe waehrend Stosslueftung
                type = num
                visu_acl = rw
                value = 8
  
             [[[[value_after_boost]]]] 
                name = Stufe nach Stosslueftung
                type = num
                visu_acl = rw
                
            [[[[boost_duration]]]]
                name = Dauer der Stosslueftung
                type = num
                value = 2700
                # cache = True
                visu_acl = rw
                
            [[[[fireplace_mode]]]]
                name = Kaminfunktion ja nein
                type = bool
                visu_acl = rw

Erst werden die verschiedenen Items in der Visu durch ein Popup mit Werten geladen (io.write - die % für die Fortlüftung fehlen noch, könnten aber z.B. auch durch eine Konstante in der Logik gelöst werden).

Die Kamin-/Stoßlüftung wird dann über das Item "switch" getriggert.

Da alles "von Hand" unter Umgehung der Helios-Funktion eingestellt wird, kann man die Stoßlüftung auch zu einem beliebigen Zeitpunkt wieder abbrechen (was bei Original-Helios nicht möglich ist).

Ich wäre schon gern weiter mit der Logik, bin aber auf ein Problem in der Visu gestoßen, das ich erst knacken möchte (io.read geht nicht, damit keine vernünftige Initialisierung der Radiobuttons für die Zeitdauern). Hab mal ein Bild angehängt, wie das dann ungefähr aussehen könnte - alles noch Bastelstadium, man verzeihe mir die "verwurschtelte" Darstellung.

/tom

[gkwlm]

... die Reaktionszeiten sind ziemlich lang. Ist das durch die niedrige Baudrate bedingt, oder läuft das auf'm PC schneller? Hier auf dem PI braucht ein einzelner Lesebefehl rund 0.85s, der komplette Statusabruf 2,5s.

Kann dazu jemand noch was erhellendes sagen? 0,85s würden ja im Prinzip für rund 800 übertragene Bytes reichen, gebraucht wird effektiv aber nur ein einziges. Ist der Rest wirklich Protokolloverhead und/oder Warten auf freien Bus?

Oder ist bloß bei mir auf dem Raspberry dieses Skript so langsam?

[Tom Bombadil]

Ich vermute, dass es eine Kombination aus

• allgemeiner Geschwindigkeit des Pi,
• programmierte Wartezeiten am RS485 ("nur Senden, wenn Ruhe am Bus"),
• Protokolloverhead,
• eingestellter Geschwindigkeit des RS485 (9600),
• nicht primär auf Geschwindigkeit ausgelegter Programmierung

ist (in dieser Reihenfolge).

Habe neben sh.py noch die Visu auf dem Pi am Laufen und muss auch jedesmal mehrere Sekunden warten, bis die Seite aufgebaut wird. Ist halt so, man gewöhnt sich dran.

Ob der Ansatz mit dem Caching funktioniert, kann ich nicht sagen - einen Versuch wäre es sicherlich wert. Auch kann man sicher die Items auf die gewünschten Informationen reduzieren, dadurch lassen sich sicher auch noch ein paar ms herausholen, denn es wird ja weniger über den Bus ausgelesen / übertragen ...

/tom