Hub Firmware 25.x Beta

You’re part of the group held in reserve for additional testing focused on converting to the new Z-Wave framework. However, I’ll have the 25.x firmware pushed to you now so that you can do your testing.

Great, thank you,
Look forward to FW 25. Hopefully this will fix my issues with the motion sensors (which are Aeotec multisensor -> Z-wave).
I will report back via the Beta testing site.
Thanks again !

Received the beta yesterday and didn’t notice any issues except for my Aeotec Nano Switch (ZW116) going offline. A quick break flip to cycle the power fixed that. Not a beta issue but still a SmartThings issue, is there any way the default Z-Wave Metering Switch and Z-Wave Metering Switch Secure DTH’s can be changed to stop the enforcement of parameter 101 and 111 on the Aeon Labs/Aeotec devices? This sets the power metering parameters to unrealistic values. That or make these default DTH’s parameters editable.

EDIT: I’ve had the same device lock up again. I’m going to reset it again after giving it a while to see if it will come back on it’s own. It may also be due to making changes and testing the device handler code it uses. Regardless of outcome, I’m going to test a bit further before looking at the hub upgrade as a potential culprit.

Anyone with Xiaomi temp sensors? They all stopped reporting temperature, other parameters work fine. Anything to do with this beta?

Does the change to Zigbee messages include adding the “F” / “C” unit to the raw description string of temperature reports?

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.

Thanks, Zach!

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.

1 Like

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?

@Zach_Varberg

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.

2 Likes

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).

1 Like

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.

7 Likes

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 :slight_smile:

2 Likes

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?

1 Like

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.

Well, I said the main parse function of this beta firmware seems to round off that value based on a short run of log entries posted by user @cscheiene here.

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.

7 Likes