Z-WavePlus Thermostat Eurotronic Spirit: Schrittweise Inbetriebnahme

[Beta-User]

Hmmm kan mich irren,  für mich bezieht sich das auf den eingestellten Sollwert.

Na ja, in der xml heißt es nur lapidar:

Code Auswählen Erweitern

1-50: Report temperature at 0.1-5.0°C temperature difference
Dass sich das auf das Delta zur Solltemperatur bezieht, wäre eine mögliche Interpretation, irgendwo in den Untiefen des Inet habe ich das andere gefunden, und die Bedienungsanleitung meint:

Code Auswählen Erweitern

Die vom Spirit Z-Wave Plus gemessene Raumtemperatur wird automatisch bei einer Änderung von ±0,5°C gesendet. Der Schwellwert kann konfiguriert werden.

Das spräche eher für "meine" Interpretation, dass es entweder das Delta zur vorangegangenen Messung ist oder zum vorangegangenen übertragenen Messwert (was wohl auch eine Interpretation deiner Aussage zu von "22=>18" wäre) - jedenfalls habe ich für diese KW insgesamt ca. 120 Zeilen im Log (für alles), vorher hatte ich tagelang gar keinen Wert (ist aber ein Nebenraum, in dem die Temperatur eher nicht so schwankt bzw. der vom Hauptraum auch was an Wärme abbekommt). Als besonders gesprächig würde ich das daher im Moment nicht bezeichnen (gedanklicher Vergleichspunkt sind die HM-CC-RT-DN, die alle 2,5 Minuten "alles mögliche" senden).

Ein Thermostat ist nun mal kein Thermometer bzw. Multisensor wie das sogenannte Fibaro "Auge".

Das ist schon klar, aber zunächst will ich ja erst mal verstehen, wie das Ding "tickt", und dafür brauche ich halt erst mal Daten - optimalerweise von dem Teil selbst, notfalls eben dann doch von Zusatzequipment, mal sehen...

Wenn ich es es richtig überblicke versucht Du über Bit und Bytes Einstellungen den Thermostaten als
Thermometer zu überreden laienhaft gesprochen? 

An sich müsstest Du bei Dir gut an Hand des Zeitstempels erkennen wie oft der interne Temp Sensor
bei minimal 0,1 Schwankung abgefragt wird?

Wie gesagt: Wenn ich wirklich einen Thermometer brauche, dann nehme ich einen anderen, ich will nur erst mal wissen, wie das Ding intern tickt und was man damit am besten so "anstellt" - und an sich finde ich "hin und wieder eine Meldung" auch gar nicht schlecht. In jedem Fall sind die workarounds, die hier teils geteilt werden (mit den regelmäßigen get-Abfragen) mAn. die schlechtere Variante gg. automatischen Pushes des Devices selbst.

Vielleicht kann der Hersteller dazu was sagen.

Der schweigt sich bisher jedenfalls zur firmware-Anfrage aus. Außer einer "kann sich situationsbedingt verzögern"-Antwort ist da seit der Anfrage vor einer Woche Funkstille.

Aber in der Bedienungsanleitung habe ich eben noch was interessantes gefunden:

Code Auswählen Erweitern

Um den vollen Funktionsumfang des Spirit Z-Wave Plus nutzen zu können wird ein Security Enabled Z-Wave Controller benötigt.
Werde das Ding also nochmal exkludieren und dann mit Security includieren. Vielleicht gibt es dann auch "clock"? (Dass sich die verfügbaren Kommandos _auch bei sowas simplem wie einem Thermostaten_ unterscheiden könnten, darauf wäre ich von alleine wohl auch nicht gekommen... Muß mal suchen, ob dazu hier im Forum schon was zu finden ist.)

Auch vermute ich das die Anwendung des Thermostaten über entsprechende Zentralen gedacht ist
also Klicki Bunti und für den "Normalo" Anwender ohne tieferes config Wissen gedacht ist.
Wo wir wieder bei den Templates wären?

Na ja, besonders intuitiv fand ich jetzt weder das HomeCenter lite noch z-way. Vermutlich müßte man sich auch mit dieser Art Zentrale intensiver befassen - aber am Ende wird das so ähnlich sein wie bei deconz: Letztlich kann man nur sehr schwer nachvollziehen, was denn tatsächlich abläuft (ob z.B. die Hardware direkt miteinander spricht oder die Zentrale erforderlich ist). Da mache ich doch lieber noch etwas Experimente mit FHEM, da weiß ich am Ende wenigstens, woran ich bin...

[Nobbynews]

Aber in der Bedienungsanleitung habe ich eben noch was interessantes gefunden:

Code Auswählen Erweitern

Um den vollen Funktionsumfang des Spirit Z-Wave Plus nutzen zu können wird ein Security Enabled Z-Wave Controller benötigt.

Wobei sich mir bei der Tabelle auf Seite 15 der Bedienungsanleitung die Frage stellt, welche Befehlsklasse durch S0 oder S2 zusätzlich zur Verfügung stehen soll.
Eigentlich sagt die Tabelle doch aus, dass bei S0 oder S2 die Befehlsklassen "Security", "Transport Service" und "Z-Wave Plus Info" nicht unterstütz werden.
Fehlinterpretation meinerseits?

[Beta-User]

Wobei sich mir bei der Tabelle auf Seite 15 der Bedienungsanleitung die Frage stellt, welche Befehlsklasse durch S0 oder S2 zusätzlich zur Verfügung stehen soll.
Eigentlich sagt die Tabelle doch aus, dass bei S0 oder S2 die Befehlsklassen "Security", "Transport Service" und "Z-Wave Plus Info" nicht unterstütz werden.
Fehlinterpretation meinerseits?

Gedanklich hatte ich diesen Hänger auch schon, und nachdem ich die Hinweise von Rudi zum Thema Funklast bei Security in letzter Zeit gesehen habe, macht das für mich eigentlich keinen großen Sinn mit "Security" für das Ding, zumal ja auch die xml (die auch von anderen Lösungen zugrundegelegt werden) keine Unterscheidungen zu enthalten scheinen... Damit würde man auch wieder im Nebel rumtappen.


Es ist mir jetzt übrigens gelungen, über den userReadings-Weg das desired-temp-Reading zu erzeugen und zu füllen - das scheint im wesentlichen zu klappen, allerdings  (wg. des Einklinkens in die ACK-Schleife) nur nicht-triggernd. Könnte man anders machen, wenn man sich in die state-Verarbeitung einklinkt, aber wie geschrieben wäre das de facto eine Änderung des defaults in den Gateway-Einstellungen... (leider reagiert das gar nicht mehr, wenn ich versuche, das von "nicht-triggerndem" Readings-Udate auf ein entsprechendes Bulk-Verfahren umzustellen (Versuch ist auskommentiert, ab Zeile 5092):

Code Auswählen Erweitern

readingsSingleUpdate($hash, "transmit", $lmsg, 0);
        #readingsBeginUpdate($hash);
        #readingsBulkUpdate($hash, "transmit", $lmsg, 0);
        #readingsEndUpdate($hash,1);
       

Den myUtils-Code habe ich eingecheckt (kann man über contrib/das template holen), das userReadings-Attribut dazu sieht so aus:

Code Auswählen Erweitern

attr ZWave_THERMOSTAT_20 userReadings energySaveHeating:setpointTemp.+energySaveHeating {ReadingsNum($name,"setpointTemp",0)}, heating:setpointTemp.+heating {ReadingsNum($name,"setpointTemp",0)}, thermostatMode:setpointTemp.+ {ReadingsVal($name,"setpointTemp",0)=~m/(heating|energySaveHeating)/;; $1?$1:undef}, valve:reportedState.+(dim.[0-9.]+|off) {my $val = ReadingsVal($name,"state",0);; return 0 if $val eq "off";; ReadingsNum($name,"state",0)}, testAck2:transmit.*OK { FHEM::attrT_ZWave_Utils::desiredTemp($name) }

An sich könnte man auch die ersten paar in den Code integrieren, das war noch die Auswertung der "get"-Anfragen, aber auch da wäre es m.E. konsistenter, sich in die set-ACK-Schleife einzuklinken.

Ziel sollte eigentlich mAn. sein, auf sämtliche get-Anfragen möglichst zu verzichten, denn die führen immer mal wieder zu Problemen, jedenfalls scheint auch das hier eine Bestätigung dieser These zu sein: https://forum.fhem.de/index.php/topic,115561.0.html

Anbei auch mal ein log mit den 1/1 Einstellungen bei valve- und temp-Differenz - alles ganz ohne get-Anfragen. MAn wäre das völlig ok so (wenn es denn bei allen Devices mit diesen Einstellungen auch entsprechende Rückmeldungen gäbe).

Meinungen/Kritik/Anregungen dazu...?

[Nobbynews]

Gedanklich hatte ich diesen Hänger auch schon, und nachdem ich die Hinweise von Rudi zum Thema Funklast bei Security in letzter Zeit gesehen habe, macht das für mich eigentlich keinen großen Sinn mit "Security" für das Ding, zumal ja auch die xml (die auch von anderen Lösungen zugrundegelegt werden) keine Unterscheidungen zu enthalten scheinen... Damit würde man auch wieder im Nebel rumtappen.

Ich habe mir zu Vergleichszwecken zusätzlich zum Spirit noch den von Aeotec geholt und per secure inkludiert.
Version ist:

Code Auswählen Erweitern

Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.2
Scheinen also so ziemlich identisch zu sein.
Was den Batteriestatus angeht, macht es aber keinen Unterschied zum non secure inkludierten Spirit.
Freiwliig spucken die nichts aus, obwohl beide auf SendOnceADay stehen.

[Beta-User]

Nachdem du das Teil secure inkludiert hast: Vermutlich ändert das ja nichts an den CLASSES. Aber _wenn_ es dann ginge, Wochenprogramme zu fahren (was ich jetzt nicht wirklich glaube), dann müßte das Ding eine Uhrzeit haben wollen bzw. setzen lassen.

Mein ursprünglicher "Versuchsplan" war, daher schlicht das CLOCK (?) zu ergänzen und dann zu versuchen, mal eine Uhrzeit zu setzen und den Wert abzufragen (k.A., wie das genau geht). Wenn auch das nicht geht, steht m.E. fest, dass nicht nur die Werbung falsch ist, sondern wohl auch die Aussage aus der Bedienungsanleitung... Dann macht secure nur zusätzliche Funklast und wäre daher - jedenfalls für den üblichen Hausgebrauch - nicht zu empfehlen.

Was das mit der Batterie angeht, ist es wirklich seltsam. Im Zweifel könnte man da aber ein "halbtägiges at" (oä.) definieren, das dann alle Spirit, die nicht innerhalb der letzten 24h ein Reading geliefert haben auffordert das nachzureichen? Wenn man das über eine Routine abbildet, müßte sich die Abfrage auch entzerren lassen, indem man für jedes Element eine entsprechende Verzögerung dazubaut.

[rudolfkoenig]

Mein ursprünglicher "Versuchsplan" war, daher schlicht das CLOCK (?) zu ergänzen und dann zu versuchen, mal eine Uhrzeit zu setzen und den Wert abzufragen (k.A., wie das genau geht)

Ich staune ueber die vielen Versuche, die Firmware durch setzen von FHEM-Attributen zu erweitern: ich gehe davon aus, dass ein Firmware-Schreiber, der die Muehe macht, die Funktionalitaet zu implementieren, der verschweigt das nicht.
Die CLOCK Befehle/Events sind dokumentiert.

[Nobbynews]

Nachdem du das Teil secure inkludiert hast: Vermutlich ändert das ja nichts an den CLASSES. Aber _wenn_ es dann ginge, Wochenprogramme zu fahren (was ich jetzt nicht wirklich glaube), dann müßte das Ding eine Uhrzeit haben wollen bzw. setzen lassen.

Nein, wollte das Teil nicht. Und wenn ein Wochenprogramm von Haus aus im Gerät ginge, dann sollte das doch eigentlich irgendwo beschrieben und auch einstellbar sein.
Stattdessen gibt es z.B. bei Eurotronic im Datenblatt nur den dezenten Hinweis, dass zur Nutzung der "energieeffizienten Steuerung" eine Z-Wave Zentrale erforderlich ist.
Bei Aeotec hießt es auch nur:

You can automate it, and you can manually control it. Radiator Thermostat can be intelligently automated or scheduled via Z-Wave, or it can be manually controlled from an app or its on-device buttons and backlit, LCD screen.

Ich würde daher mal sagen, die Dinger sind im Vergleich zu z.B. MAX ziemlich "dumm".

[Beta-User]

...bescheuert ist eigentlich nur, dass die "Werbung" suggeriert (ich hatte das die Tage mal irgendwo zitiert), das Ding wäre intelligenter...

Aber mit FHEM ist es dann auch kein Problem, "unendlich" viele Werte in ein Wochenprogramm einzubauen, von daher ist dann auch wieder die Werbeaussage in die andere Richtung bescheuert (oder andere Controller-Software ist beschränkt? Dass "unendlich" nicht sinnvoll ist, ist auch klar...).

Wie dem auch sei, dann bleibt das Ding hier jedenfalls inkludiert "as is" und meine Versuche werden dann eher in Richtung der "Verbesserung" der Readings gehen. Dazu braucht es aber vermutlich mindestens noch eine Unterscheidung in "durch get angefragt" und "vom Thermostaten gesendet" bei der Rückmeldung der "heating"-Werte.

@Nobbynews: bekommst du denn eine Rückmeldung, wenn du manuell am Thermostaten selbst die Soll-Temperatur änderst oder bleibt das Ding auch in der Beziehung stumm?

@Rudi (und ggf. krikan): Eine Rückmeldung wäre nett, ob ich mit den ganzen Überlegungen zur "Nachverarbeitung nach ACK" (notfalls über userReadings auf state-Trigger+entsp. Einstellung am IO) irgendwie auf dem Holzweg bin... Eventuell habt ihr da ja vor langer Zeit schon mal intensiv drüber nachgedacht und sowas verworfen?

[Nobbynews]

@Nobbynews: bekommst du denn eine Rückmeldung, wenn du manuell am Thermostaten selbst die Soll-Temperatur änderst oder bleibt das Ding auch in der Beziehung stumm?

Bei beiden Thermostaten kommt die Rückmeldung über:

Code Auswählen Erweitern

2020-11-06_14:57:03 HK_Flur setpointTemp: 23.0 C heating
Unverändert bleibt:

Code Auswählen Erweitern

state    desired-temp 22.0

[Beta-User]

  dass überhaupt eine Rückmeldung kommt ist gut...

...muß mal bei Gelegenheit damit noch ein wenig rumspielen, aber vermutlich bastle ich für den userReadings-trigger setPointTemp noch was neues, das in die folgende Richtung geht:
Ein "get" müßte eigentlich auch ein ACK auslösen (muß ich noch prüfen), was bedeutet, dass (mit ziemlicher Sicherheit) eine ReadingsAge-Abfrage auf transmit ausreichen müßte, um zwischen "ungefragt" (=manuelle desired-temp-Änderung) und "gefragt" (nicht für desired-temp relevant) unterscheiden zu können...?
Dementsprechend könnte man dann zusätzlich (ungefragter Fall) das desired-temp setzen, was dann auch in Log landen könnte, da dieser Auslöser triggernd ist.

[krikan]

@Rudi (und ggf. krikan): Eine Rückmeldung wäre nett, ob ich mit den ganzen Überlegungen zur "Nachverarbeitung nach ACK" (notfalls über userReadings auf state-Trigger+entsp. Einstellung am IO) irgendwie auf dem Holzweg bin... Eventuell habt ihr da ja vor langer Zeit schon mal intensiv drüber nachgedacht und sowas verworfen?

Da mir das Problem nicht wirklich klar ist, halte ich mich zurück. 
Gruß, Christian

[Beta-User]

Das "Problem" besteht imo im wesentlichen darin, dass ziemlich viele User unsicher zu sein scheinen, wie sie den aktuellen "Sollzustand" ihrer Thermostaten "überwachen" können. Das führt dazu, dass "alles mögliche" an workarounds gebastelt wird - allerdings ohne, dass das wirklich in jedem Fall erforderlich wäre oder gar sinnvoll; eher sind diese Ansätze - vom Bauchgefühl her jedenfalls - kontraproduktiv, weil der Funkverkehr (teils zum unpassenden Zeitpunkt) vermehrt wird.

Bei CUL_HM hat man das Problem nicht, da wird alle 2,5 Minuten eben das Reading "desired-temp" unaufgefordert aktualisiert (und eine ganze Menge mehr, einschließlich des Öffnungsgrades am Ventil).

Diese "Schweigsamkeit" der Spirits säht einen gewissen Zweifel an der Zuverlässigkeit der tatsächlichen Ausführung angewiesener Schaltvorgaben.

Ein Teilziel wäre daher, zumindest das an Info vollständig auszuwerten, was wir eben "eigentlich" sowieso haben - kommt z.B. ein ACK auf eine Schaltanweisung, wird das betreffende Reading (welches auch immer dazu "gut" sein mag) aktualisiert (und nicht nur state, wenn man das am IO mit den showSetInState aktiviert). Im Moment landet eben jeweils eine Teilinfo dazu "irgendwo", ohne dass es konsistent zu sein scheint (oder ist dir direkt klar, welche Temperatur denn eingestellt wird, wenn du "eco" anweist? Und bring das mal einem SVG-plot bei, was du "auf einen Blick" erkennen kannst, aber auch nur solange, wie du die setPoints nicht anfasst...).

Hoffe, das trägt eher zur Klarheit bei als es verwirrt...?

[rudolfkoenig]

Habs verstanden, dass es Dir wichtig ist.
Kommt bei mir auf die TODO-Liste, wird aber vmtl. erst naechste Woche was.

[Beta-User]

Vorab mal danke!

Da wir das Thema "korrekte Rückwärts-Auswertung der Ack-Messages" hier schon mal angerissen hatten: Aus meiner Sicht besteht eigentlich nicht unbedingt der Bedarf nach einer (EDV-mäßig gedacht) 100% korrekten Lösung. Mein Ansatz über das simple "es ist irgendwas korrekt angekommen" dürfte ausreichen, um den "Praktikerbedarf" abzudecken, und - sofern es in diese Richtung gehen würde - die Aufnahme gerätespezifischen Codes sollte auch nicht unbedingt der Weg sein (Geräteklassen-spezifisch wäre ggf. was anderes). Gerätespezifika könnte man m.E. genausogut durch "add-ons" abdecken.

[rudolfkoenig]

Ich habe ZWDongle mit dem setReadingOnAck Attribut erweitert:

If the attribute is set to 1, and a set command with an argument is issued to a ZWave device, then a reading with the same name will be updated upon reception of the corresponding ZWave ACK radio telegram.

Bei Mehrfach-Befehlen (ich meine damit mit ; getrennte sets/gets) an Security Geraete wurden Fehlermeldungen ab den zweiten Befehl ignoriert. Das habe ich jetzt gefixt.

showSetInState ist mehrfach kaputt: bei Security wird es ignoriert, bei Mehrfach-Befehlen landet sofort der letzte Befehl als set_XXX in state, und state wird zu XXX, nachdem der erste ACK empfangen wurde. Das habe ich (noch?) nicht gefixt.

setReadingOnAck habe ich mit Mehrfach-Befehlen bei zwei "always on" Geraeten getestet, einmal mit Security, einmal ohne.
Brauche noch Feedback, insb. fuer WAKE_UP Geraete.