For all the extra hours you put in at night, weekends & holidays going that extra mile in figuring out these issues and then the extra hours working on the fixes.
A personal thank you for this one…
We weren’t crazy. . .how many network heals have Vera owners done to no avail?
Thank you to MCV for following through and describing to the end user why the Zwave system was routing to dead ends . . . how frustrating has that been…
I hope this fixes the reliability with the locks we are seeing. Since the locks use a secure communication to vera. If the response takes more then a few seconds, the secure response expires and never gets recognized by vera. The dead route issue sounds exactly what is happening to getting proper status of the locks. Looking forward to the next release for testing!
Is the z-wave routing table “workaround” enabled release in the hands of the beta testers at this point? As mentioned in other threads I’ve been suffering from severe scene slowness from my z-wave devices. It seemed counter intuitive that running heal/repair operations seemed to make the issue incrementally worse each time, but with this announcement my issues seem to make perfect sense.
I’d like to know if any beta testers had been experiencing similar issues to mine (scenes that once took 1-3 seconds, consistently taking 15-30 seconds or more to complete, especially scenes that include devices which have been moved from room to room in the past), and if this workaround has resolved the issues? I’m very much looking forward to trying it out myself when it is made available for the general public to test.
@fall-line: what hw/fw versions do you have? My stuff all responds instantly (or almost) and I’ve migrated from a V1 to a V2 and moved modules around without any problems.
I’m on Vera2, 1.1.1186 at this point. I’ve been on the same system since vera2 was first released, and have just upgraded firmware versions as they have been released. I’m trying not to get my hopes up too much, but it does sound as though the routing table issue (specifically not being cleared, but just added to) that has been described by MCV is a likely culprit of my issues. Over time, i’ve noticed my scenes slowing down more and more, and each time I’ve moved devices around and/or tried to run a “heal” it seems to have made it worse.
Correct me if I’m wrong, but when you migrated from v1 to v2, your routing table would have been rebuilt fresh, right? It has been suggested that if I do a factory reset, and re-import my backed up config, that I would get a fresh table as well, but I have been hesitant (or, er, lazy) to do this, especially now that a potential resolution is close at hand.
I have similar issues, not so much in devices being moved but with devices being added, as MCV stated, each device thats added, the chip thinks it can communicate with it directly on the first hop.
Sometimes my scenes take 30 minutes to complete so I’m really anxious to get this work around FW to be able to run and complete a heal network for the first time.
The route is not rebuilt unless you run AND complete a heal network. This should be done after every device added, or group of devices…
I added a couple more devices today, and the scene execution time of my most commonly used scenes (e.g. living room lights, bedtime, etc - scenes that I use man times daily) is well over 30 seconds, every time. As I mentioned before, I expect the routing table changes MCV has mentioned will help, but I’m getting desperate here. To my fiancee and any guests, the appearance is that the lighting system is broken.
I’m submitting a ticket with verbose logging to MCV, and am considering a factory reset and restore from backup as had been suggested previously. Anyone else has another suggestion, or more information on when the next beta will be available?
It’s been a week or so since i’ve attempted one. Once MCV announced the issues with the routing table, I’ve expected an additional heal could if anything, make things worse.
If you can access the log file after then you know they complete. Before I started using a USB drive mine would rarely complete and it would screw things up more.
I find the heal to be a random at the moment, they are never good (compared to a fresh and small network) but occasionally you can run one that seems to make the best of a bad situation.
Good thoughts, thank you. I’m running another heal now, and will double chreck the result. To be fair, I’ve used a heal to greet effect in the past, it just doesn’t seem to be helping (possibly hurting) here.
If worse comes to worse, do you concur that a factory reset and restore from backup would provide a fresh table and in theory better performance? Aside from the PITA factor, any reason not to do this?
I’d hang out for some new Firmware if I was you! If you have a large network then who’s to say that it doesn’t just get up to a certain point and then just get bad again!?
I concur with @Strangely, hold off until the next MCV release. The next release will have a work around fix for the heal process.
Rebuilding may create a new routing table but it wont be a good one, the problem at the moment is the way the Sigma FW thinks every device is at Hop 1. That’s why the heal process does not work.
I had been planning to just wait for the new firmware (and will continue to). The situation is just getting more dire when it comes to the acceptance factor. Thanks again for you help gents.
The repair operation I ran yesterday does seem to have completed, as there is a new Repair Report listed in the Z-Wave Repair tab. I have been unable to view this report via the UI ( I click on the drop down and select it, but the report is never displayed.), but I was able to find it after loggin in via SSH in /tmp/.
I read through the report and everything looks to be in order.
11-03-07 1:46:55 report for HealNetwork. Successful: Y Updated net: N Job ID: job#2 :heal network resume (0x0x761d28) P:50 S:5