Z-WavePlus Thermostat Eurotronic Spirit: Schrittweise Inbetriebnahme

[Nobbynews]

Da ich mir kürzlich auch einen Spirit zugelegt habe, hier noch eine neue Variante:

Code Auswählen Erweitern

Lib 3 Prot 4.61 App 0.16 HW 26 FWCounter 1 FW 0.2
Eine Version mit HW 26 habe ich bisher hier noch nicht gesehen.
Batterie wird aber auch nicht täglich aktualisiert.

[curt]

Ok, an diesem Punkt möchte ich @rudolfkoenig etwas zur Sache fragen.

Rudolf, es geht um "get [thermostatdevice] version". Wenn ich recht verstand, hast Du das zuständige Modul gecodet. Wenn ich weiter recht verstand, läuft alles auf Byte-Folgen hinaus, die ausgetauscht werden. Vermute ich recht, wenn ich sage, dass Lib, Prot, App, HW, FWCounter, FW quasi schon "Übersetzungen" von Dir sind?

Wenn dem so sein sollte: Kannst Du bitte sagen, was sich dahinter im Original verbirgt?

[curt]

Liebe Freunde der wohltemperierten Wohnstube, <langer Beitrag>

ich versprach es mehrmals: Ich zeige meine Konfiguration. Es geht mir darum, diese öffentlich zu zeigen - und den Weg, den man dazu nehmen muss. Ich versuche so zu schreiben, dass auch spätere Nutzer mit diesem Beitrag etwas anfangen können. Mir ist bewusst, dass ich möglicherweise Fehler machte, dazu ganz unten.

Ich habe mich entschlossen, auf die Darstellung in meinem Frontend (FTUI) in diesem Beitrag zu verzichten, das würde sonst zu komplex. Aber auch das kann ich gern nachreichen.

Ich habe acht identische Thermostate aus zeitlich verschiedenen Lieferungen (2020-03 bis 2020-09), alle via Amazon. "get version" liefert bei allen

Code Auswählen Erweitern


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


Inbetriebnahme:
Das stellte sich bei fummelig heraus, aus zwei Gründen:
1) Der Thermostat muss relativ nahe (sagen wir 2 Meter) an die Antenne der Basis.
2) Laut Forum bin ich nicht der Einzige, bei dem "UNKOWN" Devices erstellt wurden: Es ist klug, das Attribut "ignoreTypes" bei "autocreate" für die Zeit der Assoziation auszuschalten.

FHEM sagt man nun

Code Auswählen Erweitern


set <ZWDongle> addNode onNw

und drückt anschließend den mittleren Knopf am Thermostat. Dort läuft nun ein Countdown ab 120 (Sekunden). Im Idealfall stoppt das Ganze nach sicher mehr als 45 Sekunden, eine Zahl wird angezeigt. Gleichzeitig meldet FHEM, dass die Device xxx_zahl angelegt wurde.
Nun geht man mit dem Thermostat in aller Ruhe in den Raum, in dem der Heizkörper beglückt werden soll, schraubt den Thermostat an. Danach drückt man dort wieder die mittlere Taste: Man hört den Stellmotor, er vermisst quasi das Ventilspiel.

Wir gehen zurück zum Computer, es lauert viel Arbeit: Erstmal den neuen Stand speichern. Danach ist da die eigentliche Arbeit:

1) associationAdd - den korrekten Befehl reicht sicher jemand nach, mir nicht momentan.

2) Wir müssen einige GET absenden, sonst fehlen uns Readings:

Code Auswählen Erweitern


get <device> associationAll
get <device> configAll
get <device> versionClassAll


Danach ergibt sich ein Device wie in der Anlage gezeigt (list). Als Raw stellt sich das so dar - nächste Anlage (Das stateFormat ist nicht schön, aber schön geklaut).

In der Folge gehe ich davon aus, dass wir vermittels SET den Modus tmHeating einstellten.

Wirklich dramatisch ist, dass der Thermostat im Grunde nichts zurückmeldet. Es ist schnuppe, ob Du die Temperatur-Soll via SET über FHEM ansagst oder die Dame des Hauses direkt am Thermostat die Temperatur verstellt: FHEM bekommt das nicht mit. Auch die Veränderungen der verschiedenen möglichen Heizungsmodi bekommt FHEM nicht mit. Manche Thermostate bekommen zudem den Batterie-Status nicht mitgeteilt.

Also frisch ans Werk (Anmerkung: Ein Nutzer sagte mir: Alle wichtigen Befehle zweimal, immer "sleep 3 " dazwischen):

Alle halbe Stunde holen wir uns den Status aller Thermostaten, das mache ich in einem Rutsch in einem Befehl, zeige Euch aber nur den ersten Thermostaten:

Code Auswählen Erweitern


define Cron.PollZwaveThermostat DOIF ([+00:30]) {fhem("get Thermostat_Arbeitszimmer smStatus;;sleep 3;;get Thermostat_Arbeitszimmer swmStatus;;sleep 3;;get Thermostat_Arbeitszimmer setpoint;;sleep 3;; <weitere Thermostate>")}
attr Cron.PollZwaveThermostat do always
attr Cron.PollZwaveThermostat room 97 Heizung


Bei mir kommt der Batterie-Status nicht freiwillig, also zwingen wir den:

Code Auswählen Erweitern


define Thermostat_battery_at_1 at *05:10 get Thermostat_Arbeitszimmer battery;; sleep3;; <weitere-Thermostate>
attr Thermostat_battery_at_1 room 97 Heizung


Und die Sache mit den offenen Fenstern (Geber ist nicht ZWave), da muss ich auf das Gästezimmer zurückgreifen:

Code Auswählen Erweitern


define Gaestezimmer_doif DOIF ([Gaeste_Fenster_Strasse:status] =~ "open") \
{fhem("set Thermostat_Gaestezimmer tmOff;;sleep 3;;set Thermostat_Gaestezimmer tmOff;;sleep 3;;get Thermostat_Gaestezimmer thermostatMode;;")} \
DOELSEIF ([Gaeste_Fenster_Strasse:status] =~ "closed") \
{fhem("set Thermostat_Gaestezimmer tmHeating;;sleep 3;;set Thermostat_Gaestezimmer tmHeating;;sleep 3;;get Thermostat_Gaestezimmer thermostatMode;;")}
attr Gaestezimmer_doif room 97 Heizung


Um einem Thermostaten via FHEM-Standard-Interface mit Klapp-Runter-Menü einen neuen Sollwert vorzugeben (da wart Ihr echt zickig) habe ich nach anstrengenden Betteleien dieses:

Code Auswählen Erweitern


define di_Thermostat_Arbeitszimmer DOIF ([$SELF:"SollArbeitszimmer"])\
   (set Thermostat_Arbeitszimmer desired-temp [$SELF:SollArbeitszimmer];; sleep 3;; set Thermostat_Arbeitszimmer desired-temp [$SELF:SollArbeitszimmer];; sleep 3;; get Thermostat_Arbeitszimmer setpoint)
attr di_Thermostat_Arbeitszimmer do always
attr di_Thermostat_Arbeitszimmer event-on-change-reading SollArbeitszimmer
attr di_Thermostat_Arbeitszimmer readingList SollArbeitszimmer
attr di_Thermostat_Arbeitszimmer room 10 Heizung
attr di_Thermostat_Arbeitszimmer setList SollArbeitszimmer:8,17,18,19,20,21,21.5,22,22.5,23
attr di_Thermostat_Arbeitszimmer stateFormat gewaehlt: SollArbeitszimmer
attr di_Thermostat_Arbeitszimmer webCmd SollArbeitszimmer


Mir geht es in diesem Beitrag grundsätzlich darum, meine Konfiguration zu zeigen. Sie könnte als Basis der weiteren Diskussion dienen. Selbstverständlich und sehr gern darf man kritisieren. Oder weitere Hinweise geben. Ich bin bei sachlicher Kritik nicht nur schmerzbefreit - ich bin sogar sehr dankbar. - (Vielleicht fangen wir aber beim Grundsätzlichen an. Fehlen da wichtige Befehle zum Start?)

Und abschließend noch ein Dank, das liegt mir am Herzen: Sehr viele sehr freundliche Menschen halfen mir, teils auch via PN: Danke!

[Beta-User]

Hmm, also vorab mal meine eigenen Erfahrungen:
Ich hatte onNw includiert, das ging stressfrei, und es ist bisher auch _kein einziger_ der set- und get-Befehle verloren gegangen, den ich abgesendet hatte.

(Temperaturwerte bekomme ich zwischenzeitlich auch rein, nachdem ich auf "1" gestellt habe).

Von daher _glaube ich_, dass diese Art der Konfiguration eher dazu führt, bestehende Probleme in der Konfiguration des ZWave-Mesh eher zu überdecken oder gar zu verstärken - Rudi ist bestimmt aus guten Gründen sehr sparsam mit Abfragen an welches Gerät auch immer...

Wenn man also überhaupt (@Rudi: was ist mit der Frage nach der ACK-Auswertung?) irgendeinen "ist es angekommen"-Mechanismus braucht, sollte man den wenigstens so "intelligent" machen, dass erneute Anfragen (die nach dem sleep) nur dann gestellt werden, wenn der erwartete Rückgabe-Wert "zu alt" ist.

Wenn wir dafür Code entwicken wollen, sollte das mMn. myUtils-Code sein, ich habe ehrlich gesagt keine Lust, mich wegen dieser Sache hier in DOIF einzudenken und finde myUtils-Code auch einfacher zu (ver-)teilen...


@curt: Irgendwas ist an deinem Mesh komisch, vermutlich würde es Sinn machen, erst mal damit anzufangen, bevor wir workarounds optimieren.

[curt]

(Temperaturwerte bekomme ich zwischenzeitlich auch rein, nachdem ich auf "1" gestellt habe).

Bitte sehr präzise formulieren: Was hast Du auf "1" gestellt?

Von daher _glaube ich_, dass diese Art der Konfiguration eher dazu führt, bestehende Probleme

Bitte sehr präzise formulieren: Was ist konkret "diese Art der Konfiguration"? Und was ist die andere Art der Konfiguration? Und wie erreicht man diese?

@curt: Irgendwas ist an deinem Mesh komisch

Bitte sehr präzise formulieren: Was erscheint Dir komisch? Und wie hast Du das erkannt?
(Ich habe einen Repeater im ZWave-Netz, das technisch nebenbei.)

Genau das empfinde ich oft in diesem Forum als störend (bitte fühle Dich nicht persönlich angegriffen): Es kommt nie eine klare Ansage. Nichtmal als "ich glaube, Du hast xyz falsch gemacht". Sondern es kommen nebulöse Andeutungen. Mit denen kann niemand was anfangen.

[Beta-User]

Bitte sehr präzise formulieren: Was hast Du auf "1" gestellt?

configTemperatureReportThreshold 1

Bitte sehr präzise formulieren: Was ist konkret "diese Art der Konfiguration"? Und was ist die andere Art der Konfiguration? Und wie erreicht man diese?

Das DOIF (wenn ich es richtig verstehe) als Teil der FHEM-Konfiguration ist eigentlich nur ein at, das stumpf wiederholt dieselben "was ist der Status von..."- Befehle raushaut, ohne zu berücksichtigen, ob es eine schon Rückmeldung gab.
MMn. sollte man ReadingsAge() des angefragten Werts prüfen, und dann nur nochmal anfragen, wenn man nicht schon eine Antwort hat. Code dazu liefere ich bei Bedarf bzw. dann nach, wenn das allg. als sinnvolles Vorgehen angesehen wird.

Bitte sehr präzise formulieren: Was erscheint Dir komisch? Und wie hast Du das erkannt?
(Ich habe einen Repeater im ZWave-Netz, das technisch nebenbei.)

Eingangs hatte ich geschrieben: Bei mir kommen ALLE Befehle anstandslos an, ich habe aber auch eine ganze Anzahl von netzbetriebenen (230V-) Komponenten, die das Mesh ohne "expliziten Repeater" bereitstellen. Über die hat auch die Inklusion an einer vom USB-Dongle weit entfernten Stelle funktioniert.

Wie man ZWave-Netz optimiert, ist auch für mich relatives Neuland, von daher bitte ich zu entschuldigen, dass ich da eben im Moment auch nicht mehr wie das Stichwort liefern kann und die Überlegung, dass man sich erst mal damit beschäftigen sollte: Ursachenbekämpfung statt workaround eben.

[curt]

Das DOIF (wenn ich es richtig verstehe) als Teil der FHEM-Konfiguration ist eigentlich nur ein at, das stumpf wiederholt dieselben "was ist der Status von..."- Befehle raushaut, ohne zu berücksichtigen, ob es eine schon Rückmeldung gab.

Da es nie Rückmeldungen gibt, ist das sinnvoll.
Das habe übrigens nicht ich mir ausgedacht, das machten andere, die mit dem Thermostat deutlich vor mir den gleichen Trödel hatten und logischerweise noch haben.

Hier kommen wir übrigens zum Kern:
Wenn das bislang alle (oder viele) falsch machten, Du aber sagen kannst, wie man es richtig macht, wird es höchste Zeit.

MMn. sollte man ReadingsAge() des angefragten Werts prüfen, und dann nur nochmal anfragen, wenn man nicht schon eine Antwort hat. Code dazu liefere ich bei Bedarf bzw. dann nach, wenn das allg. als sinnvolles Vorgehen angesehen wird.

Von diesem Absatz habe ich nichts verstanden.
Aber ich ahne da was. Neh, das ist der falsche Ansatz. Wenn ein Reading sich nicht (weil Device von sich aus sendet) aktualisiert, bringt das nichts. Es passiert ja nie.

Eingangs hatte ich geschrieben: Bei mir kommen ALLE Befehle anstandslos an, ich habe aber auch eine ganze Anzahl von netzbetriebenen (230V-) Komponenten, die das Mesh ohne "expliziten Repeater" bereitstellen. Über die hat auch die Inklusion an einer vom USB-Dongle weit entfernten Stelle funktioniert.

Du hattest unterstellt, dass in meinem ZWave-Netz was nicht stimmt. Das will ich gar nicht ausschließen. Es hilft mir (und anderen Mitlesern) aber wenig, wenn Du auf die Nachfrage, woran Du das erkanntest, Dich in Allgemeinplätze flüchtest.

Abschließend:
Das ist kein Angriff auf Dich, ganz im Gegenteil. Sondern Du kannst helfen.

Ich bin nicht allein, meine Erkenntnisse gerade in Sachen Readings fielen nicht vom Himmel. Das waren andere User, teils via PN. Klar kann man unterstellen, dass die alle doof sind - und ich auch. Ich sag mal so: Ich bin der laute, der die Probleme öffentlich macht. Ich kann das, weil mein Fremdbild in diesem Forum mir eher egal ist.

Es geht um etwas ganz anderes:
So ein Thermostat ist keine Rakete. Das darf keine Geheimwissenschaft sein. Ein mittelmäßig begabter Mensch muss in der Lage sein, das Dingens in Betrieb zu nehmen, ohne 300 Schalter zu erraten. (Das Thema hatten wir übrigens schon, warum ist denn zum Beispiel "configTemperatureReportThreshold" nicht standardmäßig auf 1? Weil die Profis sich freuen, dass jeder erstmal drei Wochen rumübt, ja?)

Genau das müssen wir abstellen. Man muss den Thermostat unter FHEM in Betrieb nehmen können, selbst wenn man nicht Deine beeindruckende Kenntnis hat. Das ist doch der Punkt.

P.S. Im Furor Fehlerchen macht .. "configTemperatureReportThreshold" ist auf 5. Bei allen.

[Beta-User]

Sorry, Fehlinterpretation des DOIF.

Zum Rest: ein andermal, evtl. versuche ich mal, den Zwischenstand zu vertemplaten, damit "Nachahmer" z.B. das mit der "1" bei der Temperatur-Meldung gleich "richtig" haben....

[rudolfkoenig]

Wenn dem so sein sollte: Kannst Du bitte sagen, was sich dahinter im Original verbirgt?

Ich habe die Bedeutung der Bytes aus der offiziellen ZWave Doku, meine aktuelle Kopie ist SDS13782-Z-Wave-Management-Command-Class-Specification.pdf . Mag sein, dass diese Funktion im Modul anhand einer aelteren Version erstellt wurde, und/oder dass da noch Fehler drin sind.

Rudi ist bestimmt aus guten Gründen sehr sparsam mit Abfragen an welches Gerät auch immer...

Ich habe bei meiner Mini-Installation mit 4 Geraeten mit ZWCUL monitoring gesehen, dass aus nicht nachvollziehbaren Gruenden ein Telegramm ueber 2 Hops geroutet wurde, was pro Richtung 7, beim get mit Antwort 14 Funktelegramme bedeutet. Bei einer grossen Installation nach vielen Daten ohne Grund zu fragen bedeutet mAn nach ueberfluessigen Problemen zu suchen.

@Rudi: was ist mit der Frage nach der ACK-Auswertung?

Was genau ist damit gemeint?
Bei NACK oder anderen Problemen wird z.Zt. ein Reading gesetzt und ein Event erzeugt.

warum ist denn zum Beispiel "configTemperatureReportThreshold" nicht standardmäßig auf 1?

Weil der Hersteller, aus welchem Grund auch immer, meint, dass das so richtig ist, hoffentlich begruendet.
Wir (als FHEM) koennen zwar versuchen, "bessere" defaults zu setzen, bei den vielen ZWave Geraeten ist das aber eine echte Herausforderung, und womoeglich mit neuen Problemen verbunden, die der Hersteller schon analysiert hat.

[Nobbynews]

Ich habe die Bedeutung der Bytes aus der offiziellen ZWave Doku, meine aktuelle Kopie ist SDS13782-Z-Wave-Management-Command-Class-Specification.pdf . Mag sein, dass diese Funktion im Modul

Eine aktuelle vom 6.7.2020 gibt es hier:
https://www.silabs.com/documents/login/miscellaneous/SDS13783-Z-Wave-Transport-Encapsulation-Command-Class-Specification.pdf

Edit:
Leider nicht richtig gelesen....
Die Version von @rudolfkoenig ist aktuell

[Beta-User]

Was genau ist damit gemeint?
Bei NACK oder anderen Problemen wird z.Zt. ein Reading gesetzt und ein Event erzeugt.

Na ja, der Punkt ist folgender: "eigentlich" ist für das Herstellen eines auch in den Readings konsistenden Zustands - jedenfalls mAn. und bei diesem Device (vermutlich zumindest bei jedem "clima"-Type-Device) - eigentlich eine Auswertung der zugestellten Nachrichten erforderlich. An sich klappt das sogar über userReadings-Code. Aus irgendwelchen Gründen dachte ich bisher, dafür wäre ein "echter" trigger (=Event) erforderlich, was aber gar nicht stimmt, siehe dieses list:

Code Auswählen Erweitern

defmod ZWave_THERMOSTAT_20 ZWave 12345678 20
attr ZWave_THERMOSTAT_20 IODev zwaveme
attr ZWave_THERMOSTAT_20 classes ZWAVEPLUS_INFO ASSOCIATION ASSOCIATION_GRP_INFO VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY PROTECTION SENSOR_MULTILEVEL SWITCH_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT BATTERY CONFIGURATION ALARM POWERLEVEL SECURITY SECURITY_S2 TRANSPORT_SERVICE SUPERVISION FIRMWARE_UPDATE_MD
attr ZWave_THERMOSTAT_20 room Steuerung->ZWave
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}, testAck:transmit.* {ReadingsVal($name,"timeToAck",0)}
attr ZWave_THERMOSTAT_20 vclasses ALARM:8 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:1 POWERLEVEL:1 PROTECTION:1 SECURITY:1 SECURITY_S2:1 SENSOR_MULTILEVEL:5 SUPERVISION:1 SWITCH_MULTILEVEL:1 THERMOSTAT_MODE:3 THERMOSTAT_SETPOINT:3 TRANSPORT_SERVICE:2 VERSION:2 ZWAVEPLUS_INFO:2

setstate ZWave_THERMOSTAT_20 tmEnergySaveHeating
setstate ZWave_THERMOSTAT_20 2020-10-27 08:17:59 SEND_DATA failed:00
setstate ZWave_THERMOSTAT_20 2020-10-24 08:49:58 alarm System: Event cleared: State Idle
setstate ZWave_THERMOSTAT_20 2020-10-23 08:15:58 assocGroup_1 Max 1 Nodes zwaveme
setstate ZWave_THERMOSTAT_20 2020-10-23 08:15:58 assocGroups 1
setstate ZWave_THERMOSTAT_20 2020-10-29 02:49:54 battery 100 %
setstate ZWave_THERMOSTAT_20 2020-10-29 02:49:54 batteryPercent 100
setstate ZWave_THERMOSTAT_20 2020-10-29 02:49:54 batteryState ok
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:47 configBacklight BacklightEnabled
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:48 configBatteryReport SendOnceADay
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:48 configLCDInvert Normal
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:48 configLCDTimeout 0
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:48 configMeasuredTemperatureOffset 0
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:49 configOpenWindowDetection MediumSensibility
setstate ZWave_THERMOSTAT_20 2020-10-27 08:18:05 configTemperatureReportThreshold 1
setstate ZWave_THERMOSTAT_20 2020-10-26 06:54:07 configValveOpeningPercentageReport 1
setstate ZWave_THERMOSTAT_20 2020-10-26 11:46:39 energySaveHeating 18.0
setstate ZWave_THERMOSTAT_20 2020-10-23 08:10:54 fwMd fwMdManId: 0148, fwMdFwId_0: 0301, fwMdChkSum_0: e455, fwMdUpgradeable: ff, fwMdNrTarg: 01, fwMdFrqSize: 0028, fwMdFwId_1: 0001
setstate ZWave_THERMOSTAT_20 2020-10-26 21:03:41 heating 18.0
setstate ZWave_THERMOSTAT_20 2020-10-23 08:10:18 model EUROtronic EUR_SPIRITZ Wall Radiator Thermostat
setstate ZWave_THERMOSTAT_20 2020-10-23 08:10:18 modelConfig eurotronic/eur_spiritz.xml
setstate ZWave_THERMOSTAT_20 2020-10-23 08:10:18 modelId 0148-0003-0001
setstate ZWave_THERMOSTAT_20 2020-10-29 07:27:53 reportedState off
setstate ZWave_THERMOSTAT_20 2020-10-26 21:03:41 setpointTemp 18.0 C heating
setstate ZWave_THERMOSTAT_20 2020-10-29 07:28:30 state tmEnergySaveHeating
setstate ZWave_THERMOSTAT_20 2020-10-29 06:49:54 temperature 19.63 C
setstate ZWave_THERMOSTAT_20 2020-10-29 07:28:32 testAck 1.236
setstate ZWave_THERMOSTAT_20 2020-10-26 21:03:41 thermostatMode heating
setstate ZWave_THERMOSTAT_20 2020-10-29 07:28:32 timeToAck 1.236
setstate ZWave_THERMOSTAT_20 2020-10-29 07:28:32 transmit OK
setstate ZWave_THERMOSTAT_20 2020-10-26 21:11:51 version Lib 3 Prot 4.61 App 0.15 HW 49 FWCounter 1 FW 0.9
setstate ZWave_THERMOSTAT_20 2020-10-23 08:10:22 zwavePlusInfo version:01 role:SleepingListeningSlave node:Z-Wave+Node installerIcon:1200 userIcon:1200

Denn eigentlich interessiert einen bei einem Thermostaten mMn. praktisch immer, welche Zieltemperatur gerade eingestellt ist und (optimalerweise) welcher aktuelle Messwert dagegen steht; interessant ist auch der Öffnungsgrad, aber das ist eigentlich eher zur Problemanalyse hilfreich, wenn die beiden anderen Werte  nicht in etwa in Deckung zu bringen sind.

Jetzt kann man bei dem Ding aber eben (im normalen Betriebsmodus) die Solltemperatur über einige setter vorgeben: desired-temp (findet sich nur im state), tm.*Heating, tmOn, tmOff, tmFullPower (was witzigerweise dim-Rückmeldungen ergibt und nach Ende des boost-Modus dann auf energySaveHeating, ohne dass dies allerdings über das userReading gekommen wäre, denn setpointTemp bleibt unverändert ...), thermostatSetpointSet.

Meine Idee wäre, aus dem state rauszulesen, was denn die letzte Anweisung war und dann ein Reading (desired-temp?) triggernd zu generieren, das halbwegs verlässlich ist, ohne dass man - in welchem Zyklus auch immer - die betreffende Info vom Thermostat erfragen muss...
Muß aber bei Gelegenheit mal noch ein paar Tests machen, was da eigentlich im Moment schon möglich wäre, und was wir ggf. noch bräuchten (ich habe den Verdacht, dass das nicht-triggernde readingsSingleUpdate in ZWave.pm geringfügig verändert werden müßte, damit man weitere triggernde readingsBulkUpdate dazwischenschieben kann).

Wir (als FHEM) koennen zwar versuchen, "bessere" defaults zu setzen, bei den vielen ZWave Geraeten ist das aber eine echte Herausforderung, und womoeglich mit neuen Problemen verbunden, die der Hersteller schon analysiert hat.

Na ja, bei diesem Device ist nach Lektüre diverser Quellen mein Vertrauen in den Hersteller erst mal nicht so hoch - schließlich hätte man ja auch irgendwo mal "offiziell" erklären können, warum "5" der default ist - das ist jedenfalls iVm. dem Vergleich mit der vorhergehenden Messung (ob an das assoziierte Device versendet oder nicht) jedenfalls mir völlig räteslhaft...
Was wir tun können, ist eben die Erfahrungen zu sammeln und das ganze irgendwie zu verstetigen...

[Beta-User]

Moin.

Mal folgende Zwischeninfo: valve hatte ich - aus welchen Gründen auch immer - als eigenes Reading erwartet, was aber natürlich zu kurz gegriffen war. Via userReadings klappt das aber... Aktueller Zwischenstand:

Code Auswählen Erweitern

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)}


Dazu hatte ich dann noch ergänzt:

Code Auswählen Erweitern

, testAck:transmit.* {ReadingsVal($name,"timeToAck",0)}, testAck2:transmit.* { FHEM::attrT_ZWave_Utils::desiredTemp($name) }
Der Code wird auch aufgerufen, allerdings klappte das nicht, darüber weitere Readings zu erzeugen. 10_ZWave.pm ist bei der "transmit"-Verarbeitung dazu auch testweise von readingsSingleUpdate() auf den bulk-Mechanismus umgestellt, der betreffende Code in der myUtils sieht aktuell so aus, dann wird evtl. klarer, was eigentlich beabsichtigt ist:

Code Auswählen Erweitern

sub desiredTemp {
  my $name = shift // return;
  my $call = shift // 'OK';
 
  my $hash = $defs{$name} // return;
  my $now = time;
  my $state = ReadingsVal($name,'state','unknown');
  my $stateNum = ReadingsNum($name,'state',20);
  #Log3($name, 3, "ZWave-utils desiredTemp called");
  #return if ReadingsAge($name,'state',10000000) > 3;
 
  if ($state =~ m,desired-temp|thermostatSetpointSet,) {
    readingsBulkUpdate($hash, 'desired-temp',$stateNum,1);
    return;
  }
  if ($state =~ m,tmAuto|tmManual|tmHeating,) {
    readingsBulkUpdate($hash, 'desired-temp',ReadingsVal($name,'heating','unknown'),1);
    return;
  }
  if ($state =~ m,tmEnergySaveHeating,) {
    readingsBulkUpdate($hash, 'desired-temp',ReadingsVal($name,'energySaveHeating','unknown'),1);
    return;
  }
 
  if ($state =~ m,off,) {
    readingsBulkUpdate($hash, 'desired-temp',6,'unknown',1);
    return;
  }
  return;
}
(Ob das überhaupt eine gute Idee ist, kann ich noch nicht sagen).

[Deckoffizier]

Hallo Beta-User,

Sorry

Na ja, bei diesem Device ist nach Lektüre diverser Quellen mein Vertrauen in den Hersteller erst mal nicht so hoch - schließlich hätte man ja auch irgendwo mal "offiziell" erklären können, warum "5" der default ist - das ist jedenfalls iVm. dem Vergleich mit der vorhergehenden Messung (ob an das assoziierte Device versendet oder nicht) jedenfalls mir völlig räteslhaft.

Komme in meinem hohen Alter schon mal etwas durcheinander 

Worauf bezieht sich die 5 ? configTemperatureReportThreshold ausgegeben als configMeasuredTemperatureReport ?

Also + - 0,5 Grad ist doch eigentlich für den Hausgebrauch soweit als default ok?
Vermute mal durch wenig Meldungen in den Standarteinstellungen soll die Batterielebensdauer
gestreckt werden.

Gruß
Hans-Jürgen

[Beta-User]

Diese Vermutung habe ich auch, und ja, es ging um configTemperatureReportThreshold.

ABER: der Threshold bezieht sich auf den letzten Messwert, nicht auf den letzten übermittelten Wert (wann auch immer gemessen wird...). Hat man also langsame, aber trotzdem große Schwankungen, wird NIE gesendet. Und das ist imo noch größerer Schwachsinn als ein etwas erhöhter Batterieverbrauch (zumal die Sendefrequenz gefühlt trotzdem weit unter dem ist, was z.B. die Homematic-Dinger machen).

Ich habe das jedenfalls jetzt so eingestellt, dass beide Threasholds auf 1 sind (für temp+valve) und bin mal gespannt, wie lange die Batterien halten.

[Deckoffizier]

Hallo Beta-User,

ABER: der Threshold bezieht sich auf den letzten Messwert, nicht auf den letzten übermittelten Wert (wann auch immer gemessen wird...). Hat man also langsame, aber trotzdem große Schwankungen, wird NIE gesendet. Und das ist imo noch größerer Schwachsinn als ein etwas erhöhter Batterieverbrauch (zumal die Sendefrequenz gefühlt trotzdem weit unter dem ist, was z.B. die Homematic-Dinger machen).

Hmmm kan mich irren,  für mich bezieht sich das auf den eingestellten Sollwert.
Ein Thermostat ist nun mal kein Thermometer bzw. Multisensor wie das sogenannte Fibaro "Auge".

Zu wird NIE gesendet habe gerade die Erfahrung gemacht durch externen Sensor Ausfall auf den internen
TempSensor umgestellt(bei Man.Modus!), es dauert natürlich lange wenn ich den Sollwert von 22 Grad auf 18 Grad mittels Weekdaytimer
abgesenkt habe ehe dann bei +-0,5 eine neue Meldung(Reading,Zeitstempel) kommt.
Na ja Bad war Heute Morgen trotzdem warm.
Der Haken ist natürlich, genaue Temp Kurve lässt sich schlechter plotten.

Tut der Funktionalität aber keinen Abbruch.
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?
Vielleicht kann der Hersteller dazu was sagen.

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?

Gruß
Hans-Jürgen