Zen Thermostat FW V2.32 Release Notes

(Broderick Carlin) #1

These release notes have been shared from Zen Ecosystems with the intent of public disclosure. These release notes are in regard to the recent V2.32 Zen Thermostat FW update made available in the 25.X hub release. This firmware is made available for the Zen-01 model thermostat.

Change Description

  1. Observed intermittent wake up issue

Problem description

Waking up the thermostat by a centre touch is intermittently not waking the display of the thermostat.

Analysis and resolution

Our investigation has shown that when we successfully replicate this issue the centre touch event was detected by the firmware. But this touch event is not acted on by the relevant software thread in the thermostat firmware.

We determined that the reason why the touch event was not detected is because there is a race condition between two threads; the touch event thread and the power monitoring thread. To resolve this issue we have implemented a fix which ensures that thread state transition and touch event monitoring are interrupt safe.

  1. Rejoin to home automation hub when Zen Thermostat is back from out of range is always taking 30 minutes

Problem description

Re-joins to home automation hub when the Zen thermostat is back from out of range is always taking 30 minutes and hence update to the hub is delayed and/or mobile app updates from user leads to bad user experience.

Analysis and resolution

The Zen Thermostat is a low power Zigbee device and one of the ways for it to save power is to manage how it tries to rejoin a network when it either goes out of range or the Zigbee coordinator has gone offline. When the thermostat is power up or first detected it has gone out of range, it will try to rejoin the network for approximately 5 minutes. After that initial 5 minutes has elapsed it will then only try to rejoin every 30 mins. The reason is because sending out a Zigbee beacon/rejoin request is power consuming.

Based on customer feedback, the thermostat will initiate a rejoin the moment a user activates the display while the thermostat is already in a network.

  1. OTA upgrade fails after device rejoins to home automation hub due RF interference

Problem description

After re-joining, a thermostat that is going through OTA upgrade sends an UpgradeEndRequest with status Invalid_Image.

Analysis and resolution

Our investigation has shown that the issue relating to the Zen Thermostat returning an invalid image response when upgrades are re-attempted is caused by the addition of the OTA resumption feature.

The fix involves adding a condition to handle proper resumption of OTA upgrade process if the Zen Thermostat received a corrupted OTA file.

  1. Thermostat incorrectly reporting low battery alarm Problem Description
  • When a Zen Thermostat HW is connected to a home automation hub with the thermostat supply voltage at 3.5V or below, we noticed that the thermostat displayed a low battery icon. But on the hub it was not showing a low battery warning but was showing a battery reading of 3.5V.
  • When a Zen Thermostat HW is connected to a home automation hub and the thermostat supply voltage is set to 5.4V, the thermostat reported 5.4V. This

battery voltage should not trigger a battery low warning, but on the hub it has a low battery warning and was showing 5.4V battery reading for the thermostat.

Analysis and resolution

Our investigation has shown that the root caused is due to a change on the start-up sequence between the main processor of the Zen Thermostat and the Zigbee radio module. Originally the main processor would issue a start-up complete message to the Zigbee module before it (the main processor) sends an update attribute request that specifies the battery threshold values (note: these values are used for low battery notification). The change was made so that the start-up complete message only comes after the update request is done. However, what was missed after this change was made was that the Zigbee module actually updates the battery threshold values with its own default settings after it receives the start-up complete message. The original sequence masked this behaviour since the update attribute request overwrites the changes the Zigbee module has made.

A firmware fix was introduced to prevent the module from overwriting the battery threshold values after it receives the start-up complete message.