[Device Support Request] Eurotronic Spirit ZigBee

[micha91]

Hi,

I just bought this thermostat device (on a random guess) to move away from other wireless protocols. I would love to see support for it in deCONZ. At the moment there is nearly no documentation for this device, but at least some clusters are recognised and it is possible to set the desired temperature using the attribute in the cluster. Node Info Basic Cluster: Power Configuration: Thermostat:

Thank you very much in advance

Michael

[hna1066]

The Eurotronic Spirit is inadequate and buggy implemented in Deconz. After many attempts, I succeeded in displaying the Eurotronic Spirit in the Deconz app. I can read all Cluster Info and everything that is displayed as R / W can also be written. To recognize the Eurotronic Spirit you have to call the Phoscon app, here the Eurotronic Spirit is recognized, but not displayed, the app is definitely just able to control lights. So in the deConz IN-Node in Node Red I can read temperature and status, in the OUT node, if I select "Phoscon" as server, nothing is displayed. The Eurotronic Spirit is therefore very poorly integrated by Dresden Electronics. Does anyone have an idea how I can not only read but also control the Eurotronic Spirit via Node Red?

[SkaveRat]

Have you followed the steps in #1098 (comment)?

The following process worked for me on a headless raspbian setup:

• save phoscon config (backup)
• enable boot to gui via raspi-config
• setup/install VNC
• reboot
• systemctl stop deconz and systemctl start deconz-gui
• start VNC and open deconz
• open phoscon and reload the back upped config
• reset thermostat (should display Jin)
• search for sensors in phoscon
• in deconz open the basic cluster of the thermostat and click read
• verify that the pairing was succesful in phoscon
• backup phoscon config
• quit VNC server
• systemctl stop deconz-gui and systemctl start deconz
• open phoscon and load config from backup file

I don't remember if it was really necessary to backup and load the phoscon config but a backup probably doesn't hurt either.

Took me a couple tries, but using the backup method worked for me. The main issue was, that it's aparently not possible to set a name to the thermostat node. after reading the basic data, it had a generic name and it seemed to work.

[Niogui]

Took me a couple tries, but using the backup method worked for me. The main issue was, that it's aparently not possible to set a name to the thermostat node. after reading the basic data, it had a generic name and it seemed to work.

You can change the name of the thermostat using the rest API. To do so, you can either use a REST Client (like Postman App or Tabbed Postman Chrome extension) or a command line tool like cURL. Just have a look at REST API documentation http://dresden-elektronik.github.io/deconz-rest-doc/getting_started/ everything is well explained there. Once you have your API key, get a list of all sensors by running a GET request to /api//sensors. From the response read your thermostat id. Then run a PUT request to /api//sensors/ with the the following data { "name" : "Custom Name" }. The cURL command would be something like this: curl -X PUT -H "Content-Type: application/json" -d '{"name":"Custom name"}' http://localhost:8080/api/01234abc56/sensors/4

[choss38]

Hi,

rkotulan wrote:

If you succeed you should see in HA in integration = deCONZ

and I can see HA recognize a sensor.thermostat and a climate.thermostat.

On my own It said that the sensor.thermostat is unavailable:

Have you an idea of the problem ?

[Smanar]

Hello, I have a random bug with device. I set it off and auto repeatedly with API using just

{'mode': 'off'} {'mode': 'auto'}

It works for some time, but after a moment the heatpoint in auto stay at 500, it seem the device forget the previous value.

[ebaauw]

I've seen the same, especially when switching from off to on (boost mode) or vice versa. It seems to be a "feature" of the Spirit firmware. Mode off seems to be related to the half implemented window open detection.

I only set the heatpoint from my automation and leave the mode to auto.

[Smanar]

Ok, thx, so I will try with sending my own heatpoint in same time than the auto parameter > {'mode': 'auto', 'heatsetpoint':2200 }

[donchrizz]

Hey guys,

if anybody wants a spirit zigbee thermostat - i have 3 to sell:

https://www.ebay-kleinanzeigen.de/s-anzeige/eurotronic-spirit-zigbee-thermostat/1249146122-84-9062

feel free to contact me there...

[FlyingPersian]

Have you followed the steps in #1098 (comment)?

The following process worked for me on a headless raspbian setup:

• save phoscon config (backup)
• enable boot to gui via raspi-config
• setup/install VNC
• reboot
• systemctl stop deconz and systemctl start deconz-gui
• start VNC and open deconz
• open phoscon and reload the back upped config
• reset thermostat (should display Jin)
• search for sensors in phoscon
• in deconz open the basic cluster of the thermostat and click read
• verify that the pairing was succesful in phoscon
• backup phoscon config
• quit VNC server
• systemctl stop deconz-gui and systemctl start deconz
• open phoscon and load config from backup file

I don't remember if it was really necessary to backup and load the phoscon config but a backup probably doesn't hurt either.

My Spirit isn't connecting to deConz. I'm runing Home Assistant on a RPI 2. I installed the deConz addon, added and integrated it in HA, connected to deConz via VNC and setup the Phoscon App. When I go to "add sensors" in the Phoscon App, it searches, but the Spirit doesn't connect. It just says "Jin", but nothing happens. The only thing I see in deConz is the blue default thingy that says "Coordinator" when you click it. Did I miss a step?

As @ebaauw said in the following post, do I need to add a lamp before I can add my thermostat? https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1442#issuecomment-484840592

Edit: alright, so I did some reading. The thermostat is an end-device, so does it need a router to connect to? I thought I could connect the thermostat directly to the RaspBee..

[ebaauw]

I thought I could connect the thermostat directly to the RaspBee.

The RaspBee (or any ZigBee coordinator) is a router alright; you should be able to connect the Spirit to it. Note that a router only allows a limited number of connected end devices - not sure what the current limit for the RaspBee is: 10 or 16 or something. For more end devices, you need additional routers.

[FlyingPersian]

I thought I could connect the thermostat directly to the RaspBee.

The RaspBee (or any ZigBee coordinator) is a router alright; you should be able to connect the Spirit to it. Note that a router only allows a limited number of connected end devices - not sure what the current limit for the RaspBee is: 10 or 16 or something. For more end devices, you need additional routers.

I don't have any devices connected, I got everything today and set it up completely freshly. Any idea why my Spirit isn't connecting to the RaspBee then?

[ebaauw]

Most likely bad radio signal. How far is distance between the thermostat and the RaspBee? Try and wire the Raspberry to the network, and disable WiFi and Bluetooth. Best search for devices from Phoscon, then insert the battery in the Spirit. Maybe reset the Spirit by pressing/holding all three buttons simultaneously (it starts counting down after a few seconds).

[FlyingPersian]

Most likely bad radio signal. How far is distance between the thermostat and the RaspBee? Try and wire the Raspberry to the network, and disable WiFi and Bluetooth. Best search for devices from Phoscon, then insert the battery in the Spirit. Maybe reset the Spirit by pressing/holding all three buttons simultaneously (it starts counting down after a few seconds).

I'll be damned! 2h I was playing around with this crap! I was sitting away 2m from it and I didn't think the signal would be the issue! It's connected!

[ebaauw]

ZigBee uses the 2.4GHz band, as does WiFi, bluetooth, DECT, a microwave oven, etc. Try switching to ZigBee channel 25 - that has least overlap with WiFi. Beware of metal in walls, furniture, lamp enclosures, ...

[FlyingPersian]

Done, thanks! I can't get the Spirit to show up in HA though. I already read the basic, power and thermal data in deConz, but in HA deConz only shows "Phillips Daylight" and "Phoscon-GW" (the Gateway). I added deConz automatically using discovery. From what I read here, the Spirit shows up automatically in HA..

[ebaauw]

Did you restart HA after pairing the Spirit? Did you double-check that the REST API exposes the Spirit (if the name in the GUI changed from the network address it does).

[FlyingPersian]

Did you restart HA after pairing the Spirit? Did you double-check that the REST API exposes the Spirit (if the name in the GUI changed from the network address it does).

I did restart, but I don't think the REST API exposes the Spirit. Can you post a pic which name in the network address you mean exactly? Just to be sure

[ebaauw]

The blue node for the RaspBee shows the NWK address (0x0000); the grey node for the Spirit shows the name of the REST API /sensors resource (I did change it after pairing, it probably shows Thermostat 2 or something).

[FlyingPersian]

The blue node for the RaspBee shows the NWK address (0x0000); the grey node for the Spirit shows the name of the REST API /sensors resource (I did change it after pairing, it probably shows Thermostat 2 or something).

Hm no, it still shows 0x9348. When I change it manually in the Node Info the left "LED" blinks red, and on the bottom left it says "sending user descriptor set request", but nothing happens. How do I make it expose the REST API?

Alright I got it! I had to do a sensor search in the Phoscon App and then re-read the basic data.

[FlyingPersian]

My Spirit isn't reading out the correct temperature. I re-installed it to a different radiator and even though the radiator is just slightly warm, the Spirit shows 31°C. It's not even close to that. It's been an hour now and the temperature still hasn't changed. Any ideas? Not sure using the offset is the proper way to handle this. Also, the temperature was shown correctly before on the other radiator.

[ebaauw]

Not sure using the offset is the proper way to handle this.

That's what the offset is for, I suppose.

It's been an hour now and the temperature still hasn't changed.

Make sure that attribute reporting has been setup correctly. If not, deCONZ will continue to show the old temperature. Press Read on the Thermostat cluster attributes to check whether the value has changed.

[Smanar]

I have new strange log

2019-11-08 18:47:51.563 Status: (deconz) Thermostat debug : {'config': {'heatsetpoint': 2100, 'reachable': True, 'mode': 'off', 'on': True, 'battery': 100, 'offset': 0}, 'id': '85', 't': 'event', 'e': 'changed', 'r': 'sensors', 'uniqueid': '00:15:8d:00:01:92:3b:6c-01-0201'} 2019-11-08 18:49:39.847 Status: (deconz) Thermostat debug : {'uniqueid': '00:15:8d:00:01:92:3b:6c-01-0201', 'id': '85', 't': 'event', 'state': {'on': True, 'valve': 24, 'lastupdated': '2019-11-08T17:49:39', 'temperature': 2105}, 'r': 'sensors', 'e': 'changed'} 2019-11-08 18:49:39.900 Status: (deconz) Thermostat debug : {'uniqueid': '00:15:8d:00:01:92:3b:6c-01-0201', 'id': '85', 't': 'event', 'state': {'on': True, 'valve': 24, 'lastupdated': '2019-11-08T17:49:39', 'temperature': 2105}, 'r': 'sensors', 'e': 'changed'}

The device send "off" mode, but it still have the valve open and on = true.

[saintger]

I have read the entire thread but I am not sure how to read the current valve position (I would like to check that the valve is working correctly). If I set the TRV mode to "Unknown 2", it seems that the valve display shows the opening percentage ? Is it possible to get this value directly ? Thanks

[airens]

@ebaauw, is it possible to set "Max heat setpoint limit" for this thermostat to at least 40deg by default? You know, in Russia 30deg is not enought.. I can set it manually via VNC, but in Home Assistant I still have limit at 30.

[ebaauw]

The Spirit supports target temperatures from 5°C to 30°C. That’s also the range you can set using its physical buttons. The REST API plugin enforces this range: https://github.com/dresden-elektronik/deconz-rest-plugin/blob/8bd724cef41aba17536acacb486355d0080e9ee2/resource.cpp#L225 The API doesn’t expose the range, so it’s probably hard code in the HA plugin/binding for deCONZ. I’ve hard-coded it in homebridge-hue.

I can set it manually via VNC

The Spirit seems to have its own twist of the ZigBee standard: it uses a manufacturer specific attribute for the setpoint: Current Temperature Setpoint, 0x4003. While it seems to accept setting the standard Occupied Heating Setpoint, 0x0012, it (sometimes) doesn’t honour this. Same for the standard Setpoint Raise/Lower command. Morale: be sure to read Current Temperature Setpoint to check that the Spirit has actually accepted the value.

Note that the supported setpoint range is exposed by the Spirit itself, in attributes 0x0015 and 0x0016.

[airens]

The Spirit supports target temperatures from 5°C to 30°C. That’s also the range you can set using its physical buttons. The REST API plugin enforces this range: https://github.com/dresden-elektronik/deconz-rest-plugin/blob/8bd724cef41aba17536acacb486355d0080e9ee2/resource.cpp#L225

The API doesn’t expose the range, so it’s probably hard code in the HA plugin/binding for deCONZ. I’ve hard-coded it in homebridge-hue.

I can set it manually via VNC

The Spirit seems to have its own twist of the ZigBee standard: it uses a manufacturer specific attribute for the setpoint: Current Temperature Setpoint, 0x4003. While it seems to accept setting the standard Occupied Heating Setpoint, 0x0012, it (sometimes) doesn’t honour this. Same for the standard Setpoint Raise/Lower command. Morale: be sure to read Current Temperature Setpoint to check that the Spirit has actually accepted the value.

Note that the supported setpoint range is exposed by the Spirit itself, in attributes 0x0015 and 0x0016.

Ok, looks like using "Local Temperature Calibration" is the only way to make my radiators warmer. I set it via VNC and it's working for now. Hope the device will not reset this value by itself

[ebaauw]

Only when you would reset the device (holding all three buttons for 10 seconds). Note that this calibration is exposed as config.offset by the REST API. It's intended for when the on-device thermometer registers the wrong room temperature, typically because it's too close to the radiator.

Unfortunately, we haven't been able to bind the Spirit to an external thermometer, even though the documentation and the Remote Sensing attribute (0x000a) suggest it would support that.

[ottelo9]

Hi there. Short question: Whats the status of the implementation? I would like to buy some of these Eurotronic Spirit. I use Deconz+Home Assistant.

[airens]

Hi there. Short question: Whats the status of the implementation? I would like to buy some of these Eurotronic Spirit. I use Deconz+Home Assistant.

Hello, pairing a little bit tricky, but in this topic you can find the working method. Things, that are working in Home Assistant:

• Controlling of set temperature in range 7-30degC
• Reading current radiator temperature, valve position and battery

Things, that does not work:

• Manual control of valve
• Remote sensing of temperature
• Calibration of the current radiator temperature (can be done via VNC)

As for me - great device for its price.

[ottelo9]

@airens Thanks for the fast answer. Ok now I just have to look for good offers.

[saintger]

@airens How exactly do you read the valve position ? I have not been able to find the correct attribute.

For the remote sensing of temperature, another hack used by people with the Z-wave version is to use the 'Measured Temperature Offset' to regularly compensate for the difference between the valve internal temperature sensor and the external temperature sensor: https://community.home-assistant.io/t/eurotronic-spirit-z-wave-external-temperature-sensor/88430/6

But I don't know if we can modify the 'Measured Temperature Offset' with the Zigbee version ?

[airens]

@airens How exactly do you read the valve position ? I have not been able to find the correct attribute.

For the remote sensing of temperature, another hack used by people with the Z-wave version is to use the 'Measured Temperature Offset' to regularly compensate for the difference between the valve internal temperature sensor and the external temperature sensor: https://community.home-assistant.io/t/eurotronic-spirit-z-wave-external-temperature-sensor/88430/6

But I don't know if we can modify the 'Measured Temperature Offset' with the Zigbee version ?

Yes, we can change Measured Temperature Offset by setting "Local Temperature Calibration" attruibute. You can see it as "offset" in HA, but, unfortunatelly, change it you can only via REST or VNC

[saintger]

state.valve is the value of 'PI Heating Demand' ? And this is supposed to be a percentage of the opening ? (i.e between 0-100%) ? For me it seems that the value of 'PI Heating Demand' is not same at all as the value displayed on the valve when I set the TRV mode to "Unknown 2". I'll have to check again.

To modify the "offset" in HA, is that a problem that we can only modify it though REST ? I'll have to play with HA and see if I can adapt the script use by the people using the Z-wave version.

[airens]

state.valve is the value of 'PI Heating Demand' ? And this is supposed to be a percentage of the opening ? (i.e between 0-100%) ?

Yes, it is. it's 0-254, so, you need to map it to 0-100

To modify the "offset" in HA, is that a problem that we can only modify it though REST ? I'll have to play with HA and see if I can adapt the script use by the people using the Z-wave version.

It's not a problem, but I don't think it's a good idea, because of battery life (in that case valve has been moved too frequently and amount of ZigBee packets drastically increases). I've done that firstly, but later on had to drop this. Now, I just use the simple automation in NodeRed, which changes set temperature of thermostat depending on the room temperature

[ebaauw]

How exactly do you read the valve position ?

The spirit reports it as PI Heating Demand (attribute 0x0008). It’s an u8 value, between 0 and 254. The API exposes this as state.valve, normalised to 0-100%.

For me it seems that the value of 'PI Heating Demand' is not same at all as the value displayed on the valve when I set the TRV mode to "Unknown 2".

The Spirit uses manufacturer-specific attributes (in the 0x4000 range) for settings, in particular 0x4001 to set the valve position manually. This attribute is not reportable, so I’d assume it only represents the target valve position. I would expect/hope to continue to see the current valve position in 0x0008, but maybe that’s updated only when the Spirit is in (default) automatic mode. You might want to check if the display reflects 0x4001 in mode Unknown 2.

[airens]

How exactly do you read the valve position ?

The spirit reports it as PI Heating Demand (attribute 0x0008). It’s an u8 value, between 0 and 254. The API exposes this as state.valve, normalised to 0-100%.

It's not normalized, actually, because it's value reaching 254, so I normalized it myself.

[ebaauw]

My bad, sorry. Indeed, I do the normalisation in homebridge-hue as well.

[BeamMeUpTo]

I added 4 Spirit ZigBee devices, yesterday. (With the new deCONZ 2_05_71) In spite of the really annoying sensor search procedure - I manged to get them to work with rest-api and fhem. I noticed that every time I connected a new SpiritZig Bee deCONZ shows for a really short time a Device Name with (I think!) that is like "Thermostat + the sensor ID". But while reading the basic cluster it gets overridden by SPZ0001 for each Device! So after each pairing I had to start sqlitebrowser to get rid of 4 times the name...

Does this only effect me?

[FlyingPersian]

Hello,

How can I reconnect the Spirit to my ZigBee Router when the router reboots? They're not connected atm, and I'm not sure how I can achieve that. Would rebooting the Spirit by taking out the battery help or will it be reset?

[ebaauw]

Taking out and re-inserting the battery usually works. Sometimes I need to open the network while doing that.

There's something funky with the Spirit. It doesn't recognise when it's kicked out by its parent. Consequently it won't find a new parent. It will continue to send attribute reports through its former parent, but it becomes unresponsive to commands, because no router is caching the messages to the Spirit. I've had limited success rejoining the former parent to the network (hitting L in the GUI, while the node is selected), so the Spirit would take the hint and find a new parent. Unfortunately, I typically need to take out the sniffer to find the former parent, as the line in the GUI has already disappeared.

[FlyingPersian]

And how do you use the sniffer? The line in the GUI is gone, so I assume it's not connected anymore.

Edit: I have been doing some googling. Is it this? https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html

If yes, I'm missing the CC-Debugger. I do have a CC2531. Would something like this work?

https://de.aliexpress.com/item/32995461002.html https://www.ebay.de/itm/CC-Debugger-Bluetooth-ZigBee-Emulator-For-2530-2531-2540-2541-protocol-analysis/123956323038

[ebaauw]

I use ZShark on a RaspBeery Pi for caputuring (see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/405) and Wireshark on my Macbook for analysing. I don’t have any experience with other tools.

[Sk4zz]

I am using schedy (https://community.home-assistant.io/t/heaty-will-die-schedy-be-born/71276) to make my thermostats "smart". But I am experiencing some weird behavior.

For some reason, homeassistant seems to register a change in the temperature setpoint a couple of minutes after a new temperature was set and confirmed by schedy. Schedy then interprets this as a manual change and deactivates rescheduling for the next 120 minutes, as configured. This happens so frequently that it renders schedy rather useless.

I am not sure, where so search for the culprit. I asked roschi, the developer of schedy and it seems not to be a problem in schedy but rather in homeassistant, deconz or on the interface between both.

I am attaching a schedy log, where you can see schedy correctly determining the result of the scheduling rules, i.e. 17°C and applying this value to both thermostats in my livingroom. Then, about 6 minutes later, a manual change to 21°C is registered (the old temperature setpoint) and the temperature is applied to all thermostats and a rescheduling timer is set.

Now I am not sure if 1) for some reason, the thermostat does not accept the change and just reports its previous temperature with the next regular status report

2) deconz reports or resets the previous temperature setpoint

3) homeassistant is just behaving weirdly.

Point 1) seems unlikely because I can confirm a change in the valve's position after the scheduled temperature is set. So the issue seems to be somewhere on the interface between deconz and homeassistant.

Maybe someone has an idea how to proceed in order to pinpoint the problem or even has an idea where the problem might be?

Best regards

2019-11-27 09:23:56.192242 INFO schedy_heating: --- [R:living] Final result: 17.0��
2019-11-27 09:23:56.194555 INFO schedy_heating: --- [R:living] Setting value to 17.0��.  [scheduled]
2019-11-27 09:23:56.197652 INFO schedy_heating: <-- [R:living] [A:climate.thermostat_wz] Setting value 17.0�� (left tries = 10).
2019-11-27 09:23:56.200876 INFO schedy_heating: <-- [R:living] [A:climate.thermostat_wz] Setting temperature = 17.0��, HVAC mode = 'auto'.
2019-11-27 09:23:56.269871 INFO schedy_heating: --- [R:living] [A:climate.thermostat_wz] Re-sending in 30 seconds.
2019-11-27 09:23:56.274596 INFO schedy_heating: <-- [R:living] [A:climate.thermostat_ez] Setting value 17.0�� (left tries = 10).
2019-11-27 09:23:56.284171 INFO schedy_heating: <-- [R:living] [A:climate.thermostat_ez] Setting temperature = 17.0��, HVAC mode = 'auto'.
2019-11-27 09:23:56.341412 INFO schedy_heating: --- [R:living] [A:climate.thermostat_ez] Re-sending in 30 seconds.
2019-11-27 09:23:56.351558 INFO schedy_heating: <-- [R:living] Value set to 17.0��.  [scheduled]
2019-11-27 09:23:56.355287 INFO schedy_heating: <-- [R:living] Sending state to HA: state='17.0', attributes={'actor_wanted_values': {'climate.thermostat_wz': '17.0', 'climate.thermostat_ez': '17.0'}, 'scheduled_value': '17.0', 'rescheduling_time': None, 'overlay_active': False}
2019-11-27 09:23:56.460744 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Attribute 'state' is 'auto'.
2019-11-27 09:23:56.474545 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Attribute 'temperature' is 17.0.
2019-11-27 09:23:56.477044 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Attribute 'current_temperature' is 18.6.
2019-11-27 09:23:56.479650 INFO schedy_heating: --- [R:living] [A:climate.thermostat_wz] Cancelled re-sending timer.
2019-11-27 09:23:56.481889 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Received value of 17.0��.
2019-11-27 09:23:56.484209 INFO schedy_heating: --- [R:living] Unchanged HA state: state='17.0', attributes={'actor_wanted_values': {'climate.thermostat_wz': '17.0', 'climate.thermostat_ez': '17.0'}, 'scheduled_value': '17.0', 'rescheduling_time': None, 'overlay_active': False}
2019-11-27 09:23:56.486919 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'state' is 'auto'.
2019-11-27 09:23:56.489353 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'temperature' is 17.0.
2019-11-27 09:23:56.491747 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'current_temperature' is 18.5.
2019-11-27 09:23:56.494162 INFO schedy_heating: --- [R:living] [A:climate.thermostat_ez] Cancelled re-sending timer.
2019-11-27 09:23:56.496311 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Received value of 17.0��.
2019-11-27 09:23:56.498661 INFO schedy_heating: --- [R:living] Unchanged HA state: state='17.0', attributes={'actor_wanted_values': {'climate.thermostat_wz': '17.0', 'climate.thermostat_ez': '17.0'}, 'scheduled_value': '17.0', 'rescheduling_time': None, 'overlay_active': False}
2019-11-27 09:24:08.587687 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'state' is 'auto'.
2019-11-27 09:24:08.591273 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'temperature' is 17.0.
2019-11-27 09:24:08.601148 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'current_temperature' is 18.5.
2019-11-27 09:24:08.604167 INFO schedy_heating: --- [R:living] Unchanged HA state: state='17.0', attributes={'actor_wanted_values': {'climate.thermostat_wz': '17.0', 'climate.thermostat_ez': '17.0'}, 'scheduled_value': '17.0', 'rescheduling_time': None, 'overlay_active': False}
2019-11-27 09:30:38.403937 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Attribute 'state' is 'auto'.
2019-11-27 09:30:38.412780 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Attribute 'temperature' is 21.0.
2019-11-27 09:30:38.415900 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Attribute 'current_temperature' is 18.6.
2019-11-27 09:30:38.419592 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Received value of 21.0��.
2019-11-27 09:30:38.422193 INFO schedy_heating: --- [R:living] Propagating the change to all actors in the room.
2019-11-27 09:30:38.424761 INFO schedy_heating: --- [R:living] Setting value to 21.0��.  [manual]
2019-11-27 09:30:38.427664 INFO schedy_heating: --- [R:living] [A:climate.thermostat_wz] Not sending value 21.0�� redundantly.
2019-11-27 09:30:38.430957 INFO schedy_heating: <-- [R:living] [A:climate.thermostat_ez] Setting value 21.0�� (left tries = 10).
2019-11-27 09:30:38.434282 INFO schedy_heating: <-- [R:living] [A:climate.thermostat_ez] Setting temperature = 21.0��, HVAC mode = 'auto'.
2019-11-27 09:30:38.518710 INFO schedy_heating: --- [R:living] [A:climate.thermostat_ez] Re-sending in 30 seconds.
2019-11-27 09:30:38.528690 INFO schedy_heating: <-- [R:living] Value set to 21.0��.  [manual]
2019-11-27 09:30:38.531972 INFO schedy_heating: --- [R:living] Re-applying the schedule not before 11:30:38 (in 2:00:00).
2019-11-27 09:30:38.534834 INFO schedy_heating: <-- [R:living] Sending state to HA: state='21.0', attributes={'actor_wanted_values': {'climate.thermostat_wz': '21.0', 'climate.thermostat_ez': '21.0'}, 'scheduled_value': '17.0', 'rescheduling_time': 1574850638.0, 'overlay_active': False}
2019-11-27 09:30:38.661966 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'state' is 'auto'.
2019-11-27 09:30:38.665726 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'temperature' is 21.0.
2019-11-27 09:30:38.668367 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'current_temperature' is 18.5.
2019-11-27 09:30:38.670909 INFO schedy_heating: --- [R:living] [A:climate.thermostat_ez] Cancelled re-sending timer.
2019-11-27 09:30:38.673100 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Received value of 21.0��.
2019-11-27 09:30:38.675437 INFO schedy_heating: --- [R:living] Unchanged HA state: state='21.0', attributes={'actor_wanted_values': {'climate.thermostat_wz': '21.0', 'climate.thermostat_ez': '21.0'}, 'scheduled_value': '17.0', 'rescheduling_time': 1574850638.0, 'overlay_active': False}

[ebaauw]

I’m seeing the same. What happens is that the REST API plugin updates its cache when queuing the request to change the setpoint. However, the request doesn’t reach the thermostat. When the thermostat sends its next periodic report, the REST API plugin updates its cache with the actual value.

I find this happens more frequently when updating (trying to update) multiple TRVs at the same time. Scheduling the updates a few seconds apart might help here. I would use group commands, but unfortunately the Spirit doesn’t support groups (and the REST API doesn’t support groups containing /sensors resources).

I think we should have implemented config.pending for the TRV, as we did for the Hue motion sensor. I need to check the logic we used, in particular when to clear the pending: on sending the command, on receiving the ack, or on receiving a report with the new value. For reliability, we would need the latter.

Still there’s the issue that occasionally, the TRV is “disowned” by its parent, but doesn’t find a new parent. Its reports still reach the gateway, but gateway commands no longer reach the TRV. This cannot be remedied by config.pending; only by rebooting the TRV, by removing the battery and re-inserting it.

[alpha23]

In germany the Spirit ZigBee have a black friday offer and a price of 27,99 euro now on amazon!

[jannnfe]

Today I spent the whole day integrating the thermostat into deconz. Unfortunately never with full success. I have read all the comments here and followed many of the step by step instructions. The thermosate was never displayed in the phoscon web surface. In the deconz GUI we created a new node and I can also read the basic cluster. manufacturer and model are loaded etc. but in the iobroker only a few knots such as temperature and battery come. but all others are missing. can someone please write a detailed instruction how he has integrated the thermostats? I would like to buy more because of black friday

[ottelo9]

In germany the Spirit ZigBee have a black friday offer and a price of 27,99 euro now on amazon!

sold out :(

[kugelkopf123]

Hello people, I have not read all 250 posts of this thread, so I do not know if the description has already been posted. From page 14 on you will find the data regarding the Zigbee Register. This may make it easier to support this thermostat in deconz. https://eurotronic.org/wp-content/uploads/2019/11/Spirit_ZigBee_BAL_web_DE_Okt.-2019.pdf

[ebaauw]

WTF: ok is not initialised, causing the addTaskThermostatReadWriteAttribute() call to be skipped randomly? No compiler warning, @manup?! https://github.com/dresden-elektronik/deconz-rest-plugin/blob/14c07293647d78385ee0b4dea61a8fdd04e270d7/rest_sensors.cpp#L1036-L1062

I suppose the good news is that we don't need to mess with config.pending.

[ma-ca]

I suppose the good news is that we don't need to mess with config.pending.

The tasks are being processed from a queue, but there is no check if the target has just sent an attribute report or anything else.

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/14c07293647d78385ee0b4dea61a8fdd04e270d7/de_web_plugin.cpp#L10320-L10530