Helios KWL mittels RS485 an KNX

[tuxedo]

Wer hier fleissig mitliest weiß, dass ich da was gebastelt habe. Nun hat es einen Stand erreicht wo ich es vorzeigen kann. Es ist immer noch als BETA zu betrachten, aber im ersten Tests läuft es.

[UPDATE]
ACHTUNG, NEUER DOWNLOAD-LINK:

HeliosKwlRemote-1.0.0-SNAPSHOT-distribution.tar.gz
HeliosKwlRemote-1.0.0-SNAPSHOT-distribution.zip

[/UPDATE]

Aber worum geht's hier? Die Helios Lüftungsanlagen bieten meist eine RS485 Schnittstelle (siehe https://knx-user-forum.de/forum/%C3%B...C3%BCber-rs485). Diese Software, kombiniert mit ein klein wenig Hardware und einem vorhandenen IP-Router, macht die Lüftungsanlage KNX tauglich. Nicht über eine Kommandozeilenschnittstelle oder eine IP-Abfrage im Homeserver. Nein. Dank Calimero-KNX-Stack spricht das Ding direkt KNX. Setzt man den IP Router als "vorhanden" voraus, so belaufen sich die Kosten für den "DIY KNX Upgrade" der Helios Lüftungsanlage auf pi*Daumen 50EUR.

Voraussetzungen:

1a) RS485 Adapter, z.B. so einen hier: http://www.ebay.de/itm/PC-USB-auf-RS...item43da4d5a13
und einen Linux-fähigen Rechner, z.B. einen Raspberry Pi
und das ser2net Paket, mit dessen Hilfe man den USB-Adapter üer Netzwerk verfügbar macht (gleicher Effekt wie 1b)

oder

1b) Einen Moxa RS485->Ethernet Adapter: https://www.google.de/webhp?sourceid...rnet+konverter
oder vergleichbares. Gibt's auch bei Ebay aus China für wenig Geld (steht dann halt kein Moxa drauf)

2) Einen x-beliebigen (Kleinst-)Rechner mit Windows, Linux oder Mac. Kann auch der aus 1a) sein.
3) Eine Java JRE Laufzeitumgebung --> http://java.oracle.com
4) Die oben genannte Zip-File
5) einen IP-Router


ZIP entpacken. Darin sind zwei Files enthalten. Eine config.properties und eine JAR Datei.
Die Config-Datei ist weitgehend selbsterklärend. Man muss dort angeben auf welchem Host und Port der RS485-Adapter zu finden ist. Dann gibt es noch ein paar Default-Einstellungen für die Lüftung (hier muss man aber nicht unbedingt etwas ändern) und natürlich noch die einzelnen Kommunikationsobjekte und deren Gruppenadressen.

Jede mit "#" beginnende Zeile ist "auskommentiert", sprich "nicht aktiv" und zählt als Kommentar. Die KOs lassen sich einzeln nach Bedarf "einschalten".

Die config-File sollte im aktuellen Arbeitsverzeichnis liegen. Aufruf der Anwendung mit:

java -jar HeliosKwlRemote-1.0.0-SNAPSHOT-jar-with-dependencies.jar

Dann läuft die Anwendung los:

Apr 07, 2015 3:43:18 PM de.root1.helios.Helios connect
INFORMATION: Connecting...
Apr 07, 2015 3:43:18 PM de.root1.helios.Helios connect
INFORMATION: Connected!
Register listener for clean_filter on 3/6/15
Register listener for fanspeed on 3/6/0
Register listener for fan_in_percent on 3/6/9
Register listener for incoming_temp on 3/6/6
Register listener for device_error on 3/6/4
Register listener for power_state on 3/6/3
Register listener for fan_out_percent on 3/6/10
Register listener for boost_remaining on 3/6/11
Register listener for bypass_disabled on 3/6/14
Register listener for min_fanspeed on 3/6/2
Register listener for outside_temp on 3/6/5
Setting default: fanspeed -> 3
Register listener for inside_temp on 3/6/7
Register listener for max_fanspeed on 3/6/1
Register listener for bypass_temp on 3/6/13
Register listener for exhaust_temp on 3/6/8
Register listener for boost_on on 3/6/12
Setting individual address to 1.1.51
max_fanspeed = 8
boost_on = 0
fan_in_percent = 100
fanspeed = 3
outside_temp = 12
bypass_disabled = 1
boost_status = 0
device_error = 0
bypass_temp = 10
fan_out_percent = 100
fan_in_on_off = 0
power_state = 1
exhaust_temp = 18
incoming_temp = 14
boost_setting = 1
min_fanspeed = 1
inside_temp = 21
boost_remaining = -1
clean_filter = 4
fan_out_on_off = 0

Dann kann man mit den entsprechenden Gruppenadressen direkt mit KNX seine Lüftungsanlage abfragen und steuern.


Zukunftspläne:

* Überwachung der Werte und Senden der Werte bei Änderung
* Unter Umständen "KNX Tunnel Mode" als Alternative zum "Routing Mode"

Empfohlenes Setup:

* dedizierter Raspberry Pi oder vergleichbares
* USB-RS485 Stick
* Raspbian oder Debian Linux mit ser2net
* mind. Java 7
* KNX IP-Router


Bisher bekannte Macken:

* Schaltet man über die Software die Lüftungsanlage aus, so geht die Fernbedienung mit aus. Schaltet man die Lüftungsanlage über die Software wieder ein, bleibt die Fernbedienung aus, aber die Anlage läuft.

Ein Dank geht an die Entwickler des SmartHome.py Helios Scripts, welches mit als Vorlage diente und an die Calimero-Entwickler.
Den Source hab ich noch nicht angehängt, kann aber bei Bedarf angefordert werden. Werde aber in den nächsten Tagen wohl noch ein bisschen Projekt-Webseite um das Projekt drum herum stricken und damit dann alles zusammen veröffentlichen.

Lizenz: GPL


Viel Spaß damit...

[benji]

Bisher bekannte Macken:

* Schaltet man über die Software die Lüftungsanlage aus, so geht die Fernbedienung mit aus. Schaltet man die Lüftungsanlage über die Software wieder ein, bleibt die Fernbedienung aus, aber die Anlage läuft.

Hi,

tolles Projekt, auch wenn ich das KNX Gateway von Helios nutze werde ich diese Lösung demnächst für einen Bekannten in Betracht ziehen.
Die Macke mit dem Ausschalten besteht übrigens auch bei dem Helios Gateway.

Gruß Benjamin

[tuxedo]

Ein Update:

Die Config-File hat nun neue Parameter bekommen:

cache.keep = 10000
send_on_update = true

Damit lässt sich nun einstellen, wie lange Variablen-Werte der Lüftungsanlage gecached werden sollen. Das verhindert, das jede Anfrage die an die Anlage geht, eine Abfrage auf dem langsamen RS485 auslöst. Der Wert ist in Millisekunden anzugeben. 10000ms = 10sek. Erst wenn die letzte tatsächliche Abfrage älter ist als die angegebene Zeit wird erneut die Anlage befragt. Ansonsten wird der zuletzt bekannte Wert zurückgeliefert.

"send_on_update = true" überwacht die Werte in der Lüftungsanlage und sendet bei einer Veränderung eines Wertes ein entsprechendes Update auf der zugehörigen Gruppenadresse. Ausschalten mit "false".

Die Ausgabe beim Programmstart ist jetzt auch strukturierter:

2015-04-10 15:25:00.627 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Connecting to Helios KWL on 192.168.200.4:4000
2015-04-10 15:25:00.650 INFO [main] de.root1.helios.Helios.connect: Connecting...
2015-04-10 15:25:00.679 INFO [main] de.root1.helios.Helios.connect: Connected!
2015-04-10 15:25:00.866 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Initialize cache variables with 10000ms cache-keep-time
2015-04-10 15:25:00.871 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Starting SendOnUpdate thread
2015-04-10 15:25:00.874 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'clean_filter' on 3/6/15
2015-04-10 15:25:00.878 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'fanspeed' on 3/6/0
2015-04-10 15:25:00.879 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'fan_in_percent' on 3/6/9
2015-04-10 15:25:00.880 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'incoming_temp' on 3/6/6
2015-04-10 15:25:00.882 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'device_error' on 3/6/4
2015-04-10 15:25:00.883 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'power_state' on 3/6/3
2015-04-10 15:25:00.886 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'fan_out_percent' on 3/6/10
2015-04-10 15:25:00.887 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'boost_remaining' on 3/6/11
2015-04-10 15:25:00.888 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'bypass_disabled' on 3/6/14
2015-04-10 15:25:00.889 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'min_fanspeed' on 3/6/2
2015-04-10 15:25:00.891 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'outside_temp' on 3/6/5
2015-04-10 15:25:00.892 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Setting default: fanspeed -> 3
2015-04-10 15:25:00.906 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'inside_temp' on 3/6/7
2015-04-10 15:25:00.908 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'max_fanspeed' on 3/6/1
2015-04-10 15:25:00.909 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'bypass_temp' on 3/6/13
2015-04-10 15:25:00.910 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'exhaust_temp' on 3/6/8
2015-04-10 15:25:00.911 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'boost_on' on 3/6/12
2015-04-10 15:25:00.913 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Setting individual address to 1.1.51
2015-04-10 15:25:10.937 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'max_fanspeed' changed value from 0 to 8. :Sending update on 3/6/1
2015-04-10 15:25:11.048 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'fan_in_percent' changed value from 0 to 100. :Sending update on 3/6/9
2015-04-10 15:25:11.119 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'fanspeed' changed value from 0 to 3. :Sending update on 3/6/0
2015-04-10 15:25:11.173 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'outside_temp' changed value from 0 to 21. :Sending update on 3/6/5

Hab die File in oben genanntem Downloadlink aktualisiert.

Weitere ToDo-Liste:

* Einbau einer "StandBy" Gruppenadresse mit der man die Lüftung z.B. bei Abwesenheit runterfahren oder ausschalten kann
* Projekt-Webseite anlegen, Sourcecode hosten, ...

Gruß
Alex

[tuxedo]

Am WE ist mir aufgefallen dass das auslesen von bypass_disabled nicht funktioniert und boost_remaining sowie boost_status nicht so funktioniert wie es soll.

Hatte tatsächlich ein paar Adressen verdreht. Im gleichen Zuge ist mir (erneut) aufgefallen, dass die Helios-Anlage nach einer Stoßlüftung auf fanspeed_min runter fährt, statt da weiter zu machen wo man vor der Stoßlüftung war. Hab das in die Anwendung nun mit eingebaut und konfigurierbar gemacht.
Fehlt nur noch der Punkt mit dem zeitweise herunterfahren/abschalten der Anlage wenn keiner daheim ist. Kommt als nächstes...

Gruß
Alex

[tuxedo]

So, auch das wäre erledigt. Tool läuft seit 24h fehlerfrei.

Damit wäre das Feature-Set nun wie folgt:

* Automatisches Senden von Werte-Updates wenn sich Werte ändern, ein-/ausschaltbar
* Abgefragte Werte lassen sich cachen, so dass nicht jede Werteabfrage zu einer erneuten "Belastung" des RS485 Buses wird, frei konfigurierbar
* ursprüngliche Lüftergeschwindigkeit nach einer Stoßlüftung wiederherstellen (statt auf fanspeed_min zurück zu fallen), ein-/ausschaltbar
* StandBy Modus: per KNX-GA die Anlage in StandBy versetzen: Entweder Anlage abschalten, oder Lüfter auf ein definierbares Minimum herunter fahren. Ideal um bei Abwesenheit Strom zu sparen aber ggf. nicht komplett auf die Lüftung (für den Abzug von Materialausdünstungen z.B.) zu verzichten.

Hier und da ist der Code noch unschön. Aber er funktioniert. Wenn ich ihn etwas aufgeräumt habe gibt's die Projekt-Webpage und den Sourcecode dazu.

Gruß
Alex

[tuxedo]

Da ich, bis auf Benji, offenbar der einzige bin den das hier interessiert, hab ich mich mal in Sachen "Projekt-Webseite" zurückgehalten uns bis dato nur den Source veröffentlicht:

https://github.com/tuxedo0801/HeliosKwlRemote

Lizenz: GPL v3

Als Abhängigkeit die über Maven noch nicht automatisch aufgelöst (weil im Central Repo nicht drin) wird, ist slicKnx zu erwähnen. Hierfür gibt's ein eigenes Projekt: https://github.com/tuxedo0801/slicKnx

Wer fragen dazu hat: Nur her damit.

[christianCR]

Ich bin gerade dabei das ganze auf einer virtualbox unter debian 7 für einen Test vorzubereiten. Das ganze wird dann an eine Helios KWL ET500 Pro angeschlossen. ich hoffe, das ich bis zum Wochenende die ersten Tests machen kann.

Gruß,
Christian

[starwarsfan]

Hi@all

Da ich, bis auf Benji, offenbar der einzige bin den das hier interessiert...

Dem ist definitiv nicht so! Ich verfolge das hier mit grossen Interesse, kann aber noch gar nichts machen, da unser Hausbau momentan im Endstadium ist. Ende Mai ist Einzug...

[tuxedo]

Super Sache. Schon drei Mitstreiter ;-)

Überlege schon ob es nicht Sinn macht das ganze auf einen Raspi zu klatschen und mit einer fertigen/vorinstallierten SD-Karte, sowie "einfacher" Webseite für die Konfiguration als "out out the box" Version "anzubieten". Quasi: Auspacken, anstecken, geht.

Aber dazu bräuchte es wohl erst noch mehr Interesse und vor allem noch ein paar Tester für die bestehende Software. Denn es gibt nix schlimmeres wie eine Software die "ab und an" nicht das tut was sie tun soll (nein, bisher läuft sie eigentlich fehlerfrei, ohne "reboot").

[christianCR]

Also was ich gestern schonmal rausgefunden habe, wenn ser2net noch nicht konfiguriert ist, und man trotzdem den Java Teil startet kommt noch eine unschöne Exception, wäre hier vielleicht sinnvoll, diese zu fangen und als eine für Anwender lesbarere Nachricht auf der Konsole aus zu geben.

Ich kann dir wenn du möchtest die VM geben, so das man diese dann ggf. auch zum download anbieten kann. Wäre dann für VirtualBox, man könnte diese aber auch unter VmWare laufen lasssen.

Gruß,
Christian

[tuxedo]

Ja, das Exception-Handling habe ich während der Entwicklung noch etwas stiefmütterlich behandelt. Da ist noch "room for improvement".

Die Sache mt der Vbox: Meinst du nicht das ist etwas "oversized"? Die Anwendung ist ja echt klein und läuft auch auf schwachen ARM-CPUs noch gut.

Wer mit Linux umgehen kann, wird sich kein Vbox/VmWare Image ziehen (ich weiß gar nicht warum alle so scharf auf VmWare sind... VirtualBox tut's doch?! Und ist einfacher... Aber --> andere Geschichte).

Für den Windows-User wäre wohl ein fertiges Zip oder ein Installer nicht schlecht. Aber da muss man noch eine ser2net Alternative suchen/finden/entwickeln (hätte da was am Anfang der Pipeline...).

Für Linux müsste entweder
a) ein zip/tar.gz reichen wo alles wichtige bis auf ser2net drin ist
oder
b) für den Einsteiger und gleichzeitig Stromsparer ein RaspiImage mit allem vorinstalliert und ggf. ein Webinterface für die Config
reichen.

Gruß
Alex

[christianCR]

Naja es kommt drauf an denke ich, was das "oversized" angeht. Ich habe zb. bei mir nur einen Server, welcher dann alle zusätzlichen Systeme bereitstellt (Communitygate, Visu und Logik Server, ETS, usw.) daher passt es bei mir etwas besser es als VM zu betreiben.
Ich hätte es jetzt auch einfach als zusätzliches Angebot gesehen, da es ja schon fertig zusammen gestellt wäre. (ich müsste nur die Passwörter ändern und dann noch auf DHCP umstellen)

Wenn ich dir neben dam Testen noch bei der Entwicklung helfen kann, ein klein wenig Zeit hätte ich dafür auch übrig.

Gruß,
Christian

[tuxedo]

Ich habe zb. bei mir nur einen Server, welcher dann alle zusätzlichen Systeme bereitstellt (Communitygate, Visu und Logik Server, ETS, usw.) daher passt es bei mir etwas besser es als VM zu betreiben.

Ich habe auch so einen zentralen Server. Aber ich habe da nicht alles separat in vielen VMs laufen, sondern das meiste im Linux direkt. "Oversized" wäre es, wenn es jeden Dienst in einer eigenen VM laufen lassen würde... Hier bräuchte ich ein vielfaches an RAM und CPU und am Ende auch Strom. Und gerade dieser eine Dienst ist wirklich "Mini". Der Overhead durch ein eigenes Betriebsystem/VM für diesen einen Dienst wäre "mit großkalibriger Munition Büffelmunition auf Fliegen geschossen".

Aber wenn du eine VM zusammen stellen willst: Gerne.

Wenn ich dir neben dem Testen noch bei der Entwicklung helfen kann, ein klein wenig Zeit hätte ich dafür auch übrig.

Auch gerne... Aktuell habe ich einen mehr oder weniger hässlichen Workaround beim lesen von Werten: Das geht manchmal schief und muss wiederholt werden. Schau mal in die Helios-Klasse in den read-Methoden.

Wenn du hier noch eine bessere Lösung findest (oder vllt. sogar den Fehler) wäre das super und würde das System ggf. schneller machen.

Auch bin ich allgemein am überlegen wie man das schneller machen könnte. Wenn ich z.B. den Fanspeed ändere, dauert es relativ lange bis ich die Änderung als "change" wieder sehe. Schade dass es hier kein Callback/Event gibt und man pollen muss. Wenn du hier noch eine Idee hast: Her damit.

Gruß
Alex

[tuxedo]

P.S. eine Feature-Erweiterung habe ich auch schon gefunden: https://knx-user-forum.de/forum/%C3%...567#post828567

Wäre ja super wenn man die KWL so bedarfsgerecht steuern könnte, ohne die originalen CO2 Sensoren zu verwenden. H

[tuxedo]

Hab mich heute etwas durch die finnische Doku von Vallox gekämpft. Dabei ist aufgefallen, dass wohl das falsche Register für "bypass_disabled" genutzt wurde.
Hab nach einem Hinweis hier aus dem Forum das Register mal gewechselt. Dabei dreht sich auch die Namens-Logik der Variable um. Aus "bypass_disabled" wurde bei mir nun bis auf weiteres "bypass". Ist der Wert 0, gibt es keinen Bypass und der Wärmetauscher ist aktiv. Ist der Wert 1, ist der bypass aktiv und der Wärmetauscher ist in der Sommerpause.

Daneben habe ich in der finnischen Originaldoku (Google Translate sei dank) auch entdeckt, dass es durchaus zu Lesefehlern kommen kann (welch wunder). In diesem Fall wird 10ms gewartet und dann der Wert nochmal angefordert. Das ganze geht bis zu 10x bevor es zu einem tatsächlichen Fehler-Status kommt. Es gibt also einen empfohlenen WOrkflow für diese Fehlersituation. Und den hab ich nun Code weitgehend identisch abgebildet.

Daneben ist mir noch aufgefallen, dass mein eigener Variablen-Cache auch noch bremst. Hab den jetzt mal von 60sek auf 1sek gedreht. 1sek ist verdammt wenig, reicht aber aus um zusätzlichen Stress aus dem System zu nehmen. Denn:

Hab diverse Delays im Code nun auf die Daten aus der DOku angepasst und schwups geht's auch mit dem Lesen einen Zacken schneller. Meist brauch ich rund 800ms für alle Variablen. Aber es kommt immer mal wieder zu Lesefehlern, weswegen die Zeit für den Dump aller Variablen auf 1-1,5sek steigt. Ist aber noch ganz passabel und passt einigermaßen zur obigen Cache-Zeit.