Do z-wave repeaters have to talk directly to hub?

Totally. But, situations be situations. I can't currently put hub central. I hope to soon. I need to run more cat5 to the closet I want to put hub in.

I don't see any way any of my stuff is more than 2 hops from hub... my house isn't that big.

Two points:

  1. A key word above is "ideal". Not everyone can make that happen.
  2. I suspect, that the new hub, the c7, will obviate this question due to its increased range (for zwave). Of course, at present, this is just pure speculation.

Yup. But I do want to move the hub, I've just been procrastinating about running more cable.

per the c7, and the zwave 700 chip in general, they're kinda nebulous about range extension from 500 to 700. Everything reads a bit like "we're being purposefully vague". Like, with with 300 to 500, they said 250% better range or whatever. With the 700, it's unclear on each point if they're talking about improvement over 500 or over 300 or both. =/ But yeah, I'm hoping the C7 will be better. But I'm also hoping in the next few weeks I'll be able to run some cable and get my C5 into the center of my house.

I would also assume that after repositioning the hub, you would have to run a zwave repair for the new routes to take effect.

1 Like

oh, absolutely.

I'm not sure about how the test comm works for the iris driver... I wonder if there's a flag that can be set on zwave frames to say don't relay... or the fact they're in the lifeline group. just weird.

If you want to know how many and what hops your z-wave devices take you can build a zniffer or buy a z-wave Toolbox. I have the later, but with some use/learning/testing/tweaking either can tell you a lot about the "health" of your wave mesh.

I do have a zniffer. I never saw hop count as something visible. Only the rather useless checkerboard showing what can see what.

have you tried repairing your zwave network?

yes, many times, as indicated in original post. =)

Oh I don't have that, so not sure what it does. With Z toolbox I can run the packet analyzer and it will show a log of where each device routes. I have seen a couple "4 hoppers", but I try to eliminate that when I do.

1 Like

yeah. zniffer, fwiw, is monitoring zwave traffic. I have another zwave stick that I can use with Zwave PC Controller, but it only shows a checkerboard thing. I suppose there might be a way to use either/or to see how stuff routed. All my stuff at this point is zwave plus, so it SHOULD detect optimal routes automatically...

Just have a feeling this is a device issue rather than a zwave issue (the device is only wanting to talk direct to hub or something). Or for some reason it's not updating properly on a repair. Could try an exclude and rejoin...

Zniffer has a column labeled "Data" and for routed traffic, that column contains the route info.

ZWave predefines the route and includes ahead of the payload.

ZWave Frames

Routed packets have the Hop Count and 2 slots for sequential repeaters.

2 Likes

So here's a zniffer output from running the test against one of the failing repeaters. Interestingly, the src and dst are reversed.

8	15.07.20	16:52:05.999	9.6Kbit/s	54	1	34	29	1	E08EA596	Singlecast	NOP Power	E08EA5961D410B0E010118F00013
9	15.07.20	16:52:06.211	9.6Kbit/s	53	1	213	29	1	E08EA596	Singlecast	NOP Power	E08EA5961D410B0E010118F00013
10	15.07.20	16:52:06.483	9.6Kbit/s	52	1	272	29	1	E08EA596	Singlecast	NOP Power	E08EA5961D410B0E010118F00013
11	15.07.20	16:52:06.618	9.6Kbit/s	52	1	134	29	1	E08EA596	Singlecast	NOP Power	E08EA5961D410C0E010118F00014

zniffer just crashed on me, so can't look deeper yet.

so, seeing occasional successes randomly, but definitely being routed weird. Odd that path discovery would do what it's doing. And ending up at 3 hops because of that weird routing. Kitchen repeater->Outdoor Outlet->Garage Repeater->Hub. That's the ACK.

Now just watching it, it looks like it might have removed the outdoor outlet from that path... am seeing Explorer packets...

Yeah, think the only way I'm going to "fix" this is to move the hub central. sigh guess I know what I'm doing this weekend. lol.

Wish you could manually correct bad routes... lol.

Maybe it's the vintage, but I'm seeing more 'decode' than you're showing.

Singlecast <- those are 'directly connected' no routers. The packets can be smaller by the 'routing table'.

Routed <-- those are packets to destinations that are not directly connected. :slight_smile: And the packet is increased by Hop Count and the 2 'slots' for routing. You can see in the decode I've pasted, that:

Source = 42 and Destination is 1 (the hub.) It's a unsolicited message from a MultiSensor 6.

The Data column shows:
Routed:(42)-> 10 - 34 - (1)
And the next line is the same, Except the -> is moved one to the right... same with the 3rd packet.

Took 3 packet intervals to get the message from the MultiSensor to the Hub and then the Hub ack'd the message with another three packets. 9600 baud, and 200ms to make the entire round trip (497-295 = 202ms) Therefore, a) 100kbit speed or b) a direct connection would reduce 200ms, which is as slow as it can get, to something less, maybe 4ms.. given the singlecast at the top is 40k and completes the round trip in 9ms.

You can... just move the hub manually.. :smiley: or Manually install more repeaters. LOL

1 Like

I have 5 repeaters at this point in a 1400 sq ft house. The issue is the hub is in a corner with the rest of my network gear. And yeah, you know what I mean. manually alter the routing table. Tell repeaters to only talk through repeaters, etc, or tell certain repeaters to only be neighbors for stuff nearby. Right now, this repeater is going through an outlet in garage, then out to a repeater I have in my shed, then to the hub. Completely bypassing a closer repeater, and the repeater that's literally inches from the hub.

There is clearly no direct connection between this repeater and the hub. So it shouldn't be trying to send singlecast unless the Iris driver is mandating it.

sendHubCommand(new hubitat.device.HubAction(zwave.powerlevelV1.powerlevelTestNodeSet(powerLevel: 0, testFrameCount: 30, testNodeid: 1).format(), hubitat.device.Protocol.ZWAVE))

From the driver, doesn't seem like it.

I'm using Zniffer 4.60.

Funnily, now, it appears the route it discovered results in things failing via timeout. I can see each of the packets route now, but they're taking so long to get back and forth it's just timing out.

I would expect that router to NEVER be used.

The Mesh is expecting you to be adding devices any second. And three or four times a year, it's right. The mesh is built to create the largest sphere of reception for the Home Network Number. Which means it really prefers distance. If, during Wave repair, a 2 or more nodes report that they can 'see' node X, then all other things being equal, the most distant node will be the Router.

At the opposite extreme... if the Hub can't see any nodes, except one, and it reports it can see many more, then obviously that device is going to be a practical center of the mesh instead of the Hub. The Hub's radio need only be as 'strong' as that first hop. If that first hop is 200' away, and all the other devices are 250', but because of walls etc. the radio's only good to 210', then all devices will be routed via that single repeater. I'm NOT suggesting this is a good mesh, just that it could/should be functional. :smiley:

I'm using Zniffer 4.57.17

2 Likes

So that's interesting since I've read that you generally WANT a repeater close to the hub so that the hub can offload onto it (so the hub can just send it along, and vise versa). Acts like a buffer of sorts. But what you're saying makes sense, why would a device talk to that repeater when it could talk to the hub. So is that not the case?

1 Like

You need a repeater within the sphere of the RF from the Hub. The first 'ring' so to speak. Next to it? within a foot? No.

I got a new hub a while back with the idea of splitting a bunch of the ZWave devices in and around the 'front' of my home to the new Hub. That meant I had to build a new mesh just for that new Hub. I started with an Aeon SmartSwitch6 that is about 8 ft below and about 9 ft horizontally. Pythagoras says that's about 12 ft away, but through a floor/ceiling and a couple walls. It wasn't reliable. So next I turned to my Garage Door Opener because it's literally 8 ft below the new Hub. It paired easily and became the first repeater in the new mesh. I got to about 16 devices and that GDO was the repeater for at least 9 of the devices.

So yes, there are circumstances when a Repeater that at first seems 'too close' does what the mesh needs. But in my imaginary understanding of the Mesh, I'd say ...

...is too close to be useful because the RF range for the two are virtually identical. Moving it 8 ft means it's building an 8ft larger sphere and that satisfies a component of the algorithm.

1 Like

I agree with all that.

I don't know if any technical reason to intentionally put a repeater inches from the hub.

I mean, it is fine if you do, but not for mesh strengthening reasons.

I'm not Dr Zwave, but this isn't my first rodeo or read through if the protocol documentation either.

1 Like