I suppose I could look into it but I don't need need anymore controlled outlets at the moment. 7 of the bulbs I had to re-pair were in the same room with the hub...
Devices do not necessarily connect to the "closest" hub/repeater. If they did that it would defeat the purpose of expanding your mesh outward.
I think this is also part of the frustration. When I've had had a stable z-wave/zigbee mesh under Wink/Smartthings for years and a stable network under Hubitat for months. To just be told, "Oh you got a bad mesh...".
Part of the reason why I just deleted my support thread to ask for user experiences. Ultimately I knew I was on my own and I am glad I figured it out on my own.
[edit] I know there isn't much the Hubitat staff can do to troubleshoot these kinds of issues. Mine was fixed by changing drivers. But it would be nice it there was more information that could be attained without a sniffer.
1 Like
I know that there aren't many zwave tools out there (for reasonable prices).
However, when I get a chance, I'm going to try and get an XBee and the XCTU software. from what I've heard, that's a good diagnostic tool.
By the way: to Hubitat Management:
You might want to consider getting in the business of selling such tools at reasonable prices. There is clearly a need for them.
You've been here 7 months and I'm sure, like me, you've seen: "I've had a stable z-wave/zigbee mesh under Wink/Smartthings/Vera/HASS/... for months/years" more than a few times. 
I'm also sure we don't know the exact reason for it being true.. but there are certainly ways in which SmartThings (specifically) obscured it. We know that they poll their devices, need it or not. This has the very real effect of reducing the Z-stuff radio bandwidth. You can only put useful packets on a SmartThings Z-radio network between poll packets. Remember, it's not just the poll packet that ST sends, but the reply too. ST may want to defer a poll to get a useful packet out, but it's got to wait for the reply from the previous poll to clear the airwaves. The benefit of Hubitat NOT polling indiscriminately is that those slices of Z-radio airwaves are available for more devices.
My point is.. Hubitat's use of Z-Radio airspace is probably quite different from others.
My next point is about Z-stuff deployment. When I was adding devices to SmartThings, it was 1-3 at a time, over many months. When it came time to switch to Hubitat, I did all 85 devices in a day. I was successful, but that's at least in part to the fact I've had 5 different manufacturers of Hubs over time. Now I've got just under a hundred devices on my first Hubitat Hub and another 75 on my second Hubitat Hub. All 3 of my Z-Radio meshes are stable... but that's a subjective response. If I deployed a couple of Aeon Repeaters, would I see an improvement??
2 Likes
I too had very slow Z-Wave response after upgrading from 2.1.3.128 to 2.1.4.129 and 2.1.4.130 came out right then so I tried upgrading to that but after a day Z-Wave was still very slow so I ended up going back to 2.1.3.128 and haven't had issues since (other than trying to pair a new Z-Wave device which got stuck initializing and the hub kept seeing it in the initializing state until I rebooted my hub).
OK, I realize that you think rolling back to 128 changed something. However, what you aren't aware of is that there were no changes between 128 and 130 to Z-Wave or Zigbee. Those builds have identical code for those. The only changes made were documented in the release notes.
I think our mesh issues are coincidence and not necessarily linked to a specific release. I've been having issues with both Zigbee and Z-Wave for over two months, and I'm working through the issues with BobbyD. Hopefully we come up with something, and I won't have to leave out all the cool integrations like Chromecast and HubConnect. Fingers crossed.
I did have another Z-Wave sensor die last night. I always find they've gone offline at the most inopportune time. Luckily I also have wall buttons, so I can usually make things work until I climb up on the ladder and power-cycle the zig/zw sensors by yanking batteries. It's about one device per day.
So far I have not found a monitoring app that really helps me, because they report devices as offline simply because they haven't had any activity. Though maybe I have a much larger issue if my devices are not all reporting in within an hour or two. I set it to 4+ hours and I have dozens of devices showing up on the report each time.
.128 has been great for me too. All my repeaters have stayed connected and all my battery powered zigbee devices have been firing no issue. Like they said before, if there is nothing in the release notes that you need / want changed you dont Need to update.
For me I need to update so I can fix some broken scenes, but I am dreading the day. Will probably do it on the weekend just incase I need to fix it all up.
You have a misconception about the risks of updating. What you're suggesting belongs in the category of "forum myth", not fact. We will always note when things are done to Z-Wave or Zigbee functionality in the release notes. These change pretty infrequently, and have been stable for quite some time. When we do make changes, it will almost always be to correct a problem.
It is always a good idea to update to the last release of a major release version. For 2.1.4 that is build 130. Build 130 is the most reliable and bug free build of 2.1.4. It is what we are shipping on new hubs. There is no valid reason not to update to it.
And yes, no one is going to force anyone to update. But spreading misinformation is not good.
2 Likes
all of my experiences are not myth, they did happen.
My experience of .130 was documented in my thread. Like I have said, I have to update because I need to fix my softwares broken scenes.
It seems a few people are having issues with "stable" (+ 6 month) battery powered Z setups with repeaters on their hubs on .130 I think saying "we didnt touch it" might be reassuring that it wasnt updated so its not broken - but neither was Scenes and it has a bug it in.
Im not spreading misinformation, I am replying also to try and help people with their setups, but im also open to the fact that something could be broken.
I want my/other peoples experience to be great, I hate being frustrated with things not working, but the fact of the matter is on .128 all my automations are firing as required with no issues, on .130 they didnt. I didnt add anything new to my setup - just updated it.
Yes, the bug pre-existed 2.1.4.
Please take a little time to try 130 again, and see if things work or not as before doing that. If they break, we would definitely want to take a close look at what breaks and why. Make a backup before trying it. This would be a big help to us and others.
2 Likes
@bravenel I went back to .130 and so far it's getting better. Been working with @bobbyD and he has been great!
I'm working with Motion lighting app. I think I have to set up 2 for what I want to do
Turn on kitchen light when motion is action between sunrise and 9am. Turn off after 1 min
Turn on kitchen light when motion is active between sunset and 11pm. Turn off after 1 min.
Is this correct having to set up 2
1 Like
I am open to trying it again, knowing I can roll back.
Im happy to report on it, as long as my posts are taken in the vein they are meant, to help finding issues. All I want is for the platform to be great, and i'll help however I can.
1 Like
You could setup modes,
morning = sunrise > 9am
Night = sunset > 11pm
Then you could have multiple rules running only during those times.
Restrictioned to mode X and Y
Or you can setup 2 to test for now
so no z-wave changes between 2.1.3 and 2.1.4? You can definitely add me to the list of people who are seeing oddities with 2.1.4 (123 and 130) vs 2.1.3.
I had mesh issues, bought z-wave repeaters, got my mesh perfect. My triggers are nearly instant, I've gone one crappy door lock that is off by a second or two.
2.1.4 was constant issues with door locks not updating. I couldn't get a consistent door lock state using "Generic Z-Wave Door Lock". Unlocked when locked, locked when unlocked. Tapping button does nothing, then after a minute or two it locks/unlocks. Polling on/off made no difference. My z-wave repair completed in just a couple of minutes with no errors.
Rolled back to 2.1.3 and voila, everything is back to being perfect.
It can't be a coincidence... and I was on 2.1.4 for almost a week with these issues, thinking it would sort itself out.
1 Like
If there is a problem, it doesnāt have to have been caused by direct changes to the wireless driver code. From what I can see, itās apps reacting to input or sending outputs that are where the problem occurs.
Could some change to another part of the system be causing high CPU or sucking bus bandwidth? As a programmer, thatās where Iād be looking next...
Edit: or perhaps not CPU or i/o, but dead locking on a shared resource.
1 Like
Exactly. As a software engineer, I've learned long ago that just because a piece of code in a particular area hasn't been changed, it doesn't mean that some other seemingly unrelated change could have an affect. It could be something as obscure as a simple timing change causing a latent defect to suddenly manifest itself.
1 Like
Due to the certificate issue and having a C-3 hub and not wanting to have issues getting updates in the future I decided to try the upgrade from 2.1.3.128 to 2.1.4.130 again yesterday.
So far the only issue I've noticed was I had to pull the battery from one of my Schlage locks to get it to talk to the system again. Otherwise my rules that rely on Z-Wave devices seemed to be working well last night.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
