It appears that it did, although that was unintentional. If you use the functions we provide for parsing temperature it is handled either way so I didn’t catch this in testing. I will dig a little deeper to make sure that there wasn’t something else related to temperature that I missed, but otherwise I should be able to have a fix out for this in the next couple of days.
I helped work on a couple DTHs that don’t handle it properly, but I’ll fix that.
Do you know if there’s anything else significant that’s changed in the way parsed messages are sent to the DTH? Such as… an endpoint value is now included???
Anyone using using Dome sirens (or the Zooz equivalent)? If so, can you check if you can use the bells, chimes, and sirens tiles from the mobile app (Classic)?
I can’t, just the main tile works. Since event logs only go back 7 days, which is when I got the firmware update, I don’t know if it’s hub related or device (DTH) related. I have 2 of these devices, and both exhibit this behavior.
@Kianoosh_Karami, do you guys have any of these devices you can test with?
Here’s another question for the beta group:
Anyone using Keen vents? I’ve stopped getting temperature readings from all 11 vents. As with my Dome siren question, event logs only go back 7 days, which is when I got the firmware update, so I don’t know if it’s hub related or device (DTH) related.
@Kianoosh_Karami, do you guys have any of these devices you can test with too?
I have a Keen and can confirm it stoped getting temperature reports. I believe @ady624 has a pull request in staging to fix this. Sounds like a similar issues to the Xiaomi issue @veeceeoh reported above.
Interesting. There’s also an issue with Keen’s firmware on the newer vents that don’t properly open when given an “on” command. The workaround I had to implement was pass a level set to open the vent after it was closed.
I submitted that to both Keen and ST a few months ago.
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.
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.