Hub Firmware 25.x Beta

I paired 3 devices after the firmware update and got these :

  1. Zooz Double Plug (S2 certified)
    Data networkSecurityLevel: ZWAVE_S2_FAILED
    Raw Description zw:L type:1001 mfr:027A prod:A000 model:A003 ver:1.00 zwv:5.03 lib:03 cc:5E,25,85,8E,59,55,86,72,5A,73,70,71,32,9F,60,6C,7A role:05 ff:8700 ui:8701 epc:3 ep:[‘8700 5E,85,59,8E,25,32,6C,9F’]

  2. Monoprice 24259 contact sensor (not S2 certified)
    Data networkSecurityLevel: ZWAVE_S0_LEGACY
    Raw Descriptionzw:Ss type:0701 mfr:0208 prod:0201 model:0008 ver:1.05 zwv:4.34 lib:03 cc:5E,86,72,71,59,85,80,84,73,70,7A,98,5A sec:71,59,85,80,84,70,7A role:06 ff:8C00 ui:8C00

  3. Iris 3210-L Plug z-wave repeater (Not S2 certified)
    Data networkSecurityLevel: ZWAVE_LEGACY_NON_SECURE
    Raw Description zw:L type:0F01 mfr:0246 prod:0001 model:0001 ver:1.02 zwv:4.05 lib:06 cc:5E,72,86,5A,73,85,59 role:05 ff:9B00 ui:9B00

Uploaded hub logs if you want to check them out.

Some other miscellaneous questions:

  • Will a device handler need anything special to enable S2 pairing?
  • Can an S2 device pair securely through a non-S2 device?

I am part of the Beta and have some testing tasks to do, but haven’t received the 25 firmware. My hub 2 UK is still on FW 24.20 .
I have some new issue with my Multisensor (motion) light automation not turning the light off after 3 minutes as programmed in the Automation…
I want to test this with FW 25 and hope this will be resolved…

Please let me how I can get the beta FW 25
Thanks

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.