@672southmain - My response would be completely different if the response had shown empathy for the impact I was experiencing and let me know it was actively being worked on and that "they would provide an update as they made progress" but the response was more like "we hear you but don't bug us". I run a large multi-national software development team so I am empathetic for the situation the Hubitat team is in but I know my customers would not accept that kind of response either.
1 Like
It's not in the Z-Wave log. The Z-Wave log will be empty. You will see the warning in the general log. It looks like this:
Z-Wave Network responded with Busy message.
Yes. They say a hotfix is being worked on.
So unfortunately it is normal for the latest firmware.
@dennypage - Thanks for the clarification. Yes, I am seeing Z-wave busy and a Z-wave repair is failing:
2020-08-20 02:40:30.990 pm warnZ-Wave Network responded with Busy message.
2020-08-20 02:41:48.761 pm errorZ-Wave Node 2F: Repair failed, the maximum retries have been exceeded
I continue to lurk, waiting for more official progress. I have two C-7 units that are waiting for things to be flushed out. Itâs unfortunate that the C-7 rollout has been so troublesome for Z-Wave users. Some of my thoughts (just opinions and not excuses either) on this though:
-
China tariffs and/or threat of made all sorts of things electronic have paths to develop or manufacture electronics crazy in 2019/2021.
-
China delays and issues related to COVID-19 being there early in the year also affected schedules and capacity for development and manufacturing as well and the effects continue.
-
The mass influx of users due to abandoned and/or changed platforms created a demand for the HE product at a time where stock levels were unpredictable and availability was limited. I am sure they intended to get some C-7 stock and work on that more while slowly going through the C-5âs instead of needing to sell everyone the fancy new product because it was the only thing they could deliver.
-
New employees were brought on board during all of this and deserve a reasonable training and acclamation time but instead are thrown to the wolves because of pressing needs during the rollout and due to the expanded customer base.
-
There are good people and a limited crew as clearly demonstrated by their participation in these forums working for this company. I donât personally know any of them but I do see responses all the time before 8 and after 5 and on weekends. This isnât only a job, itâs a livelihood and passion for some of them, I am sure of that.
Yeah, it sucks I canât use my C-7âs the way I want right now so I choose to let them sit. I see the company staff participating every day here in the forums and they are definitely aware of the issues. I can tell alone by the frequency of posts as it is reduced that they are busy without them having to state such.
I can see as a new user how frustrating it can be thinking you are moving to the Apple of HA platforms where this is going to be âThe Next Best Thingâ or âIt Just Worksâ but that just isnât the case. That doesnât exist. This is a small company with a hand full of people that work with their user community in what needs to be a collaboration between us and the product they put out. We can be frustrated together with bumps in the road as long as there is equal praise and recognition for the good work and added features to the platform.
Also, the dev community here is fantastic and almost everyone is open to change and ideas for apps and drivers. So nice to see.
Anyhow, I sit patiently reading these forums and waiting for the new and untested C-7 to exit essentially a beta period and what I feel was a forced-hand release and find its first stable release. This coming from a user that has a C-5 that has to restart daily to avoid slowdowns and yet is still inspired because I know that the staff behind it and the community are setup for success because they care about their product and are willing to work together to see this through.
-Travis
8 Likes
Once the Busy issue starts, you're kinda stuck. One thing the @bcopeland said is that if you are receiving Busy messages, you should not attempt to perform a Z-Wave repair.
So for some people, if they reboot the hub by shutting down and pulling power for 10 seconds, the the existing devices work fine after boot. If you are one of these, do not attempt to do a repair. For others, like me, the Busy messages start as soon as the hub boots, and there is no work-around.
I'll go one step further and say that unless you have non-plus zwave devices, you should never do a repair at all.
It is pretty much unnecessary for plus devices - just takes up time and zwave mesh bandwidth for little/no gain.
But each to their own.
1 Like
@daweeze - I suspect much of what you list are factors affecting the situation. And I do think the timing is unfortunate for many coming from another system. I've been using HE for 2.5 yrs and have to say up to now it has been very dependable and that might be part of what is driving my frustration as they used to be very proactive on social media to let users know when they had an issue they were working on which is why I am shocked now with the lack of transparency if there are truly systemic issues or not continuing after the patches last week. I play with Wyze cameras (it's not my primary video security system) and while Wyze is far from perfect, I do think they do a great job of interacting with their community and being transparent. I feel like Hubitat has lost their edge in this area but they are far from being as removed as many other, much larger, companies.
@dennypage - Thanks for the feedback. Looks like I am in the same boat as you as I get the busy error immediately after rebooting (and restoring power).
@JasonJoel - I'll keep that in mind. I had assumed repairing the network was never a bad thing to reset network routing maps as things were added/removed so didn't realize there might be a downside.
1 Like
It should always be safe to do. The issue happening right now is actually a bug, that will be fixed. So while it might not be safe and reliable right now, in general it should be and in the long-term will be.
But that said, even after the bug is fixed if you don't have any non plus devices, you really don't need to do repairs.
Exactly right. "It just works" doesn't exist in home automation, and may never exist, except in very very limited functionality. An automation hub and devices are tools. A wide variety of tools that can be used together as intended, or used together as no one ever envisioned before you.
An "It just works" smarthome would be no less surprising to me than an "It just works" woodshop that produced fine cabinetry without needing any woodworking skills.
That said, I feel the pain of folks who are waiting for fixes. This is the first 700 series hub on the market. It's having teething pains. It happens. But it's still painful to wait for.
7 Likes
the wotrkaround i found (not really a workaround .. you have to start over) but you can use the hub. is to backup to 2.2.2 , reboot, do a zwave radio reseet, reboot and start readding all devices..
at least hub works again.
so for the past two days adding zwave devices including s2 devices has been working without a problem. I decided to add another aeotec range extender 7. Brand new from amazon yesterday. I paired it, got the popup where it asks for the pin, i type it in and it sits with a "found new device with ID" and nothing more. I check in the zwave details (where the routes can be found) and i see the device id there but it has a button that says "discover" rather than a name. I exclude and click the button, i get unknown device excluded. I reboot and i attempt to re-pair the device. Same thing as above.
Is there some extra magic i should be doing here?
I'm on my fifth go-round of "start over." I'm waiting for the fix this time. 
2 Likes
Why is it unnecessary for Plus devices?
Because whether you like it or not, if they don't have a good path to the hub they will send out explorer frames and rebuild their route automatically. Non-plus devices can't do that - they will just die and stay dead (which is why repairs can help greatly with those devices).
That said, if you put a new device right in the middle of your mesh, doing a repair can help the existing nodes consider using that new device faster. So that is one place where a repair MIGHT help on plus devices.
But again, if zwave plus devices have working routes to the hub, they will tend to stick to those routes until they don't work. And if/when they don't work, they will update their routes automatically anyway.
And on the hub side it is a whole different story - it is always looking at routes and route optimization. A repair doesn't really do much for the hub side.
1 Like
The number one thing I would recommend is to not pair the RE7 securely. Uncheck all the boxes when you pair it. Security for a repeater is not particularly important. Note that even in insecure mode, it may still take a minute (literally) for the hub to decide that the RE7 is completely set up.
If you are interested in a driver (you don't need one), you can find one here. The driver is useful for conducting power and range tests to confirm placement.
I thought I saw that the process of route optimization in plus will take a few days (?) and that doing a repair is just a good way to optimize the routes quicker. Do a manufacturers implementation of Zwave influence this?
@bcopeland Knows more about it than I do (and will likely point out all the ways I'm oversimplifying the situation, if he has time). But no, I have not found that route optimization takes "days" on zwave plus devices.
I have always heard that repeated, but in many hours looking at sniffer logs and both hub and device route data I have not seen that to be true at all.
But it is a complex topic. So sometimes things can be true in a certain context, and not in others. Or true, but not in a particularly useful or meaningful way.
1 Like
oh boy... I've used the zwave toolkit to provide some insight into my ST Zwave network (hopefully a thing of the past , when he sorts out its Zwave issues) and while it was interesting it really only showed how bad my outlying sensors were.
I also read in here some place that more than two hops is not good, but I think some of my devices have 4 or 5 hops. Thoughts?
This discussion may not belong here, I have two brand new C7's that are just sitting with half of my devices on nonfunctioning hubs... so other than waiting for a fix, which sounds like its looking for beta testers, I just found your comment interesting.
I don't subscribe to that school of thought. 15-20% of my 70+ device mesh are devices at 3 hops, and they work great. I prefer not to have anything at 4 hops, though.
1 Like
