When adding devices they occasionally include improperly and one of the signs of such issues is a Raw Description in the IDE with a few too many zeros…
The part that is troubling is: mfr:0000 prod:0000 model:0000 ver:0.00 zwv:0.00 lib:00
Since I migrated to v3 hub, I have been unable to include any of my Aeotec Recessed Door Sensors properly. They all get included with this botched Raw Description, and fail to pick up the DTH that was previously working. The DTH they come up with is the default Door and Window contact DTH. While they do report open/closed events, I want to ensure the device is properly included.
Can anyone explain the process behind that Raw Description? What queries that data from the sensor? Is it the ST Cloud? If so, is this a bug somewhere in the cloud? Or is this info provided by the DTH once the proper one is selected?
I tried adding these sensors to HomeSeer’s ZFlash and they join securely in an instant. The LED then stays on for the 10 minutes or so as per the user manual. Instead, if I include them on the ST hub the LED does NOT stay on (the manual says that the LED staying on is an indication that the sensor was included properly).
Distance is not a factor as I tried including it near and far. I suspect secure inclusion is adding to the problem though… on the v2 hub I believe these were not including securely by default and I don’t even know whether the DTH can handle the secure protocol… I am guessing not but I don’t know enough Groovy to fix it.
Anyway, back to the original question:
How is the Raw Description set? I assume the data comes from the device. I verified that the devices report their mfr, prod, model and type properly as ZFlash picked it all up just fine. So… where is the issue? ST Cloud? the DTH? Elsewhere?
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
2
I have tried all sorts of things but I cannot get, except once in 20-30 attempts, ST to capture the correct full raw description of the Aeon Recessed Door Sensor. If I try to include it with the HomeSeer Z-Flash, I can see the device reports the correct “Node Information Frame” however in ST (on a v3 hub) the backend seems not to be capturing it.
@duncan - could this be a v3 related firmware issue?
Yes, I just saw the PM, thank you. Any chance this might also restore my Scenes, they have been dead since my migration not long after release of v3? (getting greedy now )
It was a long time ago so I don’t recall specific details but it appears my issues have mostly always been caused by too much zwave traffic. Try to tone down all reporting (or even better turn it off if not needed) and try again. In my case it appears that zooz 4 in 1 sensors, and zooz outlets of a couple different models were way too chatty. You could try to remove batteries to zwave sensors and unplug outlets that report energy usage, and try again. Also, I believe I did the inclusion right next to the hub and I kept the sensor awake by pressing the button every 5 to 10 seconds. I am in the process of reducing my zwave devices by replacing them with zigbee equivalents where possible. I am just tired of having these issues.
Hey sorry I didn’t see this - typically this happens as @aruffell mentioned (too much traffic) or it can happen if the device is too far from the hub or just didn’t include fully.
If you can try removing this and then including it closer to the hub, it should fix the issue.
Here’s a knowledge base article we wrote that may also help and give more of an explanation (I know this is for the dimmer switch whereas you have a bulb, but same concept applies):
Hey Eric! Thanks so much for chiming in! I’ve tried repairing well over 30 times in a number of different ways, handlers, and SmartThings apps. I even put a long cable and extension cord on to bring the hub within 1 ft. of the device and get it far away from my other equipment. I’ve tried the bulb in several different fixtures/locations. I also bought a z-wave stick and updated the firmware to 2.3. Nothing helped…
Wait for 5-10 seconds and then starting the pairing steps on the device
Pairing completed within 5 seconds and identified correctly with all parameters and even correct device handler
This is a CRAZY process to have to follow, but, sadly, while it fixed the 0000’s, it is still showing “ZWAVE_S0_FAILED” under the security field and when I try to associate the bulb with an Inovelli switch, the switch shows the association info in the IDE, but the bulb shows no trace of it. I’m assuming this is because it is not matching the S0 security that the switch is setup with.
I opened a support case with SmartThings and they told me to switch to a different brand bulb (I was shocked to read that!). I feel like this is some configuration or software issue, not a hardware issue, but not sure how to prove it at this point.
It is mentioned earlier in this thread about too much reporting, but I’m not understanding how to reduce it. I do have setup with “211” devices (a mix of Zigbee, Z-wave, and virtual, 26 of which are Inovelli ), but I wouldn’t think that should be maxing out my system, right? It is a V2 Hub.
Thanks again for your help. I really want to get these bulbs working right and enjoy them (I have 8 more to pair once figured out) instead of pulling my hair out! I do have an active support case for this open with your team as well, but it taking a bit to get figured out. Any ideas you can offer would be GREATLY appreciated!!!
@johnsonej23 - We likely have similar setups… I am at 293 (all included) devices of which 100 are Zwave. Since you are having zwave issues, I believe you can ignore the zigbee, C2C and virtual devices. In my case, it appears that all my Zooz devices were causing too much traffic. ST had me pull the battery to all the 4in1 sensors and unplug the zooz metering outlets. After doing so I was able to include the devices that were having lots of issues. I too have had to resort to rebooting the hub just before I tried inclusions as it seemed to help. It is as if it quiets down everything for just enough time to allow the information node to make it to the hub.
I am now actively reducing my zwave devices in favor of Zigbee. My first target is to replace about a dozen outlets with Zigbee 3.0 Jasco outlets. I’ve already replaced 4 and they are incredibly fast compared to their zwave counterparts installed in my system. I am hoping to spread the load across the two mesh networks to reduce my numerous traffic related issues with zwave devices.
Hmmm… yeah that’s interesting. What security do you have the switch at? If it’s at S2 that’s likely your issue, but you can fix that by removing the switch and then either using the Classic App to pair the switch or by selecting, “Scan Nearby” in the new app. It should include as S0 as well.
no comment…
I’m not too sure what the max is for ST – I think I’ve read 255, but I’m not sure honestly. That’s a nice amount of devices though, nice work!
Yeah no worries – I’ll look for you in our ticket system. If you pair one of the other bulbs, do you experience the same issue?
I got to the point where SmartThings told me there was nothing else they could do and that I needed to switch to a new brand device. I ended up buying a used V2 ST Hub. I set it up and was able to immediately, properly pair the Inovelli bulb and switch on the first try. So why am I having trouble on my original hub with all of my other devices connected to it?
How many devices do you have on your ZWAVE mesh network? I have your same issue with different devices and the issue seems to be related with excessive traffic on the zwave network causing the hub to miss the information node sent by the device being paired… or something along those lines. If I pair those same devices on another zwave controller, it works perfectly, but on my loaded ST hub it is a pure nightmare.
Maybe the device manufacturer might be able to do something about it if there are any options related to that information node being sent, such as repeating it, or allowing for more time… I really don’t know if any of these are possible or would help, but I don’t believe the issue is one sided otherwise all devices would have this issue, and it is not so in my use case.
It’s a great question – I’ve actually not seen this before happen multiple times. Usually, I’ve only seen this when a device isn’t including properly and fails as referenced in that article above. I haven’t seen it where it works on one hub and not the other. I wish I had a better explanation. I was in a similar boat with my V2 hub a few months ago where I couldn’t include devices, but I could exclude them instantly. It was so strange – unfortunately, I ended up switching hubs (different brand) and everything has been working flawlessly. So, I’m not sure what happened and I agree with @aruffell, there has to be something both sides can do to make this easier – we’ll look into it on our end, but I’m also curious to see what ST says now that you have it working on a separate hub.
In 2018, when I was troubleshooting this very same issue with ST’s developers, I was told this:
“I am 99% sure what the root cause is, the device itself is not updating its Node Information Frame fast enough once Secure inclusion is completed, I can put in a workaround in the firmware releases.”
The overarching issue with my network was that I had too many sensors and energy reporting devices that were constantly sending reports. The surprising thing is that ST gave me a list of the chatty devices (messages every 30 seconds) most of which I had already toned down the reporting (reports off or hours in between)… however, according to ST’s report, those devices were still accounting for the majority of traffic on my network regardless of my settings. For the most part those devices were Zooz 4 in 1 sensors and Zooz plug in outlets. Things seem to work better without them.
I normally had 72 z-wave devices. I took 11 “new generation” Inovelli switches off of the hub though to update firmware and left them off as part of this troubleshooting. With “only” 61 other z-wave devices (some 1st gen Inovelli) now connected, I still have the issue.
With the recent announcement that SmartThings made yesterday, it makes me wonder if my Echo Speaks implementation could cause an issue? I have 31 Echo Speaks “Devices” (yes, my wife says I have a problem…). Are they resource intensive on the hub or on the ST cloud servers? Anyone know?
I appreciate you looking into it. My ST support request referencing my original ticket was responded to basically starting all over from scratch and is trying to troubleshoot why I have 2 locations and one hub is showing offline (I only have enough network jacks for one hub at a time). I feel like this is going to be a really long road trying to get to someone that will actually look objectively at what I’m asking…
@johnsonej23 - I have heard, and experienced personally, that issues such as this one start at about 40 Zwave devices on an ST hub. I once had to rebuild my whole system and surely enough hell broke loos once I was around 40 zwave devices.
Of the 72 you mentioned, how many are energy reporting, or sensors? Can you turn off all reporting on those, or even better unplug / remove batteries? When ST had me do it, I saw the difference…
When I was troubleshooting my issues, I clarified with ST that the issue was specifically traffic on the zwave mesh network and not other traffic such as C2C integrations, zigbee, etc. It was specifically an issue with a flood of zwave messages that were causing things to be dropped or time out.
I finally got through this!! I started removing automations, smart apps, and devices. After removing and re-pairing a certain switch (one that wasn’t giving me any issues) I was finally able to start pairing other devices properly. I have all of my devices successfully paired back up again. Now I just need to get all of my automations recreated and smart apps reinstalled. Really disappointed with all of the time I wasted and that SmartThings support staff blamed it on the product when it was something with them. I’m really surprised that someone on their team couldn’t look at my setup and tell me which device was causing an issue…
)
I do have an active support case for this open with your team as well, but it taking a bit to get figured out. Any ideas you can offer would be GREATLY appreciated!!!
no comment…