DDF for ubisys H1 thermostat

[SwoopX]

Device support is provided based on firmware 1.4.0. A few observations made during testing:

• Time seems to be asynchronous wherever it can be set or checked.
  On zigbee level, it seems the thermostat queries the coordinator for its time. The respective coordinator response does neither update the time on the thermostat display nor attribute 0x0000 (utc) of the time server cluster.
  Similarly, setting the time via the device display, does not have any impact on the attribute 0x0000 (utc) of the time server cluster.
  Also, writing the coordinators utc time to the attribute 0x0000 (utc) of the time server cluster does not touch the time on the device display. Overall, this might need some more polishing by ubisys.
• Sending a direct attribute report from a temperature sensor to the thermostat is not persistent
  As the device has a temperature client cluster, it should be able to handle temperature reports from other devices. That currently works only for a short moment. When the report arrives, the temperature on the device display and on attribute 0x0000 (local temperature) of the thermostat cluster changes. However, it is reset/overwritten by the internal temperature measurement after a short time, latest with the report coming after 5 mins (currently set reporting interval).
• Offset range is +-10°C, full degrees only
  In contrast to other devices, the offset is set in full degrees, so 2,5° is not possible.
• Thermostat modes
  During testing, it felt like setting the mode to heat is an equivalent to a boost mode. The valve was still kept open although the target temp was already reached. This might be subject to further verification/confirmation.
• Vacation mode
  The vacation mode can also be set via the manufacturer specific cluster attribute 0x0005 (boolean value). Actually a nice feature, but currently not exposed via API, as an item currently doesn't exist for that very purpose.
• Attribute support
  Generally, ubisys does only seem to support mandatory attributes. E.g. for the time cluster, only attribute utc is available, which collides a bit with the current state code (although harmless). Within the thermostat cluster, attribute 0x0025 (ThermostatProgrammingOperationMode) is also not supported, which is usually used to distinguish if the thermostat temperature is set manually or via programmed schedules.
• Group support
  The thermostat, although typically treated as sensor, does support groups. config/groups as been added, a group was assigned and the thermostat cluster bound to that group.

The device is exposed via API as follows:

"209": {
    "config": {
      "battery": 100,
      "group": "20003",
      "heatsetpoint": 2050,
      "mode": "heat",
      "offset": 0,
      "on": true,
      "reachable": true,
      "schedule": {
        "W127": [
          {
            "heatsetpoint": 2400,
            "localtime": "T21:25"
          },
          {
            "heatsetpoint": 2000,
            "localtime": "T23:00"
          }
        ]
      },
      "schedule_on": true,
      "unoccupiedheatsetpoint": 1600
    },
    "etag": "4375887cec7d66917a77a764c4e9b736",
    "lastannounced": null,
    "lastseen": "2023-12-10T22:07Z",
    "manufacturername": "ubisys",
    "modelid": "H1",
    "name": "Thermostat 209",
    "state": {
      "lastupdated": "2023-12-10T22:08:18.518",
      "on": true,
      "temperature": 2100,
      "utc": "2023-12-10T22:08:01Z",
      "valve": 7
    },
    "swversion": "1.4.0",
    "type": "ZHAThermostat",
    "uniqueid": "00:1f:ee:00:00:00:00:00-01-0201"
  }

The exposed cluster 0xFC57 does currently not seem to have any content and meaning. However, this cannot be verified as no technical reference has been published (yet).

A set of additional manufacturer specific attribtues has been identified on the thermostat cluster. The purpose for all except two of them remains unknown.

<attribute id="0x0000" name="Unknown" type="u16" access="rw" required="m" mfcode="0x10f2"></attribute>
<attribute id="0x0001" name="Unknown" type="u16" access="rw" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x0002" name="Unknown" type="s16" access="r" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x0003" name="Offset" type="s8" access="rw" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x0004" name="Unknown" type="s16" access="rw" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x0005" name="Vacation" type="bool" access="rw" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x0009" name="Unknown" type="u16" access="r" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x000a" name="Unknown" type="s16" access="r" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x000b" name="Unknown" type="s8" access="r" required="m" mfcode="0x10f2"></attribute>
<attribute id="0x000c" name="Unknown" type="s8" access="r" required="m" mfcode="0x10f2"></attribute>
<attribute id="0x000d" name="Unknown" type="u8" access="r" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x000e" name="Unknown" type="u8" access="r" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x000f" name="Unknown" type="u8" access="r" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x0010" name="Unknown" type="u8" access="r" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x0011" name="Unknown" type="u8" access="r" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x0012" name="Unknown" type="u8" access="r" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x0013" name="Unknown" type="s16" access="rw" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x0014" name="Unknown" type="s8" access="rw" required="o" mfcode="0x10f2"></attribute>
<attribute id="0x0015" name="Unknown" type="s16" access="rw" required="o" mfcode="0x10f2"></attribute>

[jan666]

Sending a direct attribute report from a temperature sensor to the thermostat is not persistent

Ubisys support told me they're working on the feature to bind external temperature sensors. So I guess it does not work (yet) because it's not ready

[manup]

@Zehir I think the validator needs a small extension to recognize the change.timeout and state.timeout keys in items.
They can be optionally be specified for write requests.

{
     "name": "state/utc",
     "change.timeout": 30,
     "refresh.interval": 3660
}

Opps, @SwoopX looking a bit deeper I think these need to be inside the "write" object?

[SwoopX]

Yeah, it apparently worked during testing just accidentally. Just wanted to exit the state change a little earlier, but using it doesn't fit in that specially crafted function, which is used there.