I recently updated the firmware on my ThirdReality temp + humidity sensors and now they’re horrible.
I have 4 ThirdReality temp + humidity sensors (the ones with an LCD and AA batteries, 3RTHS24BZ). Two from a couple years ago and two brand new. One old sensor still has the old firmware, 0x15. The other three are up-to-date, 0x28.
This graph shows old & new firmware from sensors that are 1’ apart. ThirdReality seems to have slowed down the update rate and increased the temperature change threshold for reporting. It’s much worse on both axes.
Thanks for sharing that, but that’s a different problem for different sensors. Those are the coin cell puck sensors, not the LCDs that I have.
Actually, I bought & returned some of those ThirdReality puck sensors for the very “problem” you linked. I say “problem” because, in my opinion, ThirdReality is intentionally defrauding customers with those units.
From my testing and that thread, it seems the ThirdReality temp + humidity puck sensors (coin cell, 3RTHS0224Z) can only sense 0.5C (“approximately 1F”). They artificially add some small noise onto that real measurement so it looks like the unit is updating faster and with more resolution than it really is.
Even their official response in that thread sounds like they just plan to make the fraudulent readings less obvious (“processing” and “enhance its smoothness”):
The current version still has room for optimization in temperature sampling processing. We have already scheduled improvements to enhance its smoothness, and this issue will be addressed in the new version.
Is it not the same firmware for both devices, problem seems the same. Some of posts seems ref dif sensors. You might try creating a new topic at their support forum for your specific experience. I think the more posts the better.
I have the devices, believe same as you, with 2 x AA batteries and LCD display.
Do your devices have the large/coarse stepping? What firmware are they on?
I assume the two models have different firmware, since ours needs to also drive the LCD, and use the button to toggle C/F on the display. But coming from the same company, the measurement code could surely be the same.
These two issues definitely look the same at a glance (big/coarse temperature steps), but they are different.
The issue linked on the puck sensors:
They have fine time resolution, but take big temperature steps.
For example, it updates often but only ever reports 71.1 or 72.2 or 73.3 (exact steps of 1.1F).
Additionally, I believe ThirdReality went out of their way to add a little +/-0.1 or 0.2 random number so customers don’t notice it’s quantized.
The issue I’ve described here on the LCD sensors newer firmware:
They have bad time resolution (update slowly), but give fine temperature resolution.
For example, it only updates every 15 or 30m. But when it does, you’ll get a real value with 0.1F precision.
Thanks again for digging up that thread on their forums, I couldn’t find any good info like that when I was debugging those sensors earlier this year.
Blue line is .37 firmware, yellow line is .40 firmware. Other pictures for reference of setup of Zigbee2MQTT.
Hope they improve their firmware, else I am going back to BLE thermometers. I abandoned Zigbee temperature sensors for BLE sensors a number of years ago. Found the 3rd Reality units with firmware .37 and found them to be as solid as the BLE devices I was using.
Lesson is don’t upgrade firmware of something that is working. And have a test environment for firmware and other changes before changing production systems (sux that u have to do this, in this day and age) .
I found this thread as I recently updated my own temperature sensors (3RTHS24BZ) and noticed the same issue with the reporting interval after the update.
This was quite frustrating as I’d only recently bought them!
Anyway, after a lot of trial and error with various firmware update methods, I’ve managed to downgrade the firmware back to 1.00.37 (0x25) and the sensors look to be working as before, so I thought I’d share how here.
The method I found that worked was:
Update the ZHA config to use a local folder as an ota source (the warning is required for it to work interestingly):
zha:
zigpy_config:
ota:
disable_default_providers: [thirdreality]
extra_providers:
- type: advanced # !!! Please read the message below before enabling OTA updates from raw OTA files !!!
warning: I understand I can *destroy* my devices by enabling OTA updates from
files. Some OTA updates can be mistakenly applied to the wrong
device, breaking it. I am consciously using this at my own risk.
path: /config/zigpy_ota
There were some old docs online that use otau_directory in the config, but those seem to be outdated.
Download the previous firmware version from the zigbee ota archive repo (Koenkk/zigbee-OTA on github, look in the images1 folder).
Manually patch the ota file header so that it appears as v41 rather than v37 by changing a single byte. I used the bvi utility to do this, along with this page to understand the header format. My copy of the patched ota is here.
Copy the patched ota file into /config/zigpy_ota (I use docker, you might need a different directory otherwise).
Restart home assistant.
After a bit of time, ZHA should then show a new update available. It’ll show as 0x29 in the update manager, which is equivalent to v41 (just in hex). Interestingly once the update has been applied it shows correctly as 0x25, and still prompts for an update, but you can then just remove the ota from the folder.
You can then also revert the config file if you wish and renable the ThirdReality updates. I might just keep mine disabled.
Another option I tried was to use zigbee2mqtt as that does have a function for downgrading firmware, but when I tried that I got an error, so its possible the device checks the incoming ota header itself and refused the older firmware. Though maybe there’s a way to get that to work.
