Your hub most likely updated and the Classic app just isn’t reflecting the updated firmware version. If you look in the IDE I bet it will show “000.029.00008”.
1 Like
My hub is still blinking red should I reboot it?
Yes, please try power cycling the hub. Sorry about the trouble!
1 Like
My hub updated to 29.8, I was not on the beta.
I see the meshinfo data for Zigbee devices but checking a few random Z-wave devices… no meshinfo.
For this initial release, the meshinfo in graph is updated once per hour for Zigbee and once per 24 hours for Z-Wave. Those periods as well as where that data is stored and how it will be presented are very likely to change in a variety of ways moving forward.
EDIT: With jitter as well so don’t expect these right on the dot.
8 Likes
I was just about to ask why my excluded/removed zwave devices were still part of the meshinfo on other devices - but i guess this 24 hour delay answers that. Thanks!
1 Like
What about the Samsung Connect - Mesh router? I am still on 27.00010
This is Samsung made product so I expect Samsung to deliver the updates. What’s stopping?
My hub seems to have bricked, now showing a steady red LED, coinciding with this release. The IDE still shows the previous firmware version, and it dropped offline at the time shown.
Hi @Phil.Dye, I would recommend you contact support. They’ll likely have you try a few things like power cycle with batteries removed and a soft factory reset.
FYI @posborne. I also posted in the beta discussion but realized this was better. Something is odd with how Zigbee devices are joining. I was not having this issue with any previous firmware release. I submitted a support ticket now that this is in production. For your reference, it’s:
Support request #912500: Zigbee devices not joining correctly causing issues in the new app and missing Current State and Data elements in the IDE (repeatable issue)
Here’s the detail:
SmartThings hub v2 version 000.029.00008
SmartThings app v1.7.44-21
Devices attempting to join : Iris button (zigbee) model 3460-L (https://support.smartthings.com/hc/en-us/articles/115000190186-Iris-Smart-Button)
Device names : “Garage Door Smart Button” (new one) and “Panic Button” (existing)
Device Handler used : ZigBee Button (ST default) for both
.
Problem:
When joining another device of the exact same model and firmware release of another existing device, the IDE does not have the same “Current State” capabilities or “Data” values. This results in the device not having the same functionality in the new app, such as Quick Controls for the button(s). See the attachments.
“garage_button_ide_settings.jpg” shows the missing capabilities to allow this button to work correctly in the new app, such as the Quick Controls section (and Data). This is the new device I’ve joined. I’ve tried joining this multiple times, through both the new app and Classic.
“panic_button_ide_settings.jpg” shows how the device is suppose to look with the correct current states and capabilities. This is the existing device that works fine:
“Screenshot_20200303-170504.png” shows the device in the new app attempting to load the Quick controls section.
“Screenshot_20200303-170511.png” shows the failed loading of the Quick Controls section.
This is also happening on other devices that I just tested with: (Innr Smart Plugs model SP 224 and works with SmartThings through your new app)
“Garage Door Opener” is newly joined, but missing Data values compared to the three exact same devices below:
“Sunroom Outlet Left” is correct.
“Sunroom Outlet Right” is correct.
“Front Sidewalk Outlet” is correct.
Please note that the Garage Door Opener joined with the proper device handler, like the other Innr plugs use, but I just changed it to use a custom handler to act like a momentary switch, BUT the problem still exists with data values missing. My biggest concern are the Iris buttons, so please focus on those.
EDIT: I’m about to add another Zigbee Smoke Sensor (HEIMAN), and I suspect I’ll see the same results. I’ll edit this reply with an update.
EDIT: Yup, same results at the Iris button and Innr plug.
Kitchen Smoke Detector = OK (existing)
Store Room Smoke Detector = OK (existing)
Crawl Space Smoke Detector = NOT OK (new today)
The Zigbee Button handler looks like it is still rooted in the ‘classic’ environment where the ‘button’ attribute had ‘pushed’ and ‘held’ values and button numbers were added to the event data to allow for things like double clicks. The ‘new’ environment adds shed loads more values so that approach isn’t needed (and the Automations don’t support it), with the ‘supportedButtonValues’ attribute being used to specify which of those values are actually used. It has to be set by the device handler and the Zigbee Button handler doesn’t do that.
The only other difference I immediately see is that the ‘Panic Button’ also shows a ‘checkInterval’, which doesn’t make sense in combination with ‘DeviceWatch-Enroll’ and the combination certainly wouldn’t be used by the Zigbee Button handler as the ST developers know better.
So I would suggest that the ‘Panic Button’ has been set up (temporarily or otherwise) with one or more different handlers at some stage and it has picked up those attributes in that way.
Unfortunately swapping device handlers temporarily seems to be a standard technique for getting devices to update their metadata. It isn’t a good one as it pollutes the device with stray attributes. Temporarily changing the name of the device works just as well in my experience.
Yeah I could do that, but I’d lose the Quick Controls for the button, which means I’d have to reproduce as an Automation. I’d be ok with that if quick controls were going away, but I’m not changing anything until I hear back because that’s super inconvenient.
Also, for the zigbee smokes, ‘checkInterval’ is there for all of them, but not the device enroll, so I see what you mean by that. The new one is just missing “meshInfo”(not even listed). I’m actually ok with that because it’s not impacting anything.
I’m not sure if I put my point across well enough. Just in case, what I am saying is that nothing unusual has happened with the pairing of the Garage Door Opener. It only looks different to the Panic Button because at some stage the latter was installed with one or more different handlers that set the ‘checkInterval’ and ‘supportedButtonValues’ and they linger. There could be other stray attributes too. The IDE only shows the ones associated with the current handler. So basically the Panic Button only supports the Quick Controls by fluke.
There is an issue here, but it is that the Zigbee Button handler needs updating to work with the ‘new’ app as several other stock handlers have been.
The lack of a ‘meshinfo’ may just be timing. It is only updated every so often so you may have been too quick with the screenshot.
For the Health Check, you either enroll the device as ‘untracked’, meaning it just says it is online unless the hub is disconnected, or you use ‘checkInterval’, which means that, if the device hasn’t been seen to be active for a certain period, the ping() method gets called to try and elicit a response, and after that it gets marked offline. Usually ‘untracked’ devices are simulated or cloud based devices that don’t generate regular events, instead using ‘healthStatus’ to set their own online/offline status. Zigbee devices are ideally used with ‘checkInterval’ as there are typically regular events being generated, however you do get some that are less chatty. The other problem is that some handlers use both methods because Health Check isn’t documented and so anything that looked vaguely Health Check related was lobbed in.
I get what you’re saying, and agree that ST needs to get their handlers updated. I haven’t changed the handler for the device that I can recall (but it has been there since 2018), but I understand the scenario you’ve described. I’ve done this stuff too long and when I’ve moved from zwave to zigbee I’ve ensured I stayed with stock handlers, or deleted and rejoined to use stock handlers. I’ll give the meshinfo to update, but that part doesn’t bother me as much as losing quick control.
Cool! I’m seeing meshinfo for my Z-wave devices.
It looks like routes are listed starting at the hub. So if I see a route with multiple devices, messages are going from the hub to each device in the order listed before getting to the end device.
There’s a “metrics” field that I don’t yet see populated.
Any doc on what we’re looking at?
Is the expectation that “Garage Door Smart Button” will support Quick Controls? I would not expect that for Zigbee Button devices as they have an ocfDeviceType of “x.com.st.d.remotecontroller”, which is demonstrated by the remote icon for the device.
As for the meshInfo not updating, the current implementation is limited to 200 Zigbee devices. As you exceed that number, not all of your devices will display this information. That limit may be increased in a future release.
1 Like
Can anyone point me to a guide on what the new mesh diagnostic values mean? I have a device that does really fast and interested to see if I can figure anything out about it. Is RSSI signal strength?
2 Likes
Ouch, yeah let’s hope so because that’s useful info to have and I was looking forward to having that info. Would that limitation also not show Next Hop as well? I have a few zigbee devices not showing that either.
Yes, that’s my expectation since my other button devices (other Iris and Minimotes) have that capability. Here’s an Iris button. and the one below that is a Minimote (created in January using stock DTH), and the stock DTH for both has ocfDeviceType: “x.com.st.d.remotecontroller”:
The DTH for the Minimote was last updated in your Github repo on Dec 13, 2019, and the Zigbee DTH was updated on Dec 3, 2019.