eCozy Thermostat and more

[ebaauw]

Changes:

• Additional support for the eCozy Thermostat, see New Device Support Request - eCozy Smart Heating Thermostat #2393. Still work in progress:
  • Full GUI support for Thermostat cluster, including schedules and tracking setpoint changes;
  • Support Time cluster as ZHATime /sensors resource;
  • Sync on-device hardware clock with system clock;
  • Rename config.scheduler to config.schedule, and refactored the logic to expose the on-device schedule as JSON instead of as a string. The code no longer clears the schedule when refreshing it; newly received Get Weekly Schedule Response messages are merged with the cached schedule. It now also handles multiple days in the response correctly.
  • Fix hang in API plugin when receiving a schedule with more than one transition;
  • Expose PI Heating Demand (0x0008) as state.valve;
  • Rename config.scheduleron to config.schedule_on and expose Temperature Setpoint Hold (0x0023) as config.schedule_on;
  • Expose Setpoint Change Source (0x0030) as config.lastchange.source. The values can be "manual" (using the on-device keys), "schedule", or "zigbee";
  • Expose Setpoint Change Amount (0x0031) as config.lastchange.amount;
  • Expose _Setpoint Change Timestamp (0x0032) as config.lastchange.time (in UTC);
  • Make sure all state and config attributes are either reported or polled. The on-device schedule is also polled, but I think there's still an issue that some days might be missed on larger, more busy networks.
  • Note still to do: set/change/delete schedule through the API.
• Report lastseen with a resolution of minutes, and issue at most one web socket notification per minute per device for lastseen, see Proposal: deprecate reachable attributes #2590.
• Quick hack to support action.open for /groups to send Window Covering commands Open and Close to a group (to mitigate routing issues to the lumi.curtain. No check that the group actually contains Window Covering devices;
• Lose the sanity check that state.ct is exposed when doing a PUT of a /lights state with ct in the body, see Deconz reporting CT parameter as invalid #3018.
• Expose Color Capabilities of colour lights as colorcapabilities on the /lights resource. For now, just the (decimal) value of the bitmap, see API doesn't update colour for Hue Bloom #3079;
• Bug fix: the colour attributes for Color Light lights weren't updated, see API doesn't update colour for Hue Bloom #3079.
• Expose latest Hue bridge firmware version as swversion in Hue emulation mode;
• Add Basic cluster to coordinator's first endpoint on configuration restore;
• Fix segmentation fault when reading the Zone Status attribute of the IAS Zone cluster, see v2.05.79 crashes with SIGSEGV #3095.

[ebaauw]

Hm, I was still working on this one. Edited the list.

[ma-ca]

Rename config.scheduleron to config.schedule_on and expose Temperature Setpoint Hold (0x0023) as config.schedule_on

@ebaauw The Bitron Thermostat 902010/32 does not have attribute 0x0023 and the config.scheduleron was originally mapped to attribute Thermostat Programming Operation Mode 0x0025. This is a breaking change.

I am using HomeKit to turn off and on the Bitron Thermostat scheduler. In HomeKit the thermostat status on or off was mapped to the scheduler being enabled or disabled. That is a very useful feature for me, for example when leaving for holidays in the winter time.

Is it possible to revert the that change and bring back the mapping in HomeKit between scheduler and thermostat status? Or at least to make it configurable how the thermostat scheduler is mapped into HomeKit?

[ebaauw]

Does the Bitron support on-device schedules? Using the Zigbee standard or some proprietary method?

I only mapped config.schedule_on to 0x0023 for the eCozy; for others it’s still mapped to 0x0025.

I think there’s something wrong in the way Homebridge Hue currently uses the Thermostat mode. In HomeKit, you can set the target mode to Off, Heat, Cool, or Auto, indicating whether the thermostat should automatically heat, cool, or both. The current mode is Off, Heat, or Cool, indicating whether the thermostat is currently heating or cooling. This has nothing to do with whether the schedule is enabled. It also has nothing to do whether the Spirit is in automatic mode (where it sets the valve position based on the heatsetpoint) or in manual mode (where you set the value position manually).

Eve shows a separate on/off switch for the schedule, I want to see if I can map that to config.schedule_on. I also want to support setting the on-device from Eve. Showing the on-device schedule in Eve won’t always be possible, since the on-device schedule is way richer than the Eve schedule. See ebaauw/homebridge-hue#728.

[ma-ca]

Does the Bitron support on-device schedules? Using the Zigbee standard

Yes, using Zigbee standerd. I did add support in PR #1003 for Thermostat cluster (including get/set schedule) and Bitron Thermostat 902010/32.

I only mapped config.schedule_on to 0x0023 for the eCozy; for others it’s still mapped to 0x0025.

Makes me happy again.

I think there’s something wrong in the way Homebridge Hue currently uses the Thermostat mode.

That is true. I don't use Eve very often and was not aware about the option Enabled in the thermostat. Anyway, I am also happy to use Eve to enable and disable the scheduler.

[ebaauw]

I did add support in PR #1003 for Thermostat cluster (including get/set schedule) and Bitron Thermostat 902010/32.

Ah, cool. Did you see in #2393 that config.schedule now returns proper JSON and that I changed the way the schedule is set? Also, I setup periodically reading the schedule for the eCozy, we might want to do the same for the Bitron. Does the Bitron support attribute reporting for all (relevant) attributes, or do we need to poll it for some of the attributes?

[ebaauw]

Another question, @ma-ca: how does the Bitron handle the timing of the schedule? Does it have an on-device clock? How do you keep that sync'ed?

[ma-ca]

how does the Bitron handle the timing of the schedule?

The Bitron has a Time cluster that syncs the attributes for UTC time, time zone, dst start, dst end and dst shift.

[ma-ca]

Does the Bitron support attribute reporting for all (relevant) attributes, or do we need to poll it for some of the attributes?

Reporting is enabled and configured every 5 minutes for attribute 0x0000. Polling is already configured every 15 minutes for attributes 0x0012, 0x0025 and 0x0029.

[ebaauw]

The Bitron has a Time cluster that syncs the attributes for UTC time, time zone, dst start, dst end and dst shift.

Is that a client (grey) Time cluster, or a server (blue) one? Does it find the Time cluster on the coordinator and sync itself automatically? Or did you set something up?

EDIT found the technical manual at https://images-eu.ssl-images-amazon.com/images/I/91ZbuTU-duS.pdf. It's a server Time cluster that indeed syncs automatically with the gateway server Time cluster. Bummer that the eCozy doesn't do that. Or was I too impatient?

902010/32 synchronizes its time reference following the rules described in ZigBee Cluster Library Specification.
After a time between 2 and 10 minutes from the reset (chosen randomly), and every 24 hours post, 902010/32 looks for the best time server presents on its radio network.
If it finds a suitable time server then it collects the relevant time attributes.

[ma-ca]

A Time server cluster that syncs automatically to the coordinator. I did implement #774 especially for the Bitron.

[ebaauw]

The Bitron also supports 0x0030, 0x0031, and 0x0032, so it could also expose config.lastchange. There's a bug in the eCozy that it reports Setpoint Change Time Stamp in local time instead of UTC. Does the Bitron do the same?

[ma-ca]

There's a bug in the eCozy that it reports Setpoint Change Time Stamp in local time instead of UTC. Does the Bitron do the same?

The Bitron attribute 0x0032 value is the correct UTC time (right after changing heat setpoint the 0x0032 attribute value is close to Time cluster 0x000A attribute 0x0000 value with UTC time)