search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.88k stars 482 forks source link

[Device Support Request] Eurotronic Spirit ZigBee #1098

Closed micha91 closed 3 years ago

micha91 commented 5 years ago

Hi,

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

Thank you very much in advance

Michael

ebaauw commented 5 years ago

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.

manup commented 5 years ago

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.

micha91 commented 5 years ago

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.

Oliviakrkk commented 5 years ago

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.

ma-ca commented 5 years ago

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.

ebaauw commented 5 years ago

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

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?

ma-ca commented 5 years ago

@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

ebaauw commented 5 years ago

Please check out homebridge-hue v0.11.7.

ma-ca commented 5 years ago

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.

ebaauw commented 5 years ago

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.

ma-ca commented 5 years ago 
[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}
ma-ca commented 5 years ago

I am only using the Apple Home App.

ma-ca commented 5 years ago

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.

ebaauw commented 5 years ago

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.

ma-ca commented 5 years ago

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.

ebaauw commented 5 years ago

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"}
ebaauw commented 5 years ago

Note to self: Eve history.

ebaauw commented 5 years ago

Please checkout homebridge-hue v0.11.8 which should:

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

thommyDD commented 5 years ago

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

manup commented 5 years ago

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

thommyDD commented 5 years ago

@manup it does not work :(

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

manup commented 5 years ago

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

wvuyk commented 5 years ago

Is interesting, subscribing to see the progress ;-)

tkintscher commented 5 years ago

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.

sawfear commented 5 years ago

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

manup commented 5 years ago

Reading some more attributes of the thermostat:

image

sawfear commented 5 years ago

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

manup commented 5 years ago

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.

sawfear commented 5 years ago

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

manup commented 5 years ago

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.

thommyDD commented 5 years ago

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

manup commented 5 years ago

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

Workaround for 2.05.57:

tkintscher commented 5 years ago

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

asgothian commented 5 years ago

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 ?

manup commented 5 years ago

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.

asgothian commented 5 years ago

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

tkintscher commented 5 years ago

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.

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?

Oliviakrkk commented 5 years ago

I confirm those steps are working:

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

ebaauw commented 5 years ago

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

manup commented 5 years ago

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.

ma-ca commented 5 years ago

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.

wvuyk commented 5 years ago

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?

ebaauw commented 5 years ago

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.

ebaauw commented 5 years ago

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.

ebaauw commented 5 years ago

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.

thommyDD commented 5 years ago

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)

grafik grafik

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"

ebaauw commented 5 years ago

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

tkintscher commented 5 years ago

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?

tkintscher commented 5 years ago

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.

ebaauw commented 5 years ago

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.