Originally posted by: <email address deleted>
Ich schicke gleich mal Voraus, dass ich Flickwerk jetzt nicht negativ
meine, eher im beschreibenden Sinn.
Technologiebedingt und weil FHEM so viele Wege kennt ans Ziel zu kommen
gibt es gerade bei der Heizungssteuerung sehr viele Bastellösungen, wobei
das Rad immer wieder neu erfunden wird.
Vor allem das Verwalten von Wochenprogrammen etc. ist eher noch
unzufriedenstellend.
Über den Daumen gibt es zB für das Steuern der Raumtemperatur folgende
Lösungen:
FHT8v + FHT80b
FHT8v + PID
HM-CC-VD + HM-CC-TC
MAX Stellantrieb
1-Wire-Stellantrieb + PID (zumindest theoretisch)
Heizstrahler per FS20-Aktor einschalten etc.
Bei der Wärmeerzeugung gibt es auch die unterschiedlichsten Systeme mit
daraus resultierenden unterschiedlichen Anforderungen wie Fernwärme (ohne
Wärmetauscher nur Heizkörper zu steuern), bis hin zu kombinierten Erdwärme
+ Pellets Heizungen (das HCS-Modul ist schon ein wichtiger Schritt in
Richtung der Steuerung komplexerer Anlagen).
Wobei es eigentlich immer die gleichen Geräteklassen gibt:
Heizkörperstellantriebe
Fensterkontakte
Raumtemperaturfühler
Raumthermostate/Raumtemperatursteuerung
Heizungssteuerung auf Basis des Bedarfs der Raumsteuerungen
Auch die Anforderungen (software-seitig) der meisten User von FHEM ähneln
sich.
Platz 1: WAF ;)
Wochenprogramme (uU mit mehreren Profilen)
Urlaubsschaltung
Händisches Überschreiben der Raumtemperatur (Boost, Dauer)
Erkennung von Fenster/Tür-Offen
Priorisierungen von FHEM vs. Raumthermostate
viele Dinge die ich vergessen habe
Hier beschleicht mich das Gefühl, dass es Bedarf für Metaklasse Heizung
geben könnte, die die Anforderungen zentral adressiert.
Bevor jetzt als erstes kommentiert wird: "na dann mach", würde mich
interessieren ob 1. wirklich ein Bedarf besteht und 2. natürlich Input
(v.a. weil ich was die architektur von fhem betrifft eher in nackerbatzerl
bin)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Alexander,
ich kann dem nur zustimmen, das Thema Heizung steuern ist ein komplexes
Thema das eigentlich einer eigenen Gruppierung bedarf.
Platz 1: WAF ;)
oder Sicherheit?
Aus meiner Sicht muss eine Heizung funktionieren und kann im Normalfall
keine Spielwiese sein!
viele Dinge die ich vergessen habe
>
Ich z.B. habe FHEM und Homematic HMLAN - TC - VD als ideale Ergänzung zu
meiner bestehenden Heizungssteuerung entdeckt.
> Hier beschleicht mich das Gefühl, dass es Bedarf für Metaklasse Heizung
> geben könnte, die die Anforderungen zentral adressiert.
>
Kann ich durchaus nachvollziehen.
Billy
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Die CCU-Benutzer, die ja wesentlich eingeschränkter arbeiten müssen, setzen
hauptsächlich auf ein Skript:
http://homematic-forum.de/forum/viewtopic.php?f=31&t=3480
Das wäre auch recht leicht in Perl umzusetzen.
Hauptvorteil einer verbreiteten Lösung ist halt, dass die gängigsten
Sonderfälle (Urlaub, etc) abgedeckt sind und stabil laufen, weil es viele
im Einsatz haben. Wenn jeder etwas bastelt, dass nur für eine Situation 2x
im Jahr vorgesehen ist, dann ist das sicherlich fehleranfälliger...
Viele Grüße,
Ralf
Am Sonntag, 11. November 2012 17:20:52 UTC+1 schrieb littlebilly:
>
> Hallo Alexander,
>
> ich kann dem nur zustimmen, das Thema Heizung steuern ist ein komplexes
> Thema das eigentlich einer eigenen Gruppierung bedarf.
>
> Platz 1: WAF ;)
>
> oder Sicherheit?
> Aus meiner Sicht muss eine Heizung funktionieren und kann im Normalfall
> keine Spielwiese sein!
>
> viele Dinge die ich vergessen habe
>>
>
> Ich z.B. habe FHEM und Homematic HMLAN - TC - VD als ideale Ergänzung zu
> meiner bestehenden Heizungssteuerung entdeckt.
>
>
>> Hier beschleicht mich das Gefühl, dass es Bedarf für Metaklasse Heizung
>> geben könnte, die die Anforderungen zentral adressiert.
>>
>
> Kann ich durchaus nachvollziehen.
>
> Billy
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
falls sich wirklich Leute finden um so etwas abstrakt zu entwickeln sollte
berücksichtigt werden, dass z.B. bei HM die Thermostate die Regelung
eingebaut haben während bei anderen Systemen die Regelung wohl selbst
gemacht werden muss (es gibt ja schon ein PID Modul)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Man muss, denke ich, sogar noch weiter gehen.
Die meisten modernen Heizungsregler haben vielfältige
Steuerungsmöglichkeiten, die man mit in Betracht ziehen muss. Ich habe das
derzeit vor Augen, weil wir in einer gerade frisch gekauften Albauwohnung,
die von meiner Tochter bewohnt wird, eine nagelneue Gas-Etagenheizung
installieren müssen. Es wäre dumm, die autonomen Regelungsmöglichkeiten
dieser Systeme außen vor zu lassen. Beispielsweise wäre es denkbar, einem
solchen autonomen System (oder auch den FHTs) bei Bedarf einfach ein neues
Programm verpassen zu lassen.
Bleiben wir also mal bei der Liste der Komponenten, und ergänzen sie etwas
Heizkörperstellantriebe (nicht an jedem Heizkörper, direkt von FHEM
gesteuert oder über autonomes System)
Fensterkontakte (steuern entweder das autonome System, oder FHEM)
Raumtemperaturfühler
Außentemperaturfühler - oder Internet-Wetterdaten
Windsensor (oder Internet_Wetterdaten)
Sensor für solare Einstrahlung
Raumthermostate/Raumtemperatursteuerung (autonom, aber von FHEM
beeinflussbar)
Heizungssteuerung als Raumthermostat (autonom, muss aber ggf. von FHEM
beeinflusst werden)
Heizungssteuerung an Kessel und Pumpe auf Basis des Bedarfs der
Raumsteuerungen (FHEM und autonomes System)
Das ist, wenn ich das mal so sagen darf, ganz schön komplex....
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Für diesen Umfang denke ich auch, dass eine Eierlegende Wollmilchsau oder
SwissKnife zu verwirrend ist.
Und ein Kombi aller og. Steuerungen tritt ja auch selten auf.
Wenn ich FHT8v als Antriebe nutze, mische ich diese doch auch nicht mit
MAX! und oder HM.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Und warum sollte man das nicht tun ? Das ist doch genau der USP von FHEM ...
Außerdem reden wir nicht von der eierlegenden Wollmilchsau. Sondern von
einem modularen System.
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Genau, es ginge nicht um eine eierlegende Wollmilchsau sondern durch eine
Abstraktionsebene gewisse Fragestellungen im Zusammenspiel/der Steuerung
der Komponenten einmal zu lösen und nicht ständig das Rad neu zu erfinden.
2012/11/12 Prof. Dr. Peter A. Henning
> Und warum sollte man das nicht tun ? Das ist doch genau der USP von FHEM
> ...
>
> Außerdem reden wir nicht von der eierlegenden Wollmilchsau. Sondern von
> einem modularen System.
>
> pah
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Außerdem ist ja gerade vom angesprochenen Sicherheitseffekt es sinnvoll
Systeme zu mischen. Ob die Heizkörper jetzt offen oder zu sind ist mir ja
noch relativ egal (Energieverschwendung hin- oder her), aber wenn ich
meinen Brenner oder Fernwärmetauscher ansteuern will, dann verlässt man
sich nicht mehr auf Funk sondern will ein Kabel
2012/11/12 Prof. Dr. Peter A. Henning
> Und warum sollte man das nicht tun ? Das ist doch genau der USP von FHEM
> ...
>
> Außerdem reden wir nicht von der eierlegenden Wollmilchsau. Sondern von
> einem modularen System.
>
> pah
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Gut, ich bin im Rahmen meiner zeitlichen Möglichkeiten dabei. Mich ärgert
nämlich maßlos, dass Heizungsbauer offenbar nur sehr wenig davon verstehen,
was sie eigentlich machen. Stattdessen wird mit Bastelmaßnahmen wie dem
"hydraulischen Abgleich" der Kunde um sein Geld gebracht.
Wenn man also eine Art universell einsetzbarer Heizungssteuerung entwickelt
(und in FHEM einbaut...), die auch ein Otto Normalverbraucher bei seinem
alten Gaskessel mit Niedereffizienzpumpe einsetzen kann, wird dies sicher
enormes Potenzial haben.
Ich denke, dass am Beginn die folgende Frage stehen muss:
Was ist die MINIMALE Hardware-Kombination, die man sinnvoll einsetzen kann ?
Vorschlag: Ersetzung des guten alten Raumthermostaten, der die
Heizungspumpe einschaltet, durch einen elektronischen Raumthermostaten. Mit
anderen Worten also: Temperatursensor, FHEM, Schalter für die
Heizungspumpe. Komfortgewinn durch
- Zeitsteuerung
- Tages- und Wochenprogramme
- Fernbedienung per Mobiltelefone (ich habe vergessen, den ECO-Schalter
zu drücken/ich komme nach Hause)
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
> Ich denke gleich noch weiter...
>
Das Modul könnte als Attributwerte verschiedene Devicenamen geliefert
bekommen. Diese Devices sind - irgendwie und irgendwo - an FHEM
angeschlossen.
z.B,
attr XXX mainTemp OWTemp1
mainTemp ist der Attributname für das HAUPTTHERMOMETER - und das heißt in
diesem Fall OWTemp1 und könnte ein 1-Wire Sensor irgendwo in der Wohnung
sein. Oder ein FHT-Sensor. Oder ein WS300, was auch immer - Hauptsache, es
liefert eine Temperatur.
attr XXX pumpSwitch OWSw1
pumpSwitch ist der Name für den Schalter der Umwälzpumpe - z.B. ein 1-Wire
Schalter
Wenn man auf dieser Basis aufsetzt, wären also die nächsten Schritte
- Algorithmus für die Steuerung (eben aus dem PID-Modul). Parametrierbar,
z.B. in Bezug auf die Strategie zum Einschalten: lieber häufige kurze, oder
seltene lange Pumpenläufe, Hysterese etc.
- Frontend zur Eingabe von Tages- und Wochenprogrammen
- Fernbedienungsmöglichkeit via Mobiltelefon.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
@pah: full ack, mmn zb ein hydraulischer Abgleich nur notwendig wenn
schon bei der Planung der Heizung geschlampt wurde und der wärmebedarf der
einzelnen räume falsch berechnet wurde oder zu schwache pumpen etc.
Seitdem ich mich das erste mal mit fhem beschäftigt habe bin ich öfter mit
bekannten zum reden zu kommen über Heizungen und was Land auf Land ab an
heizungstechniker rumläuft ist es schon fast ein jackpot einen zu finden
der keinen groben Schnitzer macht. (persönlicher favorit waren sicher
vertauschte temperaturfühler in vor- und rücklauf die über 5 jahre und
geschätzte 15 servicetechnikerbesuche nicht aufgefallen sind/ oder der 8kw
wärmetauscher im haus mit 15kw wärmebedarf, was dazu führt, dass der
regeler zwar 62 grad vorlauf anfordert aber nicht mehr als 46 bekommt, die
liste ließe noch länger fortsetzen)
was mich ernsthaft nervt ist dass jeder hersteller sein eigenes süppchen
köcht und man weder aus regelsystem noch zählern eine info herausbekommt
außer man fängt an mit optolink zu basteln an.
Ich hätte auch gedacht dass man den heizdevicetyp als Attribut dazuhängt
(auf welcher Seite ist erstmal egal) und dass das Modul dann weiß was zu
tun ist.
Es müsste sicher je nach wärmequelle flexibel gehalten werden, weil zb eben
fernwärme mit wärmetauscher ruhig öfter geschaltet werden kann als bei
einem brennersystem oder einem kreislauf mit wärmespeicher)
Wenn man Dinge wie wochenprogrammplanung dann zentral löst, würde sich auch
der aufwand für ein frontend lohnen etc.
-- gesendet von meinem HP Touchpad
Am 12.11.2012 18:03 schrieb "Prof. Dr. Peter A. Henning" <
prof.dr.peter.a.henning@gmail.com>:
> Ich denke gleich noch weiter...
>>
>
> Das Modul könnte als Attributwerte verschiedene Devicenamen geliefert
> bekommen. Diese Devices sind - irgendwie und irgendwo - an FHEM
> angeschlossen.
>
> z.B,
>
> attr XXX mainTemp OWTemp1
>
> mainTemp ist der Attributname für das HAUPTTHERMOMETER - und das heißt in
> diesem Fall OWTemp1 und könnte ein 1-Wire Sensor irgendwo in der Wohnung
> sein. Oder ein FHT-Sensor. Oder ein WS300, was auch immer - Hauptsache, es
> liefert eine Temperatur.
>
> attr XXX pumpSwitch OWSw1
>
> pumpSwitch ist der Name für den Schalter der Umwälzpumpe - z.B. ein 1-Wire
> Schalter
>
> Wenn man auf dieser Basis aufsetzt, wären also die nächsten Schritte
> - Algorithmus für die Steuerung (eben aus dem PID-Modul). Parametrierbar,
> z.B. in Bezug auf die Strategie zum Einschalten: lieber häufige kurze, oder
> seltene lange Pumpenläufe, Hysterese etc.
> - Frontend zur Eingabe von Tages- und Wochenprogrammen
> - Fernbedienungsmöglichkeit via Mobiltelefon.
>
> LG
>
> pah
>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com