Are these optimal Z-wave settings?

As my Z-wave network is not that big yet I have problems with the connectivity for some of my battery driven devices. I wonder if these settings (default) are the most optimal ones or if I could do some tuning?

Those setting are for Vera, you also have setting for the devices too, e.g for when they wake up.

Having too many battery powered devices is not good, as they are asleep for most of the time in order to conserve power, your z-wave mesh network should really be built on some mains powered nodes with routing capabilities.

My battery devices should be configured correctly but as you say they don’t have anything to do with the Z-wave routing. I have more mains powered devices waiting to be installed so my network will soon be improved.

Regarding the Vera settings. Are these optimal? Should for example “Use Vera routing…” be enabled?

They look fine to me, and yes I would leave ‘Use Vera routing’ enabled.

I personally would leave the Vera defaults as they are (out of the box).

The performance of your z-wave network is largely going to be effected by the other things, e.g. the number of nodes you have, the distance between those nodes, the type of nodes (e.g. routing capabilities, battery powered or not), the individual node’s abilities/performance, and then you have to play with general interference (thick wall, steel etc.)

Placing Vera high up and towards the middle of your property is a good idea and then you should ideally have some well placed mains powered nodes to help underpin your z-wave mesh network, the powered one with routing capabilities will greatly support the battery ones and also help with any under performing nodes you have or those that would normally be out of reach.

Hope that helps.

Once you’re more settled/confident, upgrading the stock antennae on your Vera is felt to improve things too.

Having a mix of battery powered devices and mains devices can cause problems. I’m not sure if all battery devices are handled the same but my Danfoss thermostats and Stellaz caused so much problems with delays that I ended up separating my network on 2 Veras. The problem lies in the way that Vera will immediately try to send new setpoints without waiting for wake-up. If you then have a lot of mains powered devices then they will try to route these. The result is a fairly long series of falling attempts, 10 to 20 seconds or more. During this period the network is very slow or even blocked. So trying to turn on lamps will not work properly. What is even worse is that if you have many battery powered devices which wake up in this period they trigger even more failing trials in a chain reaction. I ended up sometimes with the network bogged down for 15 to 30 minutes before it sorted itself out. So my conclusion with Danfoss and Stellaz is that adding mains devices just made things worse. In my separate thermostat network I have no mains devices. Therefore the initial setpoint transmission fail immediately and do not block the other thermostats.

Skickat fr?n min GT-I9300 via Tapatalk

Ouch, sounds like a bug of some sort. I don’t have any battery devices being reported TO so I haven’t experienced this yet. Though, I’m think of getting theromstats in the future but now I’m getting a bit unsure. You would like the sensor itself to pick up the new setpoint once it checks in with Vera.

I’ve added my multisensor to mains now and it performs much better. I’m getting pretty stable light reports and the montion sensor seems to work much better as well.

The thermostats do pick up the setpoint from Vera when it wakes up. That part works well. The problem is the Vera trying to send the setpoint when it is changed on the UI without waiting for wake-up. On my separate thermostat network everything now works fine.

Skickat fr?n min GT-I9300 via Tapatalk

[quote=“Sigge”]The thermostats do pick up the setpoint from Vera when it wakes up. That part works well. The problem is the Vera trying to send the setpoint when it is changed on the UI without waiting for wake-up. On my separate thermostat network everything now works fine.

Skickat fr?n min GT-I9300 via Tapatalk[/quote]
Have you reported this as a bug? Sounds to me like a problem on the Vera side. I assume you have checked there is no option for the device itself?

I had a ticket registered with mios. Initially I thought that my Vera was broken. I even bought another one to replace it but the new one behaved exactly like the first one. So I have reported this to mios and the support guy said he would pass it on to the developers. So maybe someday they will fix it :slight_smile:

Skickat fr?n min GT-I9300 via Tapatalk

Maybe there will be improvements in UI6, UI7 or what comes next…


You raise an interesting point about too many powered nodes having an effect when passing the information on, as I think a request can only be forwarded 3 times before it is terminated (a hop kill)

Also all the packet of information is doing is trying to find it’s target node. If when targeting a battery powered node - it’s not awake then it will fail and try again. The network should always be aware of it’s surrounding nodes/routing table so it knows where it needs to go,

If you have no powered nodes to provide additional hops, and only have battery devices then (as they usually do not have routing capabilities) they will all have to talk directly with Vera, and if you have a small house then technically tha’s a very viable distribution model, as it’s simply point to point

However if you have nodes at distance or live in a large house and/or one that is effected by thick walls then you would need to benefit from hops to extend/improve your network.

I have upgraded the antenna on my VeraLite to improve the range and I keep an eye on my z-wave mesh (each device’s node neighbours) via the info viewer plugin

There is no doubt that the battery nodes benefit from the powered nodes from a reliability point of view. I have a fairly large house, but it’s an old wood framework design so my Vera can access the nodes directly. Setpoint updates are usually no problem but configuration is a bit shaky on the far nodes. The problem is that there is a huge difference in the time it takes for a 5X retry and fail on a network with powered nodes versus a battery only nodes network with no routing. On my powered network it takes 10-20 seconds on my thermostat network it takes a fraction of a second.
I tried putting an external antenna on the Vera but I got very strange results. It would initially work well for about a day then the network would become very sluggish with a lot of failed transmissions. If I restarted the Vera it would with again for a day. I read about somebody else that got some similar results so I gave up that idea. I don’t really know why, it should normally work better… If there was some way to disable routing for specific devices or to prevent the Vera from transmitting to battery nodes except on wake-up then that would greatly improve things. Any ideas on that?

Skickat fr?n min GT-I9300 via Tapatalk

Routing has been covered many times on this forum, and while some have played with it others will warn you to run to the hills rather than touch it.

As for stopping Vera from transmitting until a battery node is awake, that would be a nice touch and I think an element of that occurs anyway; as I believe when certain battery device wake up, they calls out to the controller to ask if there are any updates for them and if there are, then Vera will send them.

Also - when Vera routinely polls nodes in the network if it connects to an awake battery one - if it has anything in the queue to pass on it will send it. - so I believe there is some push and pull elements to the z-wave network.

Now, I’m not an expert in all this far from it, but I think the environment, the distance between nodes and the types of nodes/devices used (routing, antenna length/quality ) in the mesh play the biggest part.

I recall an issue I had with the EZ Motion v1 & v2 battery powered sensors - which after much digging and contribution from EZMotion themselves and the great people on this forms we discovered that the sensor did not stay awake long enough to always complete the information transfer during the wake up, which was why the transaction was often incomplete and some fields on the UI would not get updated. The same sensors I had closer to Vera could more often complete their transaction, the furthest ones away suffered the most. (Also those that converted the sensor to a power node, saw better performance as it allowed them to set it to be always awake.)

Things to help battery nodes, would be to shorten* the time between the wake up on the nodes, or increase the polling by Vera, as I think between the wake up, the polling and add to that the push that’s done when you submit any change - all those action work together to try to complete the information exchange.

[size=8pt]* Battery impact, wake up more often, shorter battery life.[/size]

Sorry that is a long answer to your question… :slight_smile:

As far as I can tell the transmission on wake-up works fine. My point is that the Vera causes problems by not waiting for wake-up when setpoints are set on the UI or by PLEG for example. The real problem also has to do whit the number of battery nodes. In my case all my radiators have Danfoss thermostats (and a couple of Stellaz). I use these to turn down the heat when I’m not home.
So what happens is the following:
8 new setpoints are initiated by PLEG. This starts a sequence of trials to transmit these by the Vera. It did this in sequence. Because the nodes are asleep the trials fail. However due to the routing it takes 20 seconds to do 5 failed attempts (5 attempts is somehow set in Vera). This means that the while process takes 3-4 minutes. Now, if during this process some thermostat wakes up it cannot get services because the Vera is busy but the attempt is registered somehow and will result in the Vera trying to respond when it’s pending operation is done. By that time the node is back to sleep and a new sequence of falling attempts continues. So as you may now suspect there is a sort of “critical mass”, if there are more than a number of battery nodes the probability of these collisions rises and more and more failing attempts are generated and the whole network gets blocked. So decreasing the wake-up interval and increasing powered nodes actually makes things worse :slight_smile:

Does this make sense?

Skickat fr?n min GT-I9300 via Tapatalk

From what you’re saying it sounds like you think a request to change 8 set points at the same time saturates the network and causes packet loss.? I think it’s unlikely as Vera and the z-wave set up is designed to host 100s of nodes.

Assuming via PLEG you are sending all those requests out as one ‘job’ have you tried breaking the request down e.g 2 x 4 set point jobs/requests.

Or maybe go about it a slightly different way, especially if all the set points are going to be the same. You could just use one TRV or better still add a virtual thermostat to use that as you TRV set point controller device and then via Luup.variable_watch you could make it so Vera constantly keeps them in sync, so if for any reason one of the TRVs does not get the command, Vera will check it and then if found to still be different it will send the request again… (I’m sure you could do this in PLEG too)

Looking at my Living Connect TRVs the wake up interval is set to 900 seconds so I have to assume it will take at least that long to react/respond (unless I wake it up manually)

It’s not the setting of 8 setpoints that is any problem. It’s when Vera fires these out without waiting for wake-up. Each such attempt is made up of 5 transmissions each of which is routed. It all takes about 20 seconds. If it had been powered nodes it would probably have taken a couple of seconds to send setpoints to 8 nodes with 8 sleeping nodes the failing attempts take at least 20 times 8 seconds or 3 minutes. If I now have 12 nodes with 10 minute wake-up intervals then statistically 3 of these will wake-up during these failing attempts. These will then trigger new transmission attempts from the Vera creating a selfsustaining series of falling transmissions and blocked wake-ups. So the conclusion for me is that the Vera is fine with a few battery powered devices mixed with large numbers of powered devices. But with 10+ battery devices and lots of powered devices we are in trouble.
I tried to sequence the setpoints and that works but it means that to update 8 nodes this has to be done over more than an hour. This becomes a bit awkward for daily setpoints adjustments.
So now I run all the thermostats on their own Vera without any routing nodes and everything is fine.

Skickat fr?n min GT-I9300 via Tapatalk

That does seem strange indeed. I’d think that if the device is battery operated and not a device that can be woken up through beaming, there is no sense in trying. (And Vera knows both these properties of a device.) Do you know if an actual bug report was filed on this?

From your other post it sounds like the behavior is also dependent on whether the request is routed?

That does seem strange indeed. I’d think that if the device is battery operated and not a device that can be woken up through beaming, there is no sense in trying. (And Vera knows both these properties of a device.) Do you know if an actual bug report was filed on this?

From your other post it sounds like the behavior is also dependent on whether the request is routed?[/quote]

I have not filed a specific bug report.

The difference between routed (network with powered nodes) and a battery thermostat only network is in the time it takes for the Vera to try to send to a sleeping node. If there is no routing the 5 tries that the Vera does takes a fraction of a second. If there is a large number of powered nodes the same trials will take 20 seconds. So on the thermostat network the trials don’t cause too much problems.

Skickat fr?n min GT-I9300 via Tapatalk