Deconz-rest-plugin: [Device Support Request] Eurotronic Spirit ZigBee

Interesting! Still looking for something like these, at a reasonable price.

Is it this one: https://eurotronic.org/produkte/zigbee-heizkoerperthermostat/spirit-zigbee/ ? Where did you buy it? I see Reichelt sells them for EUR 50,81.

Indeed, no _Bedienungsanleitung_ for this device on their website. Did it come with a French/Spanish/Italian/Polish-only manual or also German and/or English? (I can read German, but I don't write it well).

The specs mention supported transitions (_Schaltzeiten_) per day/week, suggesting you can store a schedule on the device. Looking at the ZCL spec (6.3.2.2.3), there's an awful lot of more attributes in the 0x0201 cluster for this. I think first order of business is to add these to general.xml, as well as the commands to set/clear/get the schedule. I doubt if the deCONZ GUI can handle a variable number of parameters to the set schedule command, though.

@manup, modelling the schedules will be a nice challenge for the /devices endpoint.

Absolutely, guess the attributes should be added into new ResourceItems.

A colleague has bought the Eurotronic thermostat a few days ago and is also very keen to get support into deCONZ and homebridge-hue, we will do some sniffing to get more insights.

Yes, it's exactly that one. I got it from voelkner via amazon for EUR 41.97. The printed manual only describes the installation/mounting and is available in german and english language. I hopped to see a little more of the protocol specification like in case of the zwave version: https://eurotronic.org/wp-content/uploads/2018/08/Spirit_Z-Wave_BAL_web_DE_view_V5.pdf

However, if I can provide some more logs, I will do my very best to do so, but at the moment I am very busy at work and do not want to shut my deCONZ installation down to get clear logs of the device before Thursday.

I found info that it uses home automation profile 1.2 and presents itself as HVAC device...

Will this be tough and time consuming to implement? If you get this then deconz connected to home assistant may be the best zigbee solution on the market.

I would also like to get homebridge-hue to support the Thermostat Cluster.

The Thermostat Cluster 0x0201 is already supported with PR #1003.

Using the REST-API it is possible to change the heating temperature, get/set scheduler, turn on/off the scheduler, set offset.

@ma-ca, I will need some help with that. It's going to be challenging without a device to test.

The HomeKit _Thermostat_ service requires the following characteristics:

• _CurrentHeatingCoolingState_ (read-only, values: _Off_, _Heat_, _Cool_) - I assume this is provided by state.on: false: _Off_; true: _Heat_?
• _TargetHeatingCoolingState_ (read/write, values: _Off_, _Heat_, _Cool_, _Auto_) - This should probably be mapped to config.scheduleron? Or should it be fixed to _Auto_ and expose config.scheduleron as a separate switch?
• _CurrentTemperature_ (read-only, in 0.1°C) - This would be state.temperature?
• _TargetTemperature_ (read/write, in 0.1°C) - This would be config.heatsetpoint?

There's also an optional characteristic _HeatingThresholdTemperature_.

I wouldn't know how to expose the schedule - They haven’t reverse-engineered the interface for the Eve Thermo yet (see https://github.com/simont77/fakegato-history/issues/11, https://github.com/simont77/fakegato-history/issues/40), but I suppose you'd want to use deCONZ rules and/or HomeKit automations to set config.heatsetpoint?

@ebaauw I am glad that you are looking into this and I am happy to help.

CurrentHeatingCoolingState (read-only, values: Off, Heat, Cool) - I assume this is provided by state.on: false: Off; true: Heat?

Yes, the state.on:true corresponds to heat on. The cool is (currently) not implemented in the REST-API.

TargetHeatingCoolingState (read/write, values: Off, Heat, Cool, Auto) - This should probably be mapped to config.scheduleron? Or should it be fixed to Auto and expose config.scheduleron as a separate switch?

Perhaps yes. How is this property displayed in HomeKit and which command is associated? If this is associated to the Siri command _turn off thermostat_ then indeed it would make sense to turn off the scheduler.

CurrentTemperature (read-only, in 0.1°C) - This would be state.temperature?

Yes. Currently the temperature value needs to be divided by 100 as defined in the Zigbee spec, for example state.temperature : 2150 is 21.5 °C.

TargetTemperature (read/write, in 0.1°C) - This would be config.heatsetpoint?

Yes, also needs to be divided by 100.

I would like to use HomeKit to set config.heatsetpoint and config.scheduleron. I don't see any benefit is in changing the scheduler from HomeKit, because after setting up the scheduler using the REST-API, there is no really need to change this.

In my use cases I would like to use HomeKit to

• turn off the scheduler when leaving for holiday
• and then being able to turn on again a day _before_ returning home.
• setting the temperature.

Please check out homebridge-hue v0.11.7.

Very nice. After installing homebridge-hue v0.11.7 the iOS Home App shows the _Thermostat_ icons with temperature and heating value.

Changing the heating does change the config.heatsetpoint. Setting mode on or off does set config.scheduleron to true or false.

The only issue is that the displayed temperature seems to be rounded to 0.5 °C, but the thermostat display has 0.1°C resolution. For example the App shows 22.5 °C but display has 22.3 °C and the state.temperature is 2230. And the heating value has a random offset, for example 17.0 °C changes the config.heatsetpoint to 1710, value 17.5°C to 1770, value 18.0°C to 1800.

Can you please attach the debug log of homebridge-hue? And the dump file, just to be sure. See the README. Are you only using Apple’s Home app, or did you check other HomeKit apps. I think Home rounds the temperature to 0.5°C when displaying it. At least that’s what I see for my temperature sensors.

[1/11/2019, 8:24:13 PM] [Hue] Phoscon-GW: 000D6F000C2B8B3D: Bitron Home 902010/32 "Thermostat 40"
[1/11/2019, 8:24:13 PM] [Hue] Phoscon-GW: /sensors/40: ZHAThermostat "Thermostat 40"
[1/11/2019, 8:24:15 PM] [Hue] Initializing platform accessory 'Thermostat 40'...
[1/11/2019, 8:25:06 PM] [Hue] Thermostat 40: homekit target temperature changed from 17.6 to 18.2
[1/11/2019, 8:25:06 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1820,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:25:15 PM] [Hue] Thermostat 40: homekit target temperature changed from 18.2 to 17.5
[1/11/2019, 8:25:16 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1750,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:25:34 PM] [Hue] Thermostat 40: homekit target temperature changed from 17.5 to 16.8
[1/11/2019, 8:25:34 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1680,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: homekit target temperature changed from 16.8 to 16.3
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: set homekit target temperature from 16.3°C to 16.8°C
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1630,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: set homekit target temperature from 16.8°C to 16.3°C
[1/11/2019, 8:26:01 PM] [Hue] Thermostat 40: homekit target temperature changed from 16.3 to 15.8
[1/11/2019, 8:26:01 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1580,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:26:09 PM] [Hue] Thermostat 40: homekit target temperature changed from 15.8 to 14.9
[1/11/2019, 8:26:09 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1490,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:26:30 PM] [Hue] Thermostat 40: homekit target temperature changed from 14.9 to 13.7
[1/11/2019, 8:26:30 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1370,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:27:08 PM] [Hue] Thermostat 40: homekit target temperature changed from 13.7 to 12.7
[1/11/2019, 8:27:09 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1270,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:27:20 PM] [Hue] Thermostat 40: state changed event: {"lastupdated":"2019-01-11T19:27:20","on":false,"temperature":2220}

I am only using the Apple Home App.

Just in case there is a relation, in the beginning the _Window Covering_ icons in the Home App did have 1% resolution when showing open state between 0% and 100%. Later this changed to 5% resolution. I thought that this was changed on purpose in homebridge-hue.

I really need the full output of homebridge -D, please see https://github.com/ebaauw/homebridge-hue#debug-log-file.

I am only using the Apple Home App.

What temperatures does Eve or another HomeKit app show?

Later this changed to 5% resolution. I thought that this was changed on purpose in homebridge-hue.

Yes, I found my lumi.curtain doesn't always report a position of 0 or 254 when fully open or closed. Even after re-calibration, it's sometimes a little bit off. I worked around that by rounding to multiples of 5. This is completely unrelated to the _Thermostat_, though.

The full debug logfile from before.

homebridge.log.gz

What temperatures does Eve or another HomeKit app show?

The Eve app does show the temperature correct with 0.1 °C resolution. Also the target temperature is translated correctly when increasing the 0.5 °C steps.

Thanks!

[1/11/2019, 8:25:06 PM] [Hue] Thermostat 40: homekit target temperature changed from 17.6 to 18.2 
[1/11/2019, 8:25:06 PM] [Hue] Phoscon-GW: gateway request 22: put /sensors/40/config {"heatsetpoint":1820}
[1/11/2019, 8:25:06 PM] [Hue] Phoscon-GW: gateway request 22: ok
[1/11/2019, 8:25:06 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1820,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:25:06 PM] [Hue] Thermostat 40: ignore unknown attribute config.scheduler

This is looking good. The thermostat is changed from HomeKit to 18.2°C. homebridge-hue sets config.heatsetpoint to 1820 and deCONZ issues a web socket notification with the new heatsetpoint. I do need to ditch the config.scheduler message, though.

[1/11/2019, 8:25:48 PM] [Hue] Phoscon-GW: gateway request 50: get /sensors
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: homekit target temperature changed from 16.8 to 16.3
[1/11/2019, 8:25:48 PM] [Hue] Phoscon-GW: gateway request 51: put /sensors/40/config {"heatsetpoint":1630}
[1/11/2019, 8:25:48 PM] [Hue] Phoscon-GW: gateway request 50: ok
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: set homekit target temperature from 16.3°C to 16.8°C
[1/11/2019, 8:25:48 PM] [Hue] Phoscon-GW: gateway request 51: ok
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1630,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: set homekit target temperature from 16.8°C to 16.3°C

The joy of asynchronous processing. The target temperature is updated while homebridge-hue is polling /sensors. homebridge-hue reverts HomeKit to the previous value (retrieved from the poll), but this is corrected when homebridge-hue receives the web socket notification of the change by the put.

And the heating value has a random offset, for example 17.0 °C changes the config.heatsetpoint to 1710, value 17.5°C to 1770, value 18.0°C to 1800.

I don't see this. In both above cases homebridge-hue sends the (to 0.1°C) correct temperature to the deCONZ gateway, and the gateway confirms this through the websocket notification. I suspect the Home app might do something funny here as well. I double-checked that both _Current Temperature_ and _Target Temperature_ have a 0.1°C resolution.

Some other remarks:

[1/11/2019, 8:24:09 PM] [Hue] config.json: {"platform":"Hue","host":"127.0.0.1","users":{"00212EFFFF00893F":"*********1"},"sensors":true,"excludeSensorTypes":["CLIPPresence","Geofence"],"lights":true,"wallSwitch":true,"hueMotionTemperatureHistory":true}
[1/11/2019, 8:24:09 PM] [Hue] config.json: {"platform":"Hue","host":"192.***.***.252","users":{"001788FFFE12CA51":"***************************************1"},"sensors":true,"lights":true,"wallSwitch":true}

You have specified two "Hue" platforms in config.json. While that currently works, it will break when moving to dynamic platform accessories. You can expose both the Hue bridge and the deCONZ gateway from a single entry by:

{
  "platform": "Hue",
  "hosts": ["127.0.0.1", "192.***.***.252"],
  "users": {
    "00212EFFFF00893F": "*********1",
    "001788FFFE12CA51": "***************************************1"
  }
}

Ah the ubisys S2. I have been waiting to see the full model S2 (5502) to expose the ZHASwitch sensor. I can read the buttonevent values from the deCONZ REST API, but not the full model. Do you get good values for consumption and power? My D1 (running a later firmware version) gives garbage for these.

[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: 001FEE000000170A: ubisys S2 (5502) "Light 1"
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /lights/1: On/Off output "Light 1"
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /lights/1: config: {"on":true,"bri":false,"ct":false,"xy":false,"wallSwitch":true,"windowCovering":false,"unknown":true}
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /lights/2: On/Off output "Light 2"
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /lights/2: config: {"on":true,"bri":false,"ct":false,"xy":false,"wallSwitch":true,"windowCovering":false,"unknown":true}
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /sensors/5: ZHAConsumption "Consumption 5"
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /sensors/6: ZHAPower "Power 6"
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /sensors/4: ZHASwitch "S2 (5502) 4"
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /sensors/4: warning: ignoring unknown ZHASwitch sensor {"config":{"group":null,"mode":"momentary","on":true,"reachable":true},"ep":3,"etag":"423162415d68374a920ef22184c6c540","manufacturername":"ubisys","mode":1,"modelid":"S2 (5502)","name":"S2 (5502) 4","state":{"buttonevent":null,"lastupdated":"none"},"swversion":"20160302-DE-FB0","type":"ZHASwitch","uniqueid":"00:1f:ee:00:00:00:17:0a-03-0006"}

Note to self: Eve history.

Please checkout homebridge-hue v0.11.8 which should:

• No longer issue messages about config.scheduler;
• Provide history in Eve for the _Thermostat_ current temperature and target temperature (see https://github.com/ebaauw/homebridge-hue/issues/426);
• Support the switch function of the ubisys S2 (see https://github.com/ebaauw/homebridge-hue/issues/427).

Let's continue the conversation about homebridge-hue support to the homebridge-hue issues.

I would like to add the Eurotronic device to the restAPI, but there is an error:

{ "config": { "on": true "reachable": true } "manufacturername": "Eurotronic" "modelid": "SPZB0001" "name": "Thermo WZ ET" "swversion": "20181205" "type": "ZHAThermostat" "uniqueid": "0x00158d0001922f50" }

[{ "error": { "address": "/sensors", "description": "Not allowed to create sensor type", "type": 501 } }]

The newest versions of deCONZ (2.05.54) and homebride-hue (v0.11.8) are installed

@thommyDD please try with this interims version :)

https://www.dresden-elektronik.de/rpi/deconz/alpha/deconz-2.05.56-qt5.deb

Thermostat needs to be rejoined again, while sensor search is running.

@manup it does not work :(

I reset the thermostat while the sensor search is running, but the thermostat was not found.

Hmmm not sure what's happening. Just ordered one via Amazon should arrive next Monday.

Is interesting, subscribing to see the progress ;-)

I also stumbled over this device recently. The Z-Wave version has the interesting feature of supporting external temperature sensors (which may give more realistic readings than the internal one).
Of those that already have the device, do you know if this is (or will be) possible via Zigbee, too? The manufacturer's website is unfortunately very sparse.

Hey there, I recently also got this device. Right now I only can set the Occupied Heating Setpoint, which is then copied by the device to the attribute Current Temperature Setpoint via deCONZ Gui. Will you also add the scheduling attributes to the deCONZ Gui? As I really don´t know right now, how I would do this via REST API, as this is out of my knowledge right now. Would be much appreciated.

Cheers

Reading some more attributes of the thermostat:

• The external temperature sensor might be supported
• Schedules are not supported

So schedules will not be supported by deCONZ for a long time?

Actually there is already schedule code in deCONZ, but I can't test this since the Eurotronic thermostat doesn't support it.

It might better to create rules to mimic the schedules, which is also more powerful.

How would one create those rules? via Rest API? or is there any functionalty in deCONZ which could handle this?

Currently this is only possible via REST-API. Or perhaps when using something like Home Assistant and other home automation systems which support deCONZ integration.

@manup Unfortunately i couldn't add the thermostat with the sensor search yet. deCONZ v2.0.57 is installed.
Is there an explanation?

It should work better with upcoming 2.05.58, which contains some related fixes.

Workaround for 2.05.57:

• Start sensor search
• Read basic cluster

Is it this one: https://eurotronic.org/produkte/zigbee-heizkoerperthermostat/spirit-zigbee/ ? Where did you buy it? I see Reichelt sells them for EUR 50,81.

Indeed, no _Bedienungsanleitung_ for this device on their website. Did it come with a French/Spanish/Italian/Polish-only manual or also German and/or English? (I can read German, but I don't write it well).

I did ask them for details via email a while ago. Even though they did not respond, they have just now added a quite comprehensive manual to their website with details on the Zigbee attributes:
https://eurotronic.org/wp-content/uploads/2019/01/Spirit_ZigBee_BAL_web_DE_view_V9.pdf

I have one of these thermostats, but can’t seem to get it to pair properly.
(Headless deconz on rpi with raspbee and deconz 2.05.58)
Following the documentation link in the previous comment, I can put the thermostat into pairing mode and start sensor pairing on the phoscon app After a short while the thermostat indicates that it is successfully paired but the phoscon app. never acknowledges the paring.

The thermostat definitely considers the pairing complete. In order to get it back into pairing mode I have to reset it completely.

Any hints what I am doing wrong ?

Any hints what I am doing wrong ?

I guess nothing. Currently the thermostat is not visible in the Phoscon App but it should be visible in the REST-API.

That’s the thing - it is not visible when getting all objects from the rest api

In my first attempt to pair via deCONZ GUI, the device would show up, but none of the properties were read, not even the manufacturer ID and no clusters showed up. Eventually, I stopped deCONZ, removed all references to the device from the zll.db, reset the device and paired it as follows, _while holding it next to the RasPi_.

• Start sensor search in Phoscon.
• Remove/reinsert batteries. Press minus+plus+boost and hold them until the device resets.
• Wait for the device to pair (green light; after ~2 seconds), then mount and let it adapt.
• Sensor search in Phoscon had failed by then, so restart it.
• Go to deCONZ GUI, list clusters, click "Basic" -> "Read" (as recommended in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-457839093)
• Now Phoscon reports a successful sensor search and it shows up in the REST API.

I don't know which of the steps did the trick, but maybe that helps.

Regarding the attributes, I've found that setting "TRV Mode" (0x4000) to "manual" (2) controls the device through the setpoint (set via 0x4003). When the mode is set to "Unknown 2", the display shows the current valve opening percentage, which can be controlled with 0x4001.

None of the other options seems to have an effect, although it seems that there are hidden features in "Host Flags" (0x4008) (e.g. I managed to turn on the child protection...).

It's also not clear how "Remote Sensing" is supposed to work. Maybe through binding, with a device that has a "temperature measurement" client cluster?

I confirm those steps are working:

• Start sensor search in Phoscon.
• Remove/reinsert batteries. Press minus+plus+boost and hold them until the device resets.
• Wait for the device to pair (green light; after ~2 seconds), then mount and let it adapt.
• Sensor search in Phoscon had failed by then, so restart it.
• Go to deCONZ GUI, list clusters, click "Basic" -> "Read" (as recommended in #1098 (comment))

I was able to pair the thermostat and can see it in deconz GUI, but with name 0x3BEE.
Also I do not see it in API. (request GET /sensors).

Got mine today! If it turns out to be working reliably, I’ve got room for seven more...

It would be cool to expose the valve position (as state.bri?). The Eve Thermo reports this as well and I’m hoping I can make homebridge-hue expose the history to the Eve app.

In HomeKit, a thermostat has a _Target Heating Cooling State_ (off, heat, cool, auto) and a _Current Heating Cooling State_ (off, heating, cooling). With state.on derived from the actual valve position, the current state is covered. Does the Eurotronic have an equivalent for the target state? I used to map config.scheduleron to the target state, but with the latest commit, that’s no longer exposed (because, if I understand correctly, it didn’t do anything for the Eurotronic). We might map boost mode to _heat_ if that’s configurable from Zigbee.

I think we need to implement config.pending for setting the target temperature. The thermostat seems to poll its parent quite often, but I alreay experienced some glitches where the update wouldn’t come through. Also, we probably should set the manufacturer-specific heatpoint attribute, instead of the standard one (that doesn’t support attribute reporting).

It would be cool to expose the valve position (as state.bri?). The Eve Thermo reports this as well and I’m hoping I can make homebridge-hue expose the history to the Eve app.

I'd prefer a state.valve or similar, guess there will be more thermostats supported in near future so we better get proper attributes in the mix.

Does the Eurotronic have an equivalent for the target state? I used to map config.scheduleron to the target state, but with the latest commit, that’s no longer exposed (because, if I understand correctly, it didn’t do anything for the Eurotronic). We might map boost mode to _heat_ if that’s configurable from Zigbee.

The scheduler isn't supported by the Eurotronic, but it has multiple values which can be set. Needs more experiments to figure out the best approach.

I think we need to implement config.pending for setting the target temperature. The thermostat seems to poll its parent quite often, but I alreay experienced some glitches where the update wouldn’t come through.

Yes, it polls every 5 seconds which is good to to get commands through reliably, config.pending makes sense though.

Also, we probably should set the manufacturer-specific heatpoint attribute, instead of the standard one (that doesn’t support attribute reporting).

They seem to be synchronized on the device. I really like that the thermostat reports the values and also forwards quickly when the temperature is changed manually. But here is some work todo, changing manually won't alter the heat set point which is also reported.

I used to map config.scheduleron to the target state, but with the latest commit, that’s no longer exposed

I am using HomeKit to enable/disable the scheduler on the Bitron Thermostat. Hopefully this will continue to work.

I have received mine also today, have played basic with it as my old valves use a conection that is not fit for the adapters delivered with the thermostat. Patience is a virtue hehhe, will need assistence to replace the old valve here.

But what I notice is that now a 'standard' seems to be changed..... So far 'complex' sensors would get seperated REST API sensors. Like a weather sensor would exist of three sensor entires, pressure, temperature and humidity. Now for this thermostat the temperature measurement, the state (on/off) and the set temperature are combined. No problem to bend it, but should this not be a logical point to reconsider if this a moment to rethink if this is the right track? Looking at this it is not a sensor, but an active device? Something that could introduce the /devices branch?

They seem to be synchronized on the device.

Only one-way and not always. According to the manual:

Die übertragenen Solltemperaturen wie Occupied / Unoccupied Heating Setpoint Attribute (0x0012 oder 0x0014) werden auf das Attribut Current Temperature Setpoint (0x4003) kopiert, um den TRV ohne hersteller spezifische Attribute verwenden zu können.

Controlling the thermostat through its buttons seems to change only 0x4003. Setting _Boost_ mode changes 0x4003 to 3000 (30°C). I could map this attribute to the target state: 500 = off; 3000 = heat; other values = auto.

I think we need to write the attribute when setting the target temperature. The _Setpoint Raise/Lower_ command changes 0x0012, but not 0x4003. Also it's in 0.01°C (like the temperature attributes, not 0.1°C. I think that's a typo in general.xml?

instead of the standard one (that doesn’t support attribute reporting).

The manual contains some inconsistencies. In 6.5, 0x008, 0x0012, and 0x0014 are listed as non-reportable, but in 6.6 they are reportable.

So far 'complex' sensors would get seperated REST API sensors.

"Complex" = multiple clusters (0x0402, 0x0403, 0x0405 for the weather sensor). The thermostat is one cluster (0x0201).

Something that could introduce the /devices branch?

Yes, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/579#issuecomment-459957111 and below.

I am using HomeKit to enable/disable the scheduler on the Bitron Thermostat. Hopefully this will continue to work.

I probably need to whitelist the Eurotronic separately in homebridge-hue.

In HomeKit, a thermostat has a _Target Heating Cooling State_ (off, heat, cool, auto) and a _Current Heating Cooling State_ (off, heating, cooling).

The Eurotronic seems to control this state with the attribute "System Mode" (attribute id 0x001c) (refer the user manual on page 15). I played a little bit with this attribute in the deCONZ software, unfortunaly without any success. The value can be set, but after re-reading the value from the thermostat, it seems to reset to the default value (Heat)

With state.on derived from the actual valve position, the current state is covered. Does the Eurotronic have an equivalent for the target state?

The value state is represent by "Pi Heating Demand"

The bit for 0x000080 in _Host flags_ (0x4008) corresponds to lock mode (holding + and - for 3 seconds). It's settable and clearable from Zigbee.

The bit for 0x000080 in _Host flags_ (0x4008) corresponds to lock mode (holding + and - for 3 seconds). It's settable and clearable from Zigbee.

How did you figure this out? I tried setting individual bits with the Attribute Editor in deCONZ. But whenever I write anything non-zero, it just enables the lock mode. Writing 0x000000 unlocks it again. And after doing this, reading the Host Flags returns very different values (0x000001 after initial setup, now mine says 0x42c381).

Edit: The Z-Wave version had useful flags, such as setting the LCD backlight timer, rotate the display by 90 degrees, and configure the "open window detection" sensitivity. I was hoping this was hidden somewhere in the Host Flags here.

Edit2: Is (_Host flags_ & 0x000004) the bit for boost mode?

I think we need to implement config.pending for setting the target temperature. The thermostat seems to poll its parent quite often, but I alreay experienced some glitches where the update wouldn’t come through.

In the beginning this happened to me as well, but after configuring attribute reporting on 0x4003 to min/max/change=1/600/1 the thermostat always reports back immediately once the temperature has been set.

How did you figure this out?

There's 10 sorts of people: those that read binary and those that don't ;-)

It reported 0x000001 before and 0x000081 after setting lock mode. Writing back 0x000001 cleared the lock mode. Now mine reports 0x400341, setting lock mode changes this to 0x4003c1. I have no clue about the other bits.

Edit: The Z-Wave version had useful flags, such as setting the LCD backlight timer, rotate the display by 90 degrees, and configure the "open window detection" sensitivity. I was hoping this was hidden somewhere in the Host Flags here.

Cool, but I don't think the display can rotate (it's not a bitmap display; the elements are hardwired). I was playing with _TRV Mode_: value _Unknown 2_ switches the display to valve position (as reported by 0x0008 - _Pi Heating Demand_).

Is (_Host flags_ & 0x000004) the bit for boost mode?

Don't think so, Boost mode is 0x4003 == 3000.

Boost-Modus
Betätigen Sie die Boost-Taste.
Alternativ können Sie die Plus Taste so lange betätigen bis ON im Display angezeigt wird.

It's also not clear how "Remote Sensing" is supposed to work. Maybe through binding, with a device that has a "temperature measurement" client cluster?

I'm trying to figure out _Remote Sensing_. According to the ZCL spec (for the _Thermostat_ server cluster):

For remote temperature sensing, the _Temperature Measurement_ client cluster (see 4.4) MAY be included on the same endpoint. For occupancy sensing, the _Occupancy Sensing_ client cluster (see 4.8) MAY be included on the same endpoint.
...
_LocalTemperature_ represents the temperature in degrees Celsius, as measured locally or remotely (over the network)
...
_OutdoorTemperature_ represents the outdoor temperature in degrees Celsius, as measured locally or remotely (over the network).
...
_Occupancy_ specifies whether the heated/cooled space is occupied or not, as measured locally or remotely
(over the network).

Since neither _OutdoorTemperature_, nor _Occupancy_ nor the client clusters are implemented, I fear _RemoteSensing_ doesn't do anything.

PR adds state.valve and config.locked, bases config.heatsetpoint on 0x4003, and sets up attribute reporting to recommended settings. Also fixed a load of bugs handling the thermostat attributes.

Haven't yet implemented config.pending for locked and heatsetpoint. Changing config.locked and config.heatsetpoint seems to work (verified by sniffing). Not sure about the reporting configuration - Wireshark reported a malformed packet on the response to setting up 0x0001/0x0021 (battery percentage); I haven't yet captured the setup for 0x0201.

IEEE 802.15.4 Data, Dst: 0x0000, Src: 0x15e9
ZigBee Network Layer Data, Dst: 0x0000, Src: 0x2a38
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x00)
    Destination Endpoint: 1
    Cluster: Power Configuration (0x0001)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 97
ZigBee Cluster Library Frame, Command: Configure Reporting Response, Seq: 152
    Frame Control Field: Profile-wide (0x18)
    Sequence Number: 152
    Command: Configure Reporting Response (0x07)
[Malformed Packet: ZigBee ZCL]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
        [Malformed Packet (Exception occurred)]
        [Severity level: Error]
        [Group: Malformed]

After the command code (0x07), there's a single byte 0x00 (indicating Success?), but no confirmation of the attribute.

deCONZ doesn't seem happy about this:

Feb  7 22:37:59 pi1 deCONZ[14715]: 22:37:55:634 0x00158D000192D251 (SPZB0001) create binding for attribute reporting of cluster 0x0001 on endpoint 0x01
Feb  7 22:37:59 pi1 deCONZ[14715]: 22:37:55:634 queue binding task for 0x00158D000192D251, cluster 0x0001
Feb  7 22:37:59 pi1 deCONZ[14715]: 22:37:55:634 binding for attribute reporting of cluster 0x0201 seems to be active
Feb  7 22:39:30 pi1 deCONZ[14715]: 22:39:25:824 binding/unbinding timeout srcAddr: 158D000192D251, retry
Feb  7 22:39:35 pi1 deCONZ[14715]: 22:39:30:824 failed to send bind/unbind request to 0x00158D000192D251 cluster 0x0001. drop
Feb  7 22:43:33 pi1 deCONZ[14715]: 22:43:33:482 binding for attribute reporting of cluster 0x0201 seems to be active
Feb  7 22:47:43 pi1 deCONZ[14715]: 22:47:39:154 binding for attribute reporting of cluster 0x0201 seems to be active

I'm getting the same malformed package when setting the binding manually from the deCONZ GUI.

Cool, thanks state.valve and config.locked looks good.

But is the reporting configuration needed? The attributes already have some default configuration so only the binding is needed.

Supported in homebridge-hue v0.11.14 (see https://github.com/ebaauw/homebridge-hue/issues/426#issuecomment-461920956). Note that homebridge-hue needs the PR for full support.

But is the reporting configuration needed? The attributes already have some default configuration so only the binding is needed.

The recommended settings differ from the factory default settings. However, the thermostat also returns a malformed _Configure Reporting Response_ when configuring reporting for the _Thermostat_ attributes. For now I'll comment out the code.

I would still like the deCONZ GUI to support _Reportable Change_ for 24-bit (and 48-bit) values, so I can configure _Host Flags_ manually.

Supported in homebridge-hue v0.11.14 (see ebaauw/homebridge-hue#426 (comment)). Note that homebridge-hue needs the PR for full support.

Nice, thanks, will be merged for 2.05.59.

I would still like the deCONZ GUI to support _Reportable Change_ for 24-bit (and 48-bit) values, so I can configure _Host Flags_ manually.

I'll check the code should also be fixed in the next version.

Is (_Host flags_ & 0x000004) the bit for boost mode?

Don't think so, Boost mode is 0x4003 == 3000.

No, Boost mode also displays "On" on the thermostat and pressing a button returns to the previously set temperature. I have (locally, for testing) tried to add a config.boost in the same way you added config.locked, which toggles the flag 0x000004 and I can now remotely turn boost mode on/off.

There seems to be a flag to also turn the thermostat off (the display then shows "Off"), but I have not consistently managed to enable it (would be nice for a window sensor, as mentioned in the manual).

Since neither _OutdoorTemperature_, nor _Occupancy_ nor the client clusters are implemented, I fear _RemoteSensing_ doesn't do anything.

Thanks, I was afraid that was the case.
Meanwhile, I've worked around this by reading the temperature from a Xiaomi sensor and adjusting config.offset. That worked perfectly, until your PR changed the units for the offset from 0.1 to 0.01 degrees.
Can you please try the following:

• Set config.offset to 10 via REST. Read the attribute in deCONZ and it shows 1. Correct.
  REST responds: [{'success': {'/sensors/12/config/offset': 10, 'set config/offset': 1}}]
• Set config.offset to -10 via REST. Read the attribute in deCONZ and it shows -103, when I would expect -1.
  REST responds: [{'success': {'/sensors/12/config/offset': -10, 'set config/offset': 429496729}}])

Looking at the change to this line, I think it should be toInt instead of toUInt (this was already wrong before, but now that the result is divided by 10, it acts up).
(_edit: I just tested it and toInt fixes it_)

No, Boost mode also displays "On" on the thermostat and pressing a button returns to the previously set temperature. I have (locally, for testing) tried to add a config.boost in the same way you added config.locked, which toggles the flag 0x000004 and I can now remotely turn boost mode on/off.

Indeed. I couldn't set / clear it before from the deCONZ GUI, but this time I succeeded (at least once). There appears to be a bug in the deCONZ GUI writing the u24 attribute value:

IEEE 802.15.4 Data, Dst: 0x2a38, Src: 0x15e9
ZigBee Network Layer Data, Dst: 0x2a38, Src: 0x0000
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
ZigBee Cluster Library Frame, Mfr: Jennic (0x1037), Command: Write Attributes, Seq: 51
    Frame Control Field: Profile-wide (0x14)
    Manufacturer Code: Jennic (0x1037)
    Sequence Number: 51
    Command: Write Attributes (0x02)
    Attribute Field
        Attribute: Unknown (0x4008)
        Data Type: 24-Bit Unsigned Integer (0x22)
[Malformed Packet: ZigBee ZCL]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]

The value (after the 0x22 byte for the type) is missing from the packet, but the thermostat responds with _Write Attributes Response_ with status OK anyways and then sends a _Report Attributes_ for 0x4008 with the new (random?) value. Missing range check in the firmware?
I also managed to get the thermostat to display "Off" briefly, but I have no clue how. 0x4003 was 500 after that.

@manup, can you confirm that this is a bug (and if so, maybe even fix it)?

I think it should be toInt instead of toUInt

I think so too. I'm afraid I only added the division and rounding and never looked at the conversion of the value from the map.

@manup, can you confirm that this is a bug (and if so, maybe even fix it)?

Yes writing 24, 40, 48 and 56-bit values as well as configure reporting was not fully implemented. It's already fixed in core and will be part of 2.05.59.

Using @ma-ca's command line plugin (https://github.com/ma-ca/deconz-cli-plugin), I'm able to send _Write Attribute_ commands reliably (and also set the attribute reporting configuration on 0x4008, so the new value is reported back immediately).

So far, I've found the following:

bit | effect
--- | ------
0x000001 | none?
0x000002 | turn display upside-down
0x000004 | boost mode
0x000008 | none?
0x000010 | set to clear off mode, but but reports back as 0x000000
0x000020 | set to set off mode, but reports back as 0x000010
0x000040 | none?
0x000080 | child lock

If you want to try yourself, I use the following to send the command:

echo "zclattrmanu 0x2a38 1 0x0201 0x1037 02084022010000" | nc localhost 5008

The payload is deciphered as follows:

| |   | + value 0x000001
| |   + type 0x22 = u24
| + attribute 0x4008 = Host Flags
+ command 0x02 = Write Attributes

Looking at the documentation of the Z-Wave version, I half expected the following in _Host Flags_:

• LCD timeout (5 bits);
• LCD backlight (1 bit);
• Window Open detection (2 bits).

I tried the other 16 bits. When set, each one is reported back by the thermostat, but I see no effect.

I cannot seem to clear bit 0x000001 - maybe that's the LCD backlight (which I cannot get to turn off)?

Latest PR adds config.boost, config.displayflipped, and config.off (I didn't bother with config.mode or something). Changes to multiple REST attributes are collected into a single _Write Attributes_ on _Host Flags_. Setting boost clears off and vice versa.

{
  "config": {
    "battery": 100,
    "boost": false,
    "displayflipped": true,
    "heatsetpoint": 2100,
    "locked": false,
    "off": false,
    "offset": 0,
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "19c89536ce4a0af7399c4405f78e516d",
  "manufacturername": "Eurotronic",
  "modelid": "SPZB0001",
  "name": "Living Room Radiator",
  "state": {
    "lastupdated": "2019-02-10T14:54:26",
    "on": true,
    "temperature": 2309,
    "valve": 82
  },
  "swversion": "15181120",
  "type": "ZHAThermostat",
  "uniqueid": "00:15:8d:00:01:92:d2:51-01-0201"
}

Awesome progress, but I'm afraid the config.on, config.off and state.on might be confusing to an API user. Wouldn't the config.mode be cleaner and easier to understand?

Yes, it would. This was the quickest to implement...

There is quite some fiddling to combine changes to multiple REST attributes into a single write command for the _Host Flags_ Zigbee attribute. Maybe it’s beter to expose it as an object, something like config.hostflags.boost, config.hostflags.off, etc. Of course that’s more work from an API parsing perspective.

Also I’m not too thrilled using getZclValue() (and setZclValue() after restart) to cache the _Host Flags_ value, rather than using a RConfigHostFlags resource. I’m not sure how to create a “hidden” REST attribute though, that is stored in the database, but not exposed by the API.

Maybe it’s beter to expose it as an object, something like config.hostflags.boost, config.hostflags.off, etc. Of course that’s more work from an API parsing perspective.

Haven't looked into the details yet, my problem currently is that by looking at these attributes naively I don't understand what they are supposed to do. Maybe a nesting into config.hostflags.something isn't needed but a simpler interface. For example if config.hostflags.off is supposed to control the config.on attribute.. we can just use config.on?

Also we should find a better word for boost mode, I have no idea what it means, if it does anything useful a word describing it would help to understand the purpose :)

I’m not sure how to create a “hidden” REST attribute though, that is stored in the database, but not exposed by the API.

Just skip the attribute in the related get request :)

Also we should find a better word for _boost_ mode, I have no idea what it means, if it does anything useful a word describing it would help to understand the purpose :)

It "boosts" the temperature, of course ;-) And you set it by pressing the Boost button ;-) The word actually comes from the Eurotronic Spirit documentation:

Boost-Modus
Betätigen Sie die Boost-Taste.
Alternativ können Sie die Plus Taste so lange betätigen bis ON im Display angezeigt wird.
Komfort-Modus
Befindet sich das Gerät nicht im Komfortmodus kann per Plus oder Minus Taste in den Komfortmodus gewech- selt werden.

The word "off" isn't mentioned in the documentation, but basically it sets the thermostat's valve to min and the display shows "Off". It is mentioned in the documentation of the Z-Wave variant.

For example if config.hostflags.off is supposed to control the config.on attribute.. we can just use config.on?

It sort of controls the state.on attribute. config.on is already used to enable or disable (firing rules from) the resource. If we would change that, we would lose compatibility with the Hue API. I agree, this is confusing, also with config.scheduleron for the other thermostat.

HomeKit uses _TargetHeatingCoolingState_ with possible values _Off_, _Heat_, _Cool_, and _Auto_., and _CurrentHeatingCoolingState_ with possible values _Off_, _Heating_, and _Cooling_. Of course, _Cool_ and _Cooling_ don't apply to the Eurotronic.
If I translate this to the REST API, I would get config.mode (config.targetstate?) with values "off", "heat", "cool", and "auto"; and state.mode or state.status (state.currentstate?) with values "off", "heating", and "cooling". If we ignore the cooling part for now, state.heating seems to make more sense. In Eurotronic speak, the config.mode values would be "off", "boost", and "comfort". I think I would prefer the HomeKit terms (they seem more generic), but I'm probably biased.

On a side note: I would prefer config.targettemperature over config.heatsetpoint.

When is v2.05.59 due? I'm happy to make the changes, but I won't finish them tonight.

Oh my god this boost thing is really confusing :) Even with the description I'm not sure what or why it exists. Will anybody need or use it?

I agree the HomeKit terms are way more human readable, totally open to adapt them for the thermostat.

But we should check for breaking changes, not sure if anybody uses the existing attributes yet. @Kane610 @wvuyk ?

When is v2.05.59 due?

Well schedule was today, but I didn't finish all details yet. So next schedule can be tomorrow evening or on Tuesday. But no hurry 2.05.60 can also arrive by the end of the week.

I've got config.mode working with values "off", "heat", and "auto". Haven't changed state.on nor config.heatsetpoint. Introduced a hidden config.hostflags to persist the _Host Flags_ attribute (0x4008) in the database.

{
  "config": {
    "battery": 100,
    "displayflipped": true,
    "heatsetpoint": 2100,
    "locked": false,
    "mode": "auto",
    "offset": 0,
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "25aac331bc3c4b465cfb2197f6243ea4",
  "manufacturername": "Eurotronic",
  "modelid": "SPZB0001",
  "name": "Living Room Radiator",
  "state": {
    "lastupdated": "2019-02-10T22:41:32",
    "on": false,
    "temperature": 2149,
    "valve": 0
  },
  "swversion": "15181120",
  "type": "ZHAThermostat",
  "uniqueid": "00:15:8d:00:01:92:d2:51-01-0201"
}

There's a bug in changeSensorConfig(): it issues the web socket event too early, even before an error is returned. Try PUTting {"mode": "invalid"} to config.

In other systems such as Homematic, MAX! etc. the boost button opens the valve completely for a limited time. I never used it until I moved to a flat with skylights. After closing them on cold days, the glass was so cold that it became fogged. To avoid this, I use the boost mode whenever I close my windows and the temperature is lower than 5 degrees

@manup I have a PR up for deconz thermostat support. So this is the right time to do changes.

Either I post pone it to next release in 3 weeks or if you release 59 with this support before beta on Thursday. And I of course need the proper list of attributes :)

@manup,

I am internally working on it, but on a very flexible manner, so please go ahead and use the correct attribute. Make it a standard as we all would expect more thermostats might arrive?

edit As far I can check here attributes as quite close to what Homeseer exposes for other thermostats BTW.

I've got config.mode working with values "off", "heat", and "auto". Haven't changed state.on nor config.heatsetpoint. Introduced a hidden config.hostflags to persist the _Host Flags_ attribute (0x4008) in the database.

That looks really good. If there is still concern, in the Z-Wave manual the "boost" mode is also called "full power". I think that might be even more accurate than "heat". Btw, as for the Z-Wave version, this mode heats at full power for a few minutes, then it automatically returns to normal mode (and the host flags are reported accordingly in this case).

However, I think there is one corner case left: If you set config.mode to "off", and afterwards change config.heatsetpoint, the device will go back to normal mode, but the host flags will still indicate 0x000010. To resolve the confusion, I think the host flags should be cleared of the off/boost bits whenever config.heatsetpoint is touched.

In the Z-Wave manual the "boost" mode is also called "full power". I think that might be even more accurate than "heat".

Do you want generic terms, or Eurotronic speak? If the latter, we better use "off", "boost", and "comfort" (I don't like the space in "full power"). If the former, "off", "heat", and "auto" seem more appropriate.

Btw, as for the Z-Wave version, this mode heats at full power for a few minutes, then it automatically returns to normal mode (and the host flags are reported accordingly in this case).

I suppose I haven't left Boost mode on long enough to see this happening. Testing right now...
EDIT indeed, ~15 minutes, it would seem.

Feb 11 17:39:11 pi1 dc_eventlog[792]: /sensors/8/config: {"mode":"heat"}
Feb 11 17:39:14 pi1 dc_eventlog[792]: /sensors/8/config: {"heatsetpoint":3000}
...
Feb 11 17:54:31 pi1 dc_eventlog[792]: /sensors/8/config: {"heatsetpoint":2100,"mode":"auto"}

I think the host flags should be cleared of the off/boost bits whenever config.heatsetpoint is touched.

I think you're right, but the flags should be cleared on the device, not in the REST API cache. See my comment on your PR.

However, I think there is one corner case left

I found that switching from Boost mode to Off or v.v., the original value for _HeatSetPoint_ is lost. Not sure if that's easily worked around.

In the Z-Wave manual the "boost" mode is also called "full power". I think that might be even more accurate than "heat".

Do you want generic terms, or Eurotronic speak? If the latter, we better use "off", "boost", and "comfort" (I don't like the space in "full power"). If the former, "off", "heat", and "auto" seem more appropriate.

I don't know, because I only have the Eurotronic one available. It may depend on what modes a wall thermostats (e.g. for floor heating) would provide. But for now I don't mind the generic terms.

I found that switching from Boost mode to Off or v.v., the original value for _HeatSetPoint_ is lost. Not sure if that's easily worked around.

Are you sure? I just tried: setpoint is at 21C. Now I send 0x20 and it goes to "off" and the setpoint is reported at 5C. Now send 0x10, it goes back to normal and immediately reports the setpoint as 21C again. I can also leave the "off" mode by pressing _+_ or _-_ on the device (twice).
This also works for the boost mode (also when leaving boost mode by pressing the _boost_ button on the device (twice)).

Are you sure? Are you sure? I just tried: setpoint is at 21C. Now I send 0x20 and it goes to "off" and the setpoint is reported at 5C. Now send 0x10, it goes back to normal and immediately reports the setpoint as 21C again. I can also leave the "off" mode by pressing _+_ or _-_ on the device (twice).

This is switching from Off mode back to Comfort; not switching from Off mode straight to Boost mode.

When running (with some time between the commands):

$ ph put /sensors/8/config '{"mode": "heat"}'
$ ph put /sensors/8/config '{"mode": "off"}'
$ ph put /sensors/8/config '{"mode": "auto"}'

the Heat SetPoint is left at 30°C:

Feb 11 18:13:24 pi1 dc_eventlog[792]: /sensors/8/config: {"mode":"heat"}
Feb 11 18:13:30 pi1 dc_eventlog[792]: /sensors/8/config: {"heatsetpoint":3000}
Feb 11 18:13:30 pi1 dc_eventlog[792]: /sensors/8/state: {"lastupdated":"2019-02-11T17:13:30"}
Feb 11 18:13:30 pi1 dc_eventlog[792]: /sensors/8/state: {"lastupdated":"2019-02-11T17:13:30","temperature":2087}
Feb 11 18:13:44 pi1 dc_eventlog[792]: /sensors/8/config: {"mode":"off"}
Feb 11 18:13:50 pi1 dc_eventlog[792]: /sensors/8/config: {"heatsetpoint":500}
Feb 11 18:13:50 pi1 dc_eventlog[792]: /sensors/8/state: {"lastupdated":"2019-02-11T17:13:50"}
Feb 11 18:13:58 pi1 dc_eventlog[792]: /sensors/8/state: {"lastupdated":"2019-02-11T17:13:57","on":false,"valve":0}
Feb 11 18:14:19 pi1 dc_eventlog[792]: /sensors/8/config: {"mode":"auto"}
Feb 11 18:14:23 pi1 dc_eventlog[792]: /sensors/8/config: {"heatsetpoint":3000}
Feb 11 18:14:23 pi1 dc_eventlog[792]: /sensors/8/state: {"lastupdated":"2019-02-11T17:14:23"}
Feb 11 18:14:30 pi1 dc_eventlog[792]: /sensors/8/state: {"lastupdated":"2019-02-11T17:14:30","on":true,"valve":168}

Yes, I can confirm it for this sequence: auto->heat->off->auto.
At least everything stays in sync, since the setpoint is correctly reported.

Oddly enough, it works as expected for auto->off->heat->auto.

it works as expected for auto->off->heat->auto

Indeed.

Have you tried to trigger the windows open detection?

No, I use rules based on the Xiaomi contact sensors.

The experience with my previous thermostats was that it would only work reliably if the thermostat was mounted directly below the window.

To add to the last question, and in case anyone is confused:
I think that what we call "off" (flag 0x20) is sort of a manual toggle of the open window detection. The thermostat turns off and says so in the display, but I found that it goes back to the previous setting after ~15 minutes (as mentioned in the manual).

Good find!

Die Empfindlichkeit der Fenster-Offen Erkennung kann konfiguriert werden.

That must be some of the as yet unidentified bits in _Host Flags_ (0x4008).

Im Stellwertbetrieb (Manufacturer-Specific-Mode) wird die Fenster-Offen Erkennung nicht ausgeführt.

I assume "Manufacturer-Specific Mode" is _TRV Mode_ (0x4000) "Unknown 2"?

I've found that setting "TRV Mode" (0x4000) to "manual" (2) controls the device through the setpoint (set via 0x4003). When the mode is set to "Unknown 2", the display shows the current valve opening percentage, which can be controlled with 0x4001

Die Fenster-Offen Erkennung kann durch einen externen Fensterkontakt aktiviert/deaktiviert werden.

This would suggest a binding of sorts, but without an appropriate client cluster that's going to be hard to figure out. The only thing that comes close in the ZCL spec would be an _IAS Zone_ device of type _Contact switch_.

Installed another four of these and moved them to my production network, now on 2.05.59. I plan to add three more, but need to make some room first. The thermostats are much larger than the original dials.

The deCONZ GUI in 2.05.59 now handles the u24 attribute _Host Flags_ correctly: I can change the value and the attribute reporting config. I’ve changed manually the reporting config from the default on all my thermostats:

• Disable reporting for 0x0012 and 0x0014, which we don’t use because of 0x4003. The thermostat doesn’t seem to combine multiple attributes in a single report, so this saves traffic and updates to state.lastupdated;
• Setup min interval of 1, max interval of 600, and reportable change of 1 for _PI Heating Demand_, _Errors_, and _Host Flags_, so changes are reported immediately. _Local Temperature_ gets a reportable change of 10 (0.1°C), _Current Temperature Setpoint_ of 50 (0.5°C). Still figuring out the optimal settings. Maybe I should limit the period reports to _Current Temperature_ and only configure on-change reporting for the other attributes.

I would still prefer to see the REST API plugin do this, but the thermostat seems to send a malformed _Configure Reporting Response_ (with only the status in the payload).

I think we’d better expose the _Errors_ attribute 0x4002 as well. I managed to get one of my thermostats to report an error. Murphy made sure it was the one hidden behind my desk, so it went unnoticed for quite a while.

@manup any progress on the changes planned for this?

Hi @all,

I bought 2 of these devices and wanted to connect them in the Phoscon App. But when I reset the devices and the display shows "JiN" and a blinking antenna I just get a connection error in the Phoscon App, even if I press the boost key on the device after the antenna stops to blink.

Is there any step I missed or have I use the GUI App to connect the device?

Best reagards
Mark

Edit: I updated the Rest Plugin 2.05.59 already and like the release notes say the devices should work with this version.

Yesterday I paired four thermostats to my production network without any issue. Today, I was adding the remaining three thermostats, and ran into some pairing issues as well. I have no clue what's causing it: sometimes, a node would show in the deCONZ GUI, but the list of endpoints wouldn't get updated or nothing could be read from the node. Maybe my network is getting too large, now on 101 nodes. I suspect routing issues: the thermostat's messages seem to reach the gateway, but the gateway's responses don't seem to reach the thermostat.

I deleted the nodes from the devices table in the database, removed the battery from the thermostat for a while, and tried again. Best to open the network from the old web app/search for sensors from Phoscon and then reset the thermostat (hold all three buttons for 10 seconds - it counts to 10 for you). I had to manually read the _Basic_ attributes to force the creation of the REST API resource, but after that the thermostat and deCONZ seem to like each other.

Should the thermostat be visible in the api? Or in the home assistant?

In the api: yes, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-462189373. Home assistant: I don't know. It is visible in HomeKit through homebridge-hue, see https://github.com/ebaauw/homebridge-hue/issues/426#issuecomment-461920956.

Ok thanks. I guess I will try to remove it and pair it again now. Using the procedure you mentioned in previous post.

@Oliviakrkk it is not supported in home assistant yet. I'm waiting on information if the api will change shortly or not. I have a PR open but it will not be merged until the Api is stable

@Kane610 Thanks for clarification.

@ebaauw : How can I "manually read the _Basic_ attributes to force the creation of the REST API resource"

@ebaauw: I see the devices in the GUI now and I am able to write the current temperature set point from here. But if I take a look into /sensors in the API the devices are not shown. Should they be there?

@Kane610 How can I add your changes to my HA? Have I do something more than replace the source files?

@alpha23 just follow the pr and all its changes

@Kane610 I think the API is stable (at least for now). As I mentioned before, I might add state.errors, but I don’t think we’ll need to change the current functionality.

But if I take a look into /sensors in the API the devices are not shown. Should they be there?

@alpha23 yes, but as I said before, you might need to trigger their creation manually.

How can I "manually read the _Basic_ attributes to force the creation of the REST API resource"

@Oliviakrkk Open the _Cluster Info_ panel in the deCONZ GUI. Press the right dot on the thermostat’s node to drop down the list of clusters. Select the _Basic_cluster - this fills the panel. Search for new devices in the Phoscon app. Then scroll down the _Cluster Info_ panel and press _Read_. The node name changes from the NWK address to “Thermostat xx” when the REST API resource has been created.

@ebaauw thanks!

One question: with 'on'; is it state or config that should be changed to enable/disable heating?

I believe this is replaced by "mode"="off"?

• Read-only state.on reflects the valve position (0 = false; >0 = true) from _PI Heating Demand_ (0x0008). The numeric value also exposed as state.valve;
• Read-only state.temperature reflects the temperature measured by the thermostat, from _Local Temperature_ (0x0000);
• Read/write config.heatsetpoint reflects the target temperature, from _Current Temperature Setpoint_ (0x4003);
• Read/write config.mode reflects mode, from _Host Flags_ (0x4009):
  
  
  
  • "off"= _Off_ mode (display shows Off). The thermostat changes _Current Temperature Setpoint_ to 500 (5°C); changing this reverts to _Normal_ mode.
  
  
  • "auto" = _Normal_ (aka Comfort) mode (display shows target temperature);
  
  
  • "heat" = _Boost_ mode (display shows On). The thermostat changes _Current Temperature Setpoint_ to 3000 (30°C); changing this reverts to _Normal_ mode. Note that the thermostat reverts _Boost_ mode to _Normal_ after ~15 minutes or so;
  
  
• Read/write config.on is the regular attribute to disable rules being fired from this sensor resource. It's not mapped to any of the Thermostat's attributes.

In my (brief) experience, it's best to leave "mode": "auto" and change config.heatsetpoint for the target temperature (e.g. 2100 when at home and 1500 when not). Use state.on to show whether the thermostat is heating or not.

@wvuyk off and on I take it?

Thanks @ebaauw, this write up would be good for all device types 👍 (hint hint @manup )

Some tips for those looking to get this thermostat.

• The online prices for the Eurotronic Spirit Zigbee vary enormously. I got my first one from getgoods.com for € 37.73 incl. shipping from DE to NL, but they raised the price to € 45,86, excl. shipping before I could order more. I got the next batch from yakodo.de for € 38.80 a piece (and € 12.90 for shipping, again from DE to NL), but they now raised the price to € 50.00 a piece;
• My radiators already had Danfoss RA valves installed, but with regular (non-thermostatic) faucets. It took me while to figure out how to uninstall these: open them fully and simply pull them off (sometimes violence is the right solution). With the included RA to M30 adapter installing the Spirit was a piece of cake.
• The radiator in my hallway is too close to the side wall for the Spirit to fit. I was already having nightmares about moving the radiator, when I found an M30 adapter with a 90° corner. Using the included RA to M30 adapter and this corner adapter, I installed the Spirit perpendicular to the radiator.
  
  This seems to work well - I ordered another corner adapter so I don't have to move the dining room cupboard (anchored to the wall) away from the dining room radiator.

@Oliviakrkk Open the _Cluster Info_ panel in the deCONZ GUI. Press the right dot on the thermostat’s node to drop down the list of clusters. Select the _Basic_cluster - this fills the panel. Search for new devices in the Phoscon app. Then scroll down the _Cluster Info_ panel and press _Read_. The node name changes from the NWK address to “Thermostat xx” when the REST API resource has been created.

Nice! Thank you!
API item has been created. For a moment it had name Thermostat 49 and then it renamed itself to SPZB0001.

"59": {
    "config": {
        "battery": null,
        "displayflipped": null,
        "heatsetpoint": 2100,
        "locked": null,
        "mode": "auto",
        "offset": 0,
        "on": true,
        "reachable": true
    },
    "ep": 1,
    "etag": "9c3459545806f30b2a3ad2ec4ce765ca",
    "manufacturername": "Eurotronic",
    "modelid": "SPZB0001",
    "name": "SPZB0001",
    "state": {
        "lastupdated": "2019-02-16T17:47:25",
        "on": null,
        "temperature": 1990,
        "valve": null
    },
    "swversion": "20181205",
    "type": "ZHAThermostat",
    "uniqueid": "00:15:8d:00:01:92:d2:20-01-0201"
}

I was testing the thermostat for the past few days.
I found that config.on hardly ever was set to off. I had noticed that the valve's value was set at '4' whenever the needed level of heating was reached. With @ebaauw 's answer I now understand why the config.on never was set to false.

But funny enough, since yesterday afternoon the value of state.valve is set to 0 each time the setpoint is reached. It looks like the device is adjusting itself over time?

Another find is that when I press the boost button on the device, web hooks come in for config.heatsetpoint, state.valve and state.temperature, but not for config.auto Is this not reported by the device or is this report missed to send?

But funny enough, since yesterday afternoon the value of state.valve is set to 0 each time the setpoint is reached. It looks like the device is adjusting itself over time?

I suspect it does. It seems to find the right valve setting for a constant temperature, rather than opening/closing the valve all the time. When you change the heatsetpoint far from the current temperature, it will fully open or close the valve.

Another find is that when I press the boost button on the device, web hooks come in for config.heatsetpoint, state.valve and state.temperature, but not for config.auto Is this not reported by the device or is this report missed to send?

I think you mean config.mode? It's read from the _Host Flags_ attribute 0x4008. The factory default reporting is too conservative, imho, and it doesn't report changes immediately. If you change this manually, it does get reported like the other attributes, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-464348217.

Indeed I ment config.mode. I was hoping it would report in a regular manner, like 5 minutes or so. But I have out waited the boost time, and it never reported the config.mode as "heat", the other values were reported consistantly, could see them change here, Now 15 minutes have past all is reset.

Too bad, this could have been useful information for the Homeseer events....

Two of my thermostats spontaneously (?) sort of reset, clearing displayflipped, even though the display itself is still flipped. In both cases, I see the same pattern in the log:

• The thermostat sends a _Device Announcement_ (ZDP 0x0013);
• The thermostat reports _Current Temperature Setpoint_ 0x4003 at 20°C;
• The thermostat reports _PI Heating Demand_ 0x0008 at 255 and _Local Temperature_ 0x0000 at 20°C;
• The thermostat reports _Hosts Flags_ 0x4008 at 0x000081 (locked is preserved, but displayflipped is cleared) and _Current Temperature Setpoint_ at the actual value;
• The thermostat reports _Current Temperature Setpoint_ 0x4003 at the actual value;
• The thermostat reports _PI Heating Demand_ 0x0008 and _Local Temperature_ 0x0000 at their actual values.

The next time _Host Flags_ is written, the cleared displayflipped bit is sent back to the thermostat, and the display unflips.

I'm not sure what triggered this sequence. These were different thermostats than the one going MIA in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/849.

Update Upon further analysis of the log, other thermostat went thru the same routine, but as their display wasn't flipped, I didn't notice this at first.

I'm not sure what triggered this sequence.

I think it's the thermostat's self test. According to https://eurotronic.org/produkte/zigbee-heizkoerperthermostat/spirit-zigbee/, the thermostat does a self-test once per week:

Selbsttest: 1 x wöchentlich

This device seems to be great! @Kane610 I saw your PR. Thanks for the work. It doesn't include schedules, for the moment, right? Just want to know that I won't be searching for something that isn't there.

@akaho no schedules. No way to expose it in hass atm

Hi,
I found the device with DeCONZ, thanks for the work !
But can you see it in Phoscon ? I can't find it.

Hi,
i also add a Spirit Zigbee, after the Custer Info -read procedure, Phoscon write "Sensor bereit"
But there is no Sensor in Phoscon and also nothing in IOBroker .
But i can see it in Deconz-GUI as SPZB001 following a Battery-Symbol.

I run Deconz 2.05.60 on a RPI3.

Not being into zigbee and clusters (I’ve been using wireless KNX-RF based thermostatic valves), is there support for manually driving the valve motor, or in effect doing your own PID controller for it?
Also, is currently only end point device thermostatic valves (on battery) supported, or would also mains powered (router) zigbee thermostatic valves work now?

is there support for manually driving the valve motor, or in effect doing your own PID controller for it?

The Eurotronic Spirit valves have a mode where you can set the valve position manually. This is using manufacturer-specific extentions to the Zigbee standard, so ymmv for other thermostats. I haven’t exposed this part over the REST API.

Writing your own PID controller seems quite challenging to me; would love to see your work on that.

Also, is currently only end point device thermostatic valves (on battery) supported, or would also mains powered (router) zigbee thermostatic valves work now?

Each type of thermostat needs to be whitelisted explicitly, and might need some fiddling depending on how they implement and extend the Zigbee standard. Whether they’re mains or battery powered won’t make much of a difference. Nor whether they’re Zigbee routers or Zigbee end devices (which isn’t always the same as mains vs battry powered). If you have a particular type in mind, please open a new issue, providing the info described here: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Request-Device-Support.

Hi,

i have a problem to add the eurotronic spirit with deconz v2.05.60.

my deconz is running on ubuntu without gui, so i can only use phoscon webapp and rest api. my problem is, after joining the eurotronic to deconz via Phoscon App the eurotronic device seems to added to my zigbee network (device ok, phoscon app reported "no device found"), but i cant see the device neither in phoscon app nor in rest api. the device itself reported successfull connection to zigbee network.

can someone help me?

regards Bobby

I am afraid you need to read Cluster info.
I recently bought additional thermostats and needed to do the procedure for each newly added one.

Thanks for info. is there a way to do this without x11 gui?

@BobbyXXX: I used x11vnc for it.

Same problem like BobbyXXX for me. I use deconz in docker (marthoc/deconz). So there is no GUI. I tested Eurotronic Spirit ZigBee with CC2531-Stick in iobroker (based on zigbee2mqtt.io). Device is recognized within seconds and usable in iobroker.
In deconz the device is paired but not to find in Phoscon or REST

regards Kay

Hi

Docker has option for VNC. You can access GUI via VNC.

Options:
-e DECONZ_VNC_MODE=1
-e DECONZ_VNC_PORT=5900

Thanks. That's it. I can join it.
Thank you

Kay
for docker-compose:
- DECONZ_VNC_MODE=1
- DECONZ_VNC_PORT=5900
- DECONZ_VNC_PASSWORD= XXXX

Hi, Due the posts above I managed to get mine into iobroker. Thank you! But sadly it only shows a few values and no options to set a temperature, nor set it on & off. Will this be added it the near future? Otherwise it is pretty useless and I need to return it. Is there anything I can do myself? (coding skills low) Thank you very much! Wolfgang

Because there is no Chance with Deconz, I changed the Eurotronic Spirit Zigbee to a 4$ Chinese CC2531 and that is what i get :

@Wolfgang:
I'm using node-red with iobroker. rweise is right. The CC2531 works well with this thermostat, but not with other devices. I tried both and I stay with deconz.
If you work with node red, here is my Solution:
The Idea based on sending new temperature with REST-API. There are two buttons, to increase and decrease wanted temperature. This temperture is stored in iobroker via node-red. New temperture ist sended to deconz via http-Request.
Description is in english. Name of nodes in german.

[ { "id": "8c13faa0.312318", "type": "ui_gauge", "z": "82a0e2b1.be156", "name": "Thermostat, Schlazimmer (SOLL)", "group": "62b68445.1ceddc", "order": 2, "width": "3", "height": "3", "gtype": "gage", "title": "Schlafzimmer (Soll)", "label": "°C", "format": "{{value}}", "min": "5", "max": "35", "colors": [ "#0092b5", "#00e627", "#b50000" ], "seg1": "20", "seg2": "25", "x": 1120, "y": 240, "wires": [] }, { "id": "ee827496.0baf08", "type": "http request", "z": "82a0e2b1.be156", "name": "", "method": "use", "ret": "txt", "url": "", "tls": "", "x": 1050, "y": 540, "wires": [ [] ] }, { "id": "16322cea.30f4f3", "type": "ui_button", "z": "82a0e2b1.be156", "name": "+ 1 °C", "group": "62b68445.1ceddc", "order": 3, "width": "2", "height": "1", "passthru": false, "label": "+ 1 °C", "tooltip": "", "color": "", "bgcolor": "firebrick", "icon": "", "payload": "100", "payloadType": "num", "topic": "", "x": 130, "y": 380, "wires": [ [ "d34474dd.fa8458" ] ] }, { "id": "ab90e2a6.95fc2", "type": "ui_button", "z": "82a0e2b1.be156", "name": "- 1 °C", "group": "62b68445.1ceddc", "order": 5, "width": "2", "height": "1", "passthru": false, "label": "- 1 °C", "tooltip": "", "color": "", "bgcolor": "#0092b5", "icon": "", "payload": "-100", "payloadType": "num", "topic": "", "x": 130, "y": 420, "wires": [ [ "d34474dd.fa8458" ] ] }, { "id": "d34474dd.fa8458", "type": "ioBroker get", "z": "82a0e2b1.be156", "name": "Schlazimmer, Temperatur (Soll)", "topic": "node-red.0.deconz.0.Sensor_7.heatsetpoint", "attrname": "heatsetpoint", "payloadType": "value", "x": 430, "y": 400, "wires": [ [ "f1878f12.b4c2d" ] ] }, { "id": "f1878f12.b4c2d", "type": "function", "z": "82a0e2b1.be156", "name": "Set_heatsetpoint", "func": "\nvar new_temp = {payload: (msg.heatsetpoint + msg.payload) }\nvar real_new_temp = {payload:new_temp.payload / 100}\n \n\nmsg.method = \"PUT\";\n// here put your own Apikey\nmsg.headers = { \"X-ApiKey\": \"XXXXXXXXX\" };\n\nvar data = {\"heatsetpoint\": new_temp.payload};\nmsg.payload = JSON.stringify(data);\n// here put sensor_id, mine is 7\nmsg.url = \"http://127.0.0.1/api/DB28CD6F62/sensors/7/config\"\n\nreturn [real_new_temp, new_temp, msg]\n\n\n", "outputs": 3, "noerr": 0, "x": 750, "y": 400, "wires": [ [ "8c13faa0.312318" ], [ "6a17be92.3e904" ], [ "ee827496.0baf08" ] ] }, { "id": "6a17be92.3e904", "type": "ioBroker out", "z": "82a0e2b1.be156", "name": "Schlazimmer, Temperatur (Soll)", "topic": "node-red.0.deconz.0.Sensor_7.heatsetpoint", "ack": "false", "autoCreate": "false", "x": 1110, "y": 400, "wires": [] }, { "id": "acd7e601.65e8f8", "type": "comment", "z": "82a0e2b1.be156", "name": "GUI to change Temperature", "info": "value that increases/decreases temperature\nhere: +/- 100 (-> 1°C)\n\nsaved to msg.payload", "x": 160, "y": 340, "wires": [] }, { "id": "2e589afa.4d0426", "type": "comment", "z": "82a0e2b1.be156", "name": "iobroker place to load heatsetpoint", "info": "This is to store the heatsetpoint somewhere\n\nI want to increase or decrease temperature, \nso i have to store it.\nCan be everywhere.\nIs here loaded to change temperature to:\n\nsaved to msg.heatsetpoint", "x": 440, "y": 360, "wires": [] }, { "id": "edd2e760.bdea58", "type": "comment", "z": "82a0e2b1.be156", "name": "iobroker place to store heatsetpoint", "info": "Here the new temperature is stored", "x": 1120, "y": 340, "wires": [] }, { "id": "b30bf85a.5aafc8", "type": "comment", "z": "82a0e2b1.be156", "name": "Gui of new temperature ", "info": "", "x": 1080, "y": 200, "wires": [] }, { "id": "1962d290.5e630d", "type": "comment", "z": "82a0e2b1.be156", "name": "http request", "info": "All information comes from function", "x": 1050, "y": 500, "wires": [] }, { "id": "f07d3e8e.499a6", "type": "comment", "z": "82a0e2b1.be156", "name": "Function to create Api-Call", "info": "Here you have to change your own API Information.\n- API key\n- Sensors ID", "x": 750, "y": 360, "wires": [] }, { "id": "62b68445.1ceddc", "type": "ui_group", "z": "", "name": "Temperatur", "tab": "e70b7e9b.cc318", "order": 2, "disp": true, "width": "6", "collapse": true }, { "id": "e70b7e9b.cc318", "type": "ui_tab", "z": "", "name": "Werte", "icon": "dashboard", "order": 1, "disabled": false, "hidden": false } ]

Can I add a CC2531 to my raspberry in addition to my Conbee so they co-exist as two coordinators on different channels? That would be a 5-8$ solution and quickfix?

Yes you can, and i do it :-)
kaykoch is right, deconz has more options and better support. i use a lot of xiaomi stuff. And deconz has often a easy way for automation , because there is an option "lastupdated" that i miss in zigbee.
But because, there is no way for easy going with thermostats i use a Zigbee Stick with the iobroker zigbee adapter too . Both works very well und the distance from the 5$ Zigbee Stick to the Thermostate is 6m with a 24cm stonewall in between.

Finally i hope, that dresden-elektronik, will make it happen, that the Spirit Zigbee will work with deconz like it works with zigbee. Normaly, they have a very good support.

And here it is, the red light on deconz and the green one is the zigbee Stick.

And here is your Version :-)

Falls sie aus D sind, ich habe mehrere Sticks ...

Hallo,
Bin aus Österreich und habe warte, dass meiner aus China kommt. Da ich nur einen Stick benötige habe ich keinen Flasher etc. Sollte er nicht ankommen, melde ich mich gerne...
Danke :)

Nur für Sie. Suchen sie auf Ebay nach jblack_de Schreiben sie mir hier,
wann sie mir über eBay ihre Adresse gesendet haben Nichts Kaufen!!! Sie
bekommen dann in wenigen Tagen einen völlig kostenlosen Brief Nach
Österreich...

Einfach weil ich es kann :-) und gerne helfe ...

realwax notifications@github.com schrieb am Di., 16. Apr. 2019, 19:22:

Hallo,
Bin aus Österreich und habe warte, dass meiner aus China kommt. Da ich nur
einen Stick benötige habe ich keinen Flasher etc. Sollte er nicht ankommen,
melde ich mich gerne...
Danke :)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-483767001,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANHUcloaKts41eqCWnYzlAtZmRXz-NQOks5vhgbQgaJpZM4Zz_-1
.

Ich weiß nicht, wie lange die Post braucht. Ich brauche 24h ab Adresszugang
zum Versenden 😃

René Weise weise.rene@gmail.com schrieb am Di., 16. Apr. 2019, 20:06:

Nur für Sie. Suchen sie auf Ebay nach jblack_de Schreiben sie mir hier,
wann sie mir über eBay ihre Adresse gesendet haben Nichts Kaufen!!! Sie
bekommen dann in wenigen Tagen einen völlig kostenlosen Brief Nach
Österreich...

Einfach weil ich es kann :-) und gerne helfe ...

realwax notifications@github.com schrieb am Di., 16. Apr. 2019, 19:22:

Hallo,
Bin aus Österreich und habe warte, dass meiner aus China kommt. Da ich
nur einen Stick benötige habe ich keinen Flasher etc. Sollte er nicht
ankommen, melde ich mich gerne...
Danke :)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-483767001,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANHUcloaKts41eqCWnYzlAtZmRXz-NQOks5vhgbQgaJpZM4Zz_-1
.

Falls das bei eBay nicht funktioniert. Ich habe mein Postfach bei gmail und mein Benutzername hier ist erster Buchstabe des Vornamen gefolgt vom Nachnamen. Bei Google startet der Nachname von einem Punkt verfolgt. Danach könnten sie es mit Rene vor dem @ probieren 😂 Dabei bitte ebenfalls hier schreiben, das sie eine Nachricht gesendet haben...

@rweise ich habe mich per gmail gemeldet. LG Wolfgang

Ist Unterwegs , viel Spass damit :-)

Am Mi., 24. Apr. 2019 um 13:15 Uhr schrieb realwax <[email protected]

:

@rweise https://github.com/rweise ich habe mich per gmail gemeldet. LG
Wolfgang

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-486180283,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADI5I4SBJ4R6C7FDAASRKRTPSA6OJANCNFSM4GOP762Q
.

I also stumbled over this device recently. The Z-Wave version has the interesting feature of supporting external temperature sensors (which may give more realistic readings than the internal one).
Of those that already have the device, do you know if this is (or will be) possible via Zigbee, too? The manufacturer's website is unfortunately very sparse.

i have this question too. is it possible to implement this too to the api ?

If you can tell me that, and how, the Zigbee version supports it. I haven’t been able to set this up.

i am not so deep in zigbee standard but I found this in a pdf from manufacturer:
attribute id: 0x001A
Default Value: 0x00
Data type: 0x18 (8-bit bitmap)
Read/Write: RW
Manufacturer Specific: N0
Reportable: No

I hope this helps you :)

https://eurotronic.org/wp-content/uploads/2019/01/Spirit_ZigBee_BAL_web_DE_view_V9.pdf

I found that as well, but it doesn’t give me clue as to how to link the external temperature sensor. I tried setting this attribute and binding the TRV to a _Temperature Measurement_ cluster of one of my Hue motion sensors, but no joy.

it sounds like its not possible to send a temp ? and I must "link" another zigbee device with a temp reading with the thermostat ?

from the pdf It sounds like that I must send the actual temp in a 8bit cluster and all should be fine

attribute id: 0x001A
Default Value: 0x00
Data type: 0x18 (8-bit bitmap)
Read/Write: RW

from the pdf It sounds like that I must send the actual temp in a 8bit cluster and all should be fine

I was wondering about this as well. But you can see that the data type is a bitmap (i.e. a bunch of flags to toggle) and not an "int" number (as for the other temperatures in the PDF).
deCONZ allows toggling these flags. One of the options is something like "Use external temperature sensor". This can be turned on using the bitmap, but I don't understand how to send the actual temperature.

It was supported in deCONZ already very early, so it seems to be a a standard ZigBee attribute. Yet I wonder if such things are supposed to happen via bindings (which the thermostat doesn't support afaik), then why have this bitmap?

According to the manual it should also be possible to use an external window sensor, but the situation is the same...

Either we inquire with the manufacturer again, or manage to catch them at a trade fair (like IFA in September in Berlin)... ;-)

I would also be very interested in the Eurotronic, however I am rather new to hass.io and python

Can anyone give a summary what's working and what not? I'm looking for thermostats and already have a Conbee II stick so i'd like to use that for controlling the thermostats.
Thanks!

I can tell you what's working _in combination w/ Home Assistant_ frontend:

1. Reading temperature values from temperature sensor
2. Setting setpoint/target temperature
3. Turning device off

What's not working:

1. Setting HVAC/system mode to off though announced as possible HVAC mode
2. Enabling remote sensing (as I understood its possible to set a remote temperature sensor; makes sense when thermostat is near ground/ceiling level and has too low/values to regulate expected room temperature)

Didn't investigated further where the problems are located, but I think enabling remote sensing is an internal ZigBee network's/device's option and has to be solved in deCONZ so far.

as I understood its possible to set a remote temperature sensor

How? I haven’t been able to set that up on the ZigBee version of the Eurotronic Spirit.

How can I change the valve position value via the API when I am in TRV mode "Unknown 2"?
If I call "http://localhost/api/XXXX/sensors/2/state" via PUT with the content "{"valve": 127}", then I get "[{}]" as return. If I do this via the deCONZ app, the value is changed directly.

You can only PUT the state of CLIP sensors, not of ZigBee sensors. The REST API doesn’t support setting the valve position directly, only thru the temperature setpoint.

Must have missed it in the API documentation. Is it planned for future versions?

No. There's no API support for TRV mode either.

Why would you want this? Are you writing your own PID controller?

Yes with dependencies e.g. "at home", "not at home" and "on vacation". Or outside temperature and room temperature. Or solar radiation into the room, so that the system also knows that the room is being heated by the sun.

I'm sorry, I don't understand what you're trying to achieve. Isn't it way easier just to set the target temperature and let the TRV handle the valve position?

Outside temperature or room being heated by the sun are relevant when you have a single room thermostat driving the central heating boiler and you still want to heat other rooms. The TRV only drives a single radiator, only influencing the temperature of the room it's in.

Just imagine it's early in the morning and you controlled the thermostat through your Smarthome control panel by time. So the sun rises, but it's cloudy. The valve opens 80%.
Same scenario, but it's not cloudy. The sun shines into the room, the valve opens only 20%, because the sun heats the room supporting.
If I set this above the target temperature e.g. to 22 degrees, the valve stands up much further than it should.
In addition, the heat accumulates at one point on my radiator and an external thermostat is obligatory.
I would have to set it to 26 degrees, although the room should only have 22 degrees, so that the valve does not close too early by mistake. Sounds all confusing but makes more sense in my case. Therefore also the question whether it would be a lot of effort for you to implement this.

No. There's no API support for TRV mode either.
Why would you want this? Are you writing your own PID controller?

I'd support this, too.

Since I found no way to link the TRV to a remote temperature sensor so far after trying around w/ device bindings and reading ZigBee spec + TRV docs.
(Sceanrio was: Thermostatas near ground w/ wrong/too low temperature values so that regulation is faulty because of wrong feedback values)

As solution only was to work around this problem is to implement / use an PID algoirithm/template in Home Assistant or NodeRed and link these entities on higher application level.

As @cinemarene described this solution provides much more possibilities like time and based automations.

Implementing direct valve position control would involve creating config resources for setting the target valve position and TRV mode, and maybe a state resource to report the actual TRV mode. I’m still seeing occasional hiccups where deCONZ temporary loses the route to the TRV, so it might be prudent to update these using the config.pending mechanism. That’s a fair amount of work.

Personally, I daren’t set the valve position before the routing issues are resolved. I’m actually quite happy with the TRV’s PID algorithm, where needed using the temperature offset to correct the TRV’s measurement. My challenge is to align the setting of the room thermostat of my central heating to the TRV setting (whose PID algorithm gets thrown off when the boiler is not providing heated water), so I won’t be working on valve position control anytime soon.

I’m still seeing occasional hiccups where deCONZ temporary loses the route to the TRV

Yeah, that would be quite error-prone and could end up in a sauna, especially since one of my thermostats looses connection for longer periods actually, too ;-)

I’m actually quite happy with the TRV’s PID algorithm, where needed using the temperature offset to correct the TRV’s measurement.

I agree, the implementation of another PID would be a workaround only.
In the meantime I'll play a bit around w/ the temperature offset and maybe have a deeper look into the remote sensor thing.

I can't get deCONZ to detect my Spirit ZigBee. I opened the deCONZ web app and chose add new sensor. Next, I put the thermostat into pairing mode (sceen shows INS) by inserting the batteries and installed it to the radiator. However, the conbee II stick / deCONZ web app does not detect my devices (tried 2 of them). I tried it several times, also with new batteries. I even put the thermostat directly next to the stick - nothing worked.

How did you manage to pair deCONZ and the Spirit Zigbee?

Try to connect to deConnz via VNC. Than I was able to connect.

Ty, now I am one step further. I am connected to deCONZ via VPN. However, I am running Hass.io and Home Assistant 0.98.5. If I choose Permit Join it sais please use the WebApp for joining. However, if I click on open WebApp nothing happens. How can I open the WebApp? I just now how to connect to the Phoscon App and not to the WebApp.

Update: Found the old WebApp, but still the device gets not detected.

Is there something that I miss as I am not used to the new GUI(s) aside of Phoscon?

I have same setup. You have to enable connection i plugin config. Then use VNC client to connect. Then you will see your devices.

an you will see

Thank you very much!!! I got it in deDONZ and did the discovery in the control menu as discribed in the user manual. Are there any further steps to expose it to home assistant?

If you succeed you should see

in HA in integration = deCONZ

if you don see you can try this...not sure about exact steps,...

click on thermostat entity, then Cluster info (left down corner) you need to have two dots in the box.

could select Device enabled and try click read. After few tried I see second dots and thermostat apeard i n HA.

Or you can try repair thermostat.

I repaired it a few times and now I have two dots. I read all the entities. If I change the temperature on the device, I can also read the updated value. Nevertheless, the entity device enabled returns unsupported attribute and is now grey. I also can not change its name

BTW all basic device settings seem to be unsupported:

I got it working now. Thank you very much for your help @rkotulan.

The essence is that it took ca. 7 tries of removing and re-joining until the TRV was recognized as "Thermostat 22" instead of the hex name. I do not know why but suddenly immediately after the last joining it got directly recognized in HA.

I will integrate the other two the next days and report in case I make some deviating observations.

Finally a could figure out the working way to pair this device properly (so it's exposed to REST API and shows up in Home Assistant). Here are the steps:
1) Place the device right next to ConBee stick
2) Reset the device (hold all 3 buttons for 10 seconds than release till it's rebooted and shows "Jin" on its screen)
3) Open Phoscon app and start searching for new Sensors
4) Connect to Deconz via VNC and look for new device. It's green dot should be solid green
5) Wait till dot start flashing from time to time
6) Open Basic cluster Info and click read
7) After that, the name of device should change from hex number to Model Identifier and pairing process at Phoscon app should finish successfully.

After that, I placed thermostat on radiator and pressed Boost button two times to start calibration. Now, everything is working properly.
P.S> I think, that the problem here is with Deconz software. It should read the Basic cluster, when solid dot on node start flashing automatically, but it doesn't, so user have to do it manually to finish pairing process.

Thanks @airens ! The instruction was very helpful. The thermostat finally appeared in HA

I also can confirm that @airens method works! (RaspBee Bridge on a stand alone Raspberry Pi, connected to hass.io)

Thanks!

After a few annoying hours, I managed to connect the Eurotronic spirit with deCONZ. I can read and overwrite values in the cluster info, but the Eurotronic spirit does not appear in the Phoscon app.
I tried to connect via a node to the thermostat and installed node-red-contrib-deconz in Node Red. With the deCONZ in-node, I can call the Eurotronic spirit and see the ON status, the opening ratio of the valve and the reading of the internal temperature sensor.
What I do not see is the current temperature setpoint, an I have no options to change the setpoint.
Any idea how this could work? I think may the deConz out-node, but how?

I can confirm @airens steps. Reading the basic cluster was an important point.

@dresden-elektronik: that would be great, if the component could be read out automatically, like any other.

Error in Phoscon App: it was recognized and works in HA, but still does not appear in the Phoscon App under "Sensors"...

PS: I had a strange behaviour in home assistant after setting a new target-temperature, the instruction was given correct to the thermostat, but then the the temperature at the web-gui in home assistant jumped back to the old value while the thermostat worked right.. after some waiting the error seemed to vanish on its own.. right on the pile of unreproducable stuff and thanks for the fun with debug mode @homeassistant 👯‍♂

Can the Eurotronic Spirit ZigBee at this point be paired just by using the Phoscon app? I plan to get one of these but my deconz is running in headless mode and i have no access to the UI (running on Raspbian headless).

You can connect to Conbee with VNC.

How would i do that?

I thought that the Phoscon app is what should be used to pair devices... Why this still cannot be done with the Eurotronic Spirit ZigBee?

How would i do that?

I think connecting directly to conbee was a misunderstanding, at least i don't know how that could be possible. But you cann connect to the deconz-gui via raspi vnc:

Good Instructions for VNC on Raspi
https://www.elektronik-kompendium.de/sites/raspberry-pi/2011121.htm

Autostart VNC Server
sudo x11vnc -storepasswd /etc/x11vnc.pass
sudo nano /lib/systemd/system/x11vnc.service

[Unit]
Description=Start X11VNC
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -display :0 -auth guess -forever -loop -noxdamage -repeat -rfbauth /etc/x11vnc.pass -rfbport 5900 -shared

[Install]
WantedBy=multi-user.target

sudo systemctl enable x11vnc.service

Then you can connect with Tools like "Chicken of the VNC"

To run deconz-gui on autostart there should be enough info, if you google. Just be a bit patient when the gui starts automatically because at first you will see the screen where you can select a decive (like conbee) and just have to wait some seconds for auto-connect to mesh-screen

I'm running Raspbian Buster Lite which has completely no desktop and this did not work for me...

Anyway, so why the thermostat cannot be paired with Phoscon? Will this ever be supported?

Is dresden elektronik also developing the openhab2 binding? I ask because the home assistant component contains the type "Climate" but the Openhab2 binding does not.

@merdok @donchrizz
There is another way of remote handling if vnc does not work or you want so save memory and just want to use the gui as debug option. Forward X11 to your desktop.

e.g. with Windows
1) Install Cygwin & and exclude in Windows firewall / turn off firewall
2) Open Cygwin64 terminal
3) execute: startx -- -listen tcp &
4) execute: xhost + [ip_of_your_deconz_conbee_runnig_host]
5) edit /lib/systemd/system/deconz-gui.service
6) Modify line - Environment="DISPLAY=[ip_of_your_deconz_conbee_runnig_host]:0"
7) execute: systemctl stop deconz
8) execute: systemctl start deconz-gui

When finished just stop the gui and start deconz without gui.
When repeating that you need to xhost on cygwin again to allow the session.
Error might occur with windows firewall - you might want to turn it off for the time given.
After deconz update you might need to redo 5 & 6.
That way I do not need x11vnc running.

Good luck!

PS: I am looking forward to that day where Eurotronic can be added and operated like any other Ikea bulb/switch too. ;)

PS: I am looking forward to that day where Eurotronic can be added and operated like any other Ikea bulb/switch too. ;)

I support this wish wholeheartedly!

In the meantime, can anyone point me to some information how the Spirit Thermostat is exposed to homeassistant? Especially, I would like to know if there are any preset_modes defined that could be set by the climate.set_preset_mode service. Furthermore, is it possible to trigger the boost mode from homeassistant?

Best regards

How to add it was covered above with GUI and how to join and read the cluster. This way the joining process should finish and REST API expose the values. As it was not working very well I added it to a zigbee (CC2530) adapter and I am using iobroker and I can't help you there. These are the states you should get.

If you manage to add it this helps you further in terms of setting states on the display or modes. Window on/off, etc. Just add the values convert it from HEX to DEC and set spz_system_mode accordingly.

I haven't found anything on the net and I also know that development is going on here, but I don't know where else to ask. Do yours also make the decalcification trip (Entkalkungsfahrt) every Monday around 6 o'clock?

I believe "Entkalkungsfahrt" is not what you wanted to say :) maybe you can explain?

Every Monday at 6 a.m. each of my 5 thermostats opens and closes valves once. Very annoying when you are asleep. They do that too, even if you reset them and they are not connected to any bridge. Encalculation mode or something.

He means what he say. It is not real for lime, it is more to do something against fixed valves.
before i start with eurotronic, i use homematic thermostats and they do this once a week to avoid fixed valves. And , i do not know, if i prefer to go back to homematic, because i have a lot of trouble with the eurotronic thermostats. they lose the connections and then you have your personal sauna. I write a message to eurotronics and ask, if it is possible to shut the valves on error and there is no answer. 100% open is very bad ...

He means what he say. It is not real for lime, it is more to do something against fixed valves.
before i start with eurotronic, i use homematic thermostats and they do this once a week to avoid fixed valves. And , i do not know, if i prefer to go back to homematic, because i have a lot of trouble with the eurotronic thermostats. they lose the connections and then you have your personal sauna. I write a message to eurotronics and ask, if it is possible to shut the valves on error and there is no answer. 100% open is very bad ...

Mine never lost connection for half a year now. I know it for sure, because I’ve just checked Home assistant logs. I think, you need to improve signal quality by adding routers to your ZigBee net or try to find better position for Conbee.

@realwax thanks! I have used MobaXterm and got it the gui working. Now my thermostat is paired and works well!

@manup it would be good if the pairing could be done straight from the Phoscon app. It is pretty inconvenient right now. Is this planned?
Also a thermostat sensor type in the Phoscon app would really great!

Is anyone getting battery level information from the Thermostat on Home-Assistant? I don't see the associated battery sensor for the thermostat, and I'd like to monitor it. I can see battery indication via VNC when I enable "Read Power Descriptor" for the Thermostat; then I can see the battery icon, but even then on "Cluster Info" I see some inconsistent info:

On "Node Info" I get the correct reading:

The correct Battery info was loaded on "Cluster Info" after I clicked on the "READ" button:

It's also readable from Home-Assistant now:

@rsaffi :For me, the battery is not showing up in home assistant, no matter what i read.

I too have the battery levels showing up in homeassistant. I'm quite sure I did nothing beyond the pairing procedure mentioned above.

One bug in the homeassistant implementation I experienced though are the min/max values for the thermostat. While the manual specifies a range of 5-30C, homeassistant has 7-35C and setting the target temperature beyond 30 results in an error. I am not sure, if this is a problem with homeassistant or in deconz.

One bug in the homeassistant implementation I experienced though are the min/max values for the thermostat. While the manual specifies a range of 5-30C, homeassistant has 7-35C and setting the target temperature beyond 30 results in an error. I am not sure, if this is a problem with homeassistant or in deconz.

I noticed this as well, but forgot to report back. This is true: range on the device itself differs from Home-Assistant.

I can't vnc on my deconz. it runs in a headless docker container on my server. is there a way to get it full paired ? I paired it but it don't show up anywhere :/

As many here, mine also doesn't show up on the deCONZ web application under "Sensors", but it paired succesfully and it's seen from inside Home-Assistant. How do you know you've paired it if it doesn't show up anywhere?

Regarding VNC, you should be able to do it despite the headless docker container. Mine is also installed on a headless container running on a headless VM and I can VNC into it just fine.

@rsaffi After searching for the sensor in deconz, the green bar with "successful added" showed up

@rsaffi After searching for the sensor in deconz, the green bar with "successful added" showed up

Been there, done that. As the integration is as of now at least, your next step would be to connect to VNC, click on the Thermostat device, and click on "Read" for the "Basic" cluster info. Then your device on deCONZ will switch from showing the hexadecimal code to it's proper name and you'll be able to see it from Home-Assistant.

@rsaffi I know, mine is working perfectly ... I was answering your question:

How do you know you've paired it if it doesn't show up anywhere?

Been there, done that. As the integration is as of now at least, your next step would be to connect to VNC, click on the Thermostat device, and click on "Read" for the "Basic" cluster info. Then your device on deCONZ will switch from showing the hexadecimal code to it's proper name and you'll be able to see it from Home-Assistant.

Sorry if this is a stupid question, but does this mean that the Eurotronics thermostat will show up in Home Assistant and has working climate controls? I've recently started using HA, and haven't even dabbled in Zigbee2mqtt yet for example.

I've read many threads all over the place where they can't set a temperature. I've also seen all sorts of things but they're fairly old and things can change quickly.

A better question might be: What _isn't_ working if anything? Thanks!

Some context if it matters and anyone is interested:
I have water heated floors (I'm sure it's called something else) but my room thermostats doesn't work. So I can only change temperature for all rooms at the same time on a single thermostat in a closet (it's a regular radiator valve, like this Eurotronic one but old and analog). So far I've been guessing what temperature to set it to, since its temperature and the actual temperature in the rooms are very different.

I was hoping to, at least, easily do the same but from Home Assistant, and hopefully without creating scripts from scratch (because I'm still learning a lot). Basically easily be able to set the temperature to, for example, 22c. Perhaps the rooms will only get to 19c, but then I could just set the temperature to 25c and it'd be closer to 22c in the rooms.

Better yet, would of course be to be able to use my Xiaomi temperature sensors that I have, so I could set the temperature to 22c and the Eurotronic thermostat would use the Xiaomi sensors to adjust temperature. But I guess this bit is too much to ask?

Sorry for the long post, and thank you for reading!

@wuast94 Yes, there is. Just scroll up in the thread. I posted how to X11 forward.... Von Samsung-Tablet gesendet
-------- Ursprüngliche Nachricht --------Von: wuast94 notifications@github.com Datum: 17.10.19 23:24 (GMT+01:00) An: dresden-elektronik/deconz-rest-plugin deconz-rest-plugin@noreply.github.com Cc: Wolfgang realdjwax@gmail.com, Mention mention@noreply.github.com Betreff: Re: [dresden-elektronik/deconz-rest-plugin] [Device Support Request] Eurotronic Spirit ZigBee (#1098) I can't vnc on my deconz. it runs in a headless docker container on my server. is there a way to get it full paired ? I paired it but it don't show up anywhere :/

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098?email_source=notifications\u0026email_token=ADR3WLQL3G3DUVLCW3AVXBDQPDJ2VA5CNFSM4GOP7622YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBRSJNI#issuecomment-543368373",
"url": "https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098?email_source=notifications\u0026email_token=ADR3WLQL3G3DUVLCW3AVXBDQPDJ2VA5CNFSM4GOP7622YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBRSJNI#issuecomment-543368373",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]

Sorry if this is a stupid question, but does this mean that the Eurotronics thermostat will show up in Home Assistant and has working climate controls? I've recently started using HA, and haven't even dabbled in Zigbee2mqtt yet for example.

Yes, exaclty that. It works with Home-Assistant. As the development is right now at least, getting it to show up on Home-Assistant has just a couple of extra steps, but it's definitely working.

I've read many threads all over the place where they can't set a temperature. I've also seen all sorts of things but they're fairly old and things can change quickly.

A better question might be: What _isn't_ working if anything? Thanks!

Nothing that I'm aware of, honestly. I mean, the setup process still can be improved (without the need of the aforementioned extra steps), but other than that, it's all working.

I have water heated floors (I'm sure it's called something else) but my room thermostats doesn't work. So I can only change temperature for all rooms at the same time on a single thermostat in a closet (it's a regular radiator valve, like this Eurotronic one but old and analog). So far I've been guessing what temperature to set it to, since its temperature and the actual temperature in the rooms are very different.

I was hoping to, at least, easily do the same but from Home Assistant, and hopefully without creating scripts from scratch (because I'm still learning a lot). Basically easily be able to set the temperature to, for example, 22c. Perhaps the rooms will only get to 19c, but then I could just set the temperature to 25c and it'd be closer to 22c in the rooms.

Then go ahead and get one, because this is doable.

Better yet, would of course be to be able to use my Xiaomi temperature sensors that I have, so I could set the temperature to 22c and the Eurotronic thermostat would use the Xiaomi sensors to adjust temperature. But I guess this bit is too much to ask?

Can also be done, but for this you'll need to get your hands a bit dirty and writing the proper "Automation" for Home-Assistant, but it's definitely nothing out of this world.

I got curious about the possibility of using an external sensor for determining the current temperature...

In the Thermostat cluster I found the writable attribute Remote Sensing with the possibility to set "Local temperature sensed remotely", "Outdoor temperature sensed remotely" and "Occupancy sensed remotely" but no way to specify the external sensors.

A somewhat related question is whether it is possible to configure the "window open sensing" and configure an external window sensor as mentioned in the manual on p13 ("Die Fenster-Offen Erkennung kann durch einen externen Fensterkontakt aktiviert/deaktiviert werden")

Edit: Nevermind. I just realized that this was discussed earlier without success.

Hey guys,

i found out, that my spirit thermostats show a strange behaviour, when over some hours there is no change in temp in the room or no change-input from home assistant. Result: It will disconnect itself and no longer be in the zigbee netwerk. Solution: I press the middle button (o) of the thermostat and it is directly back in... feels like some kind of a sleep mode... anyone got any suggestions? At the moment I'm thinking about to drop the spirit thermostats and go to homematic without deconz...

cheers,
chris

I have had a similar experience. First time it happened I thought I made some mistake during the initial pairing process, so I reset the thermostats and repaired them. I had no problems for a week or so but yesterday one thermostat didn't react to temperature settings from homeassistant anymore. I changed the temperature manually once and now it's reacting fine again. Sounds like the same issue that you experienced. I thought it was just a random glitch but I'll see if there is a pattern, should it happen again.

is there a way to add the device via deconz, when you're using the deconz systemd setup?

When I VNC into my headless raspberry, I can stop the service and use the VNC session to see the device (I think. there's not that much info do actually identify it, tbh). But when closing deconz and starting the systemd service again, the device doesn't show up.

Have you followed the steps in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-460403451?

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.

I asked this in a different thread:
I still don't habe a clue how to get other than the useless values in ioBroker for this thing.
For example "heatsetpoint" appears in the log for the deconz adapter in ioBroker, but i can not read the value. I tried it with node Red.
Can anyone give me a hint?
Many thanks.

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?

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.

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

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 ?

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.

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.

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

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...

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..

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 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?

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

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!

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, ...

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..

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

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

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

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.

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.

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.

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.

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

@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.

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.

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

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.

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.

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.

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

@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 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

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.

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

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.

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.

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

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?

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?

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.

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

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.

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}

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.

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

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

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

sold out :(

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

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.

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

Hi all!
I very appreciate the work you do for this community!
Unfortunately I'm not familiar with all the tech in the background - just a normal user ;).

Can you already estimate when the Phoscon App supports the Eurotronic devices? I'm really looking forward to it because all I managed was to connect the device to the deconz GUI. Now I'm stuck...

//jacdec

Hi and first of all, thank you all so very much for all the great work with the deconz- and homebridge-hue stuff!

Now for my (hopefully not that stupid) question:
I’m running deconz in form of a raspbee shield on a pie 3 in headless (platform minimal) mode.
Is there any way, I could perform this step

• Go to deCONZ GUI, list clusters, click "Basic" -> "Read" (as recommended in #1098 (comment))

without going to the hassle to install a x11 environment or vnc setup?

I’d love to add four Spirits to my homebridge setup, but am missing the step to make the, available via the api :)

Thanks again and please keep up the fine work!

John

Thank you @ebaauw for the quick fix! Unfortunately I haven't yet had the time to check if it's working for me. I guess this fix will be included in the next release? Is there an ETA for the next release?

While I'm at it, I want to address some of the latest posts:

• @kugelkopf123 I believe people here are aware of the manual from eurotronics, but it seems the manual you linked is an updated version from October, although I could not spot any differences to the older version. In particular, the "remote sensing" attribute and the "window open detection" is not addressed in more detail than before. I have written to eurotronics, asking for clarification. I also directed them to this thread.
• @jacdec I too would appreciate it, if the spirit (and possibly more thermostats) were supported in phoscon. I believe, I read somewhere in this thread that this would require a complete reworking of phoscon. That being said, I believe at least exposing the sensors in phoscon and making the pairing process simpler and possible even in a headless setup would be great!
• @irrwitzer42 AFAIK there is no way right now to pair the spirit without the deCONZ Gui.

Best regards

From all I read so far, making use of a remote temperature sensor isn't possible with the Spirit. Is there a proper way of using it with Home Assistant? Something like "if temp below 23°C, set climate to valve 255" or "...set climate to Heat mode"? I'm not sure if valve control is possible from within HA..

Hi all.
Why its not possible to use 0x4003 Current Temperature Setpoint s16 rw to controle the thermostat? Because from my point of view it ist the needed Attribute or i'm totaly wrong?

Hi all, just got my Eurotronic Zigbee and I'm having trouble pairing it via deconz. The deconz web ui launches however, when I choose to add new device-> sensor and perform the search, then power on the thermostat, the join mode appears and the button does not start blinking. Am I missing some steps I should perform before I try to pair it?

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.

@ebaauw How exactly do you use the sniffer to reconnect the devices? I don't just have this issue with the Spirit, but with all ZigBee devices (1 Aqara Multisensor + 2 Xiaomi Motion Sensors).

Hi all

I installed the 2.05.72 beta yesterday. But I must report, that my problem is not solved. When trying to update two thermostats simultaneously one of the devices seems to register the change in temperature setpoint but the next time it sends a status report it reports the old temperature setpoint, which is in turn interpreted as a a manual change and thus f**ing up my schedule.

I could ask the developer of schedy if there is a way to delay the command to one device when updating a group, but this could only be a workaround and I consider this a bug in deCONZ.

I have a somewhat unrelated question, that is, in deCONZ gui there is this round status light on each device. I could not find any explanation what it means and what the different colors (green/blue) mean. I read somewhere that green indicates an unfinished joining process. Some of my thermostats are blinking blue, others green and some sometimes green and sometimes blue. I don't know what to make of it.

Lastly, @gacekk There is no way at the moment to pair the Spirit Zigbee via web UI you need access to the deCONZ GUI and perform the pairing process as described in this thread. Maybe a wiki-entry would be a good idea?

Best regards!

How exactly do you use the sniffer to reconnect the devices?

You don't. You use the sniffer to see to which router the end device sends its commands on MAC level (under the assumption that that's the former parent) and to confirm that the end device is missing from the response to the _Query Neightbour Table_ command (from the left dropdown in deCONZ GUI). Then you use the deCONZ GUI to force a re-connect by that router (by pressing the L key).

When trying to update two thermostats simultaneously one of the devices seems to register the change in temperature setpoint but the next time it sends a status report it reports the old temperature setpoint

Why do you think that the device seems to register the change? Did you read the 0x4003 attribute in the deCONZ GUI? If not, you're just seeing the deCONZ cache, which was updated when sending the command. But there's no guarantee that the command actually reached the TRV, let alone that the TRV honoured the command.

How do you update the two devices? The Spirit TRVs don't support groups, so you must be sending multiple commands. I've seen some issues with rules not triggering when I expected them to (#2148), so better double check the deCONZ log or use a sniffer to confirm that the gateway indeed sends the command.

in deCONZ gui there is this round status light on each device

If memory serves:

• Green: end device is polling the gateway (only for end devices connected directly to the RaspBee/ConBee);
• Blue: deCONZ is sending or receiving commands for this device;
• Yellow: deCONZ has sent a command, but didn't receive an ACK;
• Red: deCONZ hit a timeout on sending a command - this is what you'll see when the TRV has been disowned by its parent.

which is in turn interpreted as a a manual change and thus f**ing up my schedule.

I'm seeing the same sh*t. I tried a rule to again set the setpoint when receiving a report with any setpoint value other than the scheduled value, but then I can no longer manually override the schedule.

I'm thinking about implementing a finite state engine in deCONZ rules, that remembers whether there's still an unconfirmed setpoint change pending (using a CLIP sensor), resending the command, until the reported setpoint matches the target. After that, it would accept manual overrides.

However, that's going to have to wait until the X-mas holiday. Of course, this will work only after the Spirit has found a new parent router (either spontaneously or after rebooting it).

Ah and one more thing: Is it possible to update the firmware of the Spirit via deCONZ? My oldest spirits are _HW Version_ 34, _Application Version_ 18 with _Date Code_ 20190408 and OTAU _Current File Version_ 0x0122c380 whereas my newest are _HW Version_ 35, _Application Version_ 22 with _Date Code_ 20191014 and OTAU _Current File Version_ 0x0162e9d2

I also can't find any information about firmware updates on the Eurotronics homepage. The manual just says "A revision history is provided separately" but no hint where to find it.

Ah and one more thing: Is it possible to update the firmware of the Spirit via deCONZ?

Should be, once we'll have found the firmware. Mine are on 20181205 (which, according to the standard, should be the manufacturing date, not the firmware date, but I've seen many devices that use this as the firmware date) and _HW Version_ 34. The firmware has _SW Build ID_ 15181120 and _Application Version_ 15.

Why do you think that the device seems to register the change? Did you read the 0x4003 attribute in the deCONZ GUI? If not, you're just seeing the deCONZ cache, which was updated when sending the command. But there's no guarantee that the command actually reached the TRV, let alone that the TRV honoured the command.

When I first experienced this issue I could see that the valves are reacting to the new setpoint. But ~5 minutes later the previous setpoint was reported as the actual setpoint. I haven't confirmed that the command reached the TRV this time and I will investigate this more thoroughly tomorrow.

How do you update the two devices? The Spirit TRVs don't support groups, so you must be sending multiple commands. I've seen some issues with rules not triggering when I expected them to (#2148), so better double check the deCONZ log or use a sniffer to confirm that the gateway indeed sends the command.

As I mentioned earlier, I use schedy for homeassistant. This is a python scheduling framework which allows grouping devices into rooms. I am not sure how this works internally, but yes, I will be sending multiple commands for sure! I'll check the deCONZ log when I find the time.

Thank you for clarifying the colors of the status indicator. I have not seen a red status indicator, so I have not yet had a problem with parents disowning their children.

If there was a way to make sure that a setpoint change reaches the TRV or at least to react when a reported setpoint doesn't match a desired setpoint, that would be great! If I can be of any help by testing or something else, I would be happy to help!

Best regards

Edit: I am opening a new issue for this

How exactly do you use the sniffer to reconnect the devices?

You don't. You use the sniffer to see to which router the end device sends its commands on MAC level (under the assumption that that's the former parent) and to confirm that the end device is missing from the response to the _Query Neightbour Table_ command (from the left dropdown in deCONZ GUI). Then you use the deCONZ GUI to force a re-connect by that router (by pressing the L key).

To be honest I'm not sure I can follow. The sniffer shows me that the Spirit keeps sending a rejoin request and that my coordinator sends a rejoin response:

Request:

Response:

Here my deCONZ GUI:

Where is the _Query Neightbour Table_ now? I don't see it in the deCONZ GUI.
When I hit L (while selecting the Coordinator) it leaves and rejoins. Nothing happens when I do that to the spirit, even when I leave and rejoin by pressing the button at the top. Am I doing something wrong or is this just not working?

The sniffer shows me that the Spirit keeps sending a rejoin request and that my coordinator sends a rejoin response

I haven’t seen that before. Looks like the Spirit doesn’t accept the response and retries. Not too familiar with these commands, but shouldn’t the response contain the NWK address for the end device?

Here my deCONZ GUI

So the coordinator is your only router. In that case you already know what the parent router is supposed to be, so no need to find that out using the sniffer.

Where is the Query Neightbour Table now?

In the dropdown menu behind the left of the two circles on the right of the node.

Nothing happens when I do that to the spirit

That’s to be expected when deCONZ cannot reach the Spirit.

I haven’t seen that before. Looks like the Spirit doesn’t accept the response and retries. Not too familiar with these commands, but shouldn’t the response contain the NWK address for the end device?

Not sure tbh. I couldn't work it out, so I just reset it.

In the dropdown menu behind the left of the two circles on the right of the node.

Ah I see. So I had to select "Read Neighbour Table".

Okay so now that's more or less solved. Do you know how I get back the green lines from all the other devices? They are connected as it seems since my Motion Sensors work in HA. But the green line to the coordinator isn't coming back.

The lines are just a graphical representation of the neighbour tables. They don't indicate an active connection - there's no such thing in ZigBee - just messages. They're drawn when deCONZ queries the neighbour tables.

Hi all,
don't know if relevant, but maybe interesting to know that Amazon currently sells them today for 27,99€. Now I'm gonna replace all thermostats by those: https://amzn.to/2YRHqOB

@ebaauw I just tried to update my homebridge-hue to v.11.8. This is what happened. What do I have to do?

Open an issue with homebridge-hue. This has nothing to do with Eurotronic Spirit support in deCONZ.

I am using 3 spirit zigbees since this heating period and they are becoming periodically zombies. They no longer react to any command that I send via deCONZ / hassio. I also rejoined them several times and ensured proper zigbee coverage. Two of them are connected via the raspberry pi 4 that operates the conbee 2 stick - one via mesh over a hue light.

Phoscon GW: 2.05.72 / 12.12.2019
Firmware: 264A0700
Hassio Addon: V4.1
Hassio: 0.102.3
Spirit Zigbee Version: 20190408

Once they turned zombie I can get them back by pressing any of the buttons on the TRV so that they push their state again to the network.

Is there anyone that experiences these issues, too or has some advices what can go wrong?

In case I try to send a command to a zombie TRV, the log confirms that the command does not reach the TRV:
18:11:11:193 delay sending request 129 dt 0 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:293 delay sending request 129 dt 0 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:393 delay sending request 129 dt 0 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:493 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:592 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:692 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:793 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:893 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:993 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:093 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:111 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:193 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:293 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:392 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:423 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:493 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:515 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:593 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:692 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:793 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:893 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:992 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:093 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:193 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:214 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:293 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:393 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:492 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:510 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:592 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:614 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:692 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:793 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:893 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:993 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:093 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:193 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:292 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:312 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:393 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:493 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:593 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:614 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:693 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:713 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:793 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:893 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:992 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:15:093 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:15:193 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:15:293 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:15:392 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:15:412 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:15:506 0x00158D000192CF05 error APSDE-DATA.confirm: 0xD0 on task 18:11:15:506 max transmit errors for node 0x00158D000192CF05, last seen by neighbors 4124 s 18:11:16:008 don't close database yet, keep open for 900 seconds 18:11:17:274 no button map for: SML001 ep: 0x02 cl: 0x0402 cmd: 0x0A pl[0]: 000 18:11:17:274 ZCL attribute report 0x001788010213B2D6 for cluster 0x0402, ep 0x02 18:11:21:330 0x00158D000192CF05 error APSDE-DATA.confirm: 0xD0 on task 18:11:21:330 max transmit errors for node 0x00158D000192CF05, last seen by neighbors 4129 s

Once they turned zombie I can get them back by pressing any of the buttons on the TRV so that they push their state again to the network.

I’ve never experienced that. In my case, the gateway cannot reach the TRV, but the TRV can still reach the gateway (state.lastupdated continues to be updated). I need to power cycle the TRV (remove and re-insert the battery) to remedy the situation.

All my SPZB0001 TRVs just dropped offline drumroll 2^31 milliseconds after initially pairing them. Integer overflow, anyone?

Edit: They respond to cluster read operations, but they show up as disconnected in the deconz GUI.

One thought that comes to my mind: AFAICS the SPZB0001 consider the current time to be the start of the UNIX epoch, the RTC does not seem to be running. Is there a way to set the right time via the Time (0x000A) cluster?

I just got 2 of these toys. I managed to get them to show up in the gui and even set the temperature in the gui.
Unfortunately I can't find it in the web app and it doesn't show up in my domoticz either. Is there a way to get them there?

Unfortunately I can't find it in the web app and it doesn't show up in my domoticz either. Is there a way to get them there?

I had the same problem at first. Restarting the server did the job for me.

Unfortunately that didn't help. restarted several times. The gui shows both as connected but web interface still not showing them. I'm on v2.05.71. Do I have to upgrade to 2.05.72 for them to work?
That's my gui output:

EDIT: Updated to .72 and still the same

Unfortunately that didn't help. restarted several times. The gui shows both as connected but web interface still not showing them.

The Phoscon web UI won't show the SPZB0001, it will be available through the REST API, though.

The issue with the zombie TRVs still occurs more or less frequent, resulting in approx 15% failed triggers.

I am that annoyed as I spent hours of hours researching over the past months that I think I will write the vendor and ask what s* they are selling (that issue is reported vastly in the internet)

The issue with the zombie TRVs still occurs more or less frequent, resulting in approx 15% failed triggers.

I am that annoyed as I spent hours of hours researching over the past months that I think I will write the vendor and ask what s* they are selling (that issue is reported vastly in the internet)

Well i have 14 of this devices and i am more than happy. The only issue i had was, that sometimes one of the devices did not react to a command sent simultanously to 3 devices in one room. I solved this problem by delaying each command by a few seconds. Works flawless. Maybe you do not have a "server" like a lightbulb nearby and the signal is too weak. I have the devices on 3 floors and i love them.

I have 8 that, on occasion, seem to be kicked out by their parent router and won’t find a new parent. They’re still sending reports to the gateway (e.g. when changing the target temperature on the TRV), but commands from the gateway don’t reach the TRV. When I remove and re-insert the TRV batteries, it works again.
I haven’t been able to detect a pattern under what circumstances this happens. Some of my TRVs seem more vulnerable than others, but it has happened to all. They all run firmware 15181120. Most of then picked a Hue bulb as parent, but sometimes they pick an innr plug or even an XBee.

There an issue with the REST API plugin that rules based on /config.localtime and rules with a ddx condition sometimes don’t get fired, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2148. I use a lot of these for controlling the TRVs.

Hey guys, just bought one of these ZigBee spirit Thermostats to play with, but I am not able to get it connected to my network, though I have other devices like switches, bulbs, sensors connected with no problem. Could anyone help me find out what I am doing wrong? I have a conbee II connected to Home Assistant and the adding process is done the same way as for other sensors through web UI.
@Tobi0892 could you please help me connect my TVR to HASSIO? what steps do I need to take:
What I am doing is:

1. Open deconz web UI
2. GO to sensors and click on add new sensor
3. While scan is in progress I insert the batteries into TVR

I can see how the wifi icon is flashing on the TVR but nothing happens :(

Guys, let me chime in here since I got mine 2 days ago to evaluate if they could be an optional replacement for my fritz 301.

One striking thing I observed is that when the TRV looses connection to the coordinator for a longer time (let's say 18h), then it's kinda fubar. Literally nothing while sniffing (dedicated test gateway with only the TRV connected). No chance to get it back alive except for reset and join.

Anybody else made that experience?

@Valcob I assume you meant Phoscon? If not, try it there. Occasionally, i doesn't work on the first join attempt. Btw, it needs to be in join mode (jin on the display). Resetting is all 3 buttons simultaneously pressed for 10 secs.

Got the same problem as @Valcob here, Phoscon is not able to find the devices if I try to add them as sensor. Both TRV devices freshly reset and in Jin, middle button is blinking. Scan finishes with message Failed to connect in Phoscon. Other sensors and lights were connected without any problems at all.

I'm using a Raspberry Pi 3 with Docker and RaspBee.
Gateway-Version: 2.05.72 / 12/12/2019
Firmware: 26330500

I had a lot of troubles getting mine to be recognized correctly. What did the trick was following those steps:

• open deconz gui
• start sensor search in phoscon web service
• pair the trv with the network
• in the gui: go to cluster info and read the basic info while sensor search is still in progress.
  Those steps worked every time for me.

@SwoopX thanks dude u saved me :) the freaking manual says that I need to press the circle and plus buttons for ten seconds to reset the device but then I've checked the german version as well and noticed that actually u have to press all three buttons a freaking misleading instruction in english version damn it. Now I have my TVRs connected and can proceed with the tests :) thanks again

@michi1g Tried your suggestions and they seem to be paired now. At least I can see both devices in the deconz gui and modify some values there. But I still cannot see the sensors in the sensor view in Phoscon.

This is not possible at the moment, @githtz. The Spirits cannot be controlled via phoscon. They are nevertheless exposed via REST API and thus they should show up in homeassistant.

We really should put the pairing procedure and the information that the spirits cannot be controlled via phoscon in the wiki. The information becomes buried in this thread.

Hi guys, first of all I really appreciate your help: this thread is super useful! It saves a lot of time and effort for the initial pairing: it should have been written everywhere that the thermostats are not shown in the Phoscon app while they are shown in Home Assistant after the initial procedure (search for new sensors - read basic cluster info from deconz GUI)!

Anyway, as already said, I'm having the same troubles of someone of you: setting the temperature is working only during the first hours after pairing, then the integration seems not working anymore and it is necessary to go back to the reset-pairing procedure. Do you think this can be solved by an update of thermostat/gateway firmware? I'm using raspbee on raspberry pi...

Hi Guys, I have similar problem, moreover I am very new in this topic. I use Home Assistant (0.103.6; HassOS 3.7) on RPi 4 and I did these steps from @michi1g until the last one. Here, I cannot figure out how to "read basic cluster info from deconz GUI".
(I could pair Xiaomi Aqara sensors previously and I can read their data; trom these I concluded, my system works.)
After resetting my TRV, it shows connected status but I still cannot reach it under Home Assistant. Can you help me with a step-by-step procedure? :)
Thank you.

Hi @rollair as mentioned numerous times in this thread (I know it's a lot to read) you need to have access to the deconz GUI. That is not the Phoscon web UI but the GUI you see in the screenshots of the very first post of this thread. You need to read the basic cluster from the GUI to trigger the generation of REST-API entities. To this end you need to identify your TRV node, klick on the rightmost circle and then select the Basic cluster in the dropdown menu. In the left frame select the "cluster info" tab and hit "read".

See the screenshot in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-569644645 and one of the step-by-step instruction in this thread.

Unfortunately, I can't tell you how to gain access to the deconz GUI from a hass.io installation. But I believe I saw some instructions for that, too.

Sorry but i want to say this is all lost time. Earlyer or later you will
make a cut and the money and time is wasted . Normaly my goal is only
Zigbee , only with iobroker. But there is no zigbee thermostat that will
work without errors. I have more than one Sauna event and no response from
Eurotronic Support. And that' s why i go back to netter Systems for
Thermostats like homematic ip or salus.

Sk4zz notifications@github.com schrieb am Do., 9. Jan. 2020, 19:23:

Hi @rollair https://github.com/rollair as mentioned numerous times in
this thread (I know it's a lot to read) you need to have access to the
deconz GUI. That is not the Phoscon web UI but the GUI you see in the
screenshots of the very first post of this thread. You need to read the
basic cluster from the GUI to trigger the generation of REST-API entities.
To this end you need to identify your TRV node, klick on the rightmost
circle and then select the Basic cluster in the dropdown menu. In the left
frame select the "cluster info" tab and hit "read".

See the screenshot in #1098 (comment)
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-569644645
and one of the step-by-step instruction in this thread.

Unfortunately, I can't tell you how to gain access to the deconz GUI from
a hass.io installation. But I believe I saw some instructions for that,
too.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098?email_source=notifications&email_token=ADI5I4QJQFIHXGKVAATAIV3Q45TQJA5CNFSM4GOP7622YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIRITNA#issuecomment-572688820,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADI5I4VLHQ3AXI7XNY6IM73Q45TQJANCNFSM4GOP762Q
.

Sorry but i want to say this is all lost time. Earlyer or later you will make a cut and the money and time is wasted . Normaly my goal is only Zigbee , only with iobroker. But there is no zigbee thermostat that will work without errors. I have more than one Sauna event and no response from Eurotronic Support. And that' s why i go back to netter Systems for Thermostats like homematic ip or salus. Sk4zz notifications@github.com schrieb am Do., 9. Jan. 2020, 19:23:
…
Hi @rollair https://github.com/rollair as mentioned numerous times in this thread (I know it's a lot to read) you need to have access to the deconz GUI. That is not the Phoscon web UI but the GUI you see in the screenshots of the very first post of this thread. You need to read the basic cluster from the GUI to trigger the generation of REST-API entities. To this end you need to identify your TRV node, klick on the rightmost circle and then select the Basic cluster in the dropdown menu. In the left frame select the "cluster info" tab and hit "read". See the screenshot in #1098 (comment) <#1098 (comment)> and one of the step-by-step instruction in this thread. Unfortunately, I can't tell you how to gain access to the deconz GUI from a hass.io installation. But I believe I saw some instructions for that, too. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1098?email_source=notifications&email_token=ADI5I4QJQFIHXGKVAATAIV3Q45TQJA5CNFSM4GOP7622YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIRITNA#issuecomment-572688820>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADI5I4VLHQ3AXI7XNY6IM73Q45TQJANCNFSM4GOP762Q .

As i said: i have 14 devices and all work flawless since more than one month. In the beginning i had the problem that 1 device got unresponsive after a few days. But now, Zero problems. Maybe it is because i pull the heatsetpoint value every 15 minutes? So no device falls in deep sleep or whatever causes the error. I use them with conbee II on an Intel nuc via ioBroker. "Programming" is done with node Red. But i am an absolute noob...

i pull the heatsetpoint value every 15 minutes

Did you modify the REST API plugin for that, or are you using deconz-cli-plugin? Note that querying the device from the REST API just returns the cached state, and doesn’t result in any ZigBee messages.

Sorry but i want to say this is all lost time. Earlyer or later you will make a cut and the money and time is wasted . Normaly my goal is only Zigbee , only with iobroker. But there is no zigbee thermostat that will work without errors. I have more than one Sauna event and no response from Eurotronic Support. And that' s why i go back to netter Systems for Thermostats like homematic ip or salus. Sk4zz notifications@github.com schrieb am Do., 9. Jan. 2020, 19:23:
…
Hi @rollair https://github.com/rollair as mentioned numerous times in this thread (I know it's a lot to read) you need to have access to the deconz GUI. That is not the Phoscon web UI but the GUI you see in the screenshots of the very first post of this thread. You need to read the basic cluster from the GUI to trigger the generation of REST-API entities. To this end you need to identify your TRV node, klick on the rightmost circle and then select the Basic cluster in the dropdown menu. In the left frame select the "cluster info" tab and hit "read". See the screenshot in #1098 (comment) <#1098 (comment)> and one of the step-by-step instruction in this thread. Unfortunately, I can't tell you how to gain access to the deconz GUI from a hass.io installation. But I believe I saw some instructions for that, too. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1098?email_source=notifications&email_token=ADI5I4QJQFIHXGKVAATAIV3Q45TQJA5CNFSM4GOP7622YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIRITNA#issuecomment-572688820>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADI5I4VLHQ3AXI7XNY6IM73Q45TQJANCNFSM4GOP762Q .

It is a struggle witch conbee and deconz I have to admit. But that's a blueprint of the zigbee market. Yes the protocol is standardized but without a good integration of new devices or self integrating processes applied it comes down to who is faster.
In case of Eurotherm Zigbee the integration in the iobroker.zigbee adapter in combination with a koenkk flashed cc2531 works like a charm. It never gets lost and I can export it via iot adapter to alexa. In the end I am operating 2 zigbee networks with different bridges using the one operating better dependent of the sensor being used. Fingers crossed it will ever get a better integration in rest / conbee / deconz.

It is a struggle witch conbee and deconz I have to admit.

ConBee II / deCONZ seems to have a massive routing problem when the SPZB0001 isn't directly connected to the coordinator (routes are getting lost after a few days). Unfortunately, support hasn't responded to inquiries so far.

In case of Eurotherm Zigbee the integration in the iobroker.zigbee adapter in combination with a koenkk flashed cc2531 works like a charm. It never gets lost and I can export it via iot adapter to alexa. In the end I am operating 2 zigbee networks with different bridges using the one operating better dependent of the sensor being used.

Can you share more details on your setup? I'm ready to abandon ConBee II / deCONZ as soon as my CC2531 arrives from China. ATM, I'm using Home Assistant, so any kind of integration would be nice.

Has anyone been able to use the window-open detection after the devices have been paired? According to the manual the detection is disabled after pairing and I can confirm this. Any way to re-enable it?

//Edit

Ok, looks like the detection is still working, just quite sluggish. Is it possible to adjust sensitivity somehow?

@ginkel I would not recommend abandoning it. It's a solid product with a very good range in comparison to the CC2531 (without antenna or lights nearby). The grouping features, scenes etc. are very powerful like any other bridge like ikea, or philips. You can make use of all of that and include missing/malfunctioning devices on conbee with another zigbee network (on another channel) operated by the CC2531. That's precisely my setup. I have all my lights and much Xiaomi sensors/buttons on conbee stick but I operate all my IKEA and Xiaomi powerplugs and Eurotherm via CC2531. Never forget if yo do not use Phoscon you have to use iobroker scenes and stuff. Much work to do where dresden elektronik did a good job! I attach pics of my setup...

Guys, thanks for the help in this post so far: I got my Eurotronics regulator working on my ConnBee-II in iobroker - at least somehow...
A lot of struggeling when it wasn't recognized, many resets and then it worked.
But it seems the sensor is not correct implemented. I cannot see the target temperature, valve position etc. (compare my screenshot with the one from @realwax above)

Where can I start looking for a solution? Or did somebody experience the same and does know a solution?

@selen278 I guess that's a limitation of iobroker (or how deconz handles the thermostats). The target temperature of the SPZB0001 are stored in the config of the sensor and not as state.

I got the same issue here.

And that's what iobroker is showing.

@githtz I would not aim at iobroker since I have it running with all values with the zigbee adapter on a cc2531. The deconz plugin for iobroker should expose the deconz rest api and joined devices with all integrated parameters. I am not an expert here but from my understanding we are lacking of a proper deconz rest api implementation of Eurotronic Zigbee on first hand. If that's fixed you would have all the parameters. An on the other hand it's the bridge gui (Phoscon) not able modifying anything else than lights. (that is not really need for home automation but would be a good feature) Even though i got it working myself via deconz i switched to the cc2531 as it is more stable and reliable in use of the Eurotronic. Basically it depends on dresden elektronik and their devs sorting it out. Maybe I got something wrong - if yes - please excuse me, I don't want to bother anybody!

@realwax I don't know how things are with the iobroker I don't use it in my instance of home assistant everything is visible even the valve state and all is clickable and adjustable no problem


So I guess deconz is fine at passing the TVR info back to HA(homeasistant) the only thing I had is the way I need to connect the TVR with the network

1. Connect to the VNC backend of the deconz
2. Unpack the TVR and in phoscon web UI go to sensors click add new sensor
3. Given the TVR is unpacked and ready to connect put the batteries
4. Check the VNC at this stage it will show a device on the zigbee lan but nothing else should happen
5. Click the properties the most right circle on the appeared device card and the the basic cluster
6. On the left there is a button that says read cluster info click that one and you will see some info about your TVR
7. Reset the device (press all 3 buttons for 10 seconds)
8. It will go to connect mode again and this time it will appear as expected in the VNC mean all the info about the device will be on the card itself. And at the same time the device info will be sent to HA instance too.

That's it, should be simple enough to add more TVR I have 8 of them and have no problem like at all.
Just ensure u have enough repeaters in your house, mean any zigbee device (ikeea bulb, socket or anything that has power from mains) that can act as a repeater

Hope this helps

I've installed the home-assistant docker image on my rpi3 additionally to deconz and iobroker and voilà!

So I guess the TVRs are paired correctly, yay. Though I wonder why iobroker is not able to access the TRVs configuration. Maybe the iobroker-deconz-plugin does not support the deconz api completely?

Good to hear. So I was wrong regarding my thoughts on deconz rest api. Regarding iobroker deconz there was an update two days ago. Maybe one of with iobroker wants to retry? https://github.com/iobroker-community-adapters/ioBroker.deconz
I would do it myself but I have mine connected and integrated already.

I've tried it today and re-created my iobroker instance from scratch but still the sensors are read-only in the iobroker interface. Guess I'll create an issue at that project.

I can confirm that, i also cannot control them using iobroker. They appear but area read only, there is no way to set the temperature.

Seems like the latest version 1.2.3 fixes the problem! At least I can now see an modify the TRV values.

Can I somehow set the Name for the TRV? When I change the value in deCONZ it has no effect

No!
But you can use sqlitebrowser, and open~/.local/share/dresden-elektronik/deCONZ/zll.db
and change "SPZ0001" manually to whatever ;)
But backup your zll.db first 8)

I used postman to doing it via the API. Just get the API key from the Phoscon App and make a PUT to http://{$DOCONZ_HOST}/api/{$IP_KEY}/sensors/{$SENSOR_ID} with the following raw body: {"name": "{$NEW_NAME}"}

Is anybody else having issues connecting the Spirit to Hassio with deConz 5.1? I Updated my Hassio to 104.2 and after rebooting the Spirit didn't reconnect (another one did). So I deleted it via VNC and try to add it via Phoscon, but the Spirit isn't finding Hassio even though they're literally next to each other.

@Valcob Can you please elaborate what do you mean by 'And at the same time the device info will be sent to HA instance too'?
I'm trying to follow your instructions for a different brand of thermostat (eCozy) and I can read all the data in VNC but I'm not sure how to get the entity in HA. Running deCONZ on a conbee stick as hassio add-on, RPi.

@ddppddpp please open a new integration request or issue this one is for spirit sorry.

I have re-read the _whole thread_ given my last comments here were sometime back in October 2019.
So just to have it crystal clear at this moment (02.02.2020):

• The thermostat has to be paired by reading the cluster info on the GUI;
• The WebUI won't show the thermostat under Sensors tab;
• Anyone that has secondary routers (lights, sockets etc): if the thermostat connect to the network via those, at some point in time they lose that connection and can't automatically re-join the network, and one will need to remove and reinsert the battery;

Are these three points correct to this date?

If so, is there any WIP going on to address these to improve the support of these TRVs (pairing and WebUI) and also increase reliability (losing connection when the network has coordinator + routers)?

I have re-read the _whole thread_ given my last comments here were sometime back in October 2019.
So just to have it crystal clear at this moment (02.02.2020):

• The thermostat has to be paired by reading the cluster info on the GUI;
• The WebUI won't show the thermostat under Sensors tab;
• Anyone that has secondary routers (lights, sockets etc): if the thermostat connect to the network via those, at some point in time they lose that connection and can't automatically re-join the network, and one will need to remove and reinsert the battery;

Are these three points correct to this date?

If so, is there any WIP going on to address these to improve the support of these TRVs (pairing and WebUI) and also increase reliability (losing connection when the network has coordinator + routers)?

My 14 thermostats are connected through several lights and sockets and in the last 2 month i did not have a single case of lost connection.
I have a lot of sensors from aqara that are less reliable.

I have re-read the _whole thread_ given my last comments here were sometime back in October 2019.
So just to have it crystal clear at this moment (02.02.2020):

• The thermostat has to be paired by reading the cluster info on the GUI;
• The WebUI won't show the thermostat under Sensors tab;
• Anyone that has secondary routers (lights, sockets etc): if the thermostat connect to the network via those, at some point in time they lose that connection and can't automatically re-join the network, and one will need to remove and reinsert the battery;

1) and 2) are correct. For 3) I think there is IMHO a more general routing issue that is dropping devices from the network. Yesterday I lost some TRADFRI bulbs again after a SPZB0001 became inaccessible the day before. As support has been mostly ignoring requests for over a month now I have migrated to a CC2531 with zigbee2mqtt and am not looking back.

Edit: Using a Zigbee sniffer I could clearly see that the SPZB0001 is not losing connection to the network, but happily sending Data Request packets to its router, but when attempting to read a cluster from the deCONZ GUI it was clear that deCONZ is not sending any request in this case.

I have the deCONZ Phoscon WebApp running on a Raspi. Iam using the app Version 2.05.72 / 12.12.2019, Firmware 264A0700 as a service. Without the GUI, but with the webUI (which is excellent, by the way). I use zigbee lights and sensors to make them available in ioBroker and openHAB and it works like a charm. But I can confirm: With just the Phoscon-WebUI there’s no way to get Eurotronic Spirit thermostat paired at the moment. And I would really appreciate, if the Eurotronic Spirit ZigBee could be integrated in Phoscon WebApp, soon. Which, for my understanding, is the purpose of this _open_ device support request.

My workaround: I will not use the UI/VNC-App, so I had to use a CC2531 Stick instead (as proposed many times above), which is working ... a little unreliable (every 5th command works, the others just produce entries in the error log), but that does not bother me. As soon, as deCONZ WebApp supports this thermostat, I am going to switch.

What I find annoying: Eurotronic Spirit ZigBee is listed in the list of supported items (which was the reason for me to buy the conBEE2). The comment of that entry brings you to this very request page, where you read, that you have to use the UI-Version and do some technical stuff, that I really not clever enough for or you have to use a complete other gateway to get this thermostat paired (https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Supported-Devices).

The thermostat has to be paired by reading the cluster info on the GUI;

I don’t think that’s always the case and it’s certainly not an issue exclusive to the Spirit. Pairing battery powered devices is challenging, and I would really recommend having access to the GUI, to monitor and restart a stalled pairing process.

The pairing can definitely be improved, but that would require a refactoring of the corresponding code. Not something you do on a lost rainy Sunday afternoon. Probably best to combine that with the API v2.

The WebUI won't show the thermostat under Sensors tab;

Correct. After web REST API plugin adds support for a new device, each API client needs to add support as well. Phoscon is “just” another API client (that runs in your web browser).

And I would really appreciate, if the Eurotronic Spirit ZigBee could be integrated in Phoscon WebApp, soon. Which, for my understanding, is the purpose of this open device support request.

This repository is for the open source REST API plugin. Phoscon is not open source, so no-one here, except dresden elektronik themselves, can do anything about this.

Anyone that has secondary routers (lights, sockets etc): if the thermostat connect to the network via those, at some point in time they lose that connection and can't automatically re-join the network, and one will need to remove and reinsert the battery;

There are plenty of routing issues, especially on larger networks with mixed lights, but I don’t think these apply to the thermostat. I find that it remains connected to the network allright, and continues to send reports to the coordinator. However, the (previous) parent router no longer recognises the Spirit as a child, effectively rendering it unreachable by other devices (so you can no longer control or query the thermostat from deCONZ).

I’ve seen this on all my eight Spirits, but some seem more susceptible to this issue than others. When they choose an innr SP 120 plug or my lumi.curtain as parent, the issue appears within a day. When they choose one of my Hue lights, they might work fine for weeks. I see the same issue with my FYRTUR blind, incidentally.

I think this issue is caused by the Spirit firmware, in that it doesn’t (always?) recognise that it’s been disowned, and therefor doesn’t search for a new parent. I’ve had some occasions where it spontaneously found a new parent, but I haven’t been able to isolate the conditions for this. Power cycling/resetting the old parent sometimes seems to do the trick; power cycling the thermostat always does - no need to reset and re-pair the thermostat. I find on occasion, the thermostat has reset itself, and does require re-pairing.

In the spirit (pun intended) of full disclosure, I think there are two more issues:

• I find that sometimes commands don’t seem to reach the thermostat, even though it is reachable. I’m still debugging this issue, I found that sometimes rules don’t fire (see #2148), which will be fixed in v2.05.73. I fear we should have implemented state.pending after all, even though the Spirit seems to be a light sleeper, polling its parent every five seconds.
• Not all features of the Spirit are yet supported by the REST API plugin. In particular, you cannot change its mode and control te valve position manually. Imho it would be irresponsible to support that before addressing the issue above.

Exactly my experience!

1st Floor: Raspbee and one TRADFRI Driver 30W with three spirits connected to Raspbee or Driver
==> Everything works fine for weeks! They send reports and receive new heatsetpoints ;)

Ground Floor: Mixed Router Situation: innr sp120, osram smart plug01, ikea bulb
==> Only sending of reports goes on well. Setting a new heatsetpoint never reaches the target (4 other spirits, but all spirits are connected )

@githtz could elaborate on how exactly you got it to show up in home assistant?

Also, has anyone contacted dresden electronic about web phoscon support?

@LennyPenny Did you try this?
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-460403451

@githtz yea I got it connected to the ui but it's not showing in home assistant

ah okay never mind I got to work: clicking the "read" button in the deconz gui was the part I missed

@realwax I don't know how things are with the iobroker I don't use it in my instance of home assistant everything is visible even the valve state and all is clickable and adjustable no problem


So I guess deconz is fine at passing the TVR info back to HA(homeasistant) the only thing I had is the way I need to connect the TVR with the network

1. Connect to the VNC backend of the deconz
2. Unpack the TVR and in phoscon web UI go to sensors click add new sensor
3. Given the TVR is unpacked and ready to connect put the batteries
4. Check the VNC at this stage it will show a device on the zigbee lan but nothing else should happen
5. Click the properties the most right circle on the appeared device card and the the basic cluster
6. On the left there is a button that says read cluster info click that one and you will see some info about your TVR
7. Reset the device (press all 3 buttons for 10 seconds)
8. It will go to connect mode again and this time it will appear as expected in the VNC mean all the info about the device will be on the card itself. And at the same time the device info will be sent to HA instance too.

That's it, should be simple enough to add more TVR I have 8 of them and have no problem like at all.
Just ensure u have enough repeaters in your house, mean any zigbee device (ikeea bulb, socket or anything that has power from mains) that can act as a repeater

Hope this helps

You're a lifesaver man! I was mucking about and had forgot all about the vnc interface. Your explanation tought me about the vnc interface and the zigbee protocol. I too am now the happy owner of an fully operational TRV which works beautifully with HA, thnx!

@BeamMeUpTo @rsaffi
Did you guys find some kind workaround for that? I've got a sort of similar situation here now with two SPZB0001 (directly connected to the hub) working just fine but the third one is connected to various routers and it just stops working after a few days. :disappointed:

@BeamMeUpTo @rsaffi
Did you guys find some kind workaround for that? I've got a sort of similar situation here now with two SPZB0001 (directly connected to the hub) working just fine but the third one is connected to various routers and it just stops working after a few days.

I still haven't (yet) another device at home that behaves like a router, so I can't say for myself. I do have a friend that has a few routers and some Spirit Zigbee TRVs and has been facing the same problem. She even created a custom routine to force some communication between Home-Assistant and her TRVs every 2 hours, to prevent from "losing" them.

My first smart plugs will arrive between today and tomorrow, so I'll finally have other devices that are routers, I'll keep an eye to see if TRVs start misbehaving or not.

Edit: to be fair, all my lights are Philips Hue which can act as routers, but they are not connected to my Home-Assistant directly via Conbee+deCONZ, but rather using the Hue Bridge, so it's a separate Zigbee network.

@githtz - No, not really.

@tkintscher

Meanwhile, I've worked around this by reading the temperature from a Xiaomi sensor and adjusting config.offset. That worked perfectly, until your PR changed the units for the offset from 0.1 to 0.01 degrees.

Can you please explain me how did you do it? I'm new to this...
Also @ebaauw any news about the remote sensing?
thank you

Also @ebaauw any news about the remote sensing?

Why would you expect me to have any news? As far as I have been able to determine, the TRV doesn't support this function, even though it exposes the _Remote Sensing_ attribute. The manual doesn't mention this function, and Eurotronic support don't seem to react to email. There's nothing I can do.

just asking... thanks

Is there still no update on re-adding a TRV after rebooting the router? I somewhat regularely reboot it (Home Assistant on a RPI) to install updates. Usually, one of my two TRVs doesn't reconnect. Power-cycling by taking out the battery doesn't help, plus it keeps heating the entire time while trying to connect. Resetting everything is a pain in the ass since I have a few other devices that are connected.

@FlyingPersian I have the same situation.

@FlyingPersian I have the same situation.

Weirdly, after deleting the device in VNC and it re-appearing, the LED next to it keeps blinking green and blue, even when the device was off momentarily. Power-cycling, reading data, searching for new devices, etc. didn't help to re-add it :o I'm afraid that if I delete the device, it will be even more difficult to re-add it.

I had to reset the device and repeat all steps as for new device

I had to reset the device and repeat all steps as for new device

That usually doesn't work for me. If I do that, the device will not pair with deCONZ. I haven't tried since the latest updates, but I'm afraid to do so tbh.

If the device loses connectivity I get this fixed my disabling and enabling the device in Home Assistant. Sometimes I need to repeat that twice but it almost always gets the job done.

Is there still no update on re-adding a TRV after rebooting the router? I somewhat regularely reboot it (Home Assistant on a RPI) to install updates. Usually, one of my two TRVs doesn't reconnect. Power-cycling by taking out the battery doesn't help, plus it keeps heating the entire time while trying to connect. Resetting everything is a pain in the ass since I have a few other devices that are connected.

@FlyingPersian That's very odd, but all of the TRVs that I have always reconnect automatically when I restart HASS (due to an update, for instance).

Ahh, what I mostly do are restarts of Home Assistant itself (so deCONZ keep running). But a few days ago there was an update to the OS of hass.io and it rebooted and my thersmostats reconnected automatically as well.

Ahh, what I mostly do are restarts of Home Assistant itself (so deCONZ keep running). But a few days ago there was an update to the OS of hass.io and it rebooted and my thersmostats reconnected automatically as well.

Yeah, strangely, only one of my two devices re-connects. The other one doesn't.. Not sure why or how I could even find it.

Is this still something you look into?
I just bought 4 Thermostats and I managed it to connect 1, but even this one didn't work properly (couldn't control it via Home Assistant). I think I tried everything and it seems kind of random that it connects sometimes after several resets and so on. Right now I can see one thermostat in the Phoscon VNC GUI but it can't connect anymore and "Add new Sensor" on the WebApp doesn't work, too.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@Paragrimm Mine are still working. Since it's warm atm they're not used very often but I still can send commands to the thermostats (like screen-lock). But I've had a lot of problems with those, too :disappointed:
Can you modify the state of the connected thermostat from the VNC GUI?

I've just gotten two of these, and I would like to get them working as well.
@ebaauw Would it help if we tried to wake up eurotrinoc? What questions should we ask them?

• If they have newer firmware. Where they publish it.
• If/when/how they will support binding to an external temperature sensor.
• if they know of a bug in their firmware, whereby the TRV fails to detect that it’s parent has kicked it out and doesn’t find a new parent.

I asked eurotronics support in the beginning of the year for firmware updates. Their answer was that they have decided against making firmware updates publicly available. The reason they gave, was that many gateway manufacturers do not support updates. Whatever reason that might be.

Hey Erik, ok will do, what is TRV? :-)

Thermostatic Radiator Valve

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

I noticed that homebridge-hue sets the TRVs mode to "off" if its disabled within HomeKit. Does anyone know if the frost protection is still active even if the TRV is set to "OFF"?

I noticed that homebridge-hue sets the TRVs mode to "off" if its disabled within HomeKit. Does anyone know if the frost protection is still active even if the TRV is set to "OFF"?

For my thermostats, they revert from "off" mode to whatever mode was set before after 15 minutes. So it should not make a difference. (I assume that "off" mode is for some kind of window open detection)

@tkintscher Interesting! For some reason, mine keeps the "OFF" mode for several days. But if I read "Current Temperature Setpoint" it returns "500", so I suspect, the frost protection is still on. Maybe I got a newer firmware preinstalled? My "Application Version" is "22".

@titus-leistner That is interesting. Mine seem be an earlier version, where "Application version" is "15":

I believe that somewhere earlier the existence of different firmware versions was discussed, but there was no newer version available from the manufacturer for manual updating 😕

Since mine don't stay off, I have not looked into this much... but I would guess that setting it to "500" manually, instead of using "OFF" mode, would keep the frost protection on.

Mine seem be an earlier version, where "Application version" is "15"

Mine report are _Application Version_ 15 as well.

_Off_ mode (as well as _Boost_ or _On_) are set through the _Host Flags_ manufacturer-specific attribute, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-462077343. As side effect, they also change the heatpoint. I don't think you can set _Off_ through the on-device controls, and I have never seen it switch on automatically, but presumable, it's set on open window detection (i.e. sudden drop in temperature).

I noticed that homebridge-hue sets the TRVs mode to "off" if its disabled within HomeKit.

I'm afraid Homebridge Hue might not use _TargetHeatingCoolingState_ correctly. In HomeKit, you can set it to _Off_, _Heat_, _Cool_, or _Auto_, where the latter means heat or cool. Home greys out the tile when _TargetHeatingCoolingState_ is _Off_. It lights up the tile for the other vales. You can only change the _TargetTemparature_ when _TargetHeatingCoolingState_ is not _Off_. As the Eurotronic doesn't support cooling, the only logically valid values would be _Off_ and _Heat_.

Whether the _Thermostat_ is actually heating or cooling is reflected by _CurrentHeatingCoolingState_. It takes values _Off_, _Heat_, and _Cool_. When _Off_, the circle around the current temperature is green; when _Heat_, it's orange. I think it's blue when cooling, but I don't have a device to check. When _TargetHeatingCoolingState_ is _Off_, _CurrentHeatingCoolingState_ should be as well, and the circle is grey.

Not yet fully understanding this when adding support for the Eurotronic, Homebridge Hue currently sets _TargetHeatingCoolingState_ to _Heat_ for _Boost_ mode, to _Off_ for _Off_ mode, and to _Auto_ otherwise. I figured this would be a nice way to expose the _Off_ and _Boost_ modes to HomeKit. However, Eve only supports setting _TargetHeatingCoolingState_ to _Off_ and _Heat_ (it's displayed as _Mode_ with values _Off_ and _On_), because the Eve Thermo doesn't cool either. I now think it's semantically correct to use _TargetHeatingCoolingState_ for _Off_, but not for _Boost_.

Does anyone know if the frost protection is still active even if the TRV is set to "OFF"?

I would assume it will open the value when the measured temperature falls below 5°C. Never tried that out, though. To verify, best reset it, uninstall it from your radiator, re-pair it, and place it outside during winter, or place it in the fridge.

The paired device does not send updates and isn't available anymore when deCONZ is restarted

I paired my device as described above. Correct name appears in deCONZ, Temperaturregler appears in Phoscon and the temperature is shown. Blue and green blinking dots in deCONZ are shown.

Then I run following commands:

curl localhost:/api/FB61B91470/sensors/6 |jq

{
  "config": {
    "battery": null,
    "displayflipped": null,
    "heatsetpoint": 2100,
    "locked": null,
    "mode": "auto",
    "offset": 0,
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "49e35c802d0c3e55c4f1451a2af33fe1",
  "lastseen": "2020-10-16T08:53Z",
  "manufacturername": "Eurotronic",
  "modelid": "SPZB0001",
  "name": "Temperaturregler",
  "state": {
    "lastupdated": "2020-10-16T08:50:25.579",
    "on": true,
    "temperature": 2050,
    "valve": 255
  },
  "swversion": "20191014",
  "type": "ZHAThermostat",
  "uniqueid": "00:15:8d:00:05:3d:36:23-01-0201"
}

Notice battery, displayflipped and locked are null why?

curl --header "Content-Type: application/json" --request PUT --data '{"heatsetpoint": "2300"}' localhost/api/FB61B91470/sensors/6/config
[{"success":{"/sensors/6/config/heatsetpoint":"2300"}}]

deCONZ log output while setting heatsetpoint: https://pastebin.com/fkAAnVDP

Issues:

• temperature shown in Phoscon does only gets a single update right after paring, then never again
• after restarting, deCONZ shows a red dot when read basic attributes is pressed.

Questions:

• Does anybody know, why it initially updates the measured temperature but never honors heatsetpoint?
• Why does the communication get lost after deCONZ is restarted?

temperature shown in Phoscon does only gets a single update right after paring, then never again

Most likely, the API plugin failed to setup the appropriate bindings and attribute reporting settings. That could also explain the missing values for battery and locked and displayflipped. Do they fill when you manually read the corresponding attributes from the GUI (_Battery Percentage Remaining_, 0x001/0x0021, and _Host Flags_, 0x0201/0x4008)? See the user manual under help how to setup the bindings and config manually. Or try repairing. Be sure to double-check the batteries: pairing requires more power than regular operations.

Does anybody know, why it initially updates the measured temperature but never honors heatsetpoint?
Why does the communication get lost after deCONZ is restarted?

I doubt that's related to restarting deCONZ. I've had my TRVs become unreachable quite often, until I moved them to a separate network with only one router (a Trådfri repeater) in addition to the RaspBee. As far as I've been able to determine, they were kicked out by their parent router, but failed to notice and find a new parent. Note that in this case, they would still send reports to the gateway, but gateway commands wouldn't reach the TRV.
This seems to be an issue in (between) the TRV firmware (and the parent router firmware), I fear there's little deCONZ can do here. The workaround remedy was to reboot the TRV (remove and re-insert the batteries).

Thanks for your reply Erik!

I reset the device and tried your suggestions which resulted in:

• displayflipped and locked still null
• battery is 90 after read button is clicked
• heatsetpoint is reported as 500 when read button is clicked (bit frosty in my opinion)
• writing 2200 or any other value for heatsetpoint permanently fails

You need to read/write the manufacturer-specific 0x4003 attribute for heatsetpoint; the standard 0x0012 attribute doesn't work for the Eurotronic. For display flipped and locked, you need to read 0x4008. There could still be a bug in the REST API that it'll only update the REST attributes when the value changes. Maybe try and update them from the API, or lock the display by holding + and - on the TRV.

My bad, used 0x0012 the first time, as you figured out ;-) . Tried 0x4003, read works while in pairing mode, after the device is paired, neither read nor write works. Do I need to read every attribute relevant to the api while in pairing mode to make the device working properly afterwards?

That's odd. The Eurotronic is a light sleeper and should be responsive to commands. Can you see in the GUI what parent it's using? What firmware version does it have (_Date Code_ and _SW Build ID_ attributes).

Screenshot shows deCONZ while TRV is in paring mode (basic attribute read once). Attribute Editor shows failed write attempt to 0201:0x4003. I then pushed the read button for SW Build ID and after a minute the values was read: 22190930.

That’s different (newer?) firmware than mine. Never found the Eurotronic firmware online, even though they seem updatable over the air.

Can you check how frequently the node blinks green? That’s when the TRV polls its parent router for any messages. That should be once every 7 seconds or more frequently for the device to be reachable. Otherwise, we need to implement config.pending for writing the config attributes.

The TRV might be forced awake by pressing one of the physical buttons. You might try that just before and during read or write of the attributes.

As far as I know, uploading/downloading firmware is not supported. So there is no chance to downgrade the firmware.

I edited my previous comment (sorry, my iPad thought it’d be fun to post it while I was still typing).

An hour after paring it's just solid green and does not start blinking if push the TRV's button

Suggesting it's constantly polling. That's normal after pairing, but should stop at the pain of depleting the battery real quickly.

Can you sniff the Zigbee traffic? If not, can you run deCONZ with --dbg-info=2 --dbg-aps=2 --dbg-error=1 and check the log. You should see messages that the TRV is polling the gateway (as its parent).

deCONZ is currently running with --dbg-info=2 flag and logs lots of these statements:
MAC Poll 0x02 0x164E
followed by a single verify 0x00158d00053d3623 is child node after 809128 s

If the other flags are needed as well I'll restart. But then the icon will most probably turn to gray instead of solid green.

What sniffing tool would you suggest (headleass if possible)?

I'm using ZShark with an original ConBee on a Raspberry Pi to capture the packets and Wireshark on a Mac to analyse them. See https://github.com/dresden-elektronik/deconz-rest-plugin/issues/405.

So do you see log messages that the _Read Attributes_ or _Write Attributes_ commands are being sent? And corresponding responses from the TRV?

You probably could compile a special deconz version where deconz can sniff most of the traffic if you're interested and have no sniffer available.

I do see the read in the log:
0x00158D00053D3623: update ZCL value 0x01/0x0201/0x4003 after 0 s
but not the failing write to 0x4003 (at least not for the search string 4003). How should the log message look like for Read Attributes or Write Attributes?

deCONZ --auto-connect=1 --dbg-info=2 --dbg-aps=2 --dbg-error=1 --http-port=8080 --pid-file=/deconz/deconz.pid is used to start deCONZ.

I do not have a second ConBee to sniff the traffic, so the sniffing tools are not an option.

Occupied Heating Setpoint 0x0012 can be written and TRV changes the display accordingly whereas 0x4003 can only be read. I'll ask eurotronic whether they have changed something in their firmware that affects writing 0x0012.

I assume that could still be related to the order of manufacturer specific attributes in general.xml. Eurotronic is not first, but 2nd if I recall correctly.

eCozy is 1st. Would you propose switching them for testing purposes, @SwoopX ?

You could even delete it if you don't have any eCozy. But yes, might be worth a try.

i have the same firmware version and also issue as dowhiletrue.
Within deCONZ i am able to write a value to 0x0012 which is shown in the display of the device - 2050 as example.

a query via API gives me this:
{
"config": {
"battery": 80,
"displayflipped": null,
"heatsetpoint": 2000,
"locked": null,
"mode": "auto",
"offset": 0,
"on": true,
"reachable": true
},
"ep": 1,
"etag": "d2affd7f0acd6f30e10e5fb9db713d4b",
"lastseen": "2020-10-20T19:45Z",
"manufacturername": "Eurotronic",
"modelid": "SPZB0001",
"name": "Thermostat",
"state": {
"lastupdated": "2020-10-20T19:45:51.313",
"on": true,
"temperature": 1950,
"valve": 38
},
"swversion": "20191014",
"type": "ZHAThermostat",
"uniqueid": "00:15:8d:00:03:2f:62:4f-01-0201"
}

and Openhab shows the value of 0x4003 until i press on "READ" in deCONZ again. Trying to change the value of the heatsetpoint in Openhab is not written to the HAVC.

I have also problems with swversion 20191014. I can write 0x0012 via deCONZ Gui but not from home assistant or deCONZ api. The heatsetpoint is also not refreshed in when I set it manually on the HAVC.

Same problem here!
this is the log with an error when TRV mode is changed in home or eve app from automatic to heating for example.

Can anybody help?

@olliox Questions/issues regarding 3rd party integrations shouldn't be asked here. Put them in their gits.

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/rest_sensors.cpp#L1086 might be changed to something like (in pseudo code):

attrId = swversion >= 20191014 ? 0x0012 : 0x4003
if (addTaskThermostatReadWriteAttribute(task, deCONZ::ZclWriteAttributesId, VENDOR_JENNIC, attrId, deCONZ::Zcl16BitInt, heatsetpoint)) {
...

Don't know how to get get swversion though.

Would you agree with that change @SwoopX and @ebaauw ?

attrId = 0x0012;

I just tested it, writing the setpoint to 0x0012 works for me on firmware 20181205 as well.

Do we need this distinction between the firmwares, i.e. is there any firmware which doesn't also accept attribute 0x0012 next to the manufacturer-specific 0x4003?

I’m on 20181205 myself. This is quite some time ago, but if memory serves, 0x0012 isn’t updated when the _Setpoint Raise/Lower_ command is issued, and 0x4003 isn’t updated when 0x0012 is set. Always using 0x4003 (for getting and setting the target) worked consistently, so I resorted to using that in the API.

Of course if newer firmware versions no longer support that attribute, we need to accommodate that. Making the bevaviour dependent on the software version seems the prudent way to go. Note that you’re mentioning the _Date Code_ values instead of the software version. The APi exposes either as swversion, depending on which attribute was read last. Not sure if there’s a ResourceItem, but probably safest to check the zclValue for the Zigbee attribute. Make sure to change also the attribute reporting settings, with the same version check.

The TRVs appear to be firmware upgradable, but I haven’t found any firmware files.

Hi there,

unfortunately i have the same problems like @alpha23 and @olliox. I just bought the Eurotronic Spirit Zigbee yesterday and i also have the same Date Code "20191014". It would be great if anybody could help us here.

Best regards :)

I will re-open this for now.

I have bought one at the beginning of September with Version 20191014 and could connect following this instruction:
https://forum.iobroker.net/topic/28785/how-to-eurotronic-spirit-zigbee-mit-conbee-ii

Bought two more yesterday with same firmware 20191014 and have problems to join those. Will try to get back with my docker versions.

Could need some help for further investigation how to configure my log to see what is happening. I have tried to set heatpoint through deconz directly. On the already connected device it works to set and hardware is updated:

On new device write fails

@DerOetzi In the new firmware the 0x4003 is no longer writable, to change the heat point you need to write to 0x0012. That is the whole point of the code changes that @dowhiletrue is suggesting.

@DerOetzi In the new firmware the 0x4003 is no longer writable, to change the heat point you need to write to 0x0012. That is the whole point of the code changes that @dowhiletrue is suggesting.

But both thermostates are reporting same Firmwareversion 20191014?

Mine has at 0x0030 (Setpoint Change Source) the values:

• Manual (selected)
• Schedule
• Zigbee

Maybe could be the solution.. but unfortunately it's a read-only attribute

@DerOetzi In the new firmware the 0x4003 is no longer writable, to change the heat point you need to write to 0x0012. That is the whole point of the code changes that @dowhiletrue is suggesting.

But both thermostates are reporting same Firmwareversion 20191014?

I have bought two units recently and both of them only work by setting the 0x0012, I guess eurotronic is moving away from writing into custom attributes and now uses the more standard set of attributes.

@DerOetzi : might be that 20191014 actually represents theDate Code rather than swversion as as ebaauw mentioned above and your models differ in another manufacture-set attribute. Are all attributes equal between the working and the nonworking model, if you read one attribute after the other for Basic, Power and Thermostat?

I noticed on my model that read basic attributes while paring does not always lead to the same attributes being successfully read. Maybe that could explain why one model works and the other not.

I checked twice the attributtes Basic (0000), Power (0001), Identify (0003) and Thermostat (0201), can't find any difference at ids, types, access and values at all.

My Basic-attributes are (maybe it helps you to compare the different versions):

Regarding the current temperature setpoint, the manual from 10/2019 says:

[]https://eurotronic.org/wp-content/uploads/2019/11/Spirit_ZigBee_BAL_web_DE_Okt.-2019.pdf

Mine look pretty much the same. Notice the difference between Date Code and SW Build ID.

Since there might be drawbacks when just switching from 0x4003 to 0x0012, I suggest to set the attribute dependent on the SW Build ID. Any more sophisticated solutions are highly welcome.

You're right. I have the same values. I didn't know that you have to doubleclick an attribute to read that attribute explicitly.

The longer I look at the problem, I believe that it is still due to the addition to deconz.

Both the working, "old" one from September and the new one from now reports following values on basic attributes:

• 0x0006 DateCode: 20191014
• 0x4000 SW Build ID: 22190930

The longer I look at the problem, I believe that it is still due to the addition to deconz.

Both the working, "old" one from September and the new one from now reports following values on basic attributes:

• 0x0006 DateCode: 20191014
• 0x4000 SW Build ID: 22190930

Each paring behaves differently, because not all available values from basic are read, when read button is clicked.

Does anyone know, why some attributes do not appear when the read button is clicked but appear if the read button for a single attribute is clicked?

For testing purposes I changed the code as follows:

DBG_Printf(DBG_INFO, "TEMP %d for sensor attribute %x\n", heatsetpoint, 0x0012);
if (addTaskThermostatReadWriteAttribute(task, deCONZ::ZclWriteAttributesId, VENDOR_JENNIC, 0x0012, deCONZ::Zcl16BitInt, heatsetpoint))

log output shows log statement, but nothing changes afterwards, why?

I can also confirm that on a Spirit Zigbee bought around September 12, I can write to both 0x0012 and 0x4003.
On 4 Spirit Zigbee's that I bought this week, none of them 0x4003 is writable, but 0x0012 is.

All 5 devices have
Date Code 20191014
Product Code 1991
SW Build ID 22190930

Only the older device currently responds to temp commands from HA.

Using Conbee II, Phoscon 2.05.84, Firmware 26650700
HassOS 4.15 with deCONZ 6.4.1 add-on, HA 0.116.4

All 5 devices have

Are you sure? There’s no way to distinguish the device that does allow the setpoint to be set through 0x4003 from the four devices that don’t?

I have found no distinguishing attributes in the basic clusters of both devices. If you like I can link screenshots of both.
Just to be sure, I have first read the basic cluster and then individually double-clicked and read every entry individually as well.

Even external physical appearance is exactly the same - no difference in attachment ring.

The only difference I have noticed, is that the MAC address of the older, working one ends in 2XXX, while the 4 that don't work have MAC addresses ending in 3XXX

One more thing, FWIW:
I had a look at the STD OTAU Plugin. For each of the 4 non-working thermostats, the OTAU Update tab shows no data, ie. 0x000 for all fields. For the one thermostat that does work the values are:
Vendor = 0x1037
Image = 0x110c
Version = 0x0162e9d2

Not sure if that is of any significance, but I thought I'd share it anyway. :)

If there is anything else I can do to compare or provide information about the devices, let me know.

I recently bought a Sprit ZigBee as well and facing the same problem (can set temperature via 0012, but not via 4003). The attributes on the Basic page are the same as petermarasek has, so also no difference to the older thermostats. The MAC address also ends with 3XXX.
I already tried to compile a tweaked version of the rest api, but without success (api runs, no change to thermostat, buttons don´t report changes anymore). If someone would tweak the code I could assist testing with the new thermostat.

Even external physical appearance is exactly the same

@petermarasek That is to be expected. The difference is the device firmware.

For completeness: here's the _Basic_ cluster of the old firmware:

And the OTAU view (with 8 Eurotronic Spirit TRVs). I have no idea if/how the firmware file version relates to the _SW Build ID_.

For each of the 4 non-working thermostats, the OTAU Update tab shows no data

@petermarasek, the rows will populate eventually (the TRV needs to query the _OTAU_ server), or you can try and force that by selecting the node and pressing _Query_.

On the non-working thermostats, what status code is returned when trying to write the 0x4003 attribute?

Did any-one already try remote sensing with the 22190930 firmware?

Has any-one contacted Eurotronic support?

@petermarasek, just a wild thought: what the value of 0x4000 on the TRV that works, and on the ones that don't. I could image the TRV not accepting 0x4003 when 0x4000 has the wrong value. This attribute switches between setpoint mode and controlling the valve directly (bypassing the TRVs PID algorithm). The manual suck at explaining the details...

0x4000 = default value is "manual". If you set the attribute to "Unknown 1", the TVR overwrites it with "manual". If you set the attribute to "Unknown 2", the TVR doesn't overwrite it, but changing 0x4003 doesn't work yet.

As I wrote above all attributes of Basic, Power, Identify and Thermostat are same for working and not working. Checked again 0x4000 no difference

On the non-working thermostats, what status code is returned when trying to write the 0x4003 attribute?

Did any-one already try remote sensing with the 22190930 firmware?

Has any-one contacted Eurotronic support?

I have contacted the Eurotronic support and gave them the URL of this thread. Hopefully they answer and manage to clear up the confusions here :)

Hi,

i have the Danfoss Ally which is very similar to the Eurotronic, i've found that setting the setpoint seems to work fine. The screen on the thermostat updates instantly, however the valve motor sometimes reacts immediately even to large 10 degree+ changes, but sometimes it can take hours to move. I imagine this could be due to PID, but have no idea how to circumvent that.

Hi, I got one Spirit Zigbee yesterday and tried to pair it, My setup is pi 3b+ with Hass 0.116.4 and conbee II.
I went into pairing it with Phoscon as a sensor but nothing appeared there, but on the de CONZ is showing as paired, hit the read button a couple of times and attributes are now populated, but still can not add it to Phoscon.
Is it possible to controll it vie Homeassistant at all? how can I add it as device?

Thanks!

The device don't appear in phoscon, you need a third app or use directly the api for that.

But it seem there is a problem with recent version, not all is clear.

I can also confirm that on a Spirit Zigbee bought around September 12, I can write to both 0x0012 and 0x4003.
On 4 Spirit Zigbee's that I bought this week, none of them 0x4003 is writable, but 0x0012 is.

All 5 devices have
Date Code 20191014
Product Code 1991
SW Build ID 22190930

Only the older device currently responds to temp commands from HA.

Using Conbee II, Phoscon 2.05.84, Firmware 26650700
HassOS 4.15 with deCONZ 6.4.1 add-on, HA 0.116.4

I have the same problem. Two Spirit Zigbees bought on July 30th are working fine. Two other Spirit Zigbees bought on October 20th are not working because 0x4003 is not writeable:

The Eurotronic Spirit Zigbee manual suggests writing to 0x0012 or 0x0014, not to 0x4003:

6.5.4 Current Temperature Setpoint
Any value written to Thermostat / Occupied / Unoccupied Heating Setpoint attribute (0x0012 or 0x0014) will automatically be copied to the Current Temperature Set point attribute (0x4003) to allow operating the TRV without the need to be aware of the customer specific attributes.

I'm using Home Assistant 0.117.1, Phoscon 2.05.86, Conbee II Firmware 26580700

But there is no way to reconize the old / new device ?

But there is no way to reconize the old / new device ?

I've been looking at this for the last 2 weeks and the only difference I could find is in the MAC Id's of the TVR, but that is more of an observation than a certain difference.

The one TVR that has a writable 0x4003 has a MAC Id ending with 2XXX. I have four more TVR's that have a read-only 0x4003 and all their MAC Ids end in 3XXX.

But there is no way to reconize the old / new device ?

I've been looking at this for the last 2 weeks and the only difference I could find is in the MAC Id's of the TVR, but that is more of an observation than a certain difference.

The one TVR that has a writable 0x4003 has a MAC Id ending with 2XXX. I have four more TVR's that have a read-only 0x4003 and all their MAC Ids end in 3XXX.

Unfortunately i can't confirm that. The MAC ID of my TVR which have a read-only 0x4003 ends with 261A. :(

So, why not just testing method 1 and if it fails, use method 2?

So, my two Eurotronic Spirits (both end with 3XXX) are not able to write at 0x4003. As observed however, i can write to 0x0012 without any issues and as discussed, this leads to immediate setpoint change on the device. Is there any way I can manually alter the address that deCONZ is using to set the temperature? I am using deCONZ on Hassio and the problem seems so easily solvable if I could just find out how to change 0x4003 to 0x0012, right?

So, why not just testing method 1 and if it fails, use method 2?

So I'm really not a fan of exceptional programming.

I want to summarize what I have understand so far. So please correct me if I'm wrong!

All devices with following attributes work as expected, when setting temperature to address 0x0012:
Date Code 20191014
Product Code 1991
SW Build ID 22190930
MAC ends with 2XXX (those work with 0x0012 and 0x4003 as well) or 3XXX (those only work with 0x0012)

Devices like the one of @ebaauw with following attributes only work on address 0x4003 as expected:
Date Code 20181205
Product Code 1001
SW Build ID 15181120

So in my opinion we can decide by one or all three attributes Date Code, Product Code or SW Build ID which address to use, if we can be sure that the first mentioned group really work as expected on 0x0012. For having 3 devices of this group one with 2XXX and two with 3XXX I can confirm this correct behavior for me.

Did anyone try to make "remote sensing" work on one of the new devices? Would be great if they implemented this.

And BTW, no one have "segmentation fault" when adding the device ?

Hi! I also bought a Eurotronic Spirit Zigbee recently and I am experiencing exactly the same problems (can write to 0x012 but not to 0x4003).
Since it seems that there is no clear way to distinguish between the old or newer version: what happens if we do it the other way around and just always send 0x012? How do the old version of the thermostat react to that?

Sorry, I just read an earlier post describing that writing 0x012 is problematic on the earlier version.
@petermarasek Is writing 0x012 to the device that does accept the 0x4003 code also problematic? Otherwise the check on Date Code (or one of the other attributes) could still work.

I just discovered some more bad news: In my Eurotronic Spirit unit it also seems that the Current Temperature Setpoint (the values retrieved by 0x4003) is also not consistently updated after manually operating the unit :( On the other hand the 'Occupied Heating Setpoint' (the 0x012 value) is getting updated consistently after manually operation. So I think this value should also be used to read the current set temperature of the newer units... What a mess...

@petermarasek Is writing 0x012 to the device that does accept the 0x4003 code also problematic? Otherwise the check on Date Code (or one of the other attributes) could still work.

The TVR that accepts writing to 0x4003 also accepts writing to 0x0012 and 0x0014. (Occupied and Unoccupied Heating Setpoint). Writing to 0x0012 or 0x0014 automatically copies these values to 0x4003 as per the documentation and personal observation.

The TVR that accepts writing to 0x4003 also accepts writing to 0x0012 and 0x0014. (Occupied and Unoccupied Heating Setpoint). Writing to 0x0012 or 0x0014 automatically copies these values to 0x4003 as per the documentation and personal observation.

Ok, that sounds encouraging! So maybe we could use the HW version or any of the attributes to find out which code to send to the TVR. And then do the same when reading the current temperature.

@petermarasek Thanks for checking!

Okay, I´m a little bit confused now...

When I used to investigate how to set the heating setpoint on my new thermostat I saw another thermostat (which I bought last year) with the same SW version like the not working one.

I opend the DeCONZ GUI and verified that both units have the same hardware and software versions:

The funny thing is that the unit called "Küche..." dos not report an error, if I write to 0x4003. Even if I use the buttons to adjust the temperature manually the stetted value is reported correctly. Everything is working like expected.

The unit called "Büro..." reports an error if I use to write to 0x4003 and don´t report any changes.

Both units came in a box with golden printings on it. All other units I own had a box with green printings.

Maybe there are some buggy units out there?

@alpha23 This is the experience that quite a few here have described. It seems that Eurotronic has produced batches of the device that do not allow writing to 0x4003 and some that do, without them having any differential attributes, physically or according to basic cluster attributes. In my opinion, this isnt a bug, but by design. The latest available documentation states that writing to 0x0012 and 0x0014 is allowed and in line with specifications, instead of writing to 0x4003, which I believe is a manufacturer specific attribute according to this: (See Section 6.5.4)
https://eurotronic.org/wp-content/uploads/2019/11/Spirit_ZigBee_BAL_web_EN_November-2019.pdf

@petermarasek But if all the newer models operate normally (both the ones that do and the ones that don't except writing to 0x4003) when reading and writing to 0x0012 we could reliably use the HW version, Date Code or Software Build ID to have a simple if-statement (or extent the current one) to send the right code (0x4003 for the HW version < 5 and 0x0012 for HW >= 5).

I am willing to make the necessary change to the source code but it will require some time since I haven't previously touched the deconz-rest-api code (or project for that matter) and I need to figure out how to set up a developer test environment (since I run deconz on my PI as plugin for HA).
Next to that, I only have a unit that does not work at the moment so I can not perform a regression test. I could only check that the changed code works on my unit when sending and reading 0x0012.

I am willing to make the necessary change to the source code but it will require some time since I haven't previously touched the deconz-rest-api code (or project for that matter) and I need to figure out how to set up a developer test environment (since I run deconz on my PI as plugin for HA).
Next to that, I only have a unit that does not work at the moment so I can not perform a regression test. I could only check that the changed code works on my unit when sending and reading 0x0012.

That would be great. I have absolutely no experience with any of this and since I am running on Hassio, I think for me there is not much to try. What i found was specific code in the thermostat cpp at line 454. (Sorry, if a screenshot of code is against the rules, I am new to github).
Here it checks, if the thermostat is from Eurotronic and specifically states to use 0x4003. Maybe this is of any help.

@petermarasek If it is by design there should be any difference in the firmware or the hardware. If both units have the same versions there should be another problem. For me the only difference between the working and the non working device is that I ordered the working one at voelkner.de and the not working one on amazon.de

@joukestoel I have one unit with HW version 5 which work with 0x4003 and one with the same HW version which does not work. If I use to write to 0x0012 on the working unit I have to read 0x4003 manually to get the updated value.

Like the documentation say the next problem is, that only 0x4003 is reportable. But this will not happen when I write to 0x0012 or use the buttons on the device to change the value.

Like the documentation say the next problem is, that only 0x4003 is reportable. But this will not happen when I write to 0x0012 or use the buttons on the device to change the value.

@alpha23 Which documentation are you talking about? I think the fix should be (as pointed out by @mod3k ) that the code used to read the current set temperature should also 'just' read the 0x0012 value and forget about the 0x4003 value. In the screenshot of the code attached by @mod3k it would mean that the if condition needs to be extended to check the HW version as well.

But since I am new around here (and the code base) I could be very well mistaken and I might be missing something altogether.

@joukestoel https://eurotronic.org/wp-content/uploads/2019/11/Spirit_ZigBee_BAL_web_EN_November-2019.pdf

The Y/N on the right say if the attribute is reportable or not.

@alpha23 Thanks for the link! And thank you for pointing this out. As I mentioned earlier I am new to the world of home automation and Zigbee devices so I have a lot to learn :s Does reporting mean that only reporting attributes periodically send their value to deconz?

I have to take back my earlier statement that I thought that the 0x4003 value was not updated. It turns out that the default reporting time is set to max 600 seconds. As a test I have overridden the configuration to report after 20 seconds max and now I do see the updated value in the 0x4003 attribute. This means that the code that reads the current set temperature does not have to change (and the change probably wouldn't have worked anyway since the 0x0012 attribute isn't a reporting attribute)

Yes i think the only change that has to be made is a HW dependent decision to either write on 0x0012 or 0x4003. I just manually wrote a new Temperature to 0x0012 and the value was immediately updated to 0x4003.

tbh: if I would write that code for just myself, I would just send the command to both ids. Sounds dirty, but whatever the thermostat would accept, it should be updated anyway

I have contacted the Eurotronic support and gave them the URL of this thread. Hopefully they answer and manage to clear up the confusions here :)

I have also contacted Eurotronic support and requested that they respond to this thread to explain how we can solve the current problem. I did not receive a response with a solution so far...

I have just added a pull request (#3626) which should fix our issues with changing the current heating set point.
It took me a while to figure out but next to writing to the earlier discussed 0x0012 attribute (Occupied Heating Setpoint) I also needed to send a generic manufacturer code.

To distinguish between older and newer units I have used the Software Version attribute. To units with a software version below 22190903 the old 0x4003 attribute will be written too. For models with SW version 22190903 and upwards the 0x0012 attribute will be used.

This fix works for my unit but since I only have one unit I cannot guarantee that it will work for older and other units as well so let us keep our fingers crossed 🤞

Wow that ws quick. Thanks a lot! I hope these changes can be implemented quickly. Until then I am using ZHA instead of deCONZ. Installed it yesterday and everything seems to work nicely there (ZHA integration uses 0x0012 per se).

Big Thanks to @joukestoel for this fix! Now we have to wait for the release, hopefully coming soon

For what it's worth: Can confirm https://github.com/dresden-elektronik/deconz-rest-plugin/pull/3626 has fixed the issue on my end.

Have a Spirit unit with SW Build ID of 22190930 and with version 2.5.87 of Phoscon/deCONZ I can now successfully control the heating set point from the REST API (and by extension, Home Assistant).

Did run into an issue where reading the basic cluster information (in order to setup the device in the REST API) did _not_ retrieve the SW Build ID information correctly (field remained empty). Had to explicitly "read" that field from the GUI for things to start working...

Also, totally unrelated: The Sensors documentation mentions the config-parameter to be heatingsetpoint whereas in reality it appears to be heatsetpoint...

I have just added a pull request (#3626) which should fix our issues with changing the current heating set point.
It took me a while to figure out but next to writing to the earlier discussed 0x0012 attribute (Occupied Heating Setpoint) I also needed to send a generic manufacturer code.

To distinguish between older and newer units I have used the Software Version attribute. To units with a software version below 22190903 the old 0x4003 attribute will be written too. For models with SW version 22190903 and upwards the 0x0012 attribute will be used.

This fix works for my unit but since I only have one unit I cannot guarantee that it will work for older and other units as well so let us keep our fingers crossed 🤞

I Have SW Build ID 22190930 and its working fine with the old variant(2.05.81 / 14.9.2020).
I am unsure if it will break if i update now?

I just got the new release running. Unfortumately have to report we are only half way done with the fix of @joukestoel on this problem. the Basic cluster 0x4000 SW Build ID attribute seems not to be read automaticaly after restart. For this the correct address 0x012 is only used, after manually reading this attribute. For the moment I only have three thermostates to do this after restart, but when I have 13 of them I will have the need to not do this manualy after each restart

Same problem here. If I restart deCONZ or Spirit, no more updates are received and the temperature can't be set anymore.

@DerOetzi @dowhiletrue Ah, sorry! Still learning this Zigbee Deconz stuff :) I'll make an improvement to the code so that it is more robust! Hopefully this can be included in the next release.

I'll keep you updated!

And noticed another problem on the new ones:

Modus switch to off is not working as well on those. I will try to investigate on this!

Update: Writing host flags to 0x4008 fails as well

Hello all, our company is currently working for Eurotronic on firmware code review and on fixing issues with writing to 0x4003 and 0x4008 attributes. Please be patient since we are not authors of original firmware.

Good news is that I have been able to successfully update the firmware over the air (OTA).

Please, if you have discovered any other issue, write it here or contact me on email. Thank you.

Hello all, our company is currently working for Eurotronic on firmware code review and on fixing issues with writing to 0x4003 and 0x4008 attributes. Please be patient since we are not authors of original firmware.

Good news is that I have been able to successfully update the firmware over the air (OTA).

Please, if you have discovered any other issue, write it here or contact me on email. Thank you.

Thanks for good news. Can you please give a short instruction, how to do the OTA? For example where to find the firmware file?

@witriol As far as i could test, the thermostat also does not respond correctly to trying to set the local_temp_calibration (Attribute 0x0010). This used to accept values between -500 and 500 (+- 5 degrees) but now responds with "illegal value" no matter what value is written in.
Please also verify that 0x4001 can be written to when the Thermostat is set to manual mode (0x4000 set to 0x02, if i remember correctly)
If you have a firmware ready for testing - i have a new and a few of the old ones present, so i can verify that the firmware behaves as the old ones do (also matches the document on the old one).

A.

Good news is that I have been able to successfully update the firmware over the air (OTA).

@Witriol That is good news, indeed! Have any firmware files been published? It is possible to downgrade the firmware?

Main issue with the firmware is that it appears to support remote temperature sensing, but it doesn't seem to accept _Report Attribute_ messages from a remote temperature sensor.

Hello all, our company is currently working for Eurotronic on firmware code review and on fixing issues with writing to 0x4003 and 0x4008 attributes. Please be patient since we are not authors of original firmware.

Good news is that I have been able to successfully update the firmware over the air (OTA).

Please, if you have discovered any other issue, write it here or contact me on email. Thank you.

Hi @Witriol, it's nice to hear that you have OTA updates working! :-)

Besides the issues already mentioned I have two additional ones:

• I can change "TRV mode (0x4000)" to 1 in order to be able to change valve position manually. I can see that operation mode of valve changes as the display shows "0" which is the current valve position. When trying to change that valve position via "Set Valve Position (0x4001)" however the device returns "INVALID_VALUE" no matter which value I send.
• Also I'm losing Zigbee connection every second day and even a power-cycle doesn't help. I'll have to reset and re-pair the device via "three-button-method".

As there seem to be a lot of issues with the current firmware a downgrade would be a clean and fast quick-fix that I'd highly appreciate.

Hi guys, I'm experiencing the same problem with a brand new spirit thermostat. Is it possible that the guys at Eurotronic misstakenly published a firmware version with a typo in its name (22190930) before going back to the original datestamp naming convention (20191014)? The name of the attribute 0x0006 "Date Code" implies a datestamp. teddy

@Witriol Also looking forward to the OTA firmware update! Thanks in advance!
teddy

@teddy-rpi : There is a firmware-build date and a firmware version:

I have just created a second pull request that implements a crude temporary workaround as earlier proposed by @DerOetzi: just write to both (0x4003 and 0x0012) attributes when changing the heating setpoint.
This is definitely not a nice solution but since we got word from @Witriol that the manufacturer is working on a firmware update (nice btw!) I feel this fix could be temporarily acceptable. I hope you all can agree.
Again the fix works on my version of the thermostat but I can't give any more guarantees :)

@magicdude4eva : Thanks! How can I discover the firmware version? In deCONZ under the basic cluster, the attribute 0x0006 "Date Code" gives me 20191014 and teh attribute 0x4000 "SW Build ID" is empty.

I have just added a pull request (#3626) which should fix our issues with changing the current heating set point.
It took me a while to figure out but next to writing to the earlier discussed 0x0012 attribute (Occupied Heating Setpoint) I also needed to send a generic manufacturer code.

To distinguish between older and newer units I have used the Software Version attribute. To units with a software version below 22190903 the old 0x4003 attribute will be written too. For models with SW version 22190903 and upwards the 0x0012 attribute will be used.

This fix works for my unit but since I only have one unit I cannot guarantee that it will work for older and other units as well so let us keep our fingers crossed 🤞

Thank you very much. Now it works fine for me.

I have just created a second pull request that implements a crude temporary workaround as earlier proposed by @DerOetzi: just write to both (0x4003 and 0x0012) attributes when changing the heating setpoint.
This is definitely not a nice solution but since we got word from @Witriol that the manufacturer is working on a firmware update (nice btw!) I feel this fix could be temporarily acceptable. I hope you all can agree.
Again the fix works on my version of the thermostat but I can't give any more guarantees :)

I never suggested such method. Think this is a really ugly workaround. Would prefer we use your first fix and force deconz to read basic cluster address 0x4000 if empty.

Sorry @DerOetzi , I have misquoted. It was @mod3k who suggested it. I agree that the workaround is ugly but hopefully it isn't necessary for too long and to be honest, my previous fix also was not a gem :s

I do think this very ugly fix is more robust and fail-safe than my previous implementation

Fix is working for me with very basic function (set target temperature). My mistake: the 0x4000 attribute was empty because I only read out the whole cluster in deCONZ instead of double clicking on the attribute and reading it separately. The field then populated with the same firmware number starting with 22 as you guys have. Thanks again, waiting for the proper OTA fix to be able to use all the features. teddy

Sorry @DerOetzi , I have misquoted. It was @mod3k who suggested it. I agree that the workaround is ugly but hopefully it isn't necessary for too long and to be honest, my previous fix also was not a gem :s

No problem 👍 I'm not sure your new fix will work correctly with older firmware versions. If I understand @ebaauw correctly in his post writing to the the wrong attribute can kind of confuse older devices:

I’m on 20181205 myself. This is quite some time ago, but if memory serves, 0x0012 isn’t updated when the Setpoint Raise/Lower command is issued, and 0x4003 isn’t updated when 0x0012 is set. Always using 0x4003 (for getting and setting the target) worked consistently, so I resorted to using that in the API.

Don't know what happens to them when writing to both attributes. So I personally would prefer to live with the workaround to read Basic Cluster 0x4000 manually after restart, which is neccassary to make your first fix working, before messing up all other older firmware versions out there. And maybe someone who knows deconz insides better then me can give whether it is possible to force it to read that attribute automatically if empty. In my opinion that would be the better solution.