Hi guys I'm really struggling moving to C7. Can someone give me an explanation of the following observation please. I'm hoping it will give me a better lead on a resolution.
I add a switch and it works fine. I turn the switch on manually and HE see its. I turn it off via HE and the switch responds. Good so far.
I start to move the switch further away.
Eventually I get the switch to a position where control from HE doesn't work but HE sees the result of me turning the switch off/on manually. I can't get me head around how my manual change(physically turning it off/on) is routed back to HE but HE doesn't have a route back.
I found this video below helpful to understand basics
I also have just a handful of Z-Wave devices (3 Aeotec recessed door sensors and about 8-10 Zooz devices, before I installed any of them I had picked up and paired a set of Aeotec repeaters and set them up in (what I thought were) strategic locations. All has been working rock solid in my ~1700 sq ft house
Thanks but I'm hoping for an answer to my original question. The C5 doesn't behave like this. It's as though the inbound message to HE is a result of some zwave type broadcast, but HE is failing to learn the new path from that inbound message and so doesn't update it's routing table. Hence HE->device fails.
This is frustrating and I have observed the same erratic duplex communication behavior between the C5 and C7 which are in the same area and distance to the device. I have had to purchase either a Z-Wave repeater or install a powered switch/outlet between the hub and the Z-Wave device to get it to {hopefully} work.
It's definitely witch craft or a conspiracy plot by the Z-Wave vendors to get us to purchase more of their devices...
That's a easy one to answer and @thebearmay is correct.
If you have a look at the z-wave spec for the series 700 z-wave chip in order for it to be able to improve the previous series ranges it's hearing sensitivity needs to be stronger. So yes it very likely your hub will hear commands that the z-wave 500 chip can't. I'm assuming your device is z-wave plus 500 because you said it sends it's state.
The C7 only has mains powered switches paired. The current physical configuration worked fine on C5. I thought the C7 was supposed to have extended range not less. All the switches are TKBHOME TZ68E mostly. I don't believe its a device issue. I'm also trying to understand the Zwave routing information provided by the C7. I have one switch delivering power readings but the routing table is blank. This device should be used to route to my failing device. I'm thinking it's a code issue in HE or the Zwave microcode. The routing tables seems to be most reluctant to update its self. My working theory that fits my observations is that HE isn't capturing the inbound routes. Of course I don't know what I am talking about but I bet someone on these forums does!
Maybe the following will help. I have 2 switches next to each other. One works fine and it's being routed through another switch. The one next to it will not work using HE. How is that even possible. I can move the failing switch to be a direct link from HE and it starts working again. How do I force a route update? Maybe I just need to wait and do nothing and it will sort its self out??
Did but got rid of them using REMOVE option in ZWAVE Details screen. Why does my routing table show many blanks. Mostly I have to do something like switch it on to get the routing table populated. What does this mean? It builds a route when the routing table is blank. Is this a sensible thing to do.. the only time my devices move is when I am pairing / setting up for the 1st time. Is it normal behaviour to have blanks in the routing table(but still work as I can see inbound data coming in)
For successful 2-way communication both controller and device need to use viable routes.. not necessarily the same ones, but in any case ones that still work. Much of this process hasn't yet been formally disclosed but quite a bit has been documented from observation. Maybe not helpful as to the 'why', but as to 'how' the process can break down:
A device has two ways to learn a route to the controller-- by being informed of one (by the controller), or discovering one on its own (using explorer frames when a known route has failed). It otherwise doesn't proactively compute routes on its own; nor does it look for new neighbors unless told to during inclusion or repair. In either case, the last working routes are remembered and used until they fail; if/when they do, the explorer mechanism is invoked.
The controller has two ways of learning routes to a device-- by computing them from a node adjacency table it maintains and sending them to the target device (during inclusion or repair, which the device then uses in reverse order as routing fields), or by observing the routing fields in incoming messages from a device (which has discovered a route on its own via explorer); the controller should use this information to update its routing tables.
When the controller's routing table shows blanks (for node adjacency) yet communication is still received from a device, it would imply that the device is not using a controller derived route, but one it has discovered on its own by explorer. Why the controller doesn't update its topology view in a timely manner is TBD..
When the routing table shows adjacencies between nodes yet no outbound communication to them is working, that is another symptom of a mismatch-- the stranded nodes have new neighbors (different ones than those shown in the routing tables); they haven't yet been told to look for and report the new ones (by a repair broadcast command). Furthermore the controller hasn't updated its routing table with current (viable) routing fields from explorer-derived routes it received from successful inbound messages. Why this malfunction happens is another TBD...
In all my reading I've see that ZWave routing is some black magic. In terms of routes, will there ever be a way to get a device to follow a specific route or at least use a specific neighbor as the first hop? I believe I have a very strong mesh, a lot of powered ZW+ devices distributed around all floors of the house; and in farther locations I even put in a repeater (like in my garage and basement). It drives me batty that I have devices that will hop 3 times and thru a device that is on the opposite side of the house and on the other side of the hub. This happens when I have at least 5 or more, directly routed, ZW+ powered devices at 100k in between the device and hub. Is there any relief for my sanity in the future?
I loved your reply.. very informative and I even understood it. I think the lesson I am learning here is that this is a C7 issue because it worked with the C5. I'd say keep away from the C7 until this is sorted(actually waited since launce to migrate... obviously didn't wait long enough). However I still love HE. Thanks guys for all your insights. I might roll it all back now.
whoops meant to add.. this looks like a storage overlay issue to me because the problem keeps moving! I can't pin it down despite spending days on the issues.
So I now have ghosts which I used to be able to remove but not anymore.
I'm getting the famous 'Z-Wave Network responded with Busy message' and nothing I do will allow me to delete them. Yes I have disconnected from power stood on one leg facing a northerly direction.. it doesn't work.
I think my problems may be related to one particular switch.. maybe its faulty. Anyway I never had these problems on C5 only C7. I have put the 'faulty' switches back to C5 and they work perfectly! I now pray for a code fix otherwise I will roll everything back to C5.
Some observations. Even in this current state if after a reboot and I get the timing right I can issue some switch changes(on/off) through HE and they work. Then nothing works again except incoming data(power usage figures)
