Eurotronic Spirit zigbee won't accept commands?

[gielfeldt]

Hi

I'm trying to control my Eurotronic Spirit Zigbee thermostats from zigbee2mqtt. Getting data from the thermostat works fine, but sending messages to the thermostat does not work. Or if it does, then I don't know how to do it properly.

What happened

Got error when trying to change temperature setpoint on Eurotronic Spirit thermostat.

2020-10-06T11:31:59.165140021Z Zigbee2MQTT:error 2020-10-06 13:31:59: Publish 'set' 'current_heating_setpoint' to 'sove_radiator' failed: 'Error: Write 0x00158d00053d357d/1 hvacThermostat({"16387":{"value":1900,"type":41}}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4151,"transactionSequenceNumber":null}) failed (Status 'INVALID_VALUE')'

What did you expect to happen

I expected the temperature setpoint to bet set.

How to reproduce it (minimal and precise)

Post {"current_heating_setpoint":19} to zigbee2mqtt/device_friendly_name/set

2020-10-06T11:31:59.165140021Z Zigbee2MQTT:error 2020-10-06 13:31:59: Publish 'set' 'current_heating_setpoint' to 'sove_radiator' failed: 'Error: Write 0x00158d00053d357d/1 hvacThermostat({"16387":{"value":1900,"type":41}}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4151,"transactionSequenceNumber":null}) failed (Status 'INVALID_VALUE')' 2020-10-06T11:31:59.169145852Z Zigbee2MQTT:info 2020-10-06 13:31:59: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'current_heating_setpoint' to 'sove_radiator' failed: 'Error: Write 0x00158d00053d357d/1 hvacThermostat({\"16387\":{\"value\":1900,\"type\":41}}, {\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":4151,\"transactionSequenceNumber\":null}) failed (Status 'INVALID_VALUE')'","meta":{"friendly_name":"sove_radiator"},"type":"zigbee_publish_error"}'

Debug info

Zigbee2MQTT version: dev latest
Adapter hardware: CC2531
Adapter firmware version: CC2531_DEFAULT_20190608

I noticed that when posting properties in payload that are unknown, zigbee2mqtt repsonds with a "No converter available". In the logs above, it also seems that it converts the 19 into 1900. Maybe that is a hint?

[gielfeldt]

Hmmm. I may have found some relevant code over at https://github.com/Koenkk/zigbee-herdsman-converters

Perhaps this issue should go there? I'm not certain, please advise.

[sjorge]

19 -> 1900 is AFAIK, I don't have mine hooked up currently but e.g. 18.5 will become 1850.

It's also within the accepted range of 10 -> 30. I'll see if I can find mine, maybe I can replicate the error.

[sjorge]

Sadly I can replicate it, I now also get INVALID_VALUE back. That's both good and bad.
good -> you're not alone
bad -> somehow this broke

edit: the plot thickens, I started wireshark to capture the traffic... but now I can no longer replicate it, it's working fine now.

Zigbee2MQTT:debug 2020-10-06 13:32:26: Received MQTT message on 'zigbee2mqtt/0x00158d0001ffaffc/set' with data '{"occupied_heating_setpoint":19}'
Zigbee2MQTT:debug 2020-10-06 13:32:26: Publishing 'set' 'occupied_heating_setpoint' to '0x00158d0001ffaffc'
Zigbee2MQTT:debug 2020-10-06 13:32:28: Received Zigbee message from '0x00158d0001ffaffc', type 'attributeReport', cluster 'hvacThermostat', data '{"16387":1900}' from endpoint 1 with groupID 0
Zigbee2MQTT:debug 2020-10-06 13:32:28: Received Zigbee message from '0x00158d0001ffaffc', type 'attributeReport', cluster 'hvacThermostat', data '{"occupiedHeatingSetpoint":1900}' from endpoint 1 with groupID 0
Zigbee2MQTT:info  2020-10-06 13:32:30: MQTT publish: topic 'zigbee2mqtt/0x00158d0001ffaffc', payload '{"current_heating_setpoint":19,"eurotronic_error_status":0,"eurotronic_host_flags":{"boost":false,"child_protection":true,"mirror_display":false,"window_open":false},"eurotronic_system_mode":129,"linkquality":31,"local_temperature":22,"occupied_heating_setpoint":19,"pi_heating_demand":0,"system_mode":"auto","unoccupied_heating_setpoint":16}'

Traffic looked good too.

Edit 2:

For completeness, here is my original error I got on the first attempt after pairing:

ESC[31mZigbee2MQTT:errorESC[39m 2020-10-06 13:17:50: Publish 'set' 'occupied_heating_setpoint' to '0x00158d0001ffaffc' failed: 'Error: Write 0x00158d0001ffaffc/1 hvacThermostat({"occupiedHeatingSetpoint":200}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null}) failed (Status 'INVALID_VALUE')'
ESC[31mZigbee2MQTT:errorESC[39m 2020-10-06 13:17:50: Publish 'set' 'occupied_heating_setpoint' to '0x00158d0001ffaffc' failed: 'Error: Write 0x00158d0001ffaffc/1 hvacThermostat({"occupiedHeatingSetpoint":18000}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null}) failed (Status 'INVALID_VALUE')'

Which in my case made sense as 200 is below 10000 and 18000 is above 3000, but you're seem to be within range. I did switch to using mosquitto_pub vs using the frontend to change it though.

Edit 3:

The device does now seem to drop from the network which never happened before when i was using it.

Zigbee2MQTT:info  2020-10-06 13:36:31: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00158d0001ffaffc","ieee_address":"0x00158d0001ffaffc"},"type":"device_announce"}'
Zigbee2MQTT:info  2020-10-06 13:36:34: MQTT publish: topic 'zigbee2mqtt/0x00158d0001ffaffc', payload '{"current_heating_setpoint":20,"eurotronic_error_status":0,"eurotronic_host_flags":{"boost":false,"child_protection":true,"mirror_display":false,"window_open":false},"eurotronic_system_mode":129,"linkquality":70,"local_temperature":20,"occupied_heating_setpoint":20,"pi_heating_demand":100,"system_mode":"auto","unoccupied_heating_setpoint":20}'
Zigbee2MQTT:info  2020-10-06 13:36:37: MQTT publish: topic 'zigbee2mqtt/0x00158d0001ffaffc', payload '{"current_heating_setpoint":19,"eurotronic_error_status":0,"eurotronic_host_flags":{"boost":false,"child_protection":true,"mirror_display":false,"window_open":false},"eurotronic_system_mode":129,"linkquality":70,"local_temperature":22,"occupied_heating_setpoint":19,"pi_heating_demand":0,"system_mode":"auto","unoccupied_heating_setpoint":16}'

The reported value are also a bit odd after the device announcement. Would be nice to have other users chime in too.

[gielfeldt]

Thanks. I consistently get the INVALID_VALUE, almost instantaneously.

However, I'm facing other challenges now, which may or may not be related. After having paired that Spirit thermostat, I seem to be unable to pair devices anymore. It's like announcements are not even coming through?
All my existing paired devices still work fine though.

It's all very weird. I'll try to remove the thermostat again, and see if that does anything.

Side-note: It also seems to be pretty chatty for a battery powered device?

[TilmanK]

@gielfeldt: Yes, the batteries don't last a full year in mine. Nevertheless, the AA ones are easy to replace.

I just tried on one of mine and sent:

{"current_heating_setpoint" : 23}

Works flawlessly.

[sjorge]

Yeah I got around 6-8 months in mine.

[gielfeldt]

I've managed to get it to pair again. I had to unplug the coordinator, and then replug it. I used a different ub port this time, not sure if that matters. Everything pairs fine now. I have two of those thermostats, and they paired without problems.

However, I still consistently get the INVALID_VALUE error when trying to manipulate any of the two thermostats.

I'm probably giving up on these thermostats, or I'm trying out another zigbee stick, or ultimately perhaps a different hub.

What are you guys using? I'm currently using a Pi 4 + a CC2531 stick.

I have a CC2530 lying around, so I might try that one out to see if it makes any difference.

I've also read about the samsung smartthings hub and the homey hub being able to run zigbee+zwave to mqtt locally? That might be something I will try out, if I don't get this to work.

[sjorge]

I'm also using a CC2531, but your joining issue sounds familiar: #3177

[Brunes]

Hi guys,

it's interesting because my two new thermostats don't work either. The one I bought before the summer works and I can control it, today I received new and the same but it says failed (Status' INVALID_VALUE ')'

How can this be fixed?

[sjorge]

Does older and newer one have different firmware? Mines pretty told so maybe why it mostly works

[Brunes]

It's 1.15.0 both.

-> Old
"manufacturer":"Eurotronic","model":"Spirit Zigbee wireless heater thermostat (SPZB0001)","name":"Termostat1","sw_version":"Zigbee2MQTT 1.15.0"}

-> New
"manufacturer":"Eurotronic","model":"Spirit Zigbee wireless heater thermostat (SPZB0001)","name":"TermostatBH","sw_version":"Zigbee2MQTT 1.15.0"}

[gielfeldt]

Mine are brand new as well, so it could make sense that new ones don't work.

1.15.0 is the zigbee2mqtt version, isn't it?

Not sure if or where you can see the firmware version for the thermostats.

[gielfeldt]

My thermostats report the following I think

Hardware version is 35
Firmware version is 22190930

[sjorge]

My thermostats report the following I think

Hardware version is 35
Firmware version is 22190930

Yep this looks more correct than 1.15.0 which is indeed de zigbee2mqtt version, my mostly working (old) one is
Firmware: 22190930
Hardware: 3234

[gielfeldt]

Then the question is: How do we figure out the protocol difference between these two?

[sjorge]

Then the question is: How do we figure out the protocol difference between these two?

Last time someone who was fluent in German managed to get them to send over a implementation document, sadly he did not share it. I forgot who it was. But probably one of the first committers for this device.

[Brunes]

I think this is a serious problem. Can zigbee2mqtt developers fix it or thermostat developers? People usually buy this device because it is on the device support list.

[TilmanK]

I've got three of them and got a new one recently:

"appVersion":18,"stackVersion":5,"hwVersion":34,"dateCode":"20190408","swBuildId":"18181120",
"appVersion":22,"stackVersion":5,"hwVersion":35,"dateCode":"20191014","swBuildId":"22190930",
"appVersion":18,"stackVersion":5,"hwVersion":34,"dateCode":"20190408","swBuildId":"18181120"

And indeed, correcting my statement above, the second one does not react when trying to set current_heating_setpoint:

ERROR: Publish 'set' 'current_heating_setpoint' to 'Heizung Hobbykeller links' failed: 'Error: Write 0x00158d00053d4419/1 hvacThermostat({"16387":{"value":2300,"type":41}}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4151,"transactionSequenceNumber":null}) failed (Data request failed with error: 'Timeout' (9999))'
INFO: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'current_heating_setpoint' to 'Heizung Hobbykeller links' failed: 'Error: Write 0x00158d00053d4419/1 hvacThermostat({"16387":{"value":2300,"type":41}}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4151,"transactionSequenceNumber":null}) failed (Data request failed with error: 'Timeout' (9999))'","meta":{"friendly_name":"Heizung Hobbykeller links"},"type":"zigbee_publish_error"}'

Nevertheless, it reports its values correctly, so there is connection (not good, but it's there):
INFO: MQTT publish: topic 'zigbee2mqtt/Heizung Hobbykeller links', payload '{"last_seen":1602056788015,"linkquality":6,"unoccupied_heating_setpoint":16}'

I'll flash my Sniffer stick and see if I can find anything about it.

[sjorge]

In the past we also asked Eurotronics for firmware images which they refused to provided. So also no downgrading.

But based on the data here it looks like current models have a different hardware revision and firmware on them, capturing the traffic via a sniffer to/from both the old and new devices might indeed be useful.

[TilmanK]

In the past we also asked Eurotronics for firmware images which they refused to provided. So also no downgrading.

But based on the data here it looks like current models have a different hardware revision and firmware on them, capturing the traffic via a sniffer to/from both the old and new devices might indeed be useful.

Yeah, we'll see. Expect results in the afternoon, I hope I'll find the time then. :)

[gielfeldt]

@TilmanK

You do, however, get a different error than @Brunes and me. I hope though that the sniffing proves useful anyways.

[TilmanK]

@TilmanK

You do, however, get a different error than @Brunes and me. I hope though that the sniffing proves useful anyways.

I know. But it's highly suspicious that those commands fail reproducibly and others not. I haven't had a look at the debug logs though...

[TilmanK]

Ok, guys, so far I know the following:

I can't see any messages from Z2M to the device with sw 22190930. Neither setting the attribute current_heating_setpoint nor trying to read it produces a logged zigbee message. It works like a charm for the other device with sw 18181120.

I set the temperature manually on both devices and sniffed the Report Attributes message. The Zigbee payload is identical apart from sequence number and counter. So the device still reports a 16-bit integer value.

Here's the relevant zigbee debug output for the working device:

�[34mZigbee2MQTT:debug�[39m 2020-10-07 17:04:36: Received MQTT message on 'zigbee2mqtt/Heizung Hobbykeller rechts/set' with data '{"current_heating_setpoint":19}'
�[34mZigbee2MQTT:debug�[39m 2020-10-07 17:04:36: Publishing 'set' 'current_heating_setpoint' to 'Heizung Hobbykeller rechts'
�[38;5;220;1mzigbee-herdsman:controller:endpoint �[0mWrite 0x00158d000192392d/1 hvacThermostat({"16387":{"value":1900,"type":41}}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4151,"transactionSequenceNumber":null}) �[38;5;220m+17s�[0m
�[38;5;27;1mzigbee-herdsman:adapter:zStack:adapter �[0msendZclFrameToEndpointInternal 0x00158d000192392d:50047/1 (0,0,1) �[38;5;27m+17s�[0m
�[38;5;205;1mzigbee-herdsman:adapter:zStack:znp:SREQ �[0m--> AF - dataRequest - {"dstaddr":50047,"destendpoint":1,"srcendpoint":1,"clusterid":513,"transid":3,"options":0,"radius":30,"len":10,"data":{"type":"Buffer","data":[20,55,16,4,2,3,64,41,108,7]}} �[38;5;205m+17s�[0m
�[38;5;33;1mzigbee-herdsman:adapter:zStack:unpi:writer �[0m--> frame [254,20,36,1,127,195,1,1,1,2,3,0,30,10,20,55,16,4,2,3,64,41,108,7,173] �[38;5;33m+17s�[0m

�[38;5;169;1mzigbee-herdsman:adapter:zStack:znp:AREQ �[0m<-- AF - incomingMsg - {"groupid":0,"clusterid":513,"srcaddr":50047,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":84,"securityuse":0,"timestamp":6847669,"transseqnumber":0,"len":6,"data":{"type":"Buffer","data":[28,55,16,4,4,0]}} �[38;5;169m+19ms�[0m
�[38;5;161;1mzigbee-herdsman:controller:log �[0mReceived 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":0,"manufacturerSpecific":true,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"transactionSequenceNumber":4,"manufacturerCode":4151,"commandIdentifier":4},"Payload":[{"status":0}]},"address":50047,"endpoint":1,"linkquality":84,"groupID":0}' �[38;5;161m+20s�[0m

�[38;5;169;1mzigbee-herdsman:adapter:zStack:znp:AREQ �[0m<-- AF - incomingMsg - {"groupid":0,"clusterid":513,"srcaddr":50047,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":84,"securityuse":0,"timestamp":6893332,"transseqnumber":0,"len":10,"data":{"type":"Buffer","data":[28,55,16,252,10,3,64,41,108,7]}} �[38;5;169m+731ms�[0m
�[38;5;161;1mzigbee-herdsman:controller:log �[0mReceived 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":0,"manufacturerSpecific":true,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"transactionSequenceNumber":252,"manufacturerCode":4151,"commandIdentifier":10},"Payload":[{"attrId":16387,"dataType":41,"attrData":1900}]},"address":50047,"endpoint":1,"linkquality":84,"groupID":0}' �[38;5;161m+731ms�[0m
�[34mZigbee2MQTT:debug�[39m 2020-10-07 17:04:40: Received Zigbee message from 'Heizung Hobbykeller rechts', type 'attributeReport', cluster 'hvacThermostat', data '{"16387":1900}' from endpoint 1 with groupID

Here's the one for the not working device:

�[34mZigbee2MQTT:debug�[39m 2020-10-07 17:05:27: Received MQTT message on 'zigbee2mqtt/Heizung Hobbykeller links/set' with data '{"current_heating_setpoint":19}'
�[34mZigbee2MQTT:debug�[39m 2020-10-07 17:05:27: Publishing 'set' 'current_heating_setpoint' to 'Heizung Hobbykeller links'
�[38;5;220;1mzigbee-herdsman:controller:endpoint �[0mWrite 0x00158d00053d4419/1 hvacThermostat({"16387":{"value":1900,"type":41}}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4151,"transactionSequenceNumber":null}) �[38;5;220m+6s�[0m
�[38;5;27;1mzigbee-herdsman:adapter:zStack:adapter �[0msendZclFrameToEndpointInternal 0x00158d00053d4419:39154/1 (0,0,1) �[38;5;27m+6s�[0m
�[38;5;205;1mzigbee-herdsman:adapter:zStack:znp:SREQ �[0m--> AF - dataRequest - {"dstaddr":39154,"destendpoint":1,"srcendpoint":1,"clusterid":513,"transid":6,"options":0,"radius":30,"len":10,"data":{"type":"Buffer","data":[20,55,16,6,2,3,64,41,108,7]}} �[38;5;205m+6s�[0m
�[38;5;33;1mzigbee-herdsman:adapter:zStack:unpi:writer �[0m--> frame [254,20,36,1,242,152,1,1,1,2,6,0,30,10,20,55,16,6,2,3,64,41,108,7,124] �[38;5;33m+6s�[0m
�[38;5;93;1mzigbee-herdsman:adapter:zStack:unpi:parser �[0m<-- [254,1,100,1,0,100] �[38;5;93m+6s�[0m
�[38;5;93;1mzigbee-herdsman:adapter:zStack:unpi:parser �[0m--- parseNext [254,1,100,1,0,100] �[38;5;93m+1ms�[0m
�[38;5;93;1mzigbee-herdsman:adapter:zStack:unpi:parser �[0m--> parsed 1 - 3 - 4 - 1 - [0] - 100 �[38;5;93m+0ms�[0m
�[38;5;56;1mzigbee-herdsman:adapter:zStack:znp:SRSP �[0m<-- AF - dataRequest - {"status":0} �[38;5;56m+6s�[0m
�[38;5;93;1mzigbee-herdsman:adapter:zStack:unpi:parser �[0m--- parseNext [] �[38;5;93m+0ms�[0m
�[38;5;27;1mzigbee-herdsman:adapter:zStack:adapter �[0mData confirm error (0x00158d00053d4419:39154,9999,0) �[38;5;27m+10s�[0m
�[38;5;220;1mzigbee-herdsman:controller:endpoint �[0mWrite 0x00158d00053d4419/1 hvacThermostat({"16387":{"value":1900,"type":41}}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4151,"transactionSequenceNumber":null}) failed (Data request failed with error: 'Timeout' (9999)) �[38;5;220m+1m�[0m
�[31mZigbee2MQTT:error�[39m 2020-10-07 17:05:37: Publish 'set' 'current_heating_setpoint' to 'Heizung Hobbykeller links' failed: 'Error: Write 0x00158d00053d4419/1 hvacThermostat({"16387":{"value":1900,"type":41}}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4151,"transactionSequenceNumber":null}) failed (Data request failed with error: 'Timeout' (9999))'
�[34mZigbee2MQTT:debug�[39m 2020-10-07 17:05:37: Error: Write 0x00158d00053d4419/1 hvacThermostat({"16387":{"value":1900,"type":41}}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4151,"transactionSequenceNumber":null}) failed (Data request failed with error: 'Timeout' (9999))
at ZStackAdapter. (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:319:27)
at Generator.next ()
at fulfilled (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:24:58)

I'll try to rejoin the device not working to see if something changes. Another difference in my setup is, that I use a CC26X2R1. Just for the record.

[TilmanK]

I rejoined the device several times. I got it working now. This doesn't make sense at all...

I have absolutely no clue.

[gielfeldt]

Can anybody recommend another zigbee radiator thermostat that I can use instead of these?

[sjorge]

Can anybody recommend another zigbee radiator thermostat that I can use instead of these?

I'm still looking my self, I have the eurotronic, viessmann, schnieder eletronic and tuya one. I'm not really satisfied of any of them.

viessmann is currently the best hardware wise, but the firmware is problematic. tuya worked but does the weird tuya stuff, the se one never really worked well for me.

[gielfeldt]

Perhaps the thermostat market is better/more mature on z-wave?

[TilmanK]

Then the question is: How do we figure out the protocol difference between these two?

Last time someone who was fluent in German managed to get them to send over a implementation document, sadly he did not share it. I forgot who it was. But probably one of the first committers for this device.

Is someone of you able to sniff the Zigbee traffic for this error? I'll be happy to contact them in German for you to see if they can help.

[TilmanK]

@sjorge, @gielfeldt @Brunes I fixed the problem that the thermostat is not reacting by rejoining it. I had problems when doing this in one software lifecycle. You might therefore want to try the following:

1. Remove the device (force remove if necessary).
2. Restart Z2M
3. Reset the device, pass the interview and then CONFIRM that it was correctly configured.

I had failures in configuration all the time and once the configuration was successful, I could reach the device as expected.

[pumuugel82]

Might be a problem with openhab or Domoticz. The sibling project "zigbee-herdsman-convertes" has a file "devices.js" where in line 10690-10692 the Spirit gets built with the correct setpoint namely "occupied_heating_setpoint". From this point of view it is very unlikely that zigbee2mqtt does anything wrong.

exposes: [e.battery(), exposes.climate().withSetpoint('occupied_heating_setpoint', 5, 30, 0.5).withLocalTemperature()
            .withSystemMode(['off', 'auto', 'heat']).withRunningState(['idle', 'heat']).withLocalTemperatureCalibration()
            .withPiHeatingDemand()],

The UI to zigbee2mqtt presents exactly those properties in the same order + linkquality.

[pumuugel82]

I've got another problem with these Spirit TRVs. Now that I run HA Supervised with RaspBee from Dresden-Elektornik instead of CC2531 USB Stick with antanna... it can't even pair anymore. But this brings me to the conclusion that it might be more a problem with the adapter (RaspBee) than with the Spirit itself.

#Koenkk/zigbee-herdsman-converters#2263

Edit: I have to mention that exactly the same TRV was able to join the zigbee network when I used the Z-Stack CC2531 chip. Nothing else changed.

[aaamoeder]

Damn, just bought some of there thermostats since they were on the supported devices page only to find that they don't work 😞
Somehow I seem to be able to set the desired temperature sometimes, but do not get the actual value back into HA..
Still hoping one of you smart people figures out how to get this working since they weren't cheap and I promised the missus the bedrooms would now never be cold again 😆 ..

[kisseler]

I also struggled with the new version of the Eurotronic Spirit Zigbee for a couple days, but I found a solution that works for me: you don't set the 'zigbee2mqtt/friendly_name/set/current_heating_setpoint but instead you set the 'zigbee2mqtt/friendly_name/set/occupied_heating_setpoint!

Thanks @awalsum , that did the trick. New version now works with zigbee2mqtt.

[prankousky]

I received this thermostat yesterday. What can I say? It works perfectly.

What I consider to be upsides:

• easily lockable (afaik, you can lock the Eurotronic as well, but the feature is not automatically discovered by Home Assistant)
• much more information about the device available (again: in Home Assistant; many more things are discovered by the auto discover feature)

and downsides:

• had to order from China; shipping to Germany was decent (~ 3 weeks, including the first shipment being sorted out, so ideally they'll be able to ship in ~ 2 weeks if things go well)
• costs about €30; this means, if you don't want to pay import taxes, you have to order one device at the time (or be lucky and have your entire order for your house not caught by customs)

If these were available on amazon Germany, I'd replace all my Eurotronic devices and hope to get some of my money back by putting the Eurotronic ones on eBay.

Then again!!! When I first started with the Eurotronic devices, they worked fine, too. I guess time will tell whether or not these ones are future proof and will work equally well after a couple of updates. If they turn out to do so, I will stick with these in future zigbee device shopping sprees - and never touch anything by Eurotronic again, as I am really disappointed by the way they are handling this.

[pumuugel82]

@prankousky what is the Version and date of the Firmware? Those with older firmware work very well.

[prankousky]

@pumuugel82 same here. The older ones work fine (almost all of the time). But unfortunately I also own some devices running on the newer firmware, that won't accept the off command any longer.

My regular routine is if window opens, turn off climate entity // if window is shut, turn on climate entity. Now I have to manually set temperature to 5°C (which is equivalent to off), which is okay. But I also need to save the temperature before setting it to 5 so that I can restore it when the window state changes to shut. Previously, there was no need for this, as the temperature value would not change at all (climate off kept the temperature, but still turned the climate entity off).

[hackex]

I received this thermostat yesterday. What can I say? It works perfectly.

What I consider to be upsides:

* **easily** lockable (afaik, you can lock the Eurotronic as well, but the feature is not automatically discovered by Home Assistant)

* **much** more information about the device available (again: in Home Assistant; many more things are discovered by the auto discover feature)

and downsides:

* had to order from China; shipping to Germany was decent (~ 3 weeks, including the first shipment being sorted out, so ideally they'll be able to ship in ~ 2 weeks if things go well)

* costs about €30; this means, if you don't want to pay import taxes, you have to order **one device at the time** (or be lucky and have your entire order for your house _not_ caught by customs)

If these were available on amazon Germany, I'd replace all my Eurotronic devices and hope to get some of my money back by putting the Eurotronic ones on eBay.

Then again!!! When I first started with the Eurotronic devices, they worked fine, too. I guess time will tell whether or not these ones are future proof and will work equally well after a couple of updates. If they turn out to do so, I will stick with these in future zigbee device shopping sprees - and never touch anything by Eurotronic again, as I am really disappointed by the way they are handling this.

Hey,
I hope you will not be disappointed with the old Tuya TVRs. If you know some German, I wrote a blog about several ZigBee TVRs and compared their heating behaviour, usability and general reliability.
You can find it here: https://www.enercover.de/smarthome-thermostate/

[drdownload]

Has anybody managed to update (more downgrade) the firmware of the spirit with the provided OTA file?

[awalsum]

No, I tried a few days ago but still not updating. It isn't really bothering me anymore though as I changed the python script and it works now.

Search for all instances of current_heating_setpoint and change it to occupied_heating_setpoint.

[drdownload]

I've got 1 that works, 1 that sometime works and 3 that dont update at all (no matter what command I use) So I would really appreaciate to get them fixed.

[pfischbach]

There is a update available for the Thermostat with the Date code 20190408
https://github.com/EUROTRONIC-Technology/Spirit-ZigBee/releases/download/20190408/20190408_EUROTRONIC_Spirit_Zigbee_0x00122C380.ota

I am not sure how to start the Zigbee2mqtt OTA process with this URL or from a local folder
using Home Assistant with the Edge Plugin and Web Interface
Would like to apply the update.
Any experience ?

[kovaga]

Just noticed that I am no longer able to change the system mode (off, heat, auto)
it is also not possible to update any of the following flags "boost", "child_protection", "mirror_display", "window_open".

Previously it was working fine. At the moment I can only change the temperature.

Is it the same for you guys as well?

[mb2993]

Just noticed that I am no longer able to change the system mode (off, heat, auto)
it is also not possible to update any of the following flags "boost", "child_protection", "mirror_display", "window_open".

Previously it was working fine. At the moment I can only change the temperature.

Is it the same for you guys as well?

Hi, Yes I am following this thread for the exact same reason.

[awalsum]

Mine did work, after changing the script to "occupied_heating_setpoint", but not anymore. I get an error when trying to change the setpoint. I get an invalid value response.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[mb2993]

Please keep this thread open since the issue is still unresolved.

[kaykoch]

I have thermostats with both firmware. Both stops sending full information.
Using "unoccupied_heating_setpoint" instead of "current_heating_setpoint" is correct.
But this is something different and belongs to z2m Update.
Zigbee2mqtt Current version: 1.18.2-1 (Home Assistant Add-on)

PAST (Maybe Version 1.17 or 1.18.1 )

    "0x00158d00019XXXXX": {
        "eurotronic_host_flags": {
            "mirror_display": false,
            "boost": false,
            "window_open": false,
            "child_protection": false
        },
        "system_mode": "auto",
        "occupied_heating_setpoint": 19,
        "unoccupied_heating_setpoint": 16,
        "update_available": false,
        "update": {
            "state": "idle"
        },
        "pi_heating_demand": 99,
        "local_temperature": 16.99,
        "battery": 65
    },

NOW

    "0x00158d00019XXXXX": {
      "battery": 55,
      "linkquality": 102,
      "pi_heating_demand": 71,
      "update": {
          "state": "idle"
      },
      "update_available": false
  }

This you can see after:

• stopping z2m
• deleting states.json
• starting z2m

system_mode

setting system_mode by mqtt:

"off" -> zigbee2mqtt/schlafzimmer_heizung/set/system_mode

• sets the display to "OFF"
• set "spi_heating_demand" to 0 (zero)

"auto" -> zigbee2mqtt/schlafzimmer_heizung/set/system_mode

• sets the display to "occupied_heating_setpoint"
• sets "spi_heating_demand" to nessesary value

BUT NO system_mode Information were send back from device:

In Homeassistant you can see in Log (Core) after deleting states.json:
2021-04-30 10:39:50 ERROR (MainThread) [homeassistant.components.mqtt.climate] Invalid modes mode:
This is, because 'system_mode' is not send anymore. If you add '"system_mode":"auto" ' or '..:"off"' manually in states.json, error is gone.

Maybe related to:
#6995
@Koenkk:
could you confirm this changed behavior?

[stizzlestizzle]

An information for all fellow sufferers: After contacting Eurotronic support, they kindly replaced my devices with the faulty firmware version with new devices running on firmware 20190408.

[pannal]

I've just got two of these from Amazon.

I'm running 1.18.3 and just tried installing one of the SPZB0001. It seems to work but shows a lot of weird behaviour, such as battery value is always null, local_temperature jumps around from -150 °C to the actual value (about 23°C),

{"battery":null,"eurotronic_trv_mode":null,"eurotronic_valve_position":null,"linkquality":114,"local_temperature":-156.14,"occupied_heating_setpoint":23,"pi_heating_demand":0,"unoccupied_heating_setpoint":16,"update":{"state":"idle"},"update_available":false}

Getting running_state returns an error:

Publish 'get' 'running_state' to 'HeizungOben' failed: 'Error: Read 0x00158d0001922d5a/1 hvacThermostat(["runningState"], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')'

Current state:

{
    "linkquality": 114,
    "local_temperature": 24.08,
    "occupied_heating_setpoint": 23,
    "pi_heating_demand": 100,
    "unoccupied_heating_setpoint": 16,
    "update": {
        "state": "idle"
    },
    "update_available": false,
    "battery": null,
    "eurotronic_trv_mode": null,
    "eurotronic_valve_position": null
}

Device Info:

Firmware build date
20190408
Firmware version
18181120
Vendor
Eurotronic
Model
SPZB0001

Should I send it back?

My second one looks like this:

{
    "battery": null,
    "eurotronic_trv_mode": null,
    "eurotronic_valve_position": null,
    "linkquality": 93,
    "local_temperature": 24.8,
    "occupied_heating_setpoint": 21,
    "pi_heating_demand": 97,
    "update": {
        "state": "idle"
    },
    "update_available": false
}

Device Info:

Firmware build date
20190408
Firmware version
00000000
Vendor
Eurotronic
Model
SPZB0001

Edit: The first one just started reporting its battery level. No changes from my end. Setting target temperature works for both of them right now, but that's about it. The second one constantly showed a pi target value of 97, which only vanished once I force-re-paired it.

Edit 2: Both are set to legacy: false
Edit 3: I think the docs are a little misleading. What does this actually mean? legacy: Set to false to disable the legacy integration (highly recommended!) (default: true) - That the legacy integration is highly recommended, or that disabling it is?
Edit 4: The second one just started sending battery info.

[kaykoch]

@stizzlestizzle

An information for all fellow sufferers: After contacting Eurotronic support, they kindly replaced my devices with the faulty firmware version with new devices running on firmware 20190408.

Could You please show the Current state of the new ones.
Please delete states.json entry of the thermostat first. (stop z2m, delete entry in states.json, start z2m)
AND:
what's the problem with the firmware?
I have two ones with 18181120 and two with 22190930.
None of them sends "system_modes". Only one of the 22190930 sends "battery".
I think this is not (only) a firmware problem.

As long, as I don't know the exactly Problem, I won't complain about it at eurotronic. Maybee someone could explain this behaviour. And why it started in 2021.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days