search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.88k stars 483 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

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.

manup commented 5 years ago

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.

ebaauw commented 5 years ago

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.

ebaauw commented 5 years ago

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.

manup commented 5 years ago

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.

tkintscher commented 5 years ago

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:

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)

ebaauw commented 5 years ago

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

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

ebaauw commented 5 years ago

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:

02084022010000
| |   | + value 0x000001
| |   + type 0x22 = u24
| + attribute 0x4008 = Host Flags
+ command 0x02 = Write Attributes
ebaauw commented 5 years ago

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

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

screenshot 2019-02-10 at 13 14

ebaauw commented 5 years ago

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

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?

ebaauw commented 5 years ago

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.

manup commented 5 years ago

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

ebaauw commented 5 years ago

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.

manup commented 5 years ago

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.

ebaauw commented 5 years ago

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.

micha91 commented 5 years ago

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

Kane610 commented 5 years ago

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

wvuyk commented 5 years ago

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

tkintscher commented 5 years ago

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.

ebaauw commented 5 years ago

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.

tkintscher commented 5 years ago

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

ebaauw commented 5 years ago

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

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.

ebaauw commented 5 years ago

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

Indeed.

Have you tried to trigger the windows open detection?

tkintscher commented 5 years ago

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.

tkintscher commented 5 years ago

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

ebaauw commented 5 years ago

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.

ebaauw commented 5 years ago

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:

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.

Kane610 commented 5 years ago

@manup any progress on the changes planned for this?

alpha23 commented 5 years ago

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.

ebaauw commented 5 years ago

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.

Oliviakrkk commented 5 years ago

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

ebaauw commented 5 years ago

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.

Oliviakrkk commented 5 years ago

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

Kane610 commented 5 years ago

@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

Oliviakrkk commented 5 years ago

@Kane610 Thanks for clarification.

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

alpha23 commented 5 years ago

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

Kane610 commented 5 years ago

@alpha23 just follow the pr and all its changes

ebaauw commented 5 years ago

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

Kane610 commented 5 years ago

@ebaauw thanks!

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

wvuyk commented 5 years ago

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

ebaauw commented 5 years ago

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.

Kane610 commented 5 years ago

@wvuyk off and on I take it?

Kane610 commented 5 years ago

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

ebaauw commented 5 years ago

Some tips for those looking to get this thermostat.

Oliviakrkk commented 5 years ago

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

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?

wvuyk commented 5 years ago

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?