The ST app has reported quite a few times these past few days that my hub is offline. I very rarely had this issue before. Is anyone seeing this problem as well? I have a Ubiquiti Unifi based network running their latest beta software so there is always a chance it is a network issue however nothing other than ST seems to have an issue. I did turn device health back on just to see if it is better than when it was introduced but I believe the offline notices to be independent, right?
Here’s the problem: I didn’t use
zigbee.getEvent() to fully parse temperature reports because it rounds off the reported temperature value to an integer.
For Fahrenheit this might be okay for some people, but for the rest of the world, a lot of people would much rather see at least 0.1 precision in Celcius temperature reports.
So in the DTHs I’ve helped with, it parses through the original raw description text to pull out the 0.01 precision reported values and work with those. But the main parse function of this beta firmware seems to round off that value as well, and then add the letter of the unit, so that for example:
a 18.45 reported value in Celcius yields a raw parse description of
temperature: 18.0 C
So, unless I’m missing something here, with the next firmware, we’ve completely lost the ability to pass on anything more precise than rounded integer values to the users.
Original & Aqara Xiaomi Zigbee Sensors (contact, temp, motion, button, outlet, leak, etc)
Hi Alex, go ahead and report this in centercode and we can take a deeper look. There are sometimes spurious offline events from cloud deploys but there appears to be something else going on in this case, possibly with this firmware.
Of course, if others are seeing this as well that feedback would be good as well (it certainly is not a universal phenomenon).
This is a BIG issue for those of us that work in Celcius - 1 degree accuracy is simply not enough when you’re working with figures in the 10-30 range. @Zach_Varberg please fix this before rolling out the 25.x firmware.
While I agree as I am a European living in the USA and simply can’t stomach Standard measurements (I am half British so I take some of the fault it even exists!) so everything is set to Celsius (except my Acura GRRRRR), I typically don’t bother too much about 10ths of a degree and even less the hundreds of a degree as most consumer measurement devices are not that accurate anyway. It is also unlikely that one can feel the difference so for practical applications it usually can, or should, be ignored. BUT I do agree proper support for metric measurements is critical regardless of the world region
This certainly isn’t intentional. I’ll look into it.
EDIT: Hmm, I’m seeing preceision down to 10ths of a degree. Do you have a specific device where you are seeing this so I can pull logs of the problem and try to track it down?
After reading the post from @johnconstantelo I’m having the same problem with my Zooz chime siren it shows as the siren is going off and I cannot reset it and cannot use any of the chimes.
In those log entries, the log entries two consecutive raw temperature report parse description strings of
temperature: 21.0 C, and I would be very very surprised to the exact same value reported twice in a row, because the Xiaomi sensor it came from just doesn’t work that way. But a longer run of log entries is needed to confirm whether all temperature report parse descriptions end in
.0 or not.
Either way, the current firmware supplies a raw temperature report parse string with precision down to 100ths of a degree.
And I need to mention again that if I use SmartThings’ recommended method of
zigbee.getEvent() to fully parse temperature reports, the values are rounded off to the nearest integer, which is why I wasn’t using that method in the first place.
Got it. We are expanding the message back to report down to hundredths.
getEvent() is just meant to make things easier for people, it is certainly not required usage. I’m hoping to have the change out by early next week, but it could be out as soon as tomorrow.
I’m also seeing issues with the dome siren. I added some detail for devs in the Center code issue.
My device event history goes back before the firmware update, but unfortunately, it appears events (other than the commands) are not recorded for the chimes.
The dome siren issue is a bug in the hub firmware. We’re working on a fix which should be included in the next release.
Chris, mid week update. Things are looking good so far with the exception of 2 things:
- After the initial update was rolled out, the hub went offline (lights out completely). Had to power cycle it to turn it back on
- There an issue with large images being received from local devices (cameras). I wondering if it’s connected to the hubAction buffer overflow which was causing a hub disconnect (diagnosed by Bryce) in the last firmware. It wasn’t fixed in 24.x, don’t know if it’s been addressed here or if that’s still the root cause
One more thing I’ve noticed Chris, when using
hubAction to communicate with local devices it seems to timeout much faster with this firmware. If a device takes more than about 5-7 seconds to respond to a hubAction the response never seems to reach the DTH/SA
Keep us posted. We set these devices to report power consumption every 5 minutes to meet some certification needs. Unfortunately, if we made the parameter editable, it would only be available in the classic app.
What type of device?
Can you report a bug in Centercode? One of our engineers will investigate.
If he hasn’t already, @Bryce_Geiser will reach out to you on this issue.
LAN Devices. Bryce updated me on it. Apparently the hub resets the socket, he said he will look into it.
There is definitely something going in this firmware that is causing this device to fail to communicate. Right now it’s in a state where it is not wanting to come up and has been for about a day. It’s the only Aeotec Nano I have so I cannot verify if this is something with these devices.
@RBoy Both my ID Locks stopped reporting the code that was used to unlock. Just says unlocked or locked. Are you seeing any similar problems?
Temperature reporting should be back to the way it was before. Please let me know if there are any issues persisting.