Z-WavePlus Thermostat Eurotronic Spirit: Schrittweise Inbetriebnahme

[Beta-User]

Es muss option:{1} heissen

Die template-file hatte ich zwischenzeitlich irgendwann auf "global" geändert gehabt; (der Doppelpunkt war und ist schon immer vorhanden).

desired-temp [...] hatte eine Sonderbehandlung in FHEMWEB

...nicht nur in FHEMWEB, auch WeekdayTimer (bzw. Heating_Control) behandelt das anders (werde bei Gelegenheit auch noch setpointTemp dazunehmen).

Jein. Ich weiss, zu welcher Hex-Befelsfolge ein ACK gehoert, nicht aber zu welchem lesbaren FHEM-Befehl. [...]

Hmm, ok, ich kann so langsam die Probleme erahnen...

Vielleicht einfach eine Rückmeldung von einem relativen ZWave-Neuling:
Zum einen hat mich schon immer irritiert, dass ziemlich viele Anweisungen in state landen (mehr oder weniger alle (?) set-( und get-) Anweisungen?). Bei reinen Aktoren (wie ich sie bisher hatte) ist das nicht weiter dramatisch, irgendwann landet dann ja auch wieder was "normales" in state.

Grundsätzlich bin ich weiter - wie wir das auch schon @MQTT2_DEVICE mal (im Zusammenhang mit der Entstehung von setStateList) diskutiert hatten - ein Fan davon, dass man bei bidirektionalen Protokollen die Übergangszustände (hier z.B. set <device> on => (state:) set_on => ACK => on) "sichtbar" macht und ggf. auch entsprechende Events generiert.

Tendenziell vermute ich auch, dass das "das kleinere Übel" gegenüber dem Beibehalten des fehlenden "Rückwärtsmappings" wäre. In vor liegendem Fall v.a. auch, weil sonst jeder user irgendwelche Workarounds bastelt wie das mit der regelmäßigen Abfrage der aktuellen Solltemperatur, nur um rauszufinden, ob denn die Anweisung wirklich angekommen war. Solche Abfragen führen letztlich nur zum früheren Batterie-Tausch...
In meiner vereinfachenden Denkweise könnte man ggf. auch einfach anhand des Zeitstempels entscheiden, zu welchem Reading ggf. ein ACK gehört und ob es Events auslösen soll. Sowas würde eventuell (auch bei secure?) "nur" voraussetzen, dass man aus dem HEX-Code des ACK in etwa ablesen könnte, zu welchem Reading es gehört?

Ist aber zugegebenermaßen alles irgendwie noch nicht zu Ende gedacht.

[Deckoffizier]

Hallo ,

@curt

bin mir bei den ganzen Problemen nicht mehr sicher ob Du auch
Schwierigkeiten mit der Anzeige der Ventilstellung hattest, oder nur beim ausprobieren des neuen Template für den Spirit?

aus dem List vom Spirit von Dir hast Du
2020-10-16 01:42:26   configValveOpeningPercentageReport 0

setze es mal auf eins.

Gruß
Hans-Jürgen

[curt]

bin mir bei den ganzen Problemen nicht mehr sicher ob Du auch
Schwierigkeiten mit der Anzeige der Ventilstellung hattest, oder nur beim ausprobieren des neuen Template für den Spirit?

Nein, habe ich nicht.
In den Modi Heating und EnergySaveHeating kommt die Ventilstellung im Reading reportedState, selbst wenn "configValveOpeningPercentageReport 0" gesetzt ist.

Keine Ahnung warum - sonderlich logisch klingt das auch nicht, da hast Du recht.

aus dem List vom Spirit von Dir hast Du
2020-10-16 01:42:26   configValveOpeningPercentageReport 0

setze es mal auf eins.

Da ist übrigens ein Fehler in "lies doch mal commandref" - da wird behauptet, dass ich auf "0" oder "1-100" setzen kann.

[Deckoffizier]

Hallo curt,

Da ist übrigens ein Fehler in "lies doch mal commandref" - da wird behauptet, dass ich auf "0" oder "1-100" setzen kann.

Wieso Fehler "1-100"  bezieht sich doch auf Delta laut Hilfetext, also 1 wäre schon mal die kleinste Änderung.

Komisch.....  habe es bei mir mal auf 0 gesetzt reportedState ist dann off ??

Fang mich an zu wundern,   nach höherer Temp einstellen in FHEM  lese ich direkt am Thermostaten 100 soweit ok,
aber in       kurzen Abständen       höre ich den Motor immer wieder takten(kurz arbeiten) obwohl bleibt bei 100.

Stelle es mal wieder zurück auf 1.  Probiere es doch ruhig mal aus, kann ja nicht schaden?

Gruß
Hans-Jürgen

[curt]

Komisch.....  habe es bei mir mal auf 0 gesetzt reportedState ist dann off ??

Das liegt möglicherweise daran, dass Du Deine Thermostaten in diesem Ventilstellungsmodus betreibst, ich die aber im Heating-Modus betreibe. Es ist jedenfalls so, dass der Wert bei allen Thermostaten auf 0 steht, ich aber die Ventilstellungen bekomme und in FTUI darstelle. Ok, einen habe ich jetzt auf 1.

Ich bin Dir für Deine Hinweise dankbar, immer. Das weißt Du. - Im Moment, sei nicht böse, ist das für mich ein Nebenkriegsschauplatz. Und selbst battery ist derzeit ein Nebenkriegsschauplatz: Ich halte alle Werte alle 24h aktiv ab und gut ist. Und ich habe allen erzählt, dass das bei mir nicht automatisch geht - irgendwann liest jemand das und schreibt "aber so geht das doch" oder schreibt "battery fehlt bei mir auch" oder noch was anderes. Ziel erreicht.

[krikan]

Mit der alten Version von AttrTemplate und dem alten zwave.template gibt es "nur" eine Fehlermeldung im FHEM-Log [..]

Ich fand und finde nichts. Schiebe es mal auf Perl 5.24.
Danke für die Logmeldungen.

Vielleicht einfach eine Rückmeldung von einem relativen ZWave-Neuling:
Zum einen hat mich schon immer irritiert, dass ziemlich viele Anweisungen in state landen (mehr oder weniger alle (?) set-( und get-) Anweisungen?). Bei reinen Aktoren (wie ich sie bisher hatte) ist das nicht weiter dramatisch, irgendwann landet dann ja auch wieder was "normales" in state.

https://wiki.fhem.de/wiki/Z-Wave#Warum_bleibt_der_Status_.28STATE.29_des_neu_inkludierten_Ger.C3.A4tes_dauerhaft_auf_.22associationAdd_.3CassociationGroup.3E_.3CCtrlNodeId.3E.22_stehen.3F sollte darauf hinweisen. Ist leider nicht optimal formuliert.

Grundsätzlich bin ich weiter - wie wir das auch schon @MQTT2_DEVICE mal (im Zusammenhang mit der Entstehung von setStateList) diskutiert hatten - ein Fan davon, dass man bei bidirektionalen Protokollen die Übergangszustände (hier z.B. set <device> on => (state:) set_on => ACK => on) "sichtbar" macht und ggf. auch entsprechende Events generiert.

Das Attribut showSetInState beim ZWDongle-Device kennst Du?

Gruß, Christian

[Beta-User]

Das Attribut showSetInState beim ZWDongle-Device kennst Du?

Ups, war mir neu...

Hab's jetzt mal aktiviert. Allerdings ist das in zweierlei Hinsicht dem ersten Empfinden nach nicht ganz optimal. Zum einen ist es nicht der default, und der wird nicht ganz ohne Grund so gesetzt sein. Wenn ich das jetzt (für attrTemplate-Zwecke) zum "Quasistandard" erheben wollte, wäre das schon deswegen nicht optimal, weil jeder andere vermutlich auch wieder über diese Kleinigkeit stolpert oder ggf. ein neues Verhalten von anderen Devices sehen würde.
Gravierender finde ich (vorläufig!), dass das alles in "state" stattfindet. Wenn man z.B. "thermostatSetpointSet" setzt, bekommt man entsprechende Veränderungen in "state", aber das (m.E. dazu passende Reading (?!?) setPointTemp macht keinen Mucks.

Von daher beschränkt sich der Vorteil auf "on/off"-Devices (da hat man "normale" Übergänge) und den Effekt, dass man überhaupt ein Event an dem Gerät hat, das man dann ggf. wieder auswerten kann, so jedenfalls mein vorläufiges Verständnis.

Was mich andererseits etwas wundert, ist das etwas "stiefmütterliche Dasein" von "transmit". Das wird hübsch aktualisiert, allerdings nicht triggernd (so deute ich jedenfalls meine Beobachtungen iVm. Zeilen 5081ff). Kann ich auf den ersten Blick nachvollziehen, soweit alles ok ist, aber dass sich niemand "die Mühe macht",  über eventuelle Probleme zu informieren, finde ich seltsam, spontan hätte ich zumindest NO_ACK (auch) in state erwartet.

Bin mit den Gedanken dazu noch nicht am Ende, aber wäre es nicht eine Idee, beim Erhalt von "ACK"-Messages eine Art "extendedUserReadings"-Logik anzuflanschen? Darüber könnten eventuell zu setzende Readings als Hash zurückgeliefert werden, man könnte feststellen, was in state an set-Anweisungen drin war (anhand des Zeitstempels abzuschichten!) und dann z.B. eben auch "desired-temp" mit dem füttern, was via "desired-temp" ODER "thermostatSetpointSet" verschickt worden war? Wäre m.E. besser, als erst ein "nachgelagertes Event" über das IO-Attribut zu erzeugen, damit man hinterher ggf. in anderen Readings "aufräumen" kann.
Gedanklich hänge ich dabei noch etwas an get-Abfragen. Die "sieht" man nach dem Absenden vermutlich nicht mehr, so dass es schwierig ist zu unterscheiden, ob eine setPointTemp-Info jetzt wegen einer lokalen Aktion über die Knöpfe am Thermostat reinkommt oder als Rückgabe einer entsprechenden Anfrage...

(Schwierig, puh; hoffe, es ist wenigstens verständlich, was ich meine?).

@Beta-User , [...] kommt bei Dir automatisch das Reading battery?
(Ich hoffe, Du bist nicht maulig, ich hab noch Außenstände. Ich weiß.)

Bin nicht maulig, sondern versuche erst mal zu beobachten, was passiert, wenn ich eines nach dem anderen an Einstellungsmöglichkeiten ausprobiere... (nebenbei will ich das Twilight-Ding wieder reparieren, das hat Prio).
battery kommt (ohne separate Anfrage, jedenfalls jetzt in 2 Nächten), ich habe aber mit 0.9 scheinbar nicht die neueste firmware-Version; das scheint 0.10 zu sein?
Gemessene Temperatur wurde bisher scheinbar genau nur 1x übertragen, den Threshold habe ich jetzt mal auf 2 gesetzt, was aber bis dato auch nicht dazu geführt hat, dass das Ding dazu nochmal was gesagt hätte.
Weiter habe ich jetzt den Valve-Wert mal auf 1 gesetzt, aber auch da: Funkstille bisher. Das Ding hängt aber in einem Abstellraum, kann sein, dass das Ventil einfach unverändert "zu" ist...

In meinem userReadings-Versuch war btw. noch ein bug drin, das verbesserte lautet aktuell:

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}

[curt]

battery kommt (ohne separate Anfrage, jedenfalls jetzt in 2 Nächten), ich habe aber mit 0.9 scheinbar nicht die neueste firmware-Version; das scheint 0.10 zu sein?

Vermutlich 0.20. Jedenfalls sind meine acht alle 0.20. Aber wer weiß das schon genau.

Gemessene Temperatur wurde bisher scheinbar genau nur 1x übertragen, den Threshold habe ich jetzt mal auf 2 gesetzt, was aber bis dato auch nicht dazu geführt hat, dass das Ding dazu nochmal was gesagt hätte.

Da ist es wieder, das Problem. Das Ding ist wenig gesprächig, man muss da viel mit GET abholen. Womit wir wieder bei meiner Bringeschuld sind - ich muss meine Konfiguration mal zeigen (und der Kritik stellen).

[Deckoffizier]

Hallo curt,

Dein Text

Vermutlich 0.20. Jedenfalls sind meine acht alle 0.20. Aber wer weiß das schon genau.

Also sind wir erst mal bei 4 verschiedenen Firmware wenn ich bei mir App 0.15 HW 49 FWCounter 1 FW 0.10 nicht mit zähle.

Wenn bei Dir  FW 0.20. nicht   version:Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.2 ist bist Du von den Meldungen erst mal damit alleine?

Gruß

Hans-Jürgen

[curt]

Nochmal vollständig - bei mir:

Code Auswählen Erweitern


version:Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.2


[Beta-User]

Ok, das mit 0.20 oder 0.2 scheint ja geklärt zu  sein. Damit ist meines mit 0.9 neuer als deine mit 0.2, oder?

Nach dem hier zu urteilen gibt es seit ca. Okt. 19 eine fw 0.16, von daher würde ich mal tippen, dass die einfach hinter dem Punkt weiterzählen.

Habe da mal eine Supportanfrage gestartet und darum gebeten, zum einen mitzuteilen, wo man aktuelle firmware bekommt und zum anderen, wie diese komische Werbeaussage mit den Schaltzeiten zu verstehen ist... Mal sehen, (ob) was von da kommt, die scheinen ja eher für beredtes Schweigen berühmt zu sein . Über das HCL gab es jedenfalls kein update-Angebot (und auch AEOTEC hat auf der homepage nichts für den nahen Verwandten im Angebot).

Das Regelverhalten mit 0.16 scheint aber lt. der obigen Quelle bei home-assistant.io deutlich besser zu sein...

[Deckoffizier]

Hallo Beta-User,

kann leider kein Englisch und will jetzt keine Verwirrung stiften.

All of the thermostats run application_version 0.16, except the slightly older one in the bathroom which seems to run on 0.15.

Sprechen wir jetzt von App 0.16, App 0.15   oder     von  FWCounter 1 FW 0.2 ,  FWCounter 1 FW 0.10 ?
Was ist bei Dir 0.9 davon?


Meine Versionen...

version:Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.10   und

version:Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.2

version:Lib 3 Prot 4.61 App 0.15 HW 49 FWCounter 1 FW 0.10




Gruß
Hans-Jürgen

[Beta-User]

Ups, vermutlich muss ich mir dazu mal ansehen, was die Teile im Detail bedeuten; ich hatte nur auf den letzten Teil (FW) geschaut, das war wohl eine Fehlinterpretation... (scheint jedenfalls als link hier zu stehen: https://wiki.fhem.de/wiki/Z-Wave#Wie_kann_man_die_SDK-Version_eines_Ger.C3.A4tes_herausfinden.3F).

Was ist denn dann die aktuellste Firmware? 0.10?

[Deckoffizier]

Hallo Beta-User,

Was ist denn dann die aktuellste Firmware? 0.10?

Gute Frage ! 0.10 mit App 16 statt App15  mit 0.10  meine bescheidene Vermutung?

Gruß
Hans-Jürgen

[curt]

Ok, das mit 0.20 oder 0.2 scheint ja geklärt zu  sein. Damit ist meines mit 0.9 neuer als deine mit 0.2, oder?

Da bin ich mir eben nicht so sicher.

In einem Beitrag von 2018 taucht schon App 0.16 FW 0.10 auf, siehe https://forum.fhem.de/index.php?topic=77598.45
Meine acht Thermostaten habe ich ab März diesen Jahres in mehreren Tranchen bei Amazon gekauft, die gelten eigentlich nicht als Verkäufer von Ladenhütern.