Fußbodenheizung - Stellmotoren plus Wärmepumpe schalten

Begonnen von sebingel, 07 November 2017, 07:50:13

Vorheriges Thema - Nächstes Thema

sebingel

Hallo zusammen,

ich bin ein absoluter Neuling was sowohl FHEM als Fußbodenheizungssteurung an sich angeht. Ich hoffe ihr könnt mir helfen. Bitte zögert auch nicht mich zu korrigieren, falls ich etwas falsches schreibe.
Es ist zwar eine Anfängerfrage, aber angesichts des eindeutigen Themas poste ich direkt in diesem Bereich.

In meiner Wohnung habe ich zurzeit eine Fußbodenheizung die nur über ein einziges Thermostat geregelt wird. Das Thermostat schaltet die Pumpe im Verteilerkasten ein oder aus. Die einzelnen Heizkreise sind manuell geregelt (siehe https://photos.app.goo.gl/zCOvvBkahImJX1td2 ).

Zwecks Komfort, möchte ich auf eine Einzelraumregelung aufrüsten.
Nun benötige ich eine Regelung die nicht nur die Stellmotoren steuert sondern ebenfalls die Pumpe einschaltete, wenn mindestens ein Stellmotor geöffnet ist und wieder ausschaltet, wenn alle Stellmotoren geschlossen sind.

Ich habe mich nun ein wenig im Internet umgesehen und ein Steuerungsgerät von HomeMatic gefunden zudem man dann nochmal extra eine Box kaufen muss die dann die Pumpe steuern kann. Alleine diese Extra Box soll allerdings schon 100€ kosten. Alleine um die Pumpe ein- und auszuschalten.

Durch die Vielzahl an unterschiedlichen Anbietern, finde ich es schwierig eine komplette Übersicht zu erhalten, daher zunächst einmal die Frage: Kennt ihr andere Anbieter/Systeme die das günstiger können? Oder übersehe ich hier vielleicht etwas?
Falls das nicht der Fall ist, kann ich mir aber vorstellen, dass man sowas recht kostengünstig mit FHEM selber bauen kann, oder?
Ich stelle mir hier einfach ein Relais vor, dass per FHEM geschaltet wird und der Pumpe den Strom gibt, oder eben nicht.

Zum Schluss noch eine kurze allgemeine Frage zu FHEM: Ich kann mit FHEM die Brücke zwischen den Systemen schlagen, oder? Ich kann für Komponente A z.B. HomeMatic verwenden ohne mich komplett darauf festzulegen und bei Komponente B ein anderes System, oder?

Ich hoffe ich habe mich verständlich genug ausgedrückt. Fragt bitte nach, falls nicht. Bin wie gesagt vollkommen neu auf diesem Gebiet.

Viele Grüße
sebingel

KölnSolar

Willkommen im Forum.
ZitatZum Schluss noch eine kurze allgemeine Frage zu FHEM: Ich kann mit FHEM die Brücke zwischen den Systemen schlagen, oder? Ich kann für Komponente A z.B. HomeMatic verwenden ohne mich komplett darauf festzulegen und bei Komponente B ein anderes System, oder?
Genau. DAS ist der entscheidende Vorteil von FHEM: die Integration verschiedener Systeme.
ZitatDurch die Vielzahl an unterschiedlichen Anbietern, finde ich es schwierig eine komplette Übersicht zu erhalten
Genau. Deshalb musst Du Dich einlesen und auch, wenn FHEM die Integration ermöglicht, muss man etwas aufpassen, dass man den "Zoo" etwas eingrenzt.
Homematic(ich hab es nicht) ist sicherlich gut f. sensible Anwendungen, da es über einen Rückkanal verfügt. Leider aber auch teuer und ein paar weitere kleinere Nachteile. Preiswerte Lösungen verfügen zumeist nicht über einen Rückkanal. Den kann man sich dann aber auch selber "basteln". Du könntest Dich also für einen simplen Schaltaktor für Deine Pumpe(230 V ?) entscheiden, der keine 10 EUR kostet. Zusätzlich misst Du z.B. die Temperatur der Rohrleitung. Steigt sie nicht, dann hat wohl ausnahmsweise das Schalten nicht funktioniert. Also nochmal.  ;)
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Beta-User

Zwischenruf:

Als Anfänger sollte man sich gut überlegen, ob man ausgerechnet mit einem sehr sensiblen System mit solchen Selberbau-Lösungen anfängt!

(Wohlgemerkt: das geht alles und man kann das auch zuverlässig funktionierend hinbekommen! Aber das ist nicht klickibunti 8) )

Wenn du am Ende 300,- Euro in eine zuverlässig funktionierende Gesamtlösung investiert hast, die einfach anzusteuern ist, ist das evtl. doch gut investiertes Geld (wobei ich das HM-Teil, von dem du sprichst nicht bewerten kann oder will).

Ganz allgemein: Wenn die FB-Heizung sowieso sehr träge ist, kann man eh' wenig regeln und der ganze Aufwand ist "für die Katz". Das hast du aber hoffentlich geprüft ;) . (Es gibt hier mehrere Threads, die die Frage behandeln, ob sich das lohnt)

Just my2ct  :D

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

sebingel

#3
Danke schonmal für die Antworten.

Eine Sache noch, die ich im original Post vergessen habe: die ganze Anlage soll über Funk laufen. Ich möchte so wenig Kabel wie möglich verlegen müssen.

Ein passender Schaltaktor für mich wäre dann z.B. der CMR-1000 von intertechno, richtig? (Die Pumpe läuft über 230V.)

Sehe ich das richtig, dass ich damit theoretisch die Steuerung der Fußbodenheizung komplett selbst bauen kann? Pro Stellmotor einen solchen Schaltaktor?

Beta-User

(***Schüttel***)

Wenn du schon unbedingt mit einem komplexen Projekt einsteigen willst, nimm' wenigstens vernünftige Hardware...

Das Intertechno-Zeugs ist teilweise bereits ab Werk gefährlicher Elektroschrott, einen Rückkanal hat es auch nicht und 433MHz ist berüchtigt für dauersendene Sensoren oder Fernbedienungen, die das ganze Frequenzband tot machen können. Das passiert auf 868MHz wegen besserer Designvorgaben erheblichst seltener (mir ist nur ein konkreter Fall bekannt).

Aber: Jeder wie er kann und mag, ich bin jedenfalls raus hier :( .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

KölnSolar

ZitatDas Intertechno-Zeugs ist teilweise bereits ab Werk gefährlicher Elektroschrott
Belege ?
Der Schrott läuft bei mir problemlos seit Jahren(so ca. 15).
Zitateinen Rückkanal hat es auch nicht
Das stimmt.
Zitat433MHz ist berüchtigt für dauersendene Sensoren oder Fernbedienungen, die das ganze Frequenzband tot machen können.
Einen größeren Blödsinn hab ich lange nicht gehört. Entbehrt jeglicher Grundlage.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Beta-User

Sorry für den deutlichen Ton, in der Sache kann her aber nur von einer 433MHz-Lösung abgeraten werden.

Zum "Schrott":
- Den Thread mit dem Thema Brandgefahr und völlig überzogender Ruheströme finde ich grade nicht, aber bei 15 Geräten kannst du ja selbst mal messen, was die Teile im ausgeschalteten Zustand so ziehen (da mag es aber erhebliche Unterschiede zwischen den Herstellern bzw. einzelnen Modellen geben).
- Dann sollte man noch wissen, für was man sie verwendet (ist für Stellantriebe eher kein Thema): https://forum.fhem.de/index.php/topic,32851.msg252792.html#msg252792

Zur fehlenden Grundlage für die Warnung vor Störungen auf 433MHz siehe beispielsweise https://forum.fhem.de/index.php/topic,32851.msg252792.html#msg252792  ;) ::) 8)
Da findet sich dann eine nette Liste, was diverse Leute nicht alles schon an Auslösern für "Dauerfunk" hatten. Ich bin sehr sicher, dass sich hier im Forum mindestens 20 weitere Beiträge finden  mit flackernden PI-GPIOs, schwachen Batterien in irgendeinem Sensor (eigene, hin und wieder auch der Nachbar...), Fernbedienungen in Schubladen usw..

Also nochmal: Wer etwas wichtiges steuern will, nehme dazu DEFINITIV NICHT 433MHz.

Allgemein: Wenn es nicht kabelgebunden geht (Kabel sind - wo möglich -  immer die bessere Wahl), kann man sowas natürlich über Funk einbinden, aber das Teilsystem selbst sollte dann autonom laufen (können).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

KölnSolar

Zitatin der Sache kann her aber nur von einer 433MHz-Lösung abgeraten werden.
Das ist eben nur Deine persönliche Meinung und das solltest Du dann auch klar zum Ausdruck bringen.
ZitatDann sollte man noch wissen, für was man sie verwendet (ist für Stellantriebe eher kein Thema)
Der Link sagt doch rein gar nichts aus. Es geht um Eigenbau UND dass man (genau wie bei Mehrfachsteckdosen) darauf achten muss, für welche Schaltleistung die Dosen ZUGELASSEN(CE) sind. Hat also rein gar nichts mit Schrott zu tun. Und Intertechno(Markenhersteller) und Baumarkt(oder auch auch alles, was aus China kommt) in einen Topf zu schmeißen, halte ich auch nicht für sinnvoll.
Zitatfehlenden Grundlage für die Warnung vor Störungen auf 433MHz siehe beispielsweise
Derselbe Link ?!?!?!? Störungen ?!?!?!?
ZitatIch bin sehr sicher, dass sich hier im Forum mindestens 20 weitere Beiträge finden  mit flackernden PI-GPIOs
GPIO's ???? Da wüßte ich jetzt mal gerne ein Beispiel, wo jemand Probleme an den GPIO's wegen 433MHz-Technologie hat UND diese bei 868MHz nicht mehr vorhanden sind. Ich behaupte, ein solches Beispiel wirst Du nicht präsentieren können, denn die unterschiedliche Frequenz dürfte keinerlei Einfluss haben.
Zitatschwachen Batterien in irgendeinem Sensor (eigene, hin und wieder auch der Nachbar...)
Das habe ich bisher nur zu HOMEMATIC bzw. 868 gelesen. Und klar gibt es zig Threads, wo die FB dauernd feuert, weil unbeabsichtigter Dauertastendruck. Das ist aber kein Problem einer bestimmten Frequenz.
ZitatWer etwas wichtiges steuern will, nehme dazu DEFINITIV NICHT 433MHz.
Also nochmal: Diese Aussage ist Unfug, denn wenn überhaupt, passt Sie zu Funklösung vs. kabelgebunden. Oder aber zum fehlenden Rückkanal(EGAL welcher Hersteller, Frequenz...) aber das lässt sich ggfs. durch einen Workaround umgehen.

Und nur mal so für den TE:
Ich habe 5 433-Rolladenaktoren, 4 433-Rauchmelder, 11 433-Funksteckdosen, 5 433-Temp-/Hum-Sensoren, 1 433-Dimmer, 2 433-BWM, 3 433-Leistungsmesssteckdosen(Rückkanal  ;D) zig 433-FB's, 433-Eigenbausensoren(in Arbeit) ...... und kenn ich die negativen Merkmale die Beta-User beschreibt ? NEEEEIIIIIN und ich spreche aus jahrelanger Erfahrung mit 433-MHz......
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Beta-User

Ja, es ist meine persönliche Meinung, mit der ich aber nicht ganz alleine bin 8) .

Und korrekt: Es gibt unterschiedliche Hersteller für 433MHz-Ware und man sollte die auch nicht alle qualitätsmäßig in einen Topf werfen, auch wenn sie dasselbe Protokoll verwenden (das hatte ich mit dem dafür gebräuchlichen Sammelbegriff eigentlich gemeint). Dass es da aber Unterschiede zwischen namhaften und noname's gibt sollte indirekt mit dem Hinweis auf die unterschiedlichen Verbauchswerte im ausgeschalteten Zustand klargestellt werden.

Auch korrekt: das kann alles problemlos funktionieren, ich will dir deine positiven Erfahrungen nicht absprechen.

Aber:
- Bei Funk hängt es immer vom Umfeld ab, je mehr Nachbarn, die auch ähnliches im Einsatz haben, desto höher das Risiko, dass mal was schiefgeht. Bei 433MHz ist es wegen fehlender Absicherung m.E. von vornherein deutlich erhöht.
- der 2. Link sollte eigentlich hierhin gehen: https://forum.fhem.de/index.php/topic,55179.msg487566.html#msg487566.
Das ist definitiv ein 433MHz-Thread.

Und danke für die Klarstellung, dass 868MHz kein Allheilmittel ist (der 2. Link war übrigens der Thread mit 868-Problemen, der mir noch im Kopf war ;) ).

Und klar kann man für alles mögliche einen Workaround finden, aber das von vornherein mit einzukalkulieren, ist (wieder meine persönliche Meinung ;) ) nicht unbedingt gutes Systemdesign und eben auch nichts, was ich einem Anfänger vorschlagen würde.

Das mit den GPIO's war anders herum: da wurde ein 433-er Sender vom PI mit Dauerfeuer belegt und der Sender hat dann den Funk auf 433 gestört.

Lassen wir es gut sein, mag der TE entscheiden, wie er sein Problem löst ;D .

Just my2ct.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

KölnSolar

Ich wollt ja nicht, aber jetzt muss ich doch noch mal.  ;)
Hattest Du gesehen, dass Du auf einen meiner Posts verlinkt hattest ?  ;D ;D ;D
Und, wenn etwas durch äußere mechanische Einwirkung kaputt geht, darf es auch dauerfunken oder gibt es dafür bei Homematic einen "Verhinderungsmechanismus"  ;D
Zitateben auch nichts, was ich einem Anfänger vorschlagen würde.
Deshalb kommentiere ich Deine sonstigen Homematic-Empfehlungen auch nie(auch wenns mich schon mal zwickt)  ;)
Im konkreten Fall aber
Zitatein Steuerungsgerät von HomeMatic gefunden ..... Alleine diese Extra Box soll allerdings schon 100€ kosten. Alleine um die Pumpe ein- und auszuschalten.
und
Zitatkann ich mir aber vorstellen, dass man sowas recht kostengünstig mit FHEM selber bauen kann, oder?
Ich stelle mir hier einfach ein Relais vor, dass per FHEM geschaltet wird und der Pumpe den Strom gibt, oder eben nicht.

Auch, wenn unser beider Diskussion etwas OT war, kann der TE nun wohl trotzdem recht gut entscheiden, was er macht  ;)
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Beta-User

 :D
Dann muß ich halt auch nochmal ;) ...

[OT]
Den "eigentlichen" Ziellink (für  den ich versehentlich den anderen doppelt hatte) fand ich auch witzig, weil hier in diesem Thread jemand steif und fest behauptet hat, Probleme durch vergessene Fernbedienungen seinen ihm völlig neu ;D ;D ;D . Und andere Fehlerursachen@433 sowieso... Und dann findet sich dort das ganze Sammelsurium vereint, so ein Zufall aber auch ;) .

Dann:
Du darfst mich gerne einbremsen, wenn ich für bestimmte Artikel ungerechtfertigt Werbung machen sollte. Der Klarstellung wegen: Nach meiner ganz persönlichen Meinung ist das meiste aus dem Hause e3-Q ein ziemlich fader Kompromiss:
- Es beginnt damit, dass es kein offenes Protokoll ist (bzw. mehrere), und daher kein echter Wettbewerb herrscht.
- Dann verwenden sie teilweise minderwertige Bauteile (Kondensatoren)
- Updates sind teilweise nur mit verheerenden Umwegen erfolgreich abzuschließen, manche schaffen es gar nicht (und da spreche ich nicht mal von CUL-Benutzern unter FHEM!)
- Die Preispolitik bei "Randartikeln" ist Abzocke

Aber:
+ Es funktioniert einigermaßen,
+ die Preispolitik im Kerngeschäft ist nicht schlechter als anderswo,
o Probleme gibt es überall, fehlerfrei gearbeitet wird praktisch nirgends
+ Es ist für Anfänger halbwegs stressfrei in FHEM zu integrieren, es existieren wenigstens (seit langem) Anleitungen (an zwave habe ich mich bisher nicht rangewagt, das geht aber scheinbar mittlerweile)
(+) zu den RT-DN-Thermostaten (und vermutlich auch den IP-Varianten) gibt es keine technisch guten Alternativen, jedenfalls, wenn man denen Glauben schenkt, die insbesondere zwave-Produkte ausprobiert haben
+ es gibt AskSin++.

Sobald es zu den RT-DN's akzeptable Alternativen gibt, werde ich darauf verweisen, wenn wieder mal ein Anfänger fragt, was er im Heizungsbereich einsetzen soll, versprochen!
[/OT]

[bißchen OT]
868-Geräte müssen eigentlich so designed werden, dass die 1%-Regel eingehalten wird. Damit lassen sich zwar Effekte aus zerstörter Hardware (oder im Bootloader hängengebliebene mcu's) nicht verhindern, aber wenigstens sollte "die in der Schublade vergessene Fernbedienung mit gedrückter Taste" nach Verbrauch ihres Budgets aufhören.... (Sollte!)
[/bißchen OT]

Jetzt aber wieder richtig zur Sache:

1. Wenn Selberbauen, würde ich es gleich richtig machen und auf eine Arduino-basierte Lösung setzen (Präferenz: MySensors). Damit kann man auch direkt im auf der Hardware fest verankerten Code die Pumpe einschalten, wenn man ein Stellventil öffnet. Das "Dumme dabei" ist nur, dass man die 230V mit zugelassener Hardware schalten muß (Versicherungsschutz!) und Arbeiten an 230V zugelassenen Fachleuten vorbehalten sind. Aber man kann ja z.B. über einen MOSFET 12V schalten und damit z.B. Eltaco-Hardware steuern, die einem ein Fachmann einbaut.
Der TE wird zwar jetzt große Augen machen und sich sagen, dass er er bislang eher weniger von C++ versteht, aber es wäre eine echte Alternative, bei Bedarf auch mit Rückkanal und der Option, direkt Infos zwischen Temp-Fühlern und der Zentalen Heizungseinheit auszutauschen ;) .

Wenn Interesse besteht, gerne dazu mehr.

2. Neulich bin ich bei einem entfernten Verwandten gewesen, der hatte irgendein System installiert, dessen Namen ich mir leider nicht gemerkt habe und den ich aber vorher auch noch nie gehört hatte. Da gab es eine Zentraleinheit im Verteilsystem der FBH mit Ausgängen für die Stellmotoren. Es stand was von 868MHz drauf, in jedem Raum war ein länglicher Temperaturfühler installiert, der irgendwie auch programmierbar zu sein schien, unten war jeweils eine Klappe mit einigen wenigen Tasten. Der Verwandte schien damit sehr zufrieden zu sein.
Vielleicht kann hier ein kompetenter Heizungbauer Auskunft geben, was das für ein System war. Vielleicht ist das ja günstiger zu bekommen und auch irgendwie in FHEM zu integrieren.

Das war's jetzt aber wirklich, oder?

Erheiterte Grüße,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Thyraz

#11
Zitat von: Beta-User am 08 November 2017, 20:31:03
(+) zu den RT-DN-Thermostaten (und vermutlich auch den IP-Varianten) gibt es keine technisch guten Alternativen, jedenfalls, wenn man denen Glauben schenkt, die insbesondere zwave-Produkte ausprobiert haben

..

Sobald es zu den RT-DN's akzeptable Alternativen gibt, werde ich darauf verweisen, wenn wieder mal ein Anfänger fragt, was er im Heizungsbereich einsetzen soll, versprochen!

[OT]
Die bisherigen Z-Wave Lösungen krankten ja am Problem, dass die Geräte nur zum "wakeup" Zeitpunkt der batteriebetrieben Geräte angesprochen werden konnten.
Das erste Gerät mit "FLIRS", was auch batteriebetriebenen Geräte sofortige Reaktionen auf Befehle der Zentrale erlaubt ist mittlerweile auf dem Markt.

Die Amazon Bewertunen sehen schonmal ganz gut aus:
https://www.amazon.de/review/R1L03FDYZEYUHJ/ref=cm_cr_dp_title?ie=UTF8&ASIN=B076616NZV&channel=detail-glance&nodeID=562066&store=ce-de

Evtl. können sich Zwave Nutzer bald tatsächlich ein weiteres System dafür sparen...
[/OT]

@sebingel ich würde mir auch gut überlegen, ob du eine Heizungssteuerung wirklich von FHEM abhängig machen willst.
Es gibt bei FHEM eben keine "stable" Releases. Jedes Update bingt den aktuellen Entwicklungsstand der Module.

So ziemlich jeder FHEM User dürfte im Laufe der Jahre mal einen FHEM Crash erlebt haben, auch wenn ein gut konfiguriertes FHEM normal nie Probleme macht.
Je nach verwendeter Hardware (z.B. Pi mit SD-Karte) sind auch Hardwareprobleme nicht sooo selten.

Ich würde daher immer auf eine Lösung setzen, welche auch ohne FHEM problemlos läuft.
FHEM darf gerne Überwachung, Visualisierung und Komfortsteuerung (Temperaturabsenkung, Heizuen nach Anwesenheit etc.) übernehmen.
Der Betrieb und auch Steuerung wie z.B. Solltemperatur-Änderungen sollte aber auch ohne möglich sein.

Frieren während einer Fehlersuche ist einfach nicht so der Knaller. ;)
Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

Beta-User

@Thyraz

[OT]
Danke für die Info.
Allerdings verstehe ich das mit dem wakeup nicht so ganz: Auch die HM's wachen - im Standard - nur alle 2,5 Min auf, um zu sehen, was es "neues gibt". Das ist auch ok so, die einzige (leider notwendige) Ausnahme ist m.E. das Kopeln mit Fensterkontakten (da hier der batteriebetriebene Sender (=FK) auch wieder schnell einschlafen muß).

Bisher hatte ich eher den (ungeprüften!) Eindruck, die Kritik bezöge sich mehr auf das Regelverhalten an sich.
[/OT]

Im Heizungsbereich braucht es m.E. aber in der Regel keine sofortige Reaktion, eigentlich wäre eine gewisse Verzögerung gar nicht schlecht, da man damit unnötige Regelfahrten z.B. bei zeitnahmen Wiederschließen einer gepairten Tür (wo ich am Kontakt keine Verzögerung einstellen will, weil das Außenlicht damit getriggert wird) verhindert würden, die Energieeinsparung aber 0 ist, weil der Regler gleich wieder aufgemacht wird...

Derartige Aufgaben an FHEM abzugeben, ist m.E. gut möglich, da man - eine vernünftige Backup- und update-Strategie vorausgesetzt - mit FHEM durchaus ein sehr stabiles und "hartes" System aufsetzen kann mit sehr wenig Ausfallzeit. Aber dazu muß man wissen, was man tut => so ein Systemaufbau ist also nichts, was man einem Anfänger (=keine Linux-Kenntnisse, keine Erfahrung mit Regelungssystemen aus dem beruflichen Umfeld) empfehlen sollte (wieder mal: meine ganz private Meinung ;) ).

Damit wären wir nochmal richtig im Topic:

Der TE möge doch bitte mal Rückmeldung zu diesem Punkt hier geben:
Zitat von: Beta-User am 07 November 2017, 10:43:36
Ganz allgemein: Wenn die FB-Heizung sowieso sehr träge ist, kann man eh' wenig regeln und der ganze Aufwand ist "für die Katz". Das hast du aber hoffentlich geprüft ;) . (Es gibt hier mehrere Threads, die die Frage behandeln, ob sich das lohnt)

Damit sollte auch klar sein, dass die eigentliche Empfehlung von Anfang an eher war: Laß' das sein und spare Dein Geld, der Effekt dürfte nicht der gewünschte sein...

(Eigentlich noch, aber da ich keine FB-Heizung habe und daher keine eigene Erfahrung damit nur mit Vorbehalt: Kümmere Dich lieber um die Vorlauftemperatursteuerung und andere Maßnahmen, die die Experten hier teilweise für zielführender halten)

Wie gewohnt: Just my2ct...

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Morgennebel

Ganz ehrlich:

Minimale Kabelziehen ist bei einer Heizung gefährlich. In den Räumen gerne, an Radiatoren gerne aber nicht an der Heizung selbst...

Mein Ratschlag daher:


  • Du bist mit FHEM richtig (nimm nicht den Arduinio-Weg).
  • Ich empfehle Dir 1-Wire in einem ordentlichen Gehäuse (5 x 12 TE Hutschiene minimal) in der Nähe der Heizung
  • Dein "Backup" ist die normale Heizungssteuerung
  • Du übersteuerst die Pumpe mit https://wiki.fhem.de/wiki/1W-WPump durch FHEM. Achtung 230V
  • Du kannst den Mischermotor mit dem STELLMOTOR-Modul ansteuern. Achtung, 230V, potentialfreie Relais erforderlich
  • Du willst es von Anfang an richtig machen. WAGO-Durchgangsklemmen, 1Wire Ethernet Controller, Sensoren
  • Du kannst dann die FB-Kreise mit 230V Aktoren und z.B. Homematic oder 1-Wire ansteuern und das PWM/PWMR zur Regelung verwenden
  • Dazu brauchst Du Thermostaten in den Räumen (Homematic)

Ich hab dasselbe hinter mir, siehe https://wiki.fhem.de/wiki/Heizung:_Verbrauchsoptimierung,_Radiator/Fu%C3%9Fboden-Steuerung und mache dies genauso. Meine elektrische Installation ist gefährliches Gefrickel, aber die Heizung wird im Sommer ausgetauscht. Dann wird es hübsch.

Das ist nichts für einen Linux- und/oder FHEM-Anfänger. Der Wiki-Artikel basiert auf gut 150h Arbeit und Investitionen von gut 750 EUR - aber die Lösung hat inzwischen 3.250 EUR eingespart...

Und noch abschliessend: laß das Projekt sein, wenn Du ein Passiv/Niedrigenergie-Haus hast. Wie mehrere Schreiber hier bereits zusammengefaßt haben, lohnt es sich dann nicht. Mein Haus ist von 1904, schlecht isoliert (und bleibt so) und ich habe in einigen Räumen nur FB-Heizung...

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Thyraz

#14
[OT]
Bei Zwave ist der Wakeupinterval weit länger.
Manche Geräte wachen per Default einmal am Tag auf.
Kurze Intervalle saugen dann auch schnell an der Batterie.
FLIRS ist daher eben eine Neuerung die bessere/neue Geräte ermöglichen soll.
Da ich aber auch Fußbodenheizer bin kann ich zu anderen Problemen wenig berichten...
[/OT]

Natürlich kann man ein stabiles FHEM hinbekommen. Ist sogar einfacher als in instabiles. ;)
Vorrausetzung ist dafür einfach nicht dauern upzudaten ohne es vorher auf einem Testsystem zu Prüfen,
oder allgemein wenig (vor allem neue oder Beta-) Module einzusetzen.

Der Spieltrieb hindert die meisten von uns jedoch sowas umzusetzen. ;)
Eine weitere Möglichkeit ist natürlich ein extra FHEM für die Heizung und dann ein weiteres für Spielereien.

Zum Regeln an sich:
Bei uns im gut gedämmten Neubau macht das zumindest wenig Sinn.
Bin ich nicht Zuhause und mach die Heizung komplett aus, sinken die Zimmertemperaturen im Schnitt nach 24h gerade mal ein knappes Grad.
Dämmung und aufgeheizter Estrich führen dazu, dass eine Nachtabsenkung, oder weniger Heizen während man außer Haus ist nicht sinnvoll ist.

Somit beschränkt sich meine "Intelligenz" bei der Heizung auch auf Erfassung von Soll/Ist Wert sowie dem Loggen der Ventilstellungen.
Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

Beta-User

[OT]
@Thyraz
Danke für die Klarstellung, dann gibt es offensichtlich (endlich) Alternativen auch in diesem Teilbereich!
[/OT]

Zitat von: Morgennebel am 09 November 2017, 09:29:33

       
  • Du bist mit FHEM richtig (nimm nicht den Arduinio-Weg).
(Es sollte klar gewesen sein, dass das KEINE Empfehlung für den TE in Richtung Arduino gewesen sein sollte!) ;D
Und wenn, dann nur in Kombination mit FHEM ;) ...

Wenn also tatsächlich Regelungsbedarf bestehen sollte (?):

Es gibt aber - jedenfalls dem ersten Suchen nach - tatsächlich auch von mehreren anderen Herstellern autonome Systeme, die für ordentliches, aber doch noch überschaubares Geld diesen Teilbereich "aus einer Hand" anbieten (Möhlenhoff, z.B.). Ob man sowas dann in FHEM integrieren kann: Keine Ahnung, ggf. selber mal suchen (oder es gibt hier direkt Rückmeldung)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files