Zwave Network On Vera Explained

rafale77 · October 30, 2019, 5:08pm

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?

slelieveld · October 30, 2019, 5:12pm

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 .

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

rafale77 · October 30, 2019, 5:15pm

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.

slelieveld · October 30, 2019, 5:18pm

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

rafale77 · October 30, 2019, 5:20pm

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.

slelieveld · October 30, 2019, 5:22pm

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

rafale77 · October 30, 2019, 6:05pm

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 0210/29/19 8:26:06.727 0410/29/19 8:26:06.729 0210/29/19 8:26:14.635 0210/29/19 8:26:14.679 0410/29/19 8:26:14.681 0210/29/19 8:26:15.265 0210/29/19 8:26:15.331 0210/29/19 8:26:15.363 0210/29/19 8:26:15.396 0110/29/19 8:26:27.409 0210/29/19 8:26:27.411 02 10/29/19 8:26:27.506 01 10/29/19 8:26:29.512 04 10/29/19 8:26:35.551 02 10/29/19 8:26:35.657 01 10/29/19 8:26:38.275 m_iSendsWit$01 1925706330 start time 1925$01 03 10/29/19 8:26:54.333 01 10/29/19 8:26:54.418 01 10/29/19 8:26:54.419 01 10/29/19 8:26:54.419 01 10/29/19 8:26:54.419 01 10/29/19 8:26:54.419 01 10/29/19 8:26:54.419 01 10/29/19 8:26:54.430 <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>
^[[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>
<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>
^[[33;1mZWaveNode::Wakeup did a poll for 73 1572362774 seconds interval 0 existing (nil) heal (nil)^[[0m <0x7eea3520>
^[[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>
<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>
^[[33;1mZWaveNode::Wakeup did a poll for 73 1572362775 seconds interval 0 existing (nil) heal (nil)^[[0m <0x7eea3520>
^[[33;1mZWaveNode::Wakeup did a poll for 73 1572362775 seconds interval 0 existing (nil) heal (nil)^[[0m <0x7eea3520>
^[[33;1mZWaveNode::Wakeup did a poll for 73 1572362775 seconds interval 0 existing (nil) heal (nil)^[[0m <0x7eea3520>
^[[33;1mZWaveNode::Wakeup did a poll for 73 1572362775 seconds interval 0 existing (nil) heal (nil)^[[0m <0x7eea3520>
^[[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>
^[[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>
^[[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>
^[[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>
<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>
^[[33;1mZWaveSerial::Send m_iSendsWithoutReceive 3^[[0m <0x7e6a3520>
^[[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
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
10/29/19 8:26:54.332 >^[[31;1mZWaveJobHandler::ConnectionIsValid failed twice result 3/(nil) exists 0^[[0m <0x7e6a3520>
JobHandler_LuaUPnP::Reload: rwee reset Critical 0 m_bCriticalOnly 0 dirty data 1 running 1 <0x7e6a3520>
^[[31;1mgot CAN^[[0m <0x7e2a3520>
^[[31;1mgot CAN^[[0m <0x7e2a3520>
^[[31;1mgot CAN^[[0m <0x7e2a3520>
^[[31;1mgot CAN^[[0m <0x7e2a3520>
^[[31;1mgot CAN^[[0m <0x7e2a3520>
^[[31;1mgot CAN^[[0m <0x7e2a3520>
^[[31;1mgot CAN^[[0m <0x7e2a3520>

fje · October 30, 2019, 8:39pm

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

dJOS · October 30, 2019, 9:09pm

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.

fje · October 30, 2019, 9:53pm

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.

dJOS · October 30, 2019, 10:35pm

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.

Pabla · October 31, 2019, 4:50pm

For those looking for instructions they’re pretty straightforward:

Go to apps
Develop apps
Test LUUP code (Lua)
Copy paste the code above
Hit go and wait for code was run successfully dialogue
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

mikewop · November 1, 2019, 5:04am

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)?

rafale77 · November 1, 2019, 9:06am

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

sm2117 · November 2, 2019, 2:08am

Is there an easy way to check that the nightly heal was actually disabled? I ran the command and saw this output in the log which suggests to me that it didn’t work:

08 11/02/19 13:06:44.648 JobHandler_LuaUPnP::HandleActionRequest device: 0 service: urn:micasaverde-com:serviceId:HomeAutomationGateway1 action: RunLua <0x738ef520>
08 11/02/19 13:06:44.648 JobHandler_LuaUPnP::HandleActionRequest argument id=lu_action <0x738ef520>
08 11/02/19 13:06:44.648 JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1 <0x738ef520>
08 11/02/19 13:06:44.649 JobHandler_LuaUPnP::HandleActionRequest argument action=RunLua <0x738ef520>
08 11/02/19 13:06:44.649 JobHandler_LuaUPnP::HandleActionRequest argument Code=luup.attr_set(“EnableNightlyHeal”,0) <0x738ef520>
01 11/02/19 13:06:44.649 GetLuaInterface can’t find device type: -1/0x140b4f8 str: (null) <

Vinx · November 2, 2019, 12:01pm

This threat has helped me a lot in understanding, thanks again @rafale77.
I’ve been having “Can’t Detect Device” on my FLiRS Spirit thermostats. From what I understand, polling should be set to 0. But they still end up being undetected (within minutes or hours). Is this still a polling issue? Or is it a problem with not Vera supporting the Spirits properly? I have them configured as HVAC_ZoneThermostat.

I hope you have any suggestions.

rafale77 · November 2, 2019, 12:43pm

You could use either ALTUI and look into the table controller to see the value of the attribute or run this code and see what it returns

return luup.attr_get(“EnableNightlyHeal”). Please correct the quotes.

@Vinx. It depends. It could be a polling failure issue or if the error message appears when you are sending a command to the thermostat then it is likely because your network is too busy to receive the answer from the thermostat which is then the overhead problems I described.

mouch · November 6, 2019, 5:25pm

rafale77:

This is the luup call to disable the wakeup nnu for all devices which wakeup (i.e battery operated devices)

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

Any idea why 3 of my window sensors (strangely the 3 that didn’t have battery level at 100%) seem to no longer being connected after those 2 changes?

rafale77 · November 6, 2019, 6:08pm

Could you describe what you are seeing? Are you seeing a “can’t detect device” error after some time or are the 3 devices no longer responding?

If it is the former, it is likely that the configuredwakeupinterval and the wakeupinterval variables are not matched. The luup engine will check (current time - lastwakeup) constantly and if that time exceeds the wakeup interval, it will through out this error even though the sensor works fine. The configurewakeupinterval variable is updated when you update the wake up interval on the device itself through the settings menu. (or you can force a manual configuration).

If it is the latter, your device may be low in battery indeed and is no longer able to reach the closest neighbor node. Or it may have lost its neighbor node which should lead to it eventually throwing a “can’t detect device” message. If this is the case, change the battery and if it is not enough, you can consider setting the “DisableWakeupARR_NNU” variable to 0 and manually wake the device for it to update its neighbor nodes again. If the vera sees the manual wakeup event, you are good to go.

mouch · November 6, 2019, 8:10pm

Definitely the first one…
configuredwakeupinterval was definitely a mismatch. I trie to force configuring the nodes (configure node right now).
Now configuredwakeupinterval is shown empty and the devices show: ERROR: Unable to get any information on node…

Do I need to wait he 24h based on th new interval for it to work again or is it something else I should do?