Fußbodenheizungssteuerung Eltako und Homematic (IP) Diskussion

[Doesenoeffner]

Hallo zusammen,

ich hoffe, ich habe das richtige Subforum erwischt.

Ich würde hier gerne mein bisheriges FHEM Projekt vorstellen und bin interesstiert an Diskussion und Verbesserungsvorschlägen. Wie hättet ihr das gelöst? Was klingt ungewöhnlich? Wo habe ich evtl. Konventionen ignoriert? Was ginge besser?
Am Ende kann aus dem Thread dann gerne ein Wiki-Eintrag werden.


Teil 1: Aller Anfang ist Hardware

Ausgangslage des Projekts: 2 Wohnungen, 11 Heizkreise mit Ventilen (230V Normally Closed [NC]), 1 Umwälzpumpe 230V, CosiTherm Ventilsteuerung, 7 AlphaEOS Sense, 1 Alpha EOS Drive, 2 Alpha EOS Base (1 je Wohnung)
Problem: 1 Alpha EOS Base ist seit November eingeschickt und es antwortet dort niemand mehr, die Wohnung oben soll vermietet werden.

Gesucht: Eine Automatisierung, die herstellerunabhängig ist.

Hardware Final Version (mit Erklärung):
Server: Raspi 3b+ (verfügbar, genug Rechenleistung für piVCCU3 120€)
Stromversorgung 2A (wird dringend empfohlen), Gehäuse (For the Lookz!)
Sensoren/Wandthermostate:
HM-MOD-RPI-PCB Funkplatine (Einbindung von Homematic/HomematicIP 20€)
HMIP-STH (Homematic IP Funk, Temperaur- und Feuchtigkeitssensor, Heizprofile; ohne Display->billiger, 33€ je)
HM-TC-IT-WM-W-EU (Homematic Funk, Temperaur- und Feuchtigkeitssensor, Heizprofile einstellbar am Sensor, manuelle Regelung am Sensor, je 80€)
Aktorik:
Eltako FSR14-4x (zum Schalten der Pumpe und Ventile, 4 Relais je Baugruppe, je 52€)
Eltako FAM14 (BUS-Master, Zugriff per PCT Software, 100€)
Eltako FGW14-USB-RS485 (Zugriff per USB/ Gateway ans FHEM, 60€) *
Eltako FTD14 (BUS-Duplizierer - wird gebraucht, um auch tatsächlich ins EnOcean Netz zu senden,100€)
Mini-Sicherungskasten mit Hutschiene (220V Kabel sollten nicht offen zugänglich sein)

Warum Eltako und Homematic (IP)?
Die Wohnung Oben soll bald wieder vermietet werden und für große Eigenentwicklungen\Test war zu wenig Zeit gegeben. Die beiden Systeme schienen sich laut Wiki und Formum bewährt zu haben und out-of-the -box zu funktionieren.

Warum verwendest du 2 verschiedene Thermostate\Sensoren?
Der Gedanke war, in der Mietwohnung Oben die Steuerung komplett über die Thermostate zu regeln (inkl. Wochenprogramm), um keinen zweiten FHEM Server zu betreiben (bei zweitem FHEM server hätte man die Pumpe synchronisieren müssen und evtl. mehrere BUS-Systeme für die Steuerung verwenden müssen). Die Untere Wohnung kommt mit Steuerung per Browser zurecht.
Benutzerverwaltung per FHEM scheint nicht unterstützt zu werden.

Lessons-Learned Hardware 1:
Man braucht ein FAM14, selbst, wenn man gar nicht senden will, zur BUS Verwaltung. Das Modul enthält auch praktischerweise direkt ein Netzteil. Hätte man bei kritischerem Lesen der Doku wissen können.

Lessons-Learned Hardware 2:
Anfangs hatte ich mit "Homematic IP Wandthermostat – basic" für oben geplant (je 50€). Leider kann man bei denen nicht direkt am Display die Heizpläne ändern. Dies geht nur mit App und Gateway. Also wieder zurückgeschickt und auf HM-TC-IT-WM-W-EU gewechselt.

Lessons-Learned Hardware 3:
Der Eltako Bus kann zwar mit EnOcean Sensoren kommunizieren, sendet aber keine Telegramme ins Funknetz, um Aktoren schalten zu können. Hierfür ist ein Eltako FTD14 Bus Duplizierer nötig (ca 100€). Ich teste den, der wird aber eventuell noch durch einen billigeren EnOcean fähigen USB-Stick ersetzt oder ganz weggelassen, falls ich doch keinen EnOcean Aktor habe am Ende. SObald der FTD14 da ist und ich mit testren fertig bin, update ich den Post nochmal.

*Einige Leute haben berichtet, ohne FGW-14-USB direkt mit dem FAM14 kommunizieren zu können, es gab aber auch Berichte, dass dies instabil ist. Habe ich noch nicht getestet.

Schritt 1: Server aufsetzen.
Debian herunterladen, auf raspberry SD card schreiben, FHEM und piVCC nach der jeweiligen Anleitung installieren. UART für Zusatzmodule freigeben wie in den Anleitungen beschrieben, Funkmodul zusammenlöten und draufstecken. (Entweder raspberrymit Monitor+ USB Tastatur + Mausbetreiben oder einfach per ssh.)

Hat 1:1 nach Anleitung funktioniert.

Jetzt stehen unter http://ccu3-webui und http://[RASPBERRY IP-ADRESSE]:8083 webinterfaces für CCU3 und FHEM zur Verfügung.

Eltako Hardware:
Nach Anleitung zusammenstecken. Wiederstände an Anfang und Ende der BUS-Connectoren. Hold Klemmen verbinden. 220V verlegen. Testweise eine Lampe schalten.
Bis hierher hat alles wie erwartet funktioniert.

Dann Busaktoren einlernen (kann je nach Aktor ggfs. auch Abweichen, siehe Anleitung):
Der Drehschalter am FAM14 wird auf Pos. 1 gedreht, dessen untere LED leuchtet rot.
Der untere Drehschalter des Aktors wird auf 1..4 gestellt.
Der mittlere Drehschalter des Aktors wird auf LRN gedreht, die LED blinkt ruhig.
Nachdem die Adresse vom FAM14 vergeben wurde, leuchtet dessen untere LED für 5 Sekunden
grün und die LED des Aktors erlischt.

Danach FAM14 auf Oben 4, unten 1 drehen, die Aktoren auf Oben 2, Mitte Auto und Unten Auto einstellen.
Das FGW 14 auf Stellung 6 drehen.

Die Konfiguration der Eltako Komponenten kann nun per PCT Software überprüft werden und einige zusätzliche Einstellungen können vorgenommen werden (z.B. Relaisstatus nach Stromverlust).


Nach langem Probieren und zusammenkopieren aus verschiedenen Forumseinträgen konnte ich dann auch den FGW-14-USB auf der Weboberfläche von FHEM hinzufügen:

Code Auswählen Erweitern

define FGW14_USB TCM ESP2 /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A10MAMIA-if00-port0@57600
attr FGW14_USB comType RS485
attr FGW14_USB learningMode always
attr FGW14_USB room EnOcean
attr FGW14_USB sendInterval 100
attr FGW14_USB verbose 3

Dann noch autmatisches device hinzufügen aktivieren:

Code Auswählen Erweitern

attr global autoload_undefined_devices 1
Jetzt wurden schon einige Devices automatisch in FHEM erkannt und angelegt. (Namentlich 12 Schalter für 3xFSR-4x)

Um die Schalter auch aus der Steuerung Schalten zu können, wurden für jeden Schalter ein virtuelles "Eltako-BUS-Device" erschaffen:

Code Auswählen Erweitern

define EnO_switch_00000001 EnOcean 00000001
attr EnO_switch_00000001 IODev FGW14_USB
attr EnO_switch_00000001 alias FussbodenPumpe
attr EnO_switch_00000001 event-on-change-reading state,buttons,channelA,channelB
attr EnO_switch_00000001 group Heizung
attr EnO_switch_00000001 gwCmd switching
attr EnO_switch_00000001 icon sani_pump
attr EnO_switch_00000001 room Heizung
attr EnO_switch_00000001 subDef 00100001
attr EnO_switch_00000001 subType gateway

Jeder dieser virtuellen Schalter wurde an ein Relais des FSR14-4x angelernt:
Drehschalter Unten: Ausgang 1-4 des Relais wählen.
Drehschalter Oben: LRN
Nun den virtuellen Schalter in den Anlernmodus bringen:

Code Auswählen Erweitern

set EnO_switch_00000001 teach
Am Ende die Drehschalter wieder auf mitte 1, unten AUTO zurücdrehen.

Nun ist es möglich, das angeschlossene Device mittels Klick in der FHEM Oberfläche zu schalten.

Vielen Dank hier nochmal an g.carls projektrettende Anleitung !

piVCCU in FHEM bekannt machen:

Code Auswählen Erweitern

define d_ccu HMCCU [HMCCU IP ADRESS] ccudelay=180
attr d_ccu ccuflags procrpc
attr d_ccu cmdIcon on:general_an off:general_aus
attr d_ccu room Homematic
attr d_ccu rpcserver on
attr d_ccu stateFormat rpcstate/state

Jetzt wurden drei devices automatisch erkannt: CCU 100054 RPC BidCos-RF, CCU 100054 RPC HmIP-RF, CCU 100054 RPC VirtualDevices.

Als nächstes wurden alle Thermostate/Sensoren an der CCU3 angelernt. Dazu http://ccu3-webuihttp://ccu3-webui im Browser öffnen, anmelden, auf "Geräte anlernen" drücken, im Subfenster auf "HM Gerät anlernen"/"HMIP Gerät anlernen" drücken, am Gerät selbst den anlern-Modus aktivieren.
Optimalerweise (aber nicht zwingend) wechselt dann der "Posteingang (0)" Button zu "Posteingang (1)". Wenn nicht, kurz warten und dann trotzdem draufdrücken. Gerät konfigurieren, einen Namen ohne Leerzeichen vergeben und dann auf "Fertig" drücken.

Es ist mir nicht gelungen, diese Geräte automatisch auch FHEM hinzuzufügen zu lassen. Daher müssen alle Geräte mit folgendem Workflow manuell hinzugefügt werden:

Code Auswählen Erweitern

#Refresht die Devicenamen
get d_ccu ccuConfig
#zeigt Devicenamen und IDs an
get d_ccu ccuDevices
# zeigt die Channels eines devices an
get d_ccu deviceInfo [DEVICENAME]
define [FHEM DEVICENAME] HMCCUCHN [DEVICEID]:[Channelnumber]
# Beispiel
define Unten_Hobby_Sensor HMCCUCHN 000E5F29B4AAAA:1

Jetzt werden in mühsamer Einzelarbeit alle Sensoren hinzugefügt.

[Doesenoeffner]

Teil 2: Ein System - Eineinhalb Regelungen

Wohnung oben:
Die Regelung soll nur umsetzen, was am HM-TC-IT-WM-W-EU eingestellt wird.
Da der Boost-Modus nicht gebraucht wird (Die Fußbodenheizung ist eh zu träge.), wurde die Boost Dauer in der CCU auf 0 Minuten eingestellt und damit deaktiviert.

Überlegung:
Das PWM Modul scheint sinnvoll, effizient, einfach zu nutzen und kümmert sich auch gleich mit um die Pumpe.

Die Wandthermostate bieten praktischerweise eine Ausgabe, auf der die aktuell gewünschte Solltemperatur ausgegeben wird: desired-temp. Sämtliche Manuell/Auto Mode, manuelle Solltemperatur, Wochenpläne, etc. werden von dem HM-TC-IT-WM-W-EU verwaltet und können vom Mieter eingestellt werden.
Auch die aktuell gemessene Temperatur steht als ACTUAL_TEMPERATURE zur Verfügung. Wir werden also einfach auf diese beiden Werte regeln.

Nach der Anleitung im Wiki, der Erklärung des PWM Moduls sowie der commandref sieht die Definition des PWM Moduls nun so aus:

Code Auswählen Erweitern

define PWM_FussbodenHeizung PWM 60 900 180 1 9,9 0,0,0 EnO_switch_00000001,0,360,on,60EnO_switch_00000001 ist die Ansteuerung der Pumpe per switch.

Und für die einzelnen Räume sieht es wie folgt aus:

Code Auswählen Erweitern

# Beispiel Wohnzimmer WZ mit Thermostat Oben_WZ_Thermostat und einem Ventil EnO_switch_00000001
define PWMR_Oben_WZ PWMR PWM_FussbodenHeizung 1,0 Oben_WZ_Thermostat:ACTUAL_TEMPERATURE EnO_switch_00000001
attr PWMR_Oben_WZ desiredTempFrom Oben_WZ_Thermostat:desired-tempFür Rüme mit mehreren Heizkreisen wurde ein Struct zum Schalten verwendet:

Code Auswählen Erweitern

# Beispiel Wohnzimmer WZ mit Thermostat Oben_WZ_Thermostat und zwei Heizkreisen bzw. Ventilen
define Ventile_Oben_Wohnzimmer structure Heizkreise EnO_switch_00000002 EnO_switch_00000003
define PWMR_Oben_WZ PWMR PWM_FussbodenHeizung 1,0 Oben_WZ_Thermostat:ACTUAL_TEMPERATURE Ventile_Oben_Wohnzimmer
attr PWMR_Oben_WZ desiredTempFrom Oben_WZ_Thermostat:desired-temp
Für Unten gestaltet sich das ganze wesentlich aufwendiger:

Es ist mir beim besten Willen nicht gelungen, von den Thermostaten per weekprofile oder HMInfo die Heizpläne auszulesen oder zu setzten. Ein Skript zu schreiben, um die Parameter zu setzen/auszulesen erschien mir nur die zweitbeste Lösung.

Neue Idee:

Eine eigene Verwaltung für die Heizpläne in FHEM per weekprofile.
Je Heizkreis gibt es einen dummy, der die Solltemperatur wiedergibt. Dieser wird von einem WeekdayTimer gesteuert. ALternativ soll es aber auch einen Manuellen Modus geben, der die Regelung überschreibt.

Initialisieren einer Wochenplanverwaltung:

Code Auswählen Erweitern

define Wochenprofile weekprofileDummy Zieltemperatur variable erstellen (mit Einstellregler):

Code Auswählen Erweitern

define Unten_WZ_ZielTemp dummy
setuuid Unten_WZ_ZielTemp 6458da3f-f33f-cb10-7bdc-3ea82fabec3960db
attr Unten_WZ_ZielTemp setList state:slider,5,0.5,30
attr Unten_WZ_ZielTemp webCmd stateEigentlich sollte der Einstellschieberegler in 0.5 Grad Schrritten arbeiten. Dies verweigert er bei mir und macht 1 Grad Schritte. Nunja, ich hoffe mal das reicht aus.
Initialisierung des Weekdaytimers:

Code Auswählen Erweitern

define Plan_Steuerung_SZ_UntenWeekdaytimer Unten_WZ_ZielTemp weekprofile:Wochenprofile:true
Für den automatischen Modus reicht das schon aus, nun brauchen wir einen virtuellen Schalter, um den manuellen Modus zu aktivieren:

Code Auswählen Erweitern

define manual_Mode_Unten_SZ dummy
attr manual_Mode_Unten_SZ setList on offUnd ein wenig notify-Logik, um den Weekdayplan zu aktivieren und zu deaktivieren.

Code Auswählen Erweitern

define notify_Manual_Mode_Unten_SZ_On  notify manual_Mode_Unten_SZ:on  set Plan_Steuerung_SZ_Unten disable
define notify_Manual_Mode_Unten_SZ_Off notify manual_Mode_Unten_SZ:off set Plan_Steuerung_SZ_Unten enable.

Wenn jetzt jemand den manuellen Modus aktiviert, wird der Weekdayplan auf inaktiv gesetzt und überschreibt nicht mehr die Soll-Temperatur. Das PWM Modul regelt nun auf die Solltemperatur, die per Schieberegler gesteuert wird.

[Doesenoeffner]

Teil 3: Der Nutzer braucht eine GUI
Zuerst habe ich per das dark UI aktiviert, weil es meinem ästhetischen Sinn am ehesten entspricht:

Code Auswählen Erweitern

attr WEB stylesheetPrefix darkDas geht auch per Menü, wenn man alle styles testen möchte.

Für die Steuerung habe ich einen neuen Raum namens Bedienfeld erschaffen und alle Bedienrelevanten Elemente dort hinzugefügt.

Für die Wohnung Oben sind das 0 Elemente, die soll über die Thermostate direkt gesteuert werden.
Für Unten sind das pro Raum: Der Zieltemperaturdummy, der virtuelle switch zum Aktivieren des Manuellen Modus und der Weekdayplan.
Außerdem das weekprofile Modul zum Erstellen und Zuweisen der Profile und eine Batterieanzeige vom Wiki.

Alle Module, welche zu einem Raum gehören, wurden zu einer raumgruppe zusammengefasst mittels:

Code Auswählen Erweitern

attr [Name] group [Raumgruppenname]und dann zweizeilig nebeneinander angezeigt. Dafür war es nötig, auch für die Batterieanzeige und das weekprofile ein group attr zu setzen.

Code Auswählen Erweitern

attr WEB column Bedienfeld:Schlafzimmer,HobbyraumUndKinderzimmer,Wochenprofile|Wohnzimmer,KuecheUndFlur,Batteriestatus
Wenn man die Heizung steuern will, begibt man sich also in den Raum Bedienoberfläche und kann alles bequem per Maus\Touch steuern. Ein Screenshot ist im Anhang

Hier ist auch der Grund, aus dem ich den Weekdayplan in die Ansicht aufgenommen habe. Über das weekprofile kann man neue Profile an devices senden. Und dann kann hoffentlich jeder Nutzer ausreichend Pattern matching betreiben und muss sich nicht wundern, warum das Zielgerät jetzt "Plan_Steuerung_WZ_Unten" heißt.


TODOS (werden vielleicht umgesetzt, vielleicht auch nicht):
- Den Alpha EOS Drive per Enocean anbinden / FDT14 konfigurieren -> Pumpensteuerung anpassen mittels weiterem dummy; Update: DAS FDT14 ist da. Wird erkannt, eine solltemperatur lässt sich alle 10 Minuten einstellen, eine aktuelle Temperatur wird übermittelt. Leider außerhalb des 10 Minuten Zeitfensters keine Kommunikation. Dauer lässt sich nicht ändern. Kein Zugriff auf Heizprofile. Keine mnanuelle Steuerung an/aus außerhalb des 10 Minuten Zeitfensters. Wird durch ein Homematic IP Gerät ersetzt.-> Pumpensteuerung anpassen mittels weiterem dummy voraussichtlich nötig.
- Rebootfähigkeit des Systems ausprobieren (oft keine Standardwerte für Schalter definiert - mir ist bisher unbekannt, wie) (werden die weekprofiles schon gespeichert?/ Müssen die neu zugewiesen werden?) - Funktioniert einwandfrei weiter nach Stromverlust. Eltako Relais sind alle zu (wie per pct konfiguriert). Ich bin begeistert.
- Andere Räume und save Button mittels hiddenroom verstecken. (Damit andere User keinen Quatsch machen.)
- Usern die Bedienung erklären (VPN, Lesezeichen auf Bedienfeld setzen, Erklären, dass dass Schalten auch mal ne viertelstunde dauern kann)
- Dokument für Mieter mit Erklärung des Thermostats (Manu Mode, Auto Mode, Heizregelung, HINWEIS DASS ES AUCH MAL 15 MINUTEN DAUERN KANN BIS HEIZUNG  REAGIERT)
- PWM Einstellungen testen (lassen)
- Doku ist hier
- Kann man die CosiTherm evtl. doch irgendwie einbinden?
- Kann man die AlphaEOS Sensoren doch irgendwie einbinden? - Test sagt Nein - Nicht ohne einschicken und umprogrammieren, aber die antworten seit über 3 Monaten nicht.
- Delete Logfiles alle Monate? Damit nicht irgendwann der Speicher voll ist