Z-WavePlus Thermostat Eurotronic Spirit: Schrittweise Inbetriebnahme

[curt]

(Threaddrift)

Ich weiss nicht, ob ich gemeint bin mit dem PM Freund, Kontakt hatten wir zumindest und ich stehe zu meinen Nachrichten

Und ich stehe dazu, dass ich Dir via PN meinen goldenen Papp-Orden "Freundlicher Helfer des Tages" verliehen habe, danke nochmals!

Den Multisensor kenne ich nicht,

Damit ist vermutlich dieses Fibaro-Auge gemeint. Auch aus einer Sicht ein übles Drecksding, ich hatte drei davon ... wieder vertickert. Aber als Testobjekt ist der vermutlich nicht schlecht: Da darfst Du mit wirklich zig Readings und Hastenichgesehen rumspielen. Und natürlich mit dem wakeup-Zirkus, in meiner Erinnerung ist der heikel, Du kriegst nicht alle Nachrichten durch - irgendwann nach Tagen hat das Auge sind dann wieder erholt.

aber da ich bisher keine Batterie-ZWaves habe und vermutlich einfach Testhardware für das eine oder andere benötige:

Da habe ich was für Dich, das würde ich Dir zusätzlich empfehlen (ernsthaft!). Das ist aus dem Urlaubsprojekt "Nachbarin muss Gartenpumpe schalten" und genau so ranzig, wie die Bewertungen vermuten lassen. Beispielsweise ist mir bis heute AssoziationAdd nicht gelungen, aber es funktioniert ganz grundsätzlich. Zudem kannst Du die vier Taster völlig frei belegen. Es ist für Tests ideal, weil Du Entfernungsprobleme bekommst. Und die WakeUp-Probleme gibt es kostenlos dazu, so gesehen ein unschlagbarer Preis, schau hier: https://www.amazon.de/gp/product/B00M2JK69M/

Ansonsten: Wenn du die Konfiguration(-sanweisungen) für den Eurotronic zusammenstellst, kann ich gerne mal versuchen, das zu "vertemplaten",

Kannst Du bitte kurz erklären, was das "vertemplaten" rein praktisch bewirkt? Wo ist der Unterschied zu der Idee, dass Rudolf das einbezieht? - Ansich kann ich das aber gern nochmal aufschreiben: Das ist AssoziatonAdd sowie die bis zu 5 weiteren Befehle, auf die Du mich hingewiesen hast. Das kann ich der Lesbarkeit wegen gern in weiterem Beitrag konkret zusammenfassen.

und gehe davon aus, dass curt dann gerne den Tester macht?

Ich habe seit wenigen Tagen acht Thermostaten in Betrieb, die sind naheliegenderweise batteriegestützt. Und weil mein Freund @Deckoffizier gesagt hat, dass es da auch mal eine Fehlcharge geben kann, habe ich einen weiteren bestellt, der wäre für Tests frei. (Blöd ist halt, dass man den real an die Heizung schrauben muss, sonst will der nicht mit mir spielen. Aber ok: No risk, no fun.)

Und so wie ich Rudi kenne, ist er auch gerne bereit, im Modul ggf. sinnvolle "Begleitcodes" bereitzustellen, falls das erforderlich wäre. Setzt halt einen "konsolidierten Wissensstand" voraus.

Bevor da irgendwas los geht, ist eine ganz zentrale Frage zu klären: Was passiert, wenn eine ZWave-Device einen ungültigen Befehl erhält? Also beispielsweise ein kabelbetriebenes Gerät einen Befehl, den es nur für batteriegestützte Geräte gibt. Was passiert dann, was darf man auf der Protokollebene voraussetzen?

Die Antwort darauf ist immes wichtig. Denn falls das in der allgemeinen Spezifikation Fehlertoleranz befohlen ist, kann man das aus meiner Froschperspektive recht allgemein halten.

[curt]

Ontopic

Ich schrieb:

Übrigens fehlt bei manchen Thermostaten das Reading "thermostatMode" ... keine Ahnung warum. Da ist es wieder - mein Problem: Wegen Amazon in mehreren Tranchen bestellt, verschiedene Verpackungen zudem: Es könnte schon sein, dass verschiedene Versionen vorliegen. Aber das sieht man den Dingern ja auch in FHEM nicht an. Oder - ich habe bei den fraglichen Thermostaten irgendwas vergessen, ein GET oder ein SET. Sowas ist als Widerspruch kaum auflösbar.

Boah, unglaublich. Das ist ja unterirdisch ... ich hab's.

Vorbemerkung:
Normalerweise bestellt man eins, schaut mal was geht (wenn es ideal kommt, hilft einem eine treue Seele im Forum) und wirft es wieder weg. Ich hatte mich entschieden, acht zu kaufen. Das hat nun den Vorteil, dass ich wirklich vergleichen kann.

Wenn man den Inklusionszirkus mit anschließend mehreren händischen Schritten überstanden hat, laufen alle Thermostaten im Modus Heating, sie empfangen und senden fein. Das ist auch sehr stabil für ein batteriegestütztes Gerät. Je nach konkretem Thermostat ist das Reading "thermostatMode" oder nicht gesetzt. Obwohl wie gesagt alle im Modus "heating" sind.

Der Trick (Zufallsfund) besteht nun darin, dass man einen set- Befehl der Gruppe tm* absetzen muss, dann wird das manchmal fehlende Reading gesetzt.

Auch da muss man gleich an zwei Stellen aufpassen: tmCooling et al wird zwar angeboten, greift natürlich aber ins Leere. Und selbstbei funktionierendem "tmoff" hat man halt anschließend keinen heizenden Heizkörper mehr ... das steht aber nur in diesem Reading. Also zurück mit "set tmHeating".

P.S: Da in vorherigen Beiträgen gleich zwei Leute schrieben ich würde frustriert klingen: Ach Quatsch. Dann hätte ich FHEM 2017 in die Ecke gehauen. Es ist anders: Ich schreibe direkt - weil ich denke, dass man Probleme präzise als Probleme benennen muss, Kuschelformulierungen halte ich persönlich für wenig zielführend. - Mir geht es gut, ich freue mich über FHEM, über meine Thermostaten, über meine vielen Freunde im Forum: Seid alle freundlich gegrüßt.

[curt]

Zur Auflockerung zeige ich euch mal, was dann machbar ist - wenn viele FHEM-Ebenen zusammengreifen (und ich vielen Forum-Freunden über die Jahre danken darf):

Im Gästezimmer sind
* batteriegestützter Temperatursensor der Marke LaCrosse/Jeelink
* Fenstermelder Homematic
* Heizkörperthermostat Z-WavePlus Thermostat Eurotronic Spirit

Dazu kommen die vielen Hinweise seit Jahren und rein optisch FTUI @setstate und Chart @eki .

Zu sehen ist eine FTUI-Grafik, darin
* rot - Temperatur-IST im Raum
* grün - Temperatur-IST des Thermostat
* gelb - Temperatur-SOLL des Thermostat, völlig automatisiert vorgegeben (!)
* grau - Fenster offen?
* blau - Ventilstellung des Thermostat (0-100%) (alle 30min erhoben)

Da lacht das Techniker-Herz. (Und ich hörte im letzten Jahrtausend zwei Semester Automatisierungstechnik, mein Herz hüpft vor Freude!)

[Beta-User]

Sieht hübsch aus .

[OT: Mein aktuelles setup, was Thermostate angeht: HM-RT-CC-DN@CUL_HM<->(ZigBee|BT-LE|CUL_HM)-Temperatursensoren + Tür-FK's in CUL_HM (indirekt gepeert, öffnen mit Zeitverzögerung)
Ich "durfte" übrigens bei der Gelegenheit einen deftigen Logikfehler im Wiki beseitigen, was die Funktionalität mit virtuellen Temp-Sensoren angeht, der da seit Jahren unwidersprochen stand...]
Spannender ist aber die Frage, wie die Solltemperatur jeweils vorgegeben wird (und wie das an den Aktor kommt, also als Solltemperatur (CUL_HM kann afaik eigentlich nichts anderes, bei mir meistens via temp-Liste im Aktor, wenn jemand da ist oder (Umschaltung des Betriebsmodus) als manuelle Temperatur bei Abwesenheit (da ist bei mir hier die (ausdifferenzierte) Erkennung noch irgendwie unfertig)) oder als Vorgabe des Öffnungsgrads (das ist afaik ein Alleinstellungsmerkmal dieses Eurotronic-Thermostattyps! (=>PID20, wenn ich's richtig verstanden habe). Vergleichbares läßt sich wohl mit anderen derzeit käuflichen Thermostaten nur durch viel Getrickse erreichen...)


Was jetzt attrTemplate angeht:
- Das funktioniert nicht von ganz allein, der Anwender muß es "anschubsen";
- Es kann nur, was FHEM/Perl kann, Befehle, die unbekannt sind, kann man auch nicht absetzen. Der Anwender kann (nach meinem Verständnis und ohne das Absetzen von kryptischen "configWord/Byte ..." ) immer nur das an Befehlen wählen, was sich aus den XML ergibt. Sind da bugs drin, kann (oder zumindest sollte) man die nur zentral beheben.
- im attrTemplate kann (bzw. sollte) man ggf. die Klartextbefehle durch die "eigentlichen" Byte/Word/...-Konfigurationsbefehle ersetzen, denn das "wording" hängt am XML und kann sich jederzeit ändern
- Zeitlich gestaffelte Befehle sind möglich, da ist allerdings die (gedankliche?) Schwierigkeit, dass die Dinge teils aufeinander aufbauen und es uU. nicht mehr klappt, wenn irgendwo was schiefgeht (s.u.).

- Unklar ist auch, wie man verhindern kann, dass ein Anwender "das falsche template" auswählt und dann eben am Ende ein "komisches" Gerät hat (aber afaik sieht man wenigstens, was passiert ist, wenn die Antworten auf diverse gets da sind).

Na ja, jedenfalls könnte man im Falle dieses Thermostats so dann auch sicherstellen, dass zumindest dieser ominöse tm*-setter einmalig abgesetzt wird. Die XML enthält zwar die Option, aber (afaik) keinerlei Instruktion an die Controller-Software, irgendwas effektiv zu senden.

"vertemplaten" meint also eigentlich nur sowas in diese Richtung:
- Die FHEM-Befehle, die zu einem funktionierenden Device führen aufschreiben und "auf einen Rutsch" ausführbar machen, das ganze ggf. in mehreren Varianten (Bsp. Solltemp vs. Ventilsteuerung oder Rollladenaktor vs. Jalousiesteuerung)
- Dem Anwender vorab anzuzeigen, was es machen wird (dann kann man es auch manuell & anders machen, wenn man will) und ggf. darauf hinweisen, wie lange er ggf. warten soll, bis alles fertig ist;
- Links bereitstellen, aus denen man (möglichst ohne umfangreiche Suche) rauslesen kann, warum es soherum gemacht wurde und nicht anders, wo eventuelle Probleme herkommen, whatever you like...


Ich habe übrigens doch zwei Batteriegeräte, die allerdings nicht wirklich mit Stress beim Einbinden verbunden waren (soweit ich das heute noch in Erinnerung habe) - Fernbedienungen/Scene-Controller... heatit 8-push und einen (devolo?) 4-fach-Taster. Da war es nur so, dass ich von dem recht teuren heatit deutlich mehr Event-Variationsmöglichkeiten erwartet hätte, (irgendwo hier auch schon berichtet), und beide mussten recht häufig aufgeweckt werden, damit die Konfiguration schneller übertragen wird, was nicht eben batterieschonend genannt werden kann. Auch solche Erfahrungen könnte man sammeln und in der Beschreibung verfügbar machen (zumindest, soweit es die eher technischen Aspekte angeht, sonst wird amaz.* ja funktionslos )...
Von daher bin ich etwas am Zweifeln, ob ich mir grade den Stress mit dieser FB geben soll, die kommt  aber auf alle Fälle mal auf meine "Liste".



Generell kommt bei ZWave immer mal wieder durch, dass (vereinzelt) Befehle verloren gegangen zu sein scheinen (gestern erst wieder unter dem Stichwort "merten" gemeldet). Da fehlt mir noch ein Gefühl dafür, wo es herkommt, ob aus der Sendelogik oder ob es ein prinzipbedingtes Thema (beschränkt auf ältere Produkte?) ist. (Da erwarte ich keine direkte Antwort, muß wohl erst auch nochmal die Doku ein 10tes Mal lesen, vermutlich steht's da schon und ich versteh's  irgendwann...).
Sowas wäre halt hinderlich auf dem Weg zu funktionierenden Konfigurationen (via attrTemplate) .

[curt]

Sieht hübsch aus .

<kämmt sich nochmal> Danke!

Spannender ist aber die Frage, wie die Solltemperatur jeweils vorgegeben wird (und wie das an den Aktor kommt

Rein technisch über "set Thermostat_Gaestezimmer desired-temp 14.7"

Aber Du meinst vermutlich was anderes. Dazu muss ich mit meinen zwei Semestern kurz ausholen:
Allein mit der Vorgabe einer Temperatur für den Thermostat hast Du einen Regelkreis. Leider hast Du (sehr oft) einen übergeordneten Regelkreis: Die Heizung selbst "denkt" auch noch mit: Da wird normalerweise Außentemperatur gemessen, irgend eine Innentemperatur, damit hat die Heizung dann Vorgaben. Aus Automatisierungssicht ist das hässlich: Da greifen zwei Regelkreise ineinander, das Ergebnis ist kaum vorhersagbar. Ok, in Normalsituationen kann man darüber hinwegsehen.

Wenn Du nun aber für einen konkreten Raum den Sollwert irgendwie steuern oder gar regeln willst, dann hast Du den dritten Regelkreis - das wird dann wirklich heikel. Sowas will man nicht. Wirklich nicht.

Im Grunde will man was anderes, das nennt sich Steuerung: Man will für einen Raum eine Wohlfühltemperatur. Oder zwei, eine für den Tag, die andere für die Nacht. Das Problem besteht darin, den SOLL-Wert dafür experimentell zu bestimmen - auf alle Fälle grätscht der erste Regelkreis (Heizung selbst) da rein. Und sowohl bei Regelung als auch bei Steuerung hast Du den Zeitversatz, das Einschwingverhalten - darauf hast Du keinen Einfluss. Ich halte es für nicht realistisch, als Laie (ich bin einer) im dritten Regelkreis eine Nachführung zu machen. Nicht nur, weil das sehr komplex würde, vor allem fehlt Dir ein Wert: Ich darf daran erinnern, dass das Device batteriegestützt ist und mit der Konstruktion meines Freundes alle 30 Minuten meldet. Öfter geht nicht, Du kannst ja nicht jede Woche Batterien wechseln.

Was jetzt attrTemplate angeht:

Überlesen. Ich weiß nicht ansatzweise, was ich mit einem Template machen könnte. Vermutlich ein GET oder ein SET auf ein Device. Und warum ich das tun sollte, wo ist da mein konkreter Gewinn? Sag mal bitte.

Neh Du: Das funktioniert grad schön.

Ich habe übrigens doch zwei Batteriegeräte, die allerdings nicht wirklich mit Stress beim Einbinden verbunden waren

Ich empfehle nochmals die von mir schon genannte Fernbedienung.

Generell kommt bei ZWave immer mal wieder durch, dass (vereinzelt) Befehle verloren gegangen zu sein scheinen

Wir müssen sehr klar zwei Situationen unterscheiden:

1) Inklusion
2) Betrieb

zu 1) Inklusion:
Da nachweisbar die Entfernung zur Basis eine Rolle spielt, muss geschlussfolgert werden, dass bei mehreren/vielen Telegrammen entweder das Zeitfenster zu klein ist oder die Device mit Fehlern schlecht umgehen kann. Dafür spricht im Grunde auch der Hinweis auf "sleep 3" für den Normalbetrieb von @rcmcronny . Das gilt übrigens nicht nur für Thermostate, selbst bei Funksteckdosen (die ja kein wakeup haben) hatte ich jedesmal den gleichen Zirkus.

zu 2) Betrieb
Im Normalbetrieb sind ZWave-Devices deutlich stabiler. Wirklich stabil.
Batteriebegestützte ZWave können offenbar aber nicht zu viele Telegramme bei Wakeup annehmen, zudem blockieren die Quittungen den Kanal, siehe Hinweis "sleep 3" von @rcmcronny.
Tatsächlich gehe ich mit der Idee schwanger, jeden Befehl (mit sleep 3) doppelt abzusenden - ich will doch nicht im Schlaf erfrieren.

[Beta-User]

Rein technisch über "set Thermostat_Gaestezimmer desired-temp 14.7"

Ich _glaube_: Jein!

- Entweder so, oder
- über die Vorgabe eines Öffnungsgrades des Ventils (!) oder
- über ein Wochenprogramm, das AUTONOM auf dem Thermostat abläuft (irgendwo meine ich gelesen zu  haben, dass das mit anderer Controller-Software ginge, und der (vermutlich ähnlich programmierte?) ZigBee-Verwandte kann es - nach entsprechender Nacharbeit - afaik auch)

Aber Du meinst vermutlich was anderes. Dazu muss ich mit meinen zwei Semestern kurz ausholen:
[...]

Na ja, das mit der Abstimmung der verschiedenen (teil-) autonomen Regelungsmechanismen (da gibt es ja noch mehr Teilsysteme, angefangen bei intelligenten Umwälzpumpen für's Heizungswasser oder die Solarthermie) ist ein allgemeines Thema, und mein Hinweis, dass da etwas mehr Wiki-Arbeit eigentlich ganz sinnvoll wäre, ging in etwa in diese Richtung.
Sollten wir aber einstweilen an dieser Stelle nicht vertiefen

Ich empfehle nochmals die von mir schon genannte Fernbedienung.

Habe schon verstanden, dass die "besonders spassig" ist; wie gesagt: kommt auf die Liste, hat aber low prio.

Überlesen. Ich weiß nicht ansatzweise, was ich mit einem Template machen könnte. Vermutlich ein GET oder ein SET auf ein Device. Und warum ich das tun sollte, wo ist da mein konkreter Gewinn? Sag mal bitte.[...]
Wir müssen sehr klar zwei Situationen unterscheiden:

1) Inklusion
2) Betrieb

"Sag mal bitte" = attrTemplate liegt eigentlich "zwischen" 1) und 2).
ad 1) Ohne fertige Inklusion gibt es keine vernünftige Kommunikation mit FHEM, prinzipiell müßte dann alles weitere scheitern. Ausnahme: bestimmte zur Inklusion gehörende Funktelegramme gehen verloren; die könnte man ggf. via attrTemplate wiederholen lassen (vermute: geht mit den originären Bodrmitteln besser, da zielgerichtet)

2) Ein "Betrieb" setzt voraus, dass das Gerät fertig konfiguriert ist. Wenn es Sinn machen sollte, die Queue zu optimieren oder Quittungsverfahren "zu härten", gehört das m.E. ins (IO-) Modul, solche würgarounds sollten überflüssig sein. Ggf. brauchen wir Möglichkeiten für den User, dem IO seine Anwendungssituation mitzuteilen. Sowas wäre ggf. über Attribute zu regeln.

Damit sind wir eben bei der Frage, wie man die Geräte optimal für den Regelbetrieb konfigurieren kann. Dazu gehören einmalige Konfigurationsbefehle nach der Inklusion sowie ggf. individuelle Einstellungen, die irgendwie zusammenpassen sollten. Das kann man vercoden, that's all.
Bringt dem nichts, der den Code liefert, sondern erst dem nächsten.

(Zu eventuellen Funktionserweiterungen - Stichwort Wochenprogramm als Beispiel - schreibe ich bei Gelegenheit noch was).

[rudolfkoenig]

- Unklar ist auch, wie man verhindern kann, dass ein Anwender "das falsche template" auswählt und dann eben am Ende ein "komisches" Gerät hat

Im Template anhand das model Reading filtern.

[curt]

Rein technisch über "set Thermostat_Gaestezimmer desired-temp 14.7"

Ich _glaube_: Jein!

Ich weiß: Nur so und nicht anders.

- über die Vorgabe eines Öffnungsgrades des Ventils (!) oder

Wer das kann, hat einen Tagessatz von um die 2.000 und meinen höchsten Respekt. Da lassen wir die Finger von.

- über ein Wochenprogramm, das AUTONOM auf dem Thermostat abläuft

Würde ich sofort ausschalten.

Na ja, das mit der Abstimmung der verschiedenen (teil-) autonomen Regelungsmechanismen

Ok, lernen in 30 Sekunden:
1) Steuerung: Sollwert vorgegeben, Istwert folgt. Geprüft wird nix.
2) Regelung: Ein Kreis. Sollwertgeber prüft immerzu wo der Istwert ist und regelt nach.

Obiges bitte fünfmal lesen, ist wichtig.

Schlussfolgerung:
Wenn verschiedene Regelungen ineinandergreifen, ist das Ergebnis faktisch nicht kontrollierbar. Das sind Projekte, die ganz schnell im Millionenbereich sind. Dafür sind wir mit FHEM alle deutlich zu arm.

Anders gesagt: Wir müssen eher verhindern, dass verschiedene Regelkreise ineinander greifen.

2) Ein "Betrieb" setzt voraus, dass das Gerät fertig konfiguriert ist. Wenn es Sinn machen sollte, die Queue zu optimieren oder Quittungsverfahren "zu härten", gehört das m.E. ins (IO-) Modul,

Genau das wünschte ich mir, siehe meine letzten Beiträge.

Damit sind wir eben bei der Frage, wie man die Geräte optimal für den Regelbetrieb konfigurieren kann. Dazu gehören einmalige Konfigurationsbefehle nach der Inklusion

Genau das wünschte ich mir, siehe meine letzten Beiträge.

[Beta-User]

Ich weiß: Nur so und nicht anders.

OK, dann sprechen wir vermutlich von einem anderen Produkt. In der openzwave_device.xml finde ich zu "KOMFORTHAUS Spirit Z-Wave Plus" (mehr habe ich mit "spirit" nicht gesucht) folgendes:

    <Value genre="user" index="0" instance="1" label="Mode" type="list">
       <Help>                 Off: No heating, only frost protection.                 Heat: Room temperature will be kept at the configured setpoint.                 Heat Eco: Energy save heating mode. Room temperature will be lowered to the configured eco setpoint in order to save energy.                 Full Power: Full power heating. This mode is left automatically after 5 minutes.                 Manufacturer Specific: Direct valve control mode. The valve opening percentage can be controlled using the switch multilevel command class.             </Help>
      <Item label="Off" value="0"/>
      <Item label="Heat" value="1"/>
      <Item label="Heat Eco" value="11"/>
      <Item label="Full Power" value="15"/>
      <Item label="Manufacturer Specific" value="31"/>

Den Einzelbeitrag mit der Sache mit den Wochenprofilen habe ich jetzt nicht gesucht, vermutlich geht es da dann auch um andere Hardware...

Wer das kann, hat einen Tagessatz von um die 2.000 und meinen höchsten Respekt. Da lassen wir die Finger von.

Welchen Tagessatz die betreffenden User verlangen, entzieht sich meiner Kenntnis, aber ich bin ziemlich sicher, dass es die gibt. Stichwort war u.a. PID20, wenn ich die Puzzleteile richtig zusammensetze. Damit wird nach meinem Verständnis die "Regelung" gemacht.

Würde ich sofort ausschalten.

Bislang hattest du dich nicht auf eine Variante festgelegt, sondern erst jetzt mitgeteilt, dass für dich nur die Variante mit dem (aktuellen) desired-temp in Frage kommt. Das ist ok, aber es ist völlig klar, dass da jeder User seine eigene Meinung dazu hat...

Dementsprechend sollte er
a) irgendwo erfahren, welche Optionen er eigentlich hat und was er sinnvollerweise an Steuerung, Regelung und Umfeldinfos, -Modulen usw. braucht, damit es am Ende jeweils so warm ist, wie er oder seine Familie das gerne hätte .

b) dann ein vereinfachtes Verfahren haben, um zumindest das betreffende Einzeldevice entsprechend seinen (Ziel-) Vorstellungen zu konfigurieren...

Im Template anhand das model Reading filtern.

Na ja, filter: (und prereq:) kamen mir hier nicht so richtig zielführend vor: filter: bewirkt nur, dass man das Template nicht sieht (=> man kann es aber via Kommandozeile ausführen!), und die Sichtbarkeit von (vielleicht!) vergleichbaren Konkurrenzprodukten, was die Konfiguration angeht, war grade was, was m.E. sinnvoll wäre...


(Da sind noch ein paar andere Punkte in den Beiträgen vergraben, zu denen mir auch ein paar noch ungeordnete Gedanken gekommen waren, dazu folgt ggf. irgendwann noch was).

[Deckoffizier]

Hallo curt,

Offen ist noch das, was @Deckoffizier da mit readingList und setlist macht - beide sind nirgendwo hinreichend (mit Beispielen!) beschrieben. Vermutlich so eine Art Runterklappmenü - aber das rate ich nur.

anbei ein Bild

für setlist ergibt sich z.B nach Auswahl einer zwischenzeitlichen Temperatur z.B. bei 24 Grad nebenstehender Text manuell aktiv oder wie Fenter offen oder Fenster noch offen.

Zur Regelung steige da jetzt nicht mehr ganz durch, aber "meine" Erklärung dazu,  entweder nutze ich die Regelstrategie des Thermostaten selber
mit seiner eigenen Temperaturmessung(find ich nicht so optimal) intern vielleicht auch PID20 Logik (heating Modus).

Oder in tmManual Modus mit externen Tempsensor und eigenen PID20 Einstellungen oder wie auch immer und z.B. weekdaytimer für die Schaltzeiten.

Hier schon mal irgendwo gelesen, zur Vorlauftemperaturreglung der Heizungsteuerung benutzt man nicht die Außentemperatur(gängig) als Eingabe, sondern "nur" die Raumtemperatur eines Referenzraumes zum ? Energiesparen.

Und Ja, ich benutze für die Raumtemperatur Messung die Fibaro Multisensor(Magische Auge) Teile und bin damit soweit Zufrieden.
Habe die Sensoren auf die ober unter Teile  einer Messing  Duftöllampe geschraubt und hat somit einen gewissen Schick 
Kann es mir leider nicht verkneifen, anbei meine Freunde suche ich mir alleine aus.

Gruß
Hans-Jürgen

[Deckoffizier]

Hallo curt,

an bei ein Bildschirmfoto von der
Regelung ala PID20 muss dazu sagen hatte über Tag die Heizung komplett abgeschaltet da es Heute
fast Sommerlich war und die Regelung des Thermostaten ohne Heizwasservolumenstrom im Plattenheizkörper
ins Leere ging.

Im Schnitt komme ich mit einmal im Jahr mit Akku nachladen aus.

Gruß
Hans-Jürgen

[Deckoffizier]

Hallo curt,

mein  Senf vage ausgedrückt zur Heizungsregelung.....

im OPTIMAL Fall sind bei entsprechender Heizungsanlage Thermostatventile überflüssig.
Sie sollen eigentlich nur den Fremdwärmeanteil wie Z.B. Sonneneinstrahlung, Kochen etc.
regeln.

Bei richtiger Heizkennlinie und Hydraulischen Abgleich(Durchfluss) wären sie immer auf 100% offen.

Eine Art der Regelung wie vorher schon angedeutet wäre eben die Regelung des Kesselschaltfeldes
mit seiner Heizkennlinie und eventuell Mischer nur über die Auswertung der  einzelnen Ventilöffnungen in den einzelnen
Räumen wie hier im Forum schon mal vorgestellt.

Heizungsregelung ist ein weites Feld und schwer pauschal zu händeln  Stichwort Fußbodenheizung Trägheit,  Plattenheizkörper, Wärmepumpe etc.

Gruß
Hans-Jürgen

[rcmcronny]

Hoi,

die Ventilsteuerung geht mit dem Spritis, dazu muss man aber in den Manuellen Modus schalten (per tmManual glaube) dann kann man per Dim 0-99 den Öffnungsgrad steuern. Macht aber nur Sinn mit PID oder was vergleichbaren meiner Meinung nach

Ronny

[curt]

Freunde der warmen Wohnküche([@Deckoffizier inbegriffen), in diesem Beitrag Antworten, allgemeine Anmerkungen.

OK, dann sprechen wir vermutlich von einem anderen Produkt.

Nein, wir sprechen über den im Subject angegebenen Thermostat. (Ich vermute aber, dass Deckoffizier einen anderen Thermostaten am Start hat.)

Bislang hattest du dich nicht auf eine Variante festgelegt, sondern erst jetzt mitgeteilt, dass für dich nur die Variante mit dem (aktuellen) desired-temp in Frage kommt. Das ist ok, aber es ist völlig klar, dass da jeder User seine eigene Meinung dazu hat...

Da waren zwei Diskussionsebenen im Spiel. Ja -ich- werde die temperaturgeführte Steuerung (bei mir ist dieser Teil Steuerung, nicht Regelung) nehmen.

Nochmal zu den Begrifflichkeiten, das scheint mir wichtig:
* Moderne Heizungsanlagen sind oft Regelungen, abhängig von der Außentemperatur
* Thermostaten sind (außer: Mode manual) insich autonome Regler
* Wenn ich als Person dem Thermostaten 22°C vorgebe, steuere ich ihn quasi - Sollwertvorgabe ohne meine Nachführung

Tatsächlich hat der Thermostat die via set ansprechbaren Modi (immer "tm" vorn)
* off (Frostschutz, Regelung 6°C),
* heating (temperaturgeführte Regelung im Thermostaten)
* ernergysaveheating (vmtl. stärkere Dämpfung des Regelglieds)
* manual (man kann von 0-100 drehen, das nutzt Steuermann)

(In den angebotenen FHEM-Optionen für diesen Thermostaten taucht auch noch cooling und auto auf. cooling steht nur zur Verwirrung des Publikums drin, natürlich kühlt der nicht. Bei auto bin ich mir nicht sicher, müsste nachsehen.)

Dementsprechend sollte er
a) irgendwo erfahren, welche Optionen er eigentlich hat und was er sinnvollerweise an Steuerung, Regelung und Umfeldinfos, -Modulen usw. braucht, damit es am Ende jeweils so warm ist, wie er oder seine Familie das gerne hätte .

Ich glaube, Du bist auf der falschen Ebene. Oder zu schnell die Treppe hoch ... ich bin noch auf dem Punkt, dass das neu inkludierte Device einige Attribute und settings und gets nicht hat, was in JEDEM Modus erforderlich ist. Da wäre es halt schön, wenn nicht jeder sich tagelang mit dem Dingens rumärgern muss. Allerdings ist das nicht so einfach, wie es auf den ersten Blick aussieht: Das Dingens ist batteriegestützt, da können Kommandos schon mal verloren gehen - das muss auch abgesichert werden.

OT: Die Anmerkung mit dem Tagessatz bezog sich nicht auf FHEM. Das war für die Situation, dass ein Dipl-Ing. Automatisierungstechnik mehrere voneinander abhängige Regelungen konfigurieren muss.

b) dann ein vereinfachtes Verfahren haben, um zumindest das betreffende Einzeldevice entsprechend seinen (Ziel-) Vorstellungen zu konfigurieren...

Ich verstehe, wo Du hin willst. Aber ich denke, dass das der zweite Schritt ist.

Hier schon mal irgendwo gelesen, zur Vorlauftemperaturreglung der Heizungsteuerung benutzt man nicht die Außentemperatur(gängig) als Eingabe, sondern "nur" die Raumtemperatur eines Referenzraumes zum ? Energiesparen.

Es gibt zig Versionen. Nur mal EIN Beispiel: Ich habe ein Niedrigenergiehaus mit einer Brennwertgasheizung. Bei der konkreten Heizung wird sowohl die Außentemperatur als auch die Innentemperatur des größten Hauses als Regelgrößen genommen. Wer es in so einer Konstellation noch nicht wusste, der lernt es dann: Da ist mit einfacher Ganglinie nichts mal einfach zu machen.

Und Ja, ich benutze für die Raumtemperatur Messung die Fibaro Multisensor(Magische Auge) Teile und bin damit soweit Zufrieden.
Habe die Sensoren auf die ober unter Teile  einer Messing  Duftöllampe geschraubt und hat somit einen gewissen Schick 

Magst Du zwecks Auflockerung mal ein Foto zeigen?

mein  Senf vage ausgedrückt zur Heizungsregelung.....
im OPTIMAL Fall sind bei entsprechender Heizungsanlage Thermostatventile überflüssig.
Sie sollen eigentlich nur den Fremdwärmeanteil wie Z.B. Sonneneinstrahlung, Kochen etc. regeln.

Es ist viel komplexer: Da spielt der k-Wert (Wärmedurchgangskoeffizient) von Wand und Fenster (und deren Flächengrößen) eine Rolle. Und wenn die Rolläden runter sind, ändert das nochmal alles.

Bei richtiger Heizkennlinie und Hydraulischen Abgleich(Durchfluss) wären sie immer auf 100% offen.
Eine Art der Regelung wie vorher schon angedeutet wäre eben die Regelung des Kesselschaltfeldes
mit seiner Heizkennlinie und eventuell Mischer nur über die Auswertung der  einzelnen Ventilöffnungen in den einzelnen
Räumen wie hier im Forum schon mal vorgestellt.

Ach, so einfach ist das alles nicht, das wäre ja der ideale Mensch. Das mag die Dame des Hauses mit ihrem Gatten noch hinkriegen, ansonsten scheitert es: Den einen ist wichtig, Energie zu sparen. Andere mögen es kuschlig warm im Wohnzimmer. Im Schlafzimmer soll es recht kühl sein - oder manche mögens heiß. Gästezimmer sollen kühl sein - außer: Gäste sind da. Aber jeder Gast ist anders. Bei Damen ist das Wärmeempfinden im Laufe des Monats unterschiedlich - Männer sind aber auch mit subjektiver Wärmeempfindung ausgestattet ...

Heizungsregelung ist ein weites Feld und schwer pauschal zu händeln  Stichwort Fußbodenheizung Trägheit,  Plattenheizkörper, Wärmepumpe etc.

Du sagst es, wir sind uns völlig einig.

[curt]

Dieser Beitrag geht fragend an alle: DOIF, readingList, setlist.

Offen ist noch das, was @Deckoffizier da mit readingList und setlist macht - beide sind nirgendwo hinreichend (mit Beispielen!) beschrieben. Vermutlich so eine Art Runterklappmenü - aber das rate ich nur.

für setlist ergibt sich z.B nach Auswahl einer zwischenzeitlichen Temperatur z.B. bei 24 Grad nebenstehender Text manuell aktiv oder wie Fenter offen oder Fenster noch offen.

Also ich glaube verstanden zu haben, dass Du vermittels eines Klapp-runter-Menüs Temperaturen allgemein vorgibst, aus denen Du Dir eine Temperatur auswählst. Ich würde gern verstehen, wie man das macht.
(Wie Du das dann in Regelung für Deine Manualregelung umsetzt, spielt für meine Fragestellung keine Rolle - nur dieser erste Teil.)

In https://forum.fhem.de/index.php/topic,105272.msg995598.html#msg995598 lese ich (auf das Relevante gekürzt):

Code Auswählen Erweitern


defmod eg_kue_wunschtemp DOIF ([Wunschtemp_temp_eg_kue])
attr eg_kue_wunschtemp do always
attr eg_kue_wunschtemp readingList mantemp
attr eg_kue_wunschtemp setList mantemp:12,17,18,19,20,21,21.5,22,22.5,23,23.5,24,26
attr eg_kue_wunschtemp webCmd mantemp


Es mag ja an meiner mangelhaften Kenntnis von DOIF liegen, Wiki hilft auch nicht (nur ein Stub für setlist, readinglist fehlt völlig), alte Forenbeiträge helfen auch nicht:
In der eckigen Klammer muss ja eigentlich eine Testbedingung stehen, dieses "Wunschtemp_temp_eg_kue" finde ich aber in dem Beitrag nicht wieder - wo kommt das her, was steht da drin?

Bei Gültigkeit der Testbedingung werden offenbar die folgenden Attribute gesetzt, richtig?

Aber was ist "mantemp"? Auf den ersten Blick scheint das ja ein Zahlenwert für Temperatur zu sein. Aber was macht das webCmd da? Steht in mantemp vielleicht ganz was anderes?

Können wir (das muss jetzt wirklich nicht nur Deckoffizier sein) mal bitte schrittweise aufdröseln, was da passiert? (Und was da ggf. fehlt?)