Off-topic rant about security

I had three ring S2 extenders and I just added two more yesterday to try to help with the back of my house.

Yesterday I had a total of 12 devices using two of the extenders.

Today I have a total of 11 devices routing through three of them. None of the new ones are being used yet.

I also have two older aeotec extenders. V6 I think. To my amazement, one is actually getting use for two devices today.

With these things I find a week is not enough to test. More like 2-3 weeks.

1 Like

Most of mine will start participating in a week to 14 days, but I had one that I put in a month ago just begin to work last night - now routing 5-6 devices...

3 Likes

Had mine for two months and nothing. Total slacker. Reminds me of me when I was 16. :wink:

Hank rules!!

2 Likes

What is that a screenshot of?

6 Likes

What he said ^^^^^^^

1 Like

My office light switch is doing most of the routing right now.


A large majority of my devices connect directly though.

2 Likes

I’m seeing something similar with pretty much everything is routing through the one of my Inovelli lights that is maybe 6 feet away from my hub...

image

I’m wondering if this may be causing issues, a single switch having to route so much data all the time...

And interestingly, I have switches all over the house, and pretty much only this one is routing everything...

Should not be an issue since everything would have to be sourced to and from the hub anyway. Hub and spoke is still one of the most popular networking models out there. If I look at my Z-Wave network for some reason my basement switch is the fist node in many of the routes even though both the kitchen and basement switches are equal distant from the hub.

2 Likes

So I'm seeing a pattern that I see in my zwave network...I can tell also by yours...those are some of the very first devices you joined to the hub.... coincidence? I think not. It seems to me the first few devices that are joined seem to get the preference of repeating. Thoughts?

2 Likes

Yes it's a artifact of starting with devices that are closest to the hub and then working outwards. But there is some Z-Wave mesh magic that happens say if a route degrades due to interference etc. The device goes to it's peer table and looks for other routes and once found it will be sticky to that route for a period if time. I added a switch to a outside light that logically should have gone to the basement switch to reach to hub but instead it went further out and followed a route two hops away. Two days latter when I looked at the table it was then using the basement switch. Also I can say is that there is some type of voodoo and it's some times best to be "ignorant."

1 Like

It's all a black box to me but @danabw sent me a repeater and maybe I can dig into this type of thing a bit more.

1 Like

AFAIK, Z-Wave uses two schemes to generate working routes, the 'classic' one is controller-centric, producing routes that would make sense based on neighbor location and hop counts from a static 'whole network view'; the other is node-centric that comes up with a route that 'worked the best' at the time it was needed.

  • Controller-calculated routes are based on neighbor adjacency that is reported by each node at time of inclusion, and also during a successful Z-Wave repair. The result is set of routes determined by the Z-Wave controller to be optimal and distributed individually; they become candidates for 'last working route' and get remembered by each node. More than one possible route is calculated and distributed to provide redundancy. If a transmission fails (returns no acknowledgement), a node will repeat it trying the next in its list of stored routes before resorting to the explorer scheme to generate new ones.

  • Explorer generated routes (for devices based on ZDK 4.5 and higher, including most fairly recent non-Plus and all Z-Wave Plus devices) originate from a node only when it has exhausted its list of stored working routes; the node floods the network with explorer broadcasts that are repeated by every other in-range node, each subsequent hop appending its intermediate node ID to the routing field in the explorer message which then gets rebroadcast. The intended destination uses the routing field of the very first explorer message that it receives, sending an acknowledgement back to the originating destination. This traverses the nodes in reverse order; and when received, the originating node sets this route as its 'last working route' and uses it till fails (or is replaced by a controller-distributed route).

Each scheme has its drawbacks. Only the controller has a complete node map; the nodes themselves only know their immediate neighbors and not which is logically the best 'next hop' from a network viewpoint. Repair has to be manually initiated, takes a while to run and doesn't always complete successfully. The explorer frame strategy isn't fast; it can take several seconds to generate a route and during this time the rest of the network will suffer slowdowns. The real mystery is why each scheme doesn't always come up with the same routes, and why (in problematic networks) the routes that are discovered don't seem to continue to work for very long.

Grrrr...the evil Ring repeater...a pox on it! :wink:

Is this actually true though?

I'm not confident that devices actually know their neighbors.. seems like they have a table of remembered good routes but no actual way to id all devices near them except maybe the one they connected to during pairing?

Clearly I do not know how this works..

I believe that they "know" this info...from the Z-Wave topology table:

image

I had assumed (and we know how dangerous that is) that this table was built by interrogating each device to find out which neighbors it knows about. @bcopeland said:

Node topology gives you an overview of the entire Z-Wave routing table. Blue dots are nodes that can see each other, and red are nodes that aren't neighbors.

So this tells us, as I understand it, which of their neighbors the devices are actually seeing.

But the only way they "see" is by assessing the strength of the routes right? That means potentially a "neighbor" could be a device across the room or somewhere else. It does not necessarily tie in with physical reality... or am I missing something here?

Yes, that's my understanding. And AFAIK you can't make them "see" (or route through) a physically nearby neighbor that they don't see, or see but don't want to route through.

Basically devices are like teenagers and only see what they want to see, and only hang out w/who they want to hang out with. :wink:

9 Likes

Ha! Very nice - but I think it's more like grandpa - you get what you get because that's the way it's always been done, not always listening / hard of hearing, resistant to change....

:grin:

So that means then adding a repeater nearby and expecting things to just work can be problematic.. It really depends on the initial setup and the ability of the device and controller to properly (and speedily) identify a better route and then make the adjustment.

3 Likes