Indeed, I am using habrige, never fails and no lag…
1 Like
Rafale I’ve turned off polling as you suggested and that has made things better.
As far as I can work out the Alexa integration will not work if a device has the ‘can’t detect device’ flag set.
This is interesting. Since I am not using the native integration but indeed the local habridge, (by the way I don’t see the habridge as a complicated workaround but a simplified more reliable and improved implementation vs. the native mios cloud to cloud which I see as flawed by design and concept, just a matter of point of view) I didn’t know this was possible. Do you mean that you can actuate the device from the alexa app but not by voice command? This is a bit surprising. I saw all the other posts about the mios servers having issues so I connected the dots… maybe too hastily. In any case, I don’t have any of these problems and would encourage people to move to it rather than relying on cloud to cloud designs.
Not from the Alexa App, but via the Vera Gui or Vera App when can’t detect device is shown. The Alexa voice command just returns a voice response that says ‘the device is not working. Please check the network connection and power supply’
I see, this makes a lot more sense now. Thanks for the clarification. It means that the mios device mirror server added device state check gating the commands so it can get alexa to respond with a failure message if the check returns an error. The habridge does something similar but responds with whether the vera has responded rather than with the state of the device. I highly recommend the habridge implementation… In any case, using 7.0.30 with the lower overhead should help you a great deal.
So are you saying the poll settings wont do anything if run on 7.30?
Btw, I ran the rest of your tweaks on my 7.30 Plus and rebooted - it’s even faster now to command devices! Im very impressed, thank you. Between 7.30 and your tweaks I’ve deferred my plans to migrate to HomeSeer (which I was not looking forward to).
1 Like
The poll settings will work on 7.0.29 and 7.0.30.
Great news that you won’t need to move to homeseer! I evaluated it myself when they had the free pi version and decided to stick around because of the progress I finally saw.
1 Like
Cheers.
I actually bought HS3, the Vera plugin and a Z-stick, that’s how close I was to moving. But I do really like a lot of things with Vera, especially plugins like Reactor, DelayLight and Patrick’s other great plugins. The iOS app is also much better on Vera amongst other pros.
1 Like
Just updated post 4 with an updated screenshot of my latest uptime on my production setup which is running an alpha test version of the firmware… 21 days! 3 weeks of continuous uptime with no reloads is no small feat after spending so much time peeling the onion on this platform to finally get it to work reliably. The way it is going, I can foresee it go a good 60 days before I will get it to crash and upgrade it to the beta.
2 Likes
That time it’ll be already production released 7.30.
1 Like
Will the upgrade when it gets release to stable version work seamless with those of us that have used your script to move the OS to external ssd?
Maybe a sweepstake for how many days uptime you can get! I’m going with 53 days…
1 Like
@rafale77, not sure it is related, but it somehow must be because I have never seen it before… Since I used your code with my firmware 7.29
for k, v in pairs(luup.devices) do
local var= luup.variable_get("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollSettings",k)
local bat = luup.variable_get("urn:micasaverde-com:serviceId:HaDevice1", "BatteryLevel",k)
if var ~= nil and v.device_num_parent== 1 and bat == nil then
if var ~= 0 then
luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollSettings", "0", k)
luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollNoReply", "0", k)
end
end
end
I keep getting in AltUI;
|||10/28/2019, 3:41:12 PM|#4998:Sensor smoke:Waiting for node to reply after 2 retries||
|||10/28/2019, 3:40:53 PM|#4997:Sensor smoke:Cannot contact device, error code: 1||
|||10/28/2019, 3:40:20 PM|#4996:Sensor smoke:Cannot contact device, error code: 32||
|||10/28/2019, 3:40:13 PM|#4995:Sensor smoke:Cannot contact device, error code: 58||
|| 10/28/2019, 3:38:42 PM #4994:Sensor smoke:Cannot contact device, error code: 1
And counting till 5000 and up… can’t get the messages away because they keep coming…
All fully battery powered and as far as I can see working well… any idea?
Are the smoke sensors battery powered? If yes then the luup code should not have affected them since you can see from my code that what it does is change a variable value for devices which are. Do these sensors have a batterylevel variable?
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