Helios KWL per ModbusTCP regeln/steuern

[Reliktdragon]

V1.3:

- Das Attribut time_level_limit ermöglicht jetzt das zeitabhängige Begrenzen der Lüfterstufe

Hinweis: Update von Script, Lüftungsanlage und Readingsgroup ist nötig!

Da es sich um überraschend komplexe Änderungen der Steuerlogik handelt, hoffe ich alles berücksichtigt und getestet zu haben. Sollte etwas "merkwürdig" sein, bitte bei mir melden. Danke!

Vielen Dank

Funktioniert super 

[hugomckinley]

V1.5:

- Der Name des Devices muss nicht mehr mit KWL beginnen, um in der ReadingsGroup angezeigt zu werden.
- Man kann die Lüftung jetzt manuell begrenzen (helios_limit_level()) -> siehe Anleitung erster Post

Hinweis: Update von Script, Lüftungsanlage und Readingsgroup ist nötig!
Achtung: Ein Update überschreibt alle bestehenden Attribute (z.B. Lüfterstufen, Zeitlisten)! Tipp: Vorher einen Screenshot der Attribute machen, um nichts zu verlieren.

[hugomckinley]

Moin Hugo,

habe gestern dein Script bei mir installiert. Klappt soweit schon mal ohne Fehlermeldung. Frage zu deinen Plänen.

1. Ich nutze die Luftfeuchtigkeit (1 Sensor Aussen und 1 Sensor Innen beides Homematik) um die Lüftung bei zu geringer Luftfeuchtigkeit im Haus runter zu regeln. Kannst du dir sowas auch vorstellen?
2. Ich habe einen Taster der die Anlage für 60 oder 120 Minuten komplett abschaltet. Das brauche ich, wenn der Nachbar mal wieder den Kamin angeworfen hat und ich den Gerucht mir nicht ins Haus holen will. Das lässt sich mit einen DOIF leicht steuern, aber ich dachte ich sag es mal Ist eigentlich nur das Gegenteil von den "WC-Lüftungs-Tastern", die du ja schon eingebaut hast.

Sonst danke für deine Arbeit und das Teilen, ich bin auf den Sommer gespannt und deine "Kühlfunktion".

Gruss
  Enno

Hallo Enno,
die aktuelle Version sollte deine Wünsche halbwegs erfüllen. Wenn du noch mehr Eingriff haben möchtest, so kannst du mit:

Code Auswählen Erweitern

setreading DeviceName manual_limit 2
{helios_calc_level("DeviceName")}
die Lüftung händisch auf Level 2 begrenzen.
Mit:

Code Auswählen Erweitern

setreading DeviceName manual_limit none
{helios_calc_level("DeviceName")}
wird Begrenzung wieder über die Automatik wieder freigegeben.

Ich hoffe das passt so.

Grüße
Hugo

[HausHH]

Hallo Hugo,

in der Versionshistorie steht für die Version 1.4 ein Wechsel von Event-on-update-reading auf Event-on-change-reading. Da ich noch Version 1.3 eingesetzt habe, wollte ich diese Änderung gerne mitnehmen.
Nach einem Update stand bei mir aber immer noch alles auf Event-on-update-reading. Ich wusste nun nicht, ob das Update gezogen hatte und es wird ja innerhalb von FHEM auch keine Versionsnummer angezeigt - zumindest habe ich keine gefunden. Das macht die Kontrolle nicht einfach.
Ein Blick in die aktuelle 99_heliosUtils.pm zeigt aber, dass dort beides drinsteht: Zeile 120 Event-on-update-reading, Zeile 121 dann Event-on-change-reading, jeweils mit den gleichen Readings.
Vielleicht liegt es daran? Ich habe sogar Device, Readingsgroup und die ATs gelöscht und neu angelegt - keine Verbesserung an dieser Stelle. Da die Anzahl der Readings gegenüber vor dem Update deutlich zugenommen hat, gehe ich aber davon aus, dass ich jetzt definitiv die Version 1.5 im Einsatz habe.

Ich stelle also nun manuell um von *Update* auf *Change*. Vielleicht hilft ja der Hinweis, das Skript zu verbessern. Falls ich beim Update etwas falsch gemacht haben sollte, freue ich mich natürlich über einen Hinweis, um es nächstes Mal besser zu machen.
Vielen Dank jedenfalls für Deine Mühen, das Modul ist wirklich klasse! In Verbindung mit den diversen anderen Informationen in FHEM (Türen/Fenster auf, Anwesenheitsstatus, Feiertage, etc.) kann man da wirklich tolle Sachen mit machen.

Edith meint: wäre super, wenn die Readings v1035 und v1036 noch zur Verfügung stehen würden. Daraus könnte ich mir eine Push-Nachricht generieren, die mich informiert, wenn der Bypass verändert wird.

Grüße aus Hamburg
Helge

[hugomckinley]

Hallo Helge,
Danke für die Hinweise. Es hat etwas gedauert
Aber jetzt hatte ich Zeit dafür, denn ich wollte eine andere Änderung noch machen, die mich ein wenig geärgert hat.

Der Fehler mit dem doppelten Anführen der events ist behoben.

Die Readings v1035 und v1036 gibt es bereits, aber sie heißen v01035 und v01036.
Für die Funktion des Bypass würde ich aber das reading v02119 verwenden (offen = 1, geschlossen =0)

Versionsnummer ist immer im script ganz oben im Header ersichtlich. Ich wüsste nicht wo ich das sonst sinnvoll anzeigen könnte.


Grüße,
Hugo

[hugomckinley]

V1.7:

- Durch die Verwendung von fhem sleep ist das Perlmodul Data::UUID nicht mehr nötig. Ich habe zufällig bemerkt, dass jedes Erzeugen eines at's ein device im log generiert, was dazu führte, dass der Seitenaufbau beim Konfigurieren von Plots ewig dauert, da die Liste der verfügbaren devices extrem lang wird. Ist jetzt behoben durch die anonymen at's durch sleep
- Der bugfix von V1.4 für event-on-update-reading zu event-on-change-reading ist nun tatsächlich wirksam

V1.6:

- Wenn der Bypass geschlossen ist, wird in den Zeitbetrieb umgeschaltet, da sonst sinnlos Strom verbraucht wird.

Hinweis: Update von Script und Lüftungsanlage ist nötig!
Achtung: Ein Update überschreibt alle bestehenden Attribute (z.B. Lüfterstufen, Zeitlisten)! Tipp: Vorher einen Screenshot der Attribute machen, um nichts zu verlieren.

[Norbert.Roller]

Hi, ein tolles Modul, dass ich dank deiner Vorarbeit schnell aktivieren konnte, als mein KWL EC270W ETR endlich installiert war.

Die Steuerung der Anlage möchte ich über einen kleinen Touch-Bildschirm selbst machen. Hierzu habe ich einen Nextion Bildschirm mit einem ESP8266 und der ESPEASY Firmware vorbereitet. Es hängen dann als Sensoren noch CO² und Temp/Feuchte am ESP.

Als Funktionen habe ich Auto / Manuell, Lüfterstufen in Manuell 0-4, Party Mode, und einiges mehr vorbereitet.

Aus deinem Code habe ich auch schon die passenden Funktionen herausgesucht, nur an dem setzen der Externen Werte scheitere ich. Im FHEM-Reading sind diese sauber gesetzt, aber die Anlage reagiert nicht auf die Änderungen. Laut Anleitung sollte sich im Auto-Mode die Lüfterdrehzahl ändern. Habe sowohl stufig als auch stufenlos probiert. Im Manuell Mode kann ich die Lüfterstufen problemlos setzen.

Den CO² Sensor habe ich wie folgt versucht zu ändern und die Anlage müsste dann im Auto-Mode auf Lüfterstufe 4 springen.
{helios_reg("Helios_KWL_OG","v00128=2700.0")}

Irgendwann dämmerte es mir dann, dass die Werte nicht zur Helios gesendet werden und ich habe long_poll und short_poll um diese Werte (v00111, v00119, v00128) erweitert. Jetzt kann ich die Werte hineinschreiben. Allerdings bleiben sie nur kurz und danach sind es wieder "-" "Irgendwas ließt die Werte aus der Anlage zurück und diese waren somit auch nicht korrekt gesetzt.

Die Anlage reagiert nach wie vor nicht.

Kannst du mir bitte auf die Sprünge helfen ?

[hugomckinley]

Hallo Norbert,
die Anlage muss helios-seitig auf manuell stehen, nur so kann man von außen die Lüfterstufen umschalten (Ich bin mir ziemlich sicher, habe es aber nie versucht im Automatikmodus etwas zu schalten). Auto ist die sture Zeitautomatik von Helios.

long_poll und short_poll ist nur das Auslesen der Anlage, schreibt jedoch nichts.

Dein {helios_reg("Helios_KWL_OG","v00128=2700")} sollte schon auf der Anlage das Register setzen, wenn sie im manuellen Modus läuft und dieses Register beschreibbar ist.
Ob man den CO2 Wert so setzen kann weiß ich nicht.

Wo sind diese Minuszeichen zu sehen? Bei den Readings der drei Register?

Ich würde an deiner Stelle die Anlage von FHEM regelen lassen. Setz einfach die Lüfterstufe 4 per FHEM, das braucht ja nicht über die Automatik von Helios gehen.
Der Automatikmodus wird ja nicht mehr benötigt.

Gruß,
Hugo

[Norbert.Roller]

Die Lüfterstufen sind ja nicht mein Problem. Ich kann von FHEM auf manuell umschalten und die Stufen von FHEM problemlos setzen.

Mein Problem ist, dass es mir nicht gelingt die "Externen Werte" für Temperatur, Feuchte und CO² in die Helios zu schreiben.

Es sieht fast so aus, als seien diese Register nicht von extern zu beschreiben, aber der Helios KWL-CO2 macht ja auch nichts anderes. Also muss es gehen.

[Norbert.Roller]

Wer lesen kann ist klar im Vorteil. Sowohl in der Beschreibung der ,,Funktions- und Schnittstellenbeschreibung" als auch bei der Helios KWL KNX Beschreibung sind die externen Sensor Werte mit read only gekennzeichnet.

Zu setzen sind diese nur über die RS485, Digital genannte, Schnittstelle.

Das KWL-BEC Bedienteil kann auch nur die Sollwerte setzen und hat, entgegen meinem ersten Eindruck, selbst keine Sensoren.

Somit bleibt mir drei Optionen.
- Sensoren von Helios kaufen für 150€ das Stück und dann überall Kabel hinlegen 😒
- Die Steuerung wie initial beschrieben bauen und die Sensor Werte nur an FHEM senden und auf dem TFT anzeigen.
- Die Steuerung bauen und die Sensor Werte an FHEM senden und die Anlage im manuellen Mode über FHEM steuern.
Oder
RS485 Datenstrom emulierten. Ein zentrales Gateway an das einzige Kabel, das ich vom Dach heruntergelegt habe anschließen. Dann von mehreren Sensoren, die über WIFI verbunden sind, die Steuerung über das Gateway umsetzen. Vorteil wäre dabei, dass ich an vielen Stellen im Haus Sensoren verteilen könnte, die nur über Batterie versorgt werden. Im Falle der Temperatur und Feuchte und der Party/Koch/Toiletten Taster würden die Batterien / Akkus ewig halten.

Der Vorteil, ohne FHEM Steuerung, wäre die Automatik von Helios, wo sicherlich viel Knowhow drinsteckt was ich aktuell nicht habe.

Am Ende alles eine Zeitfrage.

Nochmals Danke, dass du das Modul entwickelt hast.

[hugomckinley]

Das klärt die ganze Sache natürlich auf. Ich dachte eher daran, dass man einen Sensor in der Anlage aktivieren muss, um die Register zu beschreiben, aber leider geht es ja gar nicht.

Ich wäre da ganz klar für die Regelung per FHEM, denn da ist alles schon "vorbereitet" durch dieses Modul. Und kosten würde es auch nichts
Hier kannst du dann auch beliebige Sensoren im Haus verteilen. Ich habe keine Sensoren, aber eine Menge Homematic-Taster im Haus verteilt.

Für diese Regelung ist nicht wirklich KnowHow nötig, denn wenn du meine Kühlfunktion anschaust, wäre die 1:1 umsetzbar für deine CO2 Regelung, mit dem Unterschied, dass die CO2 Konzentration statt der Temperatur verwendet wird. Durch die "Töpfe" der Regelung ist es auch möglich beides (Kühlung und CO2) geleichzeitig zu machen, denn welche der beiden Regelungen mit der Lüfterstufe nach oben fährt spielt ja keine Rolle und wenn die CO2 Regelung nach unten will/kann, aber es draußen noch Kühl ist, bleibt die Lüfterdrehzahl trotzdem hoch.
Ich unterstelle auch einfach mal, dass die Helios-Regelung auch nichts anderes macht, als die Luftmenge der CO2 Konzentration anzupassen, was sollte sie auch sonst machen.
Wenn die Steuerung nicht durch FHEM erfolgt, kannst du auch keine Funktionen dieses Moduls verwenden, da im Automatikmodus die Lüfterstufen ja durch die Helios-Regelung vorgegeben werden.

Gruß,
Hugo

[enno]

- Die Steuerung bauen und die Sensor Werte an FHEM senden und die Anlage im manuellen Mode über FHEM steuern.

Moin Norbert,

ich nutze Teile (Ideen) von Hugos Lösung. Bei mir sind im ganzen Haus einige Luftfeuchtesensoren (HM und Shelly), CO2 (Bosch und andere) und ein paar Taster (HM, Shelly, 1-wire) und Fenstersensoren (1-Wire) verteilt. Das ganze wird ständig nach den Gewohnheiten der Mitbewohner verfeinert, so dass die Steuerung fast ohne manuellen Eingriff funktioniert, sogar der Kamin wird inzwischen erkannt. Wenn ich das mit Helios Technik umgesetzt hätte, wäre ich ein Vermögen los und die Logik wäre vermutlich auch eher limitiert. Daher wie Hugo auch sagt, nutze lieber FHEM und eigene Sensoren.

Gruss
  Enno

[Norbert.Roller]

Hallo zusammen,
ich habe zwischenzeitlich reichlich Fortschritte gemacht.

Die Sensoren emuliere ich über einen Raspberry mit speziellem RS485 Head. Die Hauptarbeit, mit der speziellen Modbus Kommunikation, stammt allerdings nicht von mir, sondern Marc. 
Links:
https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/geb%C3%A4udetechnik-ohne-knx-eib/1198515-helios-kwl-easycontrols-modbus-telegramme-der-ftf
https://github.com/mb-repos/helios_modbus_sensor
Dem Raspberry sende ich die Sensor Werte aus FHEM mit dem UDP-Modul und dieser sendet mit I2C an den Head und dieser wiederum bedient den RS485/ Modbus.

Es sind 4x CO2, 4x VOC und 8x Temp/Humid Sensoren möglich, die alle in die Automatik der Helios einbezogen werden. Aus meiner Sicht eine optimale Lösung.

[Norbert.Roller]

Und jetzt meine Fragen zum nächsten Schritt:

Ich habe ein eigenes Bedienelement entworfen, das auf einem ESP07 (mit ESPEasy ) und einem Nextion Touch-Bildschirm basiert.
Hierbei sende ich die Buttons des Nextion Touch Bildschirm via ESPEasy an Fhem und mit deinem Modul an die Helios weiter. Das klappt auch problemlos.

Beim "Rückweg", also aktuelle(!) Einstellungen der Helios and das ESPEasy habe ich noch Probleme. Die readings ändern sich ja erst nach dem nächsten poll.

Nach den Änderungen der Paramter der Helios durch Fhem sende ich ein {helios_reg("Helios_KWL_OG","manual_poll")}. Das manual_poll habe ich auf eine Minimum Anzahl der v..... reduziert. Nur das was ich unbedingt brauche.

Nun das Problem:
Ich habe noch kein readings gefunden was entweder mitteilt, dass gerade ge-polled wird oder das der manual_poll gerade fertig ist.
Stur 10 Sekunden mit sleep warten geht sicherlich auch, ist aber nicht schön.

Bitte schubst mich mal in die richtiges Richtung.

Danke.

[hugomckinley]

Das neu Einlesen der Werte sollte nicht nötig sein, da helios_reg(vxxxxx=abc) das reading im Gerät setzt nachdem es übertragen wurde. Somit sollte ein Lesen des Readings den gesetzten Wert ergeben.

Gruß
Hugo