Zwave Network On Vera Explained

Community Playground Getting Started & Initial Setup
#222

wiki-nightlyheal

#223

Thanks so much
 note taken
.

New question the “:3480” port is the one to be used or it depends of the current installation?

Thanks again

Javier

#224

The port 3480 is built in the luup engine so yes, it is the one to use.

#225

Perfect, Thanks so much!

#226

Perhaps I’m not understanding the context, but shouldn’t you be using port 80 and the prefix /port_3480?

#227

Huh
 you are right. This changed at some point, now I remember
 Yes the port went from an actual port to now go to 80 with a prefix.

#228

So, which is the correct command we should use for getting the Heal on/off?

Remember that some of us are not full technical people, even not full dummies :slight_smile:
Regards

#229

to turn off, run this in the lua code test window:

luup.attr_set(“EnableNightlyHeal”,0,0)

to turn it back on:

luup.attr_set(“EnableNightlyHeal”,1,0)

It is in @edward’s wiki link.

#230

Thanks so much, @rafale77.

I was supposing this was the lua code test, looking at the wiki one, but I also was getting confused when talking about the url way of doing it and the port to put in it.

Thanks again.

#231

I added this to Page Controller in ALTUI ( version in GitHub )

2 Likes
#232

So there’s an error in Wiki?

http://ip_address:3480/data_request?id=nightlyheal&enable=1&day=7&time=23:55

Should it be

http://ip_address/port_3480/data_request?id=nightlyheal&enable=1&day=7&time=23:55

#233

You are correct. tagging @edward. I did not author the wiki. The former url is an old one. The web server port has changed to :80 and just has a “/port_3480” suffix at some point.

#234

Hello All -
I ran the above three suggestions and immediately saw a reduction in network traffic and less reloads as expected.

However, I have noted one thing that, while could be coincidental, is worrisome. I have a battery-operated door sensor on the “fringe” of the network. While it is near AC powered ZWave devices, it did cause me to move my controller to a more central location about a year ago to be more reliable.

Since the above, the device has become unstable sometimes not reporting to the controller on events (open/close). I can verify that it’s a communication issue where the LED stays on for a much longer time when unable to reach (or hear?) the controller. This was also learned back when I worked with this device at length.

Any ideas of where I can start looking? Back out commands? A more surgical approach?

#235

Not quite sure how this could have anything to do with the commands run. Especially if so if it is already an older device. I would check on the battery level of the device and the connection of the most immediate neighbor which you already know which one apparently. If that device works fine then you can see if the problematic device is on its list of neighbors. If not, you can set that device to update neighbors and within one minute, wake up the battery operated device.
The codes don’t change anything to the network topology which is stored in the zwave chipset NVM. They just prevents the vera from constantly asking them to review recheck and renew all this data which has no reason to have changed. To the contrary these actions make the network more unstable and prone to breaking neighbors list and connections so they needed to be stopped.

Know also that there is a “hop number limitation” with zwave which means that the device can only be repeated by so many times so it still can’t be too far from the controller.

1 Like
#236

Try to set the polling back to default for the surrounding devices. I have had LOADS of issues of unresponsive devices since rafale’s code (sorry rafale). But setting back some devices (most of which do no support instant status) back to default/60 secs my network is now seemingly workable again.

EDIT: mean polling, under settins:
image

1 Like
#237

Understood that it doesn’t change the topology and the logic/science behind what was done makes sense to me. Just odd that the device went back to its bad habits after making the change.

Interesting @slelieveld . The devices that happen to be around this battery device do happen to NOT support instant status. (GE Switches).

#238

I think you mean polling, not wakeup
 AC powered devices don’t wakeup, they are always on. Since you are talking about instant status, indeed some devices need it to report back as a workaround for not supporting instant status. As for unresponsive devices
 if you mean they don’t respond to commands anymore, I don’t see that this is possible.

#239

If they are very old GE switches, it is possible they do not repeat correctly. Try using zwave+ devices as repeaters as much as you can.

#240

Yes, sorry mean polling, post changed.

#241

Changing them out as reasonable. But I still have several that work fine (other than this issue - assuming this is even the cause).

I assume I can just go in to each switch in the vicinity and change the polling manually? Is there code that would make it easier? (Sorry, not a lua person)