Eurotronics Spirit Readingsgroup mit Sollwerten (heating und energysaveheating)

[MadMax-FHEM]

Hmm, ok.

Unschön (hoffentlich gibt es bessere Lösungen) aber dann sollte das mit den userreadings doch gehen!?

Es steht halt im jeweiligen userreadings eben immer der letzte Wert der dazugehörigen Abfrage (also z.B. enthält "energySaveHeating" oder eben enthält "heating" und dann im userreadings eben nur der "ausgefilterte" Temperaturwert / so meine Idee)...

Damit die (beiden) userreadings nat. halbwegs aktuell sind, müssten die get-Aufrufe halt zyklisch passieren (noch weniger schön)...

Allerdings bin ich jetzt mangels Geräten und somit Wissen darüber "raus"

Gruß, Joachim

P.S.: wenn ich mir das so ansehe (in diesem und anderen Threads zu dem Thema) sind die Thermostate (aktuell) für mich kein Ersatz für meine Homematic "Classic"/BidCos (sollten die mal "ausverkauft" sein und dann "kaputt gehen")...

[curt]

Unschön (hoffentlich gibt es bessere Lösungen) aber dann sollte das mit den userreadings doch gehen!?

Falscher Ansprechpartner. Ich muss mich da jedesmal durch die Dokus kämpfen und die mürrischen Profis fragen.

P.S.: wenn ich mir das so ansehe (in diesem und anderen Threads zu dem Thema) sind die Thermostate (aktuell) für mich kein Ersatz

Ich finde die wirklich prima, nichts auszusetzen. Bei 3 von 8 hatte/habe ich selten stochastisch Probleme, die Dinger hängen ab und an und heizen fröhlich weiter. Das mag aber an der Sonderkonstellation bei mir liegen: Mein Ventilhub ist bei gleichzeitig ordentlicher Federspannung nur 2, eher 1,5mm.

Die Probleme liegen auf der Treiberseite, wenn ich mal ein Modul für ein physikalisches Gerät als Treiber ansprechen darf: Da stelle ich mir die entsprechenden Readings vor - wozu gibt es Zeitstempel für Readings? Und ich stelle mir vor, dass der Treiber auf die Besonderheit des Geräts (alles abholen) eingeht und mir Optionen für die Abholfrequenz (von 0 für nie bis usw.) gibt. Ja, geht auf die Batterie - aber so ist das Leben: Ich muss mich immerzu entscheiden, was mir wichtiger ist.

Modulautor ist wohl @rudolfkoenig und er hat im anderen Thread gesagt, dass da nichts geändert wird. Seine von mir nur halb verstandenen Argumente kann und will ich nicht anzweifeln, wer bin ich denn? Anders als bei ganz wenigen anderen Themen kann ich Rudolf in dieser Frage nicht ansatzweise das Wasser reichen.

für meine Homematic "Classic"/BidCos (sollten die mal "ausverkauft" sein und dann "kaputt gehen")...

Ich habe eins, etwas angestaubt. Das liegt offen in der Ecke, in die ich es pfefferte. Ohne mit Wlan oder wie das bei HomeMatic heißt. Noch ein "altes". Ich schenke es Dir, damit Du im Notfall Ersatz hast: Postanschrift per PN rum und es geht los. Ja, meine ich ernst.
Und im Gegenzug beantwortest Du mir ab und an eine saublöde Frage nach userreadings oder so ... saublöde Fragen kann ich stellen, das ist meine Primärqualifikation. 

[omnior]

Ok, danke Dir für die nochmalige Präzisierung. Ich bin mit den Thermostaten grundsätzlich auch sehr zufrieden, habe nur mit einem von 10 Stück ab und zu mal ein Problem.
Joachim hat ja vorgeschlagen, userreadings zu verwenden. Damit habe ich gestern abend rumprobiert bin aber noch nicht wirklich schlau ob es funktionieren könnte, einen oder beide der per

Code Auswählen Erweitern

get $DEVICE setpoint 11
get $DEVICE setpoint 1
reingeholten Sollwerte irgendwie in die userreadings reinbringen könnte, sowas in der Art wie

Code Auswählen Erweitern

attr $DEVICE userreadings SollSpar {fhem(get $DEVICE setpoint 11)}
das ist aber noch irgendwie von der Syntax falsch oder ich scheitere einfach an falschen Hochkommas oder Klammern.

[MadMax-FHEM]

Ich bin ja auch kein userreadings-Experte...

Aber das mit dem get muss "woanders" zyklisch passieren (at oder so)...

userreadings dann "nur" für die "Anzeige"...

Ich probiere später mal rum...
...allerdings halt schwer ohne so ein Ding zu haben...

Gruß, Joachim

[MadMax-FHEM]

Also nochmal und in FETT

Ich bin BEI WEITEM KEIN userReadings-Experte!!!

Ich habe mal mit einem dummy "rumgespielt" (ermangelung des tatsächlichen Devives) wie folgt:

Code Auswählen Erweitern


defmod ZWave_THERMOSTAT dummy
attr ZWave_THERMOSTAT room Test
attr ZWave_THERMOSTAT userReadings desTempHeating:setpointTemp.* {my $SetpointTempAct = ReadingsNum($name,"desTempHeating",0);; my $Setpoint = ReadingsVal($name,"setpointTemp","n.a.");; my $SetpointTemp = ReadingsNum($name,"setpointTemp",0);; if($Setpoint =~ m/heating/){return $SetpointTemp}else{return $SetpointTempAct}},desTempSaving:setpointTemp.* {my $SetpointTempAct = ReadingsNum($name,"desTempSaving",0);; my $Setpoint = ReadingsVal($name,"setpointTemp","n.a.");; my $SetpointTemp = ReadingsNum($name,"setpointTemp",0);; if($Setpoint =~ m/energySaveHeating/){return $SetpointTemp}else{return $SetpointTempAct}}

setstate ZWave_THERMOSTAT 2020-10-22 09:33:31 desTempHeating 18.0
setstate ZWave_THERMOSTAT 2020-10-22 09:33:31 desTempSaving 20.0
setstate ZWave_THERMOSTAT 2020-10-22 09:33:31 setpointTemp 20.0 C energySaveHeating


und dann ein at für meinen dummy (da müssten dann bei euch/dir halt die get irgendwas Befehle rein):

Code Auswählen Erweitern


defmod atZWave_THERMOSTAT at +*00:10:00 setreading ZWave_THERMOSTAT setpointTemp 18.0 C heating ;; sleep 10;; setreading ZWave_THERMOSTAT setpointTemp 20.0 C energySaveHeating


Das at "holt" quasi alle 10min die beiden Werte (Abstand zwischen den Werten 10s -> sleep).
Bei mir wird halt der dummy mit den hoffentlich richtigen Werten "versorgt"...

Danach steht im Reading desTempHeating der Wert der bei "heating" kommt und in desTempSaving eben der Wert der mit "energySaveHeating" kommt (zumindest so der Plan   ).

Wenn der jeweils andere Wert kommt, dann wird der aktuelle einfach noch mal ausgegeben.
Ob da ein leeres return auch ginge, also der jeweils andere Wert dann nicht (auch) aktualisiert wird: keine Ahung...

Aber da das userReadings eh nicht "super optimal" ist
Wird daran sicher auch das noch verbessert...

...sofern diese "Lösung" überhaupt in Frage kommt...

Ob es für das at auch eine andere, bessere Lösung gibt -> keine Ahnung.

EDIT: evtl. kann man noch am Trigger schrauben. Also jeweils schon den Trigger so einschränken, dass man nur noch ReadingsNum($name,"setpointTemp",0) zurückgeben muss. Also statt dem if-Match gleich eine passende RegEx beim Trigger des jeweiligen userReadings... Aber auch für RegEx gilt: bei WEITEM KEIN Experte! Daher diese "nicht so schöne" Lösung... Aber ich wollte ja auch "nur" meine "Idee" rüber bringen

EDIT: naja auch nicht viel schön aber kürzer

Code Auswählen Erweitern


attr ZWave_THERMOSTAT userReadings desTempHeating:setpointTemp.*heating {return ReadingsNum($name,"setpointTemp",0)},desTempSaving:setpointTemp.*energySaveHeating {return ReadingsNum($name,"setpointTemp",0)}


Gruß, Joachim

P.S.: achja alles "Raw-Definitions" und für dich/euch nat. nur das userReadings (und ein abgeändertes at) relevant...

[Beta-User]

P.S.: wenn ich mir das so ansehe (in diesem und anderen Threads zu dem Thema) sind die Thermostate (aktuell) für mich kein Ersatz für meine Homematic "Classic"/BidCos (sollten die mal "ausverkauft" sein und dann "kaputt gehen")...

Bin mal gespannt, was mein persönliches Fazit am Ende sein wird, wenn mein Spirit denn irgendwann hier eingetroffen und konfiguriert ist...

Aber das mit dem get muss "woanders" zyklisch passieren (at oder so)...

ABSOLUT!

Mit sowas

Code Auswählen Erweitern

attr $DEVICE userreadings SollSpar {fhem(get $DEVICE setpoint 11)}

baut man sich vermutlich einen - eventuell das komplette ZWave-Funknetz lahmlegenden (!!!) - Zirkel! Das "get" dürfte "asynchron" rausgehen und das Ergebnis triggert dann wieder ein Event an dem Device, worauf dann wieder das userReading "SollSpar" aktualisiert wird - das ist ohne Trigger, also geht das ganze von vorne los...

Daher nochmal für die "Nicht-userReadings"-Experten meine 2ct zu dem Thema:
- NIE userReadings OHNE Trigger definieren (selbst da, wo es eigentlich nicht nötig ist, schadet es in der Regel nicht);
- NIE andere als direkt abfragende Kommandos verwenden (ReadingsVal()&Co sind ok, bei get wird es schnell kritisch...).

Würde mal mit dem hier ins Rennen gehen (war schon fertig, als MadMax-FHEM auch mit seinem Vorschlag kam):

Code Auswählen Erweitern

attr DEVICE userreadings energySaveHeating:setpointTemp.+energySaveHeating {ReadingsNum($name,"setpointTemp",0)}, heating:setpointTemp.+heating {ReadingsNum($name,"setpointTemp",0)}

Ansonsten @curt:
Ja, ich lese hier mit, und ich wäre ggf. auch an deinem CUL_HM-Elektroschrott interessiert...

[omnior]

Würde mal mit dem hier ins Rennen gehen (war schon fertig, als MadMax-FHEM auch mit seinem Vorschlag kam):

Code Auswählen Erweitern

attr DEVICE userreadings energySaveHeating:setpointTemp.+energySaveHeating {ReadingsNum($name,"setpointTemp",0)}, heating:setpointTemp.+heating {ReadingsNum($name,"setpointTemp",0)}

Mir ist nur nicht klar, wie bzw. durch was hier die beiden Sollwerte (die man ja nur über get setpoint mit Parameter 11 oder 1 abfragen kann reinkommen sollen. In setpointTemp steht ja nur der zuletzt abgefragte Wert drin.

[Beta-User]

Wenn (über eine anderweitig zu veranlassende (!) Abfrage) Werte reinkommen, wird der dann darin enthaltene Zahlenwert entweder dem einen oder dem anderen Reading (energySaveHeating bzw. heating) zugeschlagen.
Mit der weiteren Frage, wie man ggf. den aktuellen Modus (möglichst ohne get) rausfinden kann, muß ich mich dann mal beschäftigen, wenn die Hardware da ist.

Aber wie gesagt: (Alle) userReadings setzen voraus, dass das Device (optimalerweise: passend) aktualisiert wird, was man ggf. dann irgendwie anders (ein at, z.B.) veranlassen muss, wenn es nicht von alleine zurückkommt (ob man nicht doch "eigentlich" schon mit dem Ack eine Rückmeldung hat, war in dem anderen Thread die Diskussion und wäre ggf. dann m.E. auch dort weiterzuführen).

[MadMax-FHEM]

attr DEVICE userreadings energySaveHeating:setpointTemp.+energySaveHeating {ReadingsNum($name,"setpointTemp",0)}, heating:setpointTemp.+heating {ReadingsNum($name,"setpointTemp",0)}

Hä!!?

Das hat mit meinem userReadings ÜBERHAUPT NICHTS zu tun!!!!

EDIT: ok so überhupt nichts auch nicht ABER: statt dem Plus doch einen Stern! (also soweit ich das in RegEx verstehe, bin aber [siehe weiter oben] KEIN Spezialist), also dann: sorry!


EDIT: und das Leerzeichen nach dem Komma zum Trennen der beiden NEUEN Readingnamen MUSS WEG! (also soweit ich userReadings verstehe [auch hier: KEIN Spezialist   ])... Komma-separated vs. Komma-und-Leerzeichen-separated...

Warum nimmst du nicht meines!?
(so viel Mühe gegeben   )

Hier noch mal:

EDIT: Raw-Def wieder gelöscht (ist ja "oben" schon)...

EDIT: auch ich finde das at nicht toll aber für den dummy brauchte ich das ja (eh) und bei den Thermostaten habe ich keine Ahnung, ob die Werte auch anders kommen können, drum

Aber wie gesagt: (Alle) userReadings setzen voraus, dass das Device (optimalerweise: passend) aktualisiert wird, was man ggf. dann irgendwie anders (ein at, z.B.) veranlassen muss, wenn es nicht von alleine zurückkommt (ob man nicht doch "eigentlich" schon mit dem Ack eine Rückmeldung hat, war in dem anderen Thread die Diskussion und wäre ggf. dann m.E. auch dort weiterzuführen).

Bitte gerne dort weiter...
Bzw. habe ich mehr zu dem Thema eh nicht mehr beizutragen...
(und jetzt wirklich   )


Naja:

also wenn du per get die Werte holst (ich mache das für den dummy über das at, gut ich versuche auch noch ein at für deine "Problematik" / ob dazu ein at notwendig ist oder ob das auch anders geht: keine Ahnung), dann wird das Reading setpointTemp doch mit einem Wert versorgt.

EDIT: hier (trotzdem) noch das at (damit werden eben zyklisch die get-Befehle abgesetzt, damit dann das userReadings was zu tun hat   und die ANDEREN Readings befüllen kann)

Code Auswählen Erweitern


defmod atZWave_THERMOSTAT at +*00:10:00 get ZWave_THERMOSTAT setpoint 11;; sleep 10;; get ZWave_THERMOSTAT setpoint 1


Also entweder steht dann:

setpointTemp 23.0 C heating

-> darauf triggert das "1te" userReadings und setzt dann das "neue" Reading: desTempHeating eben auf 23.0

oder

setpointTemp 18.0 C energySaveHeating

darauf triggert das "2te" userReadings und setzt dann das "neue" Reading: desTempSaving auf 18.0


Mal bei userReadings nachlesen:

attr Device userReadings NeuerReadingName1:Trigger1 {so wird's "berechnet" und hier wird der Wert für NeuerReadingName1 zurückgegeben},NeuerReadingName2:Trigger2 {so wird's "berechnet" und hier wird der Wert für NeuerReadingName2 zurückgegeben}

Gruß, Joachim

[omnior]

Vielleicht habe ich dein userreadings bzw. die dort benutzte if Abfrage noch nicht ganz verstanden...

Also entweder steht dann:

setpointTemp 23.0 C heating

-> darauf triggert das "1te" userReadings und setzt dann das "neue" Reading: desTempHeating eben auf 23.0

oder

setpointTemp 18.0 C energySaveHeating

darauf triggert das "2te" userReadings und setzt dann das "neue" Reading: desTempSaving auf 18.0

Wieso entweder oder? Es passiert eben beides hintereinander. Es ist ja nicht so, dass in Abhängigkeit des Modus das Ergebnis ein anderes ist, sondern der get setpoint Befehlt schreibt einfach den jeweils abgefragten Sollwert immer in das gleiche setpointTemp Reading rein. Also durch das at wird so wie du es geschrieben hast, erst der heating Sollwert und nach dem sleep der EnergySaveSollwert geschrieben.
Wie gesagt, vielleicht hab ich aber nur dein userreadings Definition nicht ganz verstanden.

Code Auswählen Erweitern

attr ZWave_THERMOSTAT userReadings desTempHeating:setpointTemp.* {my $SetpointTempAct = ReadingsNum($name,"desTempHeating",0);; my $Setpoint = ReadingsVal($name,"setpointTemp","n.a.");; my $SetpointTemp = ReadingsNum($name,"setpointTemp",0);; if($Setpoint =~ m/heating/){return $SetpointTemp}else{return $SetpointTempAct}},desTempSaving:setpointTemp.* {my $SetpointTempAct = ReadingsNum($name,"desTempSaving",0);; my $Setpoint = ReadingsVal($name,"setpointTemp","n.a.");; my $SetpointTemp = ReadingsNum($name,"setpointTemp",0);; if($Setpoint =~ m/energySaveHeating/){return $SetpointTemp}else{return $SetpointTempAct}}

Wann wird das userreading denn genau "getriggert"? Zwei mal? Erstes mal nach dem Setzen des heating Sollwerts und dann nach dem Sleep 10 Befehl nochmal?

[MadMax-FHEM]

Nochmal:

1. du musst irgendwie DAS Reading setpointTemp aktualisieren -> get ZWave_THERMOSTAT setpoint 11 bzw. get ZWave_THERMOSTAT setpoint 1
   Dafür habe ICH mal das at. Wenn es einen anderen/besseren Weg gibt: juhu!

2. ja bei der "langen" Version des userReadings (mit den if-Abfragen) wird JEDESMAL wenn sich setpointTemp ändert getriggert. Darum ja "intern" das if. Also ob es der eine oder der andere get war bzw. dessen "Ergebnis"... Je nachdem wird eben dann das eine "neue Reading" mit einem AKTUELLEN (den eben "empfangenen") Wert "versorgt" und das andere (für den KEIN neuer Wert gekommen ist, weil die get-Abfrage ja für "das andere" war) eben mit dem bisherigen Wert erneut "gefüllt"... (ist halt unschön/unnötig/doof/...   daher ja die 2te/kurze Variante)...

ABER: nimm doch die "kurze" Variante:

Code Auswählen Erweitern


attr ZWave_THERMOSTAT userReadings desTempHeating:setpointTemp.*heating {return ReadingsNum($name,"setpointTemp",0)},desTempSaving:setpointTemp.*energySaveHeating {return ReadingsNum($name,"setpointTemp",0)}


Die triggert genau nur je nachdem welcher Wert "ge-getted" wurde...
(sofern das was ich an lists gesehen und du geschrieben hast stimmen)

ABER: "irgendjemand"/"irgendetwas" muss eben (trotzdem) dafür sorgen, dass die Werte "ge-getted" werden (noch mal: bei mir eben das at)...

Gruß, Joachim

[Beta-User]

So, nachdem mein Spirit hier auch gelandet ist, mal vorab ein list von dem (fast) jungräulichen Ding (war aber gebraucht, kann natürlich sein, dass da jemand schon dran rumgespielt hatte; einen reset (Batterie raus, Knopf drücken, Batterie rein) hatte ich gemacht):

Code Auswählen Erweitern

defmod ZWave_THERMOSTAT_20 ZWave 12345678 20attr 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 ZWave
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 associationAdd 1 1
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-23 08:13:49 configTemperatureReportThreshold 5
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:49 configValveOpeningPercentageReport 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-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-23 08:10:16 state associationAdd 1 1
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:49 timeToAck 0.130
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:49 transmit OK
setstate ZWave_THERMOSTAT_20 2020-10-23 08:11:04 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:1200Dann dachte ich, es sei eine gute Idee, mal diese gets auszuführen und das mit den userReadings zu testen etc..

Daher erst mal wieder ein list - nachdem ich (in etwa) folgendes gemacht habe:
- die Solltemperatur am Thermostaten verändert (über die Knöpfe);
- die Batterie entfernt;
- danach nochmal die desired-temp geändert:

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 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)=~(heating|
energySaveHeating)?$1:undef)}
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 desired-temp 24
setstate ZWave_THERMOSTAT_20 2020-10-23 08:25:17 alarm System: hardware
failure with OEM proprietary failure code, arg 102
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-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-23 08:13:49
configTemperatureReportThreshold 5
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:49
configValveOpeningPercentageReport 0
setstate ZWave_THERMOSTAT_20 2020-10-23 08:18:45 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-23 08:24:14 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-23 08:24:14 setpointTemp 18.0 C heating
setstate ZWave_THERMOSTAT_20 2020-10-23 09:22:19 state desired-temp 24
setstate ZWave_THERMOSTAT_20 2020-10-23 08:23:07 thermostatMode heating
setstate ZWave_THERMOSTAT_20 2020-10-23 08:23:15 timeToAck 1.406
setstate ZWave_THERMOSTAT_20 2020-10-23 09:22:46 transmit NO_ACK
setstate ZWave_THERMOSTAT_20 2020-10-23 08:11:04 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

Danach kann ich diesem Vorschlag nicht mehr viel abgewinnen:

1. du musst irgendwie DAS Reading setpointTemp aktualisieren -> get ZWave_THERMOSTAT setpoint 11 bzw. get ZWave_THERMOSTAT setpoint 1
   Dafür habe ICH mal das at. Wenn es einen anderen/besseren Weg gibt: juhu!

Welchen Zweck hat die periodische Abfrage über das get? Mein Verständnis ist das: Das ist eine Einstellung, die man ändern kann (dazu soll die ReadingsGroup dienen, oder? Dann müßte man die entsprechenden configByte-Befehle ausführen, und danach (vielleicht! s.u.) wieder einmalig (!) den get-Befehl absetzen ?), die aber ansonsten unveränderlich sind.

Die eigentliche Temperaturregelung (so man nicht den valve-Modus nutzt) findet darüber statt, dass man entweder zwischen diesen beiden Punkten umschaltet (tm.*-setter) oder eben über die (synonymen) desired-temp/setpointTemp die Solltemperatur vorgibt.

Problematisch scheint nur zu sein, dass es
- keinen wirklich guten Link zwischen den set-Befehlen und den Readings gibt und
- man immer unterstellen muß, dass set-Befehle auch angekommen sind, also die Theorie der "Praxis" entspricht.

MAn. sollte man genau das tun: Annehmen, dass ZWave-Befehle auch angekommen sind. Das Protokoll ist bidirektional, und WENN es Probleme gibt, steht es in "transmit". Kann sein, dass es Ausnahmen gibt, aber deswegen gleich das Kind mit dem Bade auszukippen und das Funkbudget durch völlig unnötige (just my2ct) und - noch schlimmer - ggf. irreführende Abfragen zu belasten, das geht in die völlig falsche Richtung.

Ansonsten werde ich bei Gelegenheit mal versuchen, das mit der Konsistenz der Readings irgendwie hinzubiegen. Rückmeldung erfolgt dann aber eher in dem/den anderen Threads.

[MadMax-FHEM]

Danach kann ich diesem Vorschlag nicht mehr viel abgewinnen:

Code Auswählen Erweitern

Zitat von: MadMax-FHEM am Gestern um 17:20:04

    1. du musst irgendwie DAS Reading setpointTemp aktualisieren -> get ZWave_THERMOSTAT setpoint 11 bzw. get ZWave_THERMOSTAT setpoint 1
       Dafür habe ICH mal das at. Wenn es einen anderen/besseren Weg gibt: juhu! ;)


Konnte ich noch nie...
...war aber ja Input des TE, dass das so sein sollte/müsste

Und: ich habe die Dinger ja (noch länger   ) nicht...

Viel Erfolg, Joachim

[Beta-User]

Konnte ich noch nie...
...war aber ja Input des TE, dass das so sein sollte/müsste

Und: ich habe die Dinger ja (noch länger   ) nicht...

Viel Erfolg, Joachim

War nicht persönlich gemeint .

Mein erster Eindruck von dem Spirit, falls es dich interessiert:
Der wirkt ganz ok, Laufgeräusche sind eher auf dem Niveau der besseren meiner HM-Teile, Optik finde ich deutlich besser, auch wenn man über die (austauschbare) graue Kappe geteilter Meinung sein kann.
Handling (Inclusion, Reaktion auf Befehle usw.) war völlig unproblematisch. Man muß bei diesen Dingern halt darauf vertrauen, dass FHEM zuverlässig läuft, aber da hätte ich zwischenzeitlich nicht die großen Bedenken. Muß jetzt erst mal einen Adapter suchen, meiner kam ohne daher, aber ich sollte noch den einen oder anderen aus der HM-Welt übrig haben, dann kann das Ding mal in den Probebetrieb gehen (ich wollte eh' die WeekdayTimer/weekprofile-Kombi mal selbst austesten, aber @CUL_HM gab es dafür nicht den großen Bedarf...).

Von daher, _falls du je irgendwann_ Ersatz für CUL_HM suchst: Ein Blick (auch) in die ZWave-Richtung schadet vermutlich nicht .

[curt]

Mach mal langsamer. Nicht gleich Profile. Du möchtest erst die Fallstricke kennenlernen.

Keine Zeit - heute Abend genauer.