Suddenly shows Failed and the "Remove/Replace/Refresh" choices.
Would you mind showing me a screen shot of your node list?
Whats a more private way to send that to you?
I did see one "failed" device at the bottom with no info that I eventually (multiple "remove" attempts later) got rid of.
But I have one S2 door sensor that isn't showing up.
Can you place the "device id games" to repair that without jacking up all the RM entries?
Click on his picture and send a private message.
2 Likes
You could PM it to me
Same here....I installed 2.2.3 last night. It updated the routes all night then got hung up. I just did a full shutdown this morning and everything is working fine now.
The best advice I can give: don't do repairs if you only have zwave plus devices - it is really not needed.
If you have non-plus devices, yes it can help repair routes in those nodes.
Second best advice I can give: replace / get rid of any non-plus devices. ASAP. Then see advice #1 above after that.
1 Like
I was wondering where node A5 was........
Then I remembered if you want to drive from London to Hollyhead in North Wales to get the car ferry to Ireland you can take the A5.
As I'm in Ireland this now makes sense as I bought the C7 and some of my Z-Wave devices from Vesternet in the UK and my Z-Wave devices are probably still routing their way here by road using the A5.
Solved......
4 Likes
The M4 is my road. London to Wales and back again a few times a year.
I have some A5 routing devices. All of the failed nodes have it and some active nodes too.
I have the same A5 middleman in all but one of my 25 routes on version 2.2.3.119. The Hubitat has been rebooted a number of times and they persist. I have not performed a full shutdown removing power since upgrading to 2.2.3.119. The Node ID's sure appear to be doled out by the Hub in sequential order which I thought I read somewhere on this forum as well.
On my three day old C7 which is being set up from scratch, my Z-wave Node ID is currently up to 0x22 which is a long way from 0xA5. I'm having trouble accepting an arbitrary injection of a rogue device in the Route column which didn't exist in prior versions is likely only a cosmetic bug without wondering how useful the route display is at all in trying to troubleshoot devices.
In my case, if one assumes A5 is being displayed where there should be no ID displayed then many of my routes could not possibly work as well as they are given physical limitations. Whereas, if one assumes A5 is a misinterpretation of a single ID from my working network, they still could not possibly work given physical limitations. In any case I'd call it a bug.
I think they have found some issues. Not sure of any details.
But I'm having significant issues with communication in general.
In particular, my repeaters don't seem to be effective (they are often "failed" and not participating in routes). Anything with an A5 seems to be in trouble.
Same issue. Also 01 -> A5 -> xx.
But everything is working, so...
Hi,
I am also having this issue. On a brand new C7. With brand new Iris 3210-L2 smart plugs with Z-Wave Plus Repeaters. Everything Zigbee is working fine, including the two SmartThings Multipurpose Sensors V5, but Z-Wave is a total crapshoot. In the attached screenshot you'll see the only working repeater is 06, which is located less than 6ft away from the Hub, while 0B is less than 12ft away from the Hub and nonworking; all other Z-Wave Plus repeaters are nonworking.
Whether this issue is cosmetic or not is irrelevant and it is far worse if it is an actual functional issue which was dismissed as cosmetic. (I do not see how it could be cosmetic when interrogating and testing the devices throws a nonreachable error.) Given Hubitat's resources I can fully understand not having the testing environment to ensure every facet and configuration a new firmware will service it is also not the best look for said issue to be, at least to my eyes, dismissed in this fashion. It's especially not a good look for a brand new Hubitat user.
If there's any further diagnostics I can perform that would help solve this issue please let me know. (I have tried repairing the mesh as well as giving it time to repair itself and neither worked.) I do hope it is fixed in a firmware update quite soon.
Thanks.
I don’t think the Hubitat team are dismissing this. As there hasn’t been but the one hotfix released (which was a critical issue), I would read this as still diligently working on a fix for these reported problems.
2 Likes
I suspect that it's just a reporting issue. If things are routed through A5 but still work try to ignore it. I find that sometimes I see the A5 thing and sometimes I don't but functionality is there in either case. I see this as a low priority issue so I'll wait and see.
If you have a functional issue, however, my advice is to ignore the A5 thing when you debug the problem.
They are not routing/working (interrogation and testing communications both fail). Every device without A5 in route performs fine. Even if Hubitat throwing A5 into the routing is cosmetic it appears to prove there is a routing bug behind it.
Accusing Hubitat of dismissing the issue was likely overstating my case, especially when it was a non-staff member that offered that theory--apologies. It is just frustrating that there are multiple threads expressing this same issue with no real sense of a bug fix in sight.
1 Like
While I haven’t had any problems with the latest updates, I also have mostly zigbee devices (although it may not be related). I don’t think I have ever seen so many reports of major problems after an update and can only assume the team is working on a resolution.
2 Likes
New radio and software stack. Huge influx of users with all kinds of crazy setups. Give them some time and they'll get it resolved.
4 Likes
