Fehlende Werte von EUR_SPIRITZ Wall Radiator Thermostat

[The Grue]

Servus!

Mit meinem neuen EUR_SPIRITZ Wall Radiator Thermostat bin ich sehr zufrieden: Funktioniert, so weit ich sehen kann alles wie es soll, jedenfalls fast. Das "fast" ist:

Wenn ich per set desired-temp eine temperatur sende, zeigt das Thermostat diese Temperatur an, die readings in FHEM aber nicht. Beispiel:

Code Auswählen Erweitern


set Bathroom.Thermostat desired-temp 18


aber in Fhem sehe ich:

Code Auswählen Erweitern

setpointTemp 10.0 C heating

Kann ich da irgendwas machen?

Das Device sieht so aus:

Code Auswählen Erweitern

defmod Bathroom.Thermostat ZWave c83f1470 71
attr Bathroom.Thermostat IODev ZWDongle_0
attr Bathroom.Thermostat alias Bad: Thermostat
attr Bathroom.Thermostat 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 Bathroom.Thermostat group Heizung
attr Bathroom.Thermostat icon sani_heating
attr Bathroom.Thermostat room Bad,ZWave
attr Bathroom.Thermostat stateFormat Ist:temperature Soll:setpointTemp Bat:battery
attr Bathroom.Thermostat 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 Bathroom.Thermostat Ist:19.43 C Soll:10.0 C heating Bat:100 %
setstate Bathroom.Thermostat 2021-02-11 15:33:54 assocGroup_1 Max 1 Nodes ZWDongle_0
setstate Bathroom.Thermostat 2021-02-11 15:33:53 assocGroups 1
setstate Bathroom.Thermostat 2021-02-12 14:28:38 battery 100 %
setstate Bathroom.Thermostat 2021-02-12 14:28:38 batteryPercent 100
setstate Bathroom.Thermostat 2021-02-12 14:28:38 batteryState ok
setstate Bathroom.Thermostat 2021-02-12 11:39:12 configBacklight BacklightEnabled
setstate Bathroom.Thermostat 2021-02-12 11:39:12 configBatteryReport SendOnceADay
setstate Bathroom.Thermostat 2021-02-11 15:34:00 configLCDInvert Normal
setstate Bathroom.Thermostat 2021-02-12 11:39:13 configLCDTimeout 0
setstate Bathroom.Thermostat 2021-02-12 18:18:26 configMeasuredTemperatureOffset 20
setstate Bathroom.Thermostat 2021-02-12 11:39:13 configOpenWindowDetection MediumSensibility
setstate Bathroom.Thermostat 2021-02-12 11:39:13 configTemperatureReportThreshold 1
setstate Bathroom.Thermostat 2021-02-12 11:39:13 configValveOpeningPercentageReport 0
setstate Bathroom.Thermostat 2021-02-11 15:31:28 model EUROtronic EUR_SPIRITZ Wall Radiator Thermostat
setstate Bathroom.Thermostat 2021-02-11 15:31:28 modelConfig eurotronic/eur_spiritz.xml
setstate Bathroom.Thermostat 2021-02-11 15:31:28 modelId 0148-0003-0003
setstate Bathroom.Thermostat 2021-02-11 16:19:38 reportedState off
setstate Bathroom.Thermostat 2021-02-12 11:32:16 setpointTemp 10.0 C heating
setstate Bathroom.Thermostat 2021-02-12 18:17:52 state configMeasuredTemperatureOffset 20
setstate Bathroom.Thermostat 2021-02-12 18:19:42 temperature 19.43 C
setstate Bathroom.Thermostat 2021-02-12 08:33:34 thermostatMode heating
setstate Bathroom.Thermostat 2021-02-11 16:19:12 thermostatSetpointSupported heating energySaveHeating
setstate Bathroom.Thermostat 2021-02-12 18:18:26 timeToAck 1.411
setstate Bathroom.Thermostat 2021-02-12 18:18:26 transmit OK
setstate Bathroom.Thermostat 2021-02-11 15:29:01 zwavePlusInfo  version:01 role:SleepingListeningSlave node:Z-Wave+Node installerIcon:1200 userIcon:1200



Vielen Dank schon mal für Eure Hilfe und ein schönes Wochenende
--
Markus

[krikan]

Kann ich da irgendwas machen?

Mit dem passenden get-befehl das erfolgreiche Setzen des Wertes prüfen; hier: "get <device> setpoint". Andere Lösung gibt es afaik (leider) nicht.
(siehe auch Hinweis-Box auf https://wiki.fhem.de/wiki/Z-Wave-Eurotronic_Spirit_Thermostat#Befehle_zur_Steuerung)

Gruß, Christian

[Beta-User]

Es gibt ein Ack-Attribut am ZWDongle. Hilft das hier nicht?

(Rudi wartet noch auf Rückmeldung, damit er das zum default machen kann...)

[The Grue]

siehe auch Hinweis-Box

Die war mir wohl zu klein Danke für den Hinweis!

[The Grue]

Es gibt ein Ack-Attribut am ZWDongle. Hilft das hier nicht?

Hab dazu gerade nichts gefunden, hab aber gerne Tomaten auf den Augen... Meinst Du sowas wie per notify auf ein ack ein get ... senden?

(Sorry, hab' gerade zwei Pflaster an den Händen, tippt sich übel )

[Beta-User]

Code Auswählen Erweitern

attr zwaveme setReadingOnAck 1
(Halbwegs aktuelle ZWDongle vorausgesetzt....)

@krikan: Der Kasten ist veraltet...

[krikan]

@krikan: Der Kasten ist veraltet...

Bin etwas verunsichert, da ich das "attr zwaveme setReadingOnAck 1" nicht verstehe. Habe gerade getestet und out-of-the-box hat das bei set-desired-temp keine Auswirkung. (Müsste wohl noch ein userReading "desired-temp" anlegen!?)
Ungefähr so: Falls es ein Reading mit gleichem Namen wie dem Befehl gibt, dann gehe bei ACK davon aus, dass der Befehl erfolgreich war und der Wert korrekt gesetzt wurde? Also nicht mehr gesichert Abfrage, sondern Annahme führt zum Setzen des Readings? Werte außerhalb der Geräte-Unterstützung fallen also nicht mehr auf, wenn es einen ACK gibt? Das ist mMn überhaupt keine gesicherte Abfrage, sondern eben Vermutung.

Wenn ich richtig liege, würde ich den Kasten nicht als veraltet betrachten. 

[Beta-User]

Hm, habe nur den einen Spirit und da grade mal das userReadings-Attribut gelöscht (aber nicht gespeichert und neu gestartet).

Da wird das Reading desired-temp gesetzt. Das andere Dongle-Attribut (set_.*) ist nicht gesetzt.
So wie mir das in Erinnerung war, wurde das Reading früher gar nicht gesetzt, das landete alles in state.

Wie ich Rudi im Ohr habe, wird das Reading aktualisiert und ggf. erzeugt, wenn der Befehl ankommt (bzw. wie der Name sagt, das Ack zurückkommt).
Falls das nicht paßt, müßte man Rudi informieren (in dem "Einrichten"-Thread?).

Der Kasten ist übrigens zwischenzeitlich geändert ....

[krikan]

Da wird das Reading desired-temp gesetzt.

Stimmt, wenn man(ich) mit der aktuellen 10_ZWave.pm ohne eigene Basteleien testet, dann stimmt das. Sorry.

[Beta-User]

Kein Ding, besser nochmal nachgesehen...

[krikan]

Bleibe aber dabei, dass ich das Attribut nicht für "ideal" halte. 

Man kann den Readings dann nicht mehr glauben.
Immer wenn das Gerät ein ACK liefert wird das Readings aktualisiert und man glaubt es sei alles korrekt gesetzt.
Ist es aber nicht, wenn man unzulässige Werte an das Gerät schickt, die werden vom Gerät zwar mit ACK bestätigt, aber nicht verarbeitet. Das erfährt man nur bei der entsprechenden get-Abfrage. Das Reading und Event behaupten aber wegen des erhaltenen ACK was anderes.
Unter anderem bei den config-Klartext-Befehlen, führt das zur totalen Verwirrung:
Ein "set <device>configLCDTimeout 50" wird bspw. per ACK bestätigt und Event und Reading passen, aber gesetzt wird das nicht.
Ein "list <device>"-Auszug verliert damit deutlich an Aussagekraft.

Gruß, Christian

[Beta-User]

Hmm, kann ich letztlich nicht abschließend beurteilen...

Konfig-Befehle sind m.E. eher die Ausnahme, und da macht es dann auch Sinn, das Ergebnis mit get abzufragen. "Normale" Befehle sollten eigentlich in 99% der Fälle über FHEM-Routinen laufen und auch "normale" FHEMWEB-Befehle, die der User nicht selbst zusammenstückelt, müßten eigentlich unproblematisch sein. Aber wenn es die "perfekte" Lösung nicht gibt, stellt sich die Frage, was die nächstbeste ist. Immer ein get hinterherzusenden (wie das bisher üblich war) finde ich jedenfalls auch nicht unproblematisch. Sollten wir ggf. auch mal mit Rudi diskutieren, ich bin da nach wie vor nicht tief genug in der Materie drin (und wollte mich auch nicht unbedingt sooo tief unter diesen Teil des Autos legen... )

[krikan]

Wenn config-Befehle eine Ausnahme bilden, dann schauen wir doch auf die set-desired-temp:
- Stelle den setpoint auf 20°.
- Jetzt setze "set <device> desired-temp 30" ab, was als Event/Reading "desired-temp 30" bestätigt wird
- Frage "get <device> setpoint" ab.
Das ist eben nicht 30°, sondern unverändert 20°.
(getestet auf meinem Spirit-hab auch nur eins.)
Wenn man den Befehl über FHEMWEB per Default select-Box mit dem Schieberegeler absetzen will, passiert das nicht. Aber ist das der Normalfall?

Das Spiel kann ich letztlich unendlich mit anderen Befehlen fortsetzen: Denn ACK vom Gerät bedeutet in ZWave nur, dass die Nachricht empfangen wurde und eben nicht, dass sie korrekt war und genauso verarbeitet werden konnte.

Ich tendiere immer dahin, dass Hardwaremodule keine Nachrichten/Events/Readings vor dem Anwender unerreichbar unterschlagen bzw. -wie hier- irgendwelche nicht zwingend korrekten Annahmen treffen und daraus Events/Readings als Nachricht erraten, weil es normalerweise so sein könnte.

Immer ein get hinterherzusenden (wie das bisher üblich war) finde ich jedenfalls auch nicht unproblematisch.

Wegen des Funkverkehrs? Eigentlich ist man dann sicher, dass der Wert stimmt und hat nicht einen "vermutlichen" Wert, der gar nicht vom Gerät bestätigt ist.

Letztlich hoffe ich nur, dass das zumindest per Attribut wählbar bleibt und nicht zum Standard wird. 

Sollten wir ggf. auch mal mit Rudi diskutieren

Liest bestimmt mit und "darf" entscheiden; er ist Maintainer. Ich wiederhole mich mMn sowieso gerade  .

Gruß, Christian

[Beta-User]

Hmm, das ist aber auch tricky...
Sorry, dass ich die Einwände dazu bisher überlesen oder nicht verstanden hatte.

Mal abgesehen von dem hier dahinterstehenden Log-Eintrag-Thema: Dann müßte/sollte (?) man das get bei dem Spirit (und ähnlich "stillen" Geräten) unter diesen Umständen eigentlich zur Absicherung immer hinterhersenden. Auch irgendwie unschön... (Oder im Modul eine gerätespezifische Sonderbehandlung einbauen, was aber auch nicht ernsthaft erwünscht ist...)
30° ist jedenfalls ein gutes Beispiel, denn das verstehen andere Thermostate durchaus, was dann zu richtiger Verwirrung führen kann.

[rudolfkoenig]

Mit dem Attribut kann man bestimmte Readings aktualisieren, per Voreinstellung ist es aus, weil es nicht immer richtig funktioniert. Wen das nicht stoert, und nicht mehr genau weiss, was er selbst eingestellt hat, kann ja dieses Attribut gerne verwenden.

Ich bin noch nicht ueberzeugt, den Aufwand (sowohl was Programmierung, wie auch was Funklast betrifft) in eine idiotensichere Methode zu investieren.