Zero out local_temperature_calibration on start

[artyfarty]

Plugin fails to properly load if local_temperature_calibration is not yet reported, which can easily happen after hass/zigbee2mqtt restart. Please add a routine to force update it by zeroing it (or setting to latest state).

This will eliminate a huge chnk of "Unavailable" bug reports here,

[mtojay]

i am struggling to get two of my better thermostats to work (two work totally fine, two refuse to work completely). they all work 100% in z2mqtt. the devices are there. i can use them without better thermostat. but for two of them the better thermostat is unavailable. i have read multiple times now about local_temperature_calibration. but i have absolute no idea where i can set that. none of my entities has that option. neitehr the original thermostat nor the connected better thermostat. i am at a loss. and i am tearing my hair out trying to figure out why two are working and two are not.

there is no local_temperature_calibration and i feel like i am stupid. i have read so many times now about that and i wonder where you guys find this? i went through z2mqtt and developer tools for all devices that are playing a part in this and there simply isnt a local_temperature_calibration. could someone sent a screenshot on where you find this?

[artyfarty]

@mtojay it is entirely possible for your specific device to not have it. It's not essential for BetterThermostat to function afaik, but it enables a more nice-looking control flow.

[maxlyth]

I'm using Z2M with Sonoff TRV and experiencing unavailable BT after a HA host reboot. In the HA logs this is reported as waiting for TRV/climate entity with id 'number.hall_sonoff_trv_local_temperature_calibration' to become fully available.... If I look at the state in Z2M for each TRV I see that it is reporting a null value for the local_temperature_calibration attribute.

If I go to the 'Exposes' tab in Z2M for the TRV then the value of the calibration is empty. If I manually set the field to zero then the BT thermostat becomes available and the integration starts working again.

The local_temperature_calibration attribute is explicitly reported as a property of the device but the default value is null which causes BT to fail in an intolerant way that does not recover without manual intervention. Can I suggest that BT fails back to interpreting null as 0 for this field for the purpose of bootstrapping coming online?

[artyfarty]

Can I suggest that BT fails back to interpreting null as 0 for this field for the purpose of bootstrapping coming online?

I think forcibly zeroing it should work even better, since changing the value makes it reported. But otherwise yes, this is exactly why i opened this issue.

[TheOpsMgr]

Note that changing the BT calibration mode to "target temperature based" as opposed to "offset-based" will also bring the thermostat back online. Might need a reload of that thermostat and take a minute but I've tested it on 3 thermostats.

So you can either (1) go into Z2M, locate the TRV device, go to "exposes", set the local calibration to a number OR (2) in BT, change the calibration to for that thermostat configuration to "target temperature based"

[TheOpsMgr]

I haven't had time to hunt through the code but given this error in Z2M I suspect that when fetching the value BT is either getting an error exceptionpassed back from Z2m or getting a null (string) value being returned and then it's throwing an error because there isn't any validation on the returned value.

So, I guess you could try/catch on the exception and handle it that way by setting the value to zero if you get the exception.

[maxlyth]

This issue is randomly reoccurring on my Sonoff TRVs and while they continue to function from their last setting, the swath of offline thermostats is impacting the perceived reliably of the control system.

As a temporary fix I have written an automation that triggers when a local_temperature_calibration changes to 'unknown' and then sets the entity value to 0:

alias: Fix Unknown TRVs
description: Force Local Temperature Calibration to 0 when it changes to null
triggers:
  - trigger: state
    entity_id:
      - number.dining_sonoff_trv_local_temperature_calibration
      - number.hall_sonoff_trv_local_temperature_calibration
      - number.kitchen_sonoff_trv_local_temperature_calibration
      - number.lounge_sonoff_trv_local_temperature_calibration
      - number.bedroom_sonoff_trv_local_temperature_calibration
      - number.spareroom_sonoff_trv_local_temperature_calibration
      - number.office_sonoff_trv_local_temperature_calibration
    to: unknown
conditions: []
actions:
  - action: number.set_value
    metadata: {}
    data:
      value: "0"
    target:
      entity_id: "{{ trigger.entity_id }}"
mode: parallel
max: 10

It makes use of the automation trigger record to detect which entity caused the automation to run and then sets that entity as the target. This way, one automation works for multiple entities, you just need to list the TRV calibration entities in the trigger section.

[maxlyth]

Digging into the underlying problem it is partly the fault of Z2M but exacerbated by lack of graceful or intuitive problem handling in BT. I think there is another thread pressing to implement HAs new Repair framework so users can discover which underlying sensors are causing BT to fail because trawling through logs is not the HA way.

If you look in the State tab in Z2M for a failing TRV the base JSON record has a null value for the local_temperatur_calibration (LTC) field. In turn the MQTT template for the HA entity uses the following template to define and calculate the number entity state:

{
  "availability": [
    {
      "topic": "zigbee2mqtt/bridge/state",
      "value_template": "{{ value_json.state }}"
    }
  ],
  "command_topic": "zigbee2mqtt/Office Sonoff TRV/set/local_temperature_calibration",
  "default_entity_id": "number.office_sonoff_trv_local_temperature_calibration",
  "device": {
    "identifiers": [
      "zigbee2mqtt_0x44e2f8fffe0c5e8e"
    ],
    "manufacturer": "SONOFF",
    "model": "Zigbee thermostatic radiator valve",
    "model_id": "TRVZB",
    "name": "Office Sonoff TRV",
    "sw_version": "1.3.0",
    "via_device": "zigbee2mqtt_bridge_0x84b4dbfffecbf40a"
  },
  "device_class": "temperature",
  "entity_category": "config",
  "icon": "mdi:math-compass",
  "max": 12.7,
  "min": -12.8,
  "object_id": "office_sonoff_trv_local_temperature_calibration",
  "origin": {
    "name": "Zigbee2MQTT",
    "sw": "2.6.2",
    "url": "https://www.zigbee2mqtt.io"
  },
  "state_topic": "zigbee2mqtt/Office Sonoff TRV",
  "step": 0.2,
  "unique_id": "0x44e2f8fffe0c5e8e_local_temperature_calibration_zigbee2mqtt",
  "unit_of_measurement": "°C",
  "value_template": "{{ value_json.local_temperature_calibration }}"
}

The value_template straight copies the JSON value to the entity and a string ('null') does not go into a number. Changing the value_template to {{ value_json.local_temperature_calibration | float(default=0.0) }} would fix this at source but the logic change could break other integrations using Z2M.

I may raise an issue on the Z2M repo but I think better and more friendly exception handling in BT for this state would have wider benefits.

[maxlyth]

FWIW I did read through the Z2M/herdsman source code for the Sonoff TRV and this problem is unlikely to be fixable there. Herdsman supports thousands of Zigbee devices and the configuration for each is massively abstracted into templates and object classes.

The Z2M LTC field is shared with many other TRV types and HVAC controllers. I highly doubt that the Z2M project would accept a change on how null values are reported as the downstream impact could be huge. For the time being my hack HA automation described above has been reliable for more than a week for me.

There has not yet been feedback from a BT repo mod but if I felt that a PR would be accepted and had wider value then I could look at a solution in the BT code.