Zwave Network On Vera Explained

Messages are now gone overnight. And yes the devices are battery powered.

BUMP… started again when leaving altui open:
10/29/2019, 10:34:38 AM #2828:Sensor Smoke 2nd Floor:Cannot contact device, error code: 1
10/29/2019, 10:33:44 AM #2827:Sensor Smoke 2nd Floor:Cannot contact device, error code: 1
10/29/2019, 10:33:07 AM #2826:Sensor Smoke 2nd Floor:Timed out waiting for the node to reply
10/29/2019, 10:32:16 AM #2825:Sensor Smoke 2nd Floor:Cannot contact device, error code: 1
10/29/2019, 10:31:23 AM #2824:Sensor Smoke 2nd Floor:Cannot contact device, error code: 32
10/29/2019, 10:14:42 AM #2784:Sensor Smoke Kitchen:Timed out waiting for the node to reply
10/29/2019, 10:13:58 AM #2783:Sensor Smoke Kitchen:Cannot contact device, error code: 52
10/29/2019, 10:13:26 AM #2782:Sensor Smoke Kitchen:Cannot contact device, error code: 1
10/29/2019, 10:12:47 AM #2781:Sensor Smoke Kitchen:Cannot contact device, error code: 1

I BTW also did this on my 7.29 device:

for k, v in pairs(luup.devices) do
  local var= luup.variable_get("urn:micasaverde-com:serviceId:ZWaveDevice1", "WakeupInterval",k)
   if var ~= nil  and var ~= 0 and v.device_num_parent== 1  then 
     luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "DisableWakeupARR_NNU", "1", k)
   end
end

One question about disabling polling for non-battery devices: does Vera then detect if device is no longer connected? And if yes, how?
For example I have one wall plug which gets rarely switched on, but when needed then it really should go on. I would like to know if plug is unplugged (or broken) quite soon, not only after command is sent and device fails to respond.

rafale, thanks so much for all the tests you are doing and, even more, for sharing them and your findings with us.

Question I have: I have connected several Neo Coolcam wall plugs WR01ZE to my VERA Edge network and some of them frequently come offline. Not all of the 5 plugs I have, but most of them do, particularly two of them. Could this behavior be due to the overload of the Z-Wave network you referred to in the previous posts.

I just changed the wakeup interval of the battery powered devices to some 43000, but, again two of the wall plugs became offline.

Thanks again.

Very good use case for polling. As I said I have very few devices which require polling and I enable polling for those which are needed. If you feel you need polling, by all means enable it. Just make sure the frequency is not so high that it will generate collisions. It is a compromise to keep in mind.

Yes it could very well be. If they drop offline but still can be actuated… then it is likely due to a series of failed polls which were ignored due to network collisions. The other possibility is that your network coverage may be a bit weak for these two devices and that they need closer neighbors.

By the way I just had a luup reload while crossing the ocean. Have not had time to look at logs yet but… 22 days And 6 hours of uptime is a very significant progress. I will install the beta when I return.

I have copypasted this code, I ran it, but my time depending scenes, like turning on the lights 30 minutes before sunset, isn’t working no more, despite of the code. When I look at the list of my scenes, there use to be a correct time for “next run”. But now It´s only blank (-). I have installed the 7.30 beta, and since then, it’s not working as expected.
I tried to run the code both with the double " and with the single sign '. I haven’t rebooted the Vera secure.
Do you know @rafale77, why your code isn’t doing the trick in my case?
Thanks for a great job!
/Fanan

As I said, this is a side effect of this switch. Please do not use if if you have scenes.

luup.attr_set("ReloadOnTimeJumps", 1)

and then a reload will fix this behavior.

3 Likes

Thanks for helping @therealdb . Yes, this code above will bring back the luup reload on timejump and the scene scheduling

@slelieveld, only the poll setting code you inputed is in effect on 7.29. The disablewakeupARR_NNU code will not do anything unless you upgrade to 7.30. Also the poll settings code only affects AC powered devices. Are your smoke sensors AC powered?

Hi rafale77, smoke sensors are battery powered.

I think the poll setting is active, not seeing any improvement so far. Only thing I see is that I do not have correct status anymore on several AC powered devices such as wall switches and roller shutters… If I use vera to control off course its accurate, but if I control these devices locally I do not see them updated in vera anymore :roll_eyes:.

Also I have 2battery powered devices (fibaro motion and smoke) which I cannot by any means re-include in vera… I opened (continued) Vera support.

Hello,

I bit the bullet and excluded the FMGS001 and FGSD002. Both were not excludable via zwave. I hade to “delete” them. And even deleting does not work 2 out of 3 times…

I cannot include them successfully anymore in Vera. I get all kinds of errors. Off course I have resetted the devices properly before including them.

For FGMS001 I get:

It was before: Sensor Frontdoor Motion

Add/Remove : Successfully exchanged security keys

Add/Remove : Device failed to configure

But give name field comes etc.

Then comes up with:

Waiting for wakeup to configure device…

Wake up device then gives:

Please wait! Getting secure classes

But then does nothing.

Sometime also get when removing:

Add/remove: Comm error S-2

For FGSD002 I get:

Sensor Smoke 1st Floor

Several messages

Add/Remove : Successfully exchanged security keys

Please wait! Getting Secure Classes

This indicates that you need polling on these devices… and rather regularly. For these specific devices which don’t have correct status anymore, you may want to re-enable polling by changing the polling interval variable. You will not see improvements from any other codes until you upgrade the firmware.

I think… I did have instant status updates on all my devices before (one I knew it did not support that)…

The polling interval change code doesn’t disable instant status. All my devices which had it, still have it. It only specifically disables the polling initiated by the vera on regular interval to AC powered devices.
Instant status is a feature of the device and cannot be changed with lua code . It can only bec change by changing a device parameter which is particular to that device. It requires a device reconfiguration with a configuration parameter change.

Yes, that is how I understood it… just saying it changed for me… might have to do…

Just looked at the logs of my Luup reload.
It looks like it is caused by a series of attempts to run a wakeup poll which failed and timed out because the device was already asleep by the time the poll retries were going on.

So it is another reason to disable this wakeup poll.

0410/29/19 8:26:01.462 <Job ID=“14990” Name=“Wakeup done 73” Device=“103” Created=“2019-10-29 8:25:59” Started=“2019-10-29 8:25:59” Completed=“2019-10-29 8:26:01” Duration="2.1191$0210/29/19 8:26:01.770 ^[[33;1mZWaveNode::Wakeup did a poll for 73 1572362761 seconds interval 0 existing (nil) heal (nil)^[[0m <0x7eea3520>
0210/29/19 8:26:06.727 ^[[33;1mZWJob_SendData::ReceivedFrame job job#14991 :Wakeup done 73 dev:103 (0x68e5ce60) N:73 P:102 S:5 Id: 14991 to node 73 command 132/8 failed m_cTxStatu$0110/29/19 8:26:06.728 ^[[31;1mZWJob_SendData::ReceivedFrame job job#14991 :Wakeup done 73 dev:103 (0x68e5ce60) N:73 P:102 S:5 Id: 14991 to node 73 command 0x84/0x08 failed 0/0 or$0110/29/19 8:26:06.728 ^[[31;1mZWJob_SendData::JobFailed job#14991 :Wakeup done 73 dev:103 (0x68e5ce60) N:73 P:102 S:5 Id: 14991 Priority 102^[[0m <0x7eea3520>
0410/29/19 8:26:06.729 <Job ID=“14991” Name=“Wakeup done 73” Device=“103” Created=“2019-10-29 8:25:59” Started=“2019-10-29 8:26:01” Completed=“2019-10-29 8:26:06” Duration="7.6511$0210/29/19 8:26:06.730 ^[[33;1mJobHandler::Run job#14992 :Wakeup done 73 dev:103 (0x73136be0) N:73 P:102 S:0 Id: 14992 is 7.33895000 seconds old^[[0m <0x7e6a3520>
0210/29/19 8:26:14.635 ^[[33;1mZWaveNode::Wakeup did a poll for 73 1572362774 seconds interval 0 existing (nil) heal (nil)^[[0m <0x7eea3520>
0210/29/19 8:26:14.679 ^[[33;1mZWJob_SendData::ReceivedFrame job job#14992 :Wakeup done 73 dev:103 (0x73136be0) N:73 P:102 S:5 Id: 14992 to node 73 command 132/8 failed m_cTxStatu$0110/29/19 8:26:14.680 ^[[31;1mZWJob_SendData::ReceivedFrame job job#14992 :Wakeup done 73 dev:103 (0x73136be0) N:73 P:102 S:5 Id: 14992 to node 73 command 0x84/0x08 failed 0/0 or$0110/29/19 8:26:14.680 ^[[31;1mZWJob_SendData::JobFailed job#14992 :Wakeup done 73 dev:103 (0x73136be0) N:73 P:102 S:5 Id: 14992 Priority 102^[[0m <0x7eea3520>
0410/29/19 8:26:14.681 <Job ID=“14992” Name=“Wakeup done 73” Device=“103” Created=“2019-10-29 8:25:59” Started=“2019-10-29 8:26:06” Completed=“2019-10-29 8:26:14” Duration="14.984$0210/29/19 8:26:14.682 ^[[33;1mJobHandler::Run job#14993 :Wakeup done 73 dev:103 (0x115fd8) N:73 P:102 S:0 Id: 14993 is 13.305378000 seconds old^[[0m <0x7e6a3520>
0210/29/19 8:26:15.265 ^[[33;1mZWaveNode::Wakeup did a poll for 73 1572362775 seconds interval 0 existing (nil) heal (nil)^[[0m <0x7eea3520>
0210/29/19 8:26:15.331 ^[[33;1mZWaveNode::Wakeup did a poll for 73 1572362775 seconds interval 0 existing (nil) heal (nil)^[[0m <0x7eea3520>
0210/29/19 8:26:15.363 ^[[33;1mZWaveNode::Wakeup did a poll for 73 1572362775 seconds interval 0 existing (nil) heal (nil)^[[0m <0x7eea3520>
0210/29/19 8:26:15.396 ^[[33;1mZWaveNode::Wakeup did a poll for 73 1572362775 seconds interval 0 existing (nil) heal (nil)^[[0m <0x7eea3520>
0110/29/19 8:26:27.409 ^[[31;1mZWaveSerial::Send m_iFrameID 879606 type 0x0 command 0x16 expected 1 got ack 0 response 0 request 0 failed to get at time 1925679409 start time 1925$0110/29/19 8:26:27.410 ^[[31;1mZWaveJobHandler::SendDataAbort failed^[[0m <0x7e6a3520>
0210/29/19 8:26:27.411 ^[[33;1mZWJob_SendData::ReturnMessageNotReceived job job#14993 :Wakeup done 73 dev:103 (0x115fd8) N:73 P:102 S:5 Id: 14993 to node 73 command 0x84/0x8 retri$0410/29/19 8:26:27.414 <Job ID=“14993” Name=“Wakeup done 73” Device=“103” Created=“2019-10-29 8:26:01” Started=“2019-10-29 8:26:14” Completed=“2019-10-29 8:26:27” Duration="26.353$01 10/29/19 8:26:27.506 ^[[31;1mZWJob_SendData::JobFailed job#14993 :Wakeup done 73 dev:103 (0x115fd8) N:73 P:102 S:3 Id: 14993 Priority 102^[[0m <0x7e6a3520>
02 10/29/19 8:26:27.506 ^[[33;1mJobHandler::Run job#14994 :Wakeup done 73 dev:103 (0x20beb528) N:73 P:102 S:0 Id: 14994 is 26.117246000 seconds old^[[0m <0x7e6a3520>
01 10/29/19 8:26:29.512 ^[[31;1mZWaveSerial::Send m_iFrameID 879607 type 0x0 command 0x13 didn’t get ACK. wait for rest time 1925681511 start time 1925679510 wait 2000 m_iSendsWit$01 10/29/19 8:26:31.529 ^[[31;1mZWaveSerial::Send m_iFrameID 879607 type 0x0 command 0x13 didn’t get ACK. wait for rest time 1925683528 start time 1925681528 wait 2000 m_iSendsWit$01 10/29/19 8:26:33.537 ^[[31;1mZWaveSerial::Send m_iFrameID 879607 type 0x0 command 0x13 didn’t get ACK. wait for rest time 1925685536 start time 1925683536 wait 2000 m_iSendsWit$01 10/29/19 8:26:35.545 ^[[31;1mZWaveSerial::Send m_iFrameID 879607 type 0x0 command 0x13 expected 2 got ack 0 response 0 request 0 failed to get at time 1925687545 start time 1925$01 10/29/19 8:26:35.547 ^[[31;1mZWJob_SendData::Run done/fail job job#14994 :Wakeup done 73 dev:103 (0x20beb528) N:73 P:102 S:7 Id: 14994 took 8041 ms method 2 to node 73 command 1$01 10/29/19 8:26:35.548 ^[[31;1mZWJob_SendData::Run job job#14994 :Wakeup done 73 dev:103 (0x20beb528) N:73 P:102 S:7 Id: 14994 to node 73 command 0x84/0x08 failed 0/0 or Quit 0^[[$01 10/29/19 8:26:35.549 ^[[31;1mZWJob_SendData::JobFailed job#14994 :Wakeup done 73 dev:103 (0x20beb528) N:73 P:102 S:7 Id: 14994 Priority 102^[[0m <0x7e6a3520>
04 10/29/19 8:26:35.551 <Job ID=“14994” Name=“Wakeup done 73” Device=“103” Created=“2019-10-29 8:26:01” Started=“2019-10-29 8:26:27” Completed=“2019-10-29 8:26:35” Duration="34.160$01 10/29/19 8:26:35.552 ^[[31;1mZWJob_SendData::Run job job#14994 :Wakeup done 73 dev:103 (0x20beb528) N:73 P:102 S:3 Id: 14994 device 103 node 73 Aborting without requee after 0 r$02 10/29/19 8:26:35.553 ^[[33;1mJobHandler::Run job#14995 :Wakeup done 73 dev:103 (0x3b601ca0) N:73 P:102 S:0 Id: 14995 is 34.131662000 seconds old^[[0m <0x7e6a3520>
02 10/29/19 8:26:35.657 ^[[33;1mZWaveSerial::Send m_iSendsWithoutReceive 3^[[0m <0x7e6a3520>
01 10/29/19 8:26:38.275 ^[[31;1mZWaveSerial::Send m_iFrameID 879609 type 0x0 command 0x20 didn’t get ACK. wait for rest time 1925690274 start time 1925688274 wait 2000 m_iSendsWit$01 10/29/19 8:26:40.280 ^[[31;1mZWaveSerial::Send m_iFrameID 879609 type 0x0 command 0x20 didn’t get ACK. wait for rest time 1925692280 start time 1925690279 wait 2000 m_iSendsWit$01 10/29/19 8:26:42.290 ^[[31;1mZWaveSerial::Send m_iFrameID 879609 type 0x0 command 0x20 didn’t get ACK. wait for rest time 1925694290 start time 1925692290 wait 2000 m_iSendsWit$01 10/29/19 8:26:44.296 ^[[31;1mZWaveSerial::Send m_iFrameID 879609 type 0x0 command 0x20 expected 2 got ack 0 response 0 request 0 failed to get at time 1925696296 start time 1925$01 10/29/19 8:26:48.310 ^[[31;1mZWaveSerial::Send m_iFrameID 879610 type 0x0 command 0x20 didn’t get ACK. wait for rest time 1925700309 start time 1925698309 wait 2000 m_iSendsWit$01 10/29/19 8:26:50.318 ^[[31;1mZWaveSerial::Send m_iFrameID 879610 type 0x0 command 0x20 didn’t get ACK. wait for rest time 1925702317 start time 1925700317 wait 2000 m_iSendsWit$01 10/29/19 8:26:52.322 ^[[31;1mZWaveSerial::Send m_iFrameID 879610 type 0x0 command 0x20 didn’t get ACK. wait for rest time 1925704321 start time 1925702321 wait 2000
m_iSendsWit$01 10/29/19 8:26:54.330 ^[[31;1mZWaveSerial::Send m_iFrameID 879610 type 0x0 command 0x20 expected 2 got ack 0 response 0 request 0 failed to get at time
1925706330 start time 1925$01 10/29/19 8:26:54.332 >^[[31;1mZWaveJobHandler::ConnectionIsValid failed twice result 3/(nil) exists 0^[[0m <0x7e6a3520>
03 10/29/19 8:26:54.333 JobHandler_LuaUPnP::Reload: rwee reset Critical 0 m_bCriticalOnly 0 dirty data 1 running 1 <0x7e6a3520>
01 10/29/19 8:26:54.418 ^[[31;1mgot CAN^[[0m <0x7e2a3520>
01 10/29/19 8:26:54.419 ^[[31;1mgot CAN^[[0m <0x7e2a3520>
01 10/29/19 8:26:54.419 ^[[31;1mgot CAN^[[0m <0x7e2a3520>
01 10/29/19 8:26:54.419 ^[[31;1mgot CAN^[[0m <0x7e2a3520>
01 10/29/19 8:26:54.419 ^[[31;1mgot CAN^[[0m <0x7e2a3520>
01 10/29/19 8:26:54.419 ^[[31;1mgot CAN^[[0m <0x7e2a3520>
01 10/29/19 8:26:54.430 ^[[31;1mgot CAN^[[0m <0x7e2a3520>

1 Like

Hi, rafale. The plugs I am talking about are: one at less than 15 meters from the Vera Edge, with a wall plug (so, mesh repeater) in the middle way, and the other at less than 20 meters with an intermediate thin wall, but with several z-wave mains connected devices (so, mesh repeaters) in the way.

Then, I don’t feel it should be a problem of a weak network, but more probably a problem of the network collisions, even they cannot be actuated when they come offline as you asked for. I have to unplug and plug them again and switch them on/off in order to have them again reconnected.

I sent a mail to szneo support with the support asking for any suggestion, including any change in the configuration after the plugs are included, but no answer (only an answer questioning if they are US or EU models) for the time being.

Regards

15 metres is quite a distance for a zwave network, I’d recommend you have devices every 5-7 meters to form a reliable mesh.

Hi, dJOS, thanks for your answer. I understood a distance of 30 meters was a valid (maximum) one, even so, as I said, there is another plug in an intermediate place (that doesn’t create any problem, so, we could say there is an installation as follows: VERA Edge ---- 7 meters - plug - 7 meters ----- plug. And the one failing is the second one. There are also other mains connected devices close to the failing plug, less than 5 meters far from both plugs.

regards.

it is possible you have some faulty plugs, I had 2 Aeotec SmartSwitch 6’s die on me recently. The failure mode was that they would no longer work in the mesh, but would work with 5 meters of my VP. My supplier replaced them both despite being out of warranty.

PS, wall types can have a major impact on low power RF comms - I find my mesh works great with an AC powered device in every room.

For those looking for instructions they’re pretty straightforward:

  1. Go to apps
  2. Develop apps
  3. Test LUUP code (Lua)
  4. Copy paste the code above
  5. Hit go and wait for code was run successfully dialogue
  6. Repeat for the other codes

*if you don’t get the code was run successfully dialogue try reloading the engine, rebooting the Vera, or clearing your browser cache

Is it sufficient to run this code in the “Test Luup Code” text box only once, or should it be added as Startup Lua (also the DisableWakeupARR_NNU code)?

It doesn’t need to be added to the startup lua code. You only need to run it once.

1 Like