Ok this is indication that you did not technically set the wakeup interval on these sensors.
Try to use the normal vera way to do it:
Go under the setting page of the given device. Set the wakeup interval in the text box. click save wakeup interval. Bring the sensor closer to the vera and wake it up manually. Luup will reload (no idea why and why that helps anything but that’s what the vera does…) and your device should get its setting saved.
Hi,
I had problems with ZWave.Me scene controllers and found that you now have to bring them really close to the controller when including and with any configuration change (i.e. wake up). You really need to be within one meter of the controller for it to work. Also, if still problematic, put in a brand new battery. You can put in the older one back in after all configurations have been done.
Prior vera versions did not seem so sensitive to re-configuring battery devices. I could reconfigure leaving them in place.
Cheers Rene
A little irritation here to give people an idea of how bad the battery consumption is with the defaults wake up nnu settings and wakeup poll.
My sensative strips which are setup to wakeup only once every 24hrs and have a battery rated for 10years are now out of battery after only little more than 3.5years. I am very irritated because these devices don’t have a replaceable battery and are expensive. I now have to replace the device.
Imagine the drain on devices waking up every 30minutes per the default vera configurations…
There are practically no devices which need to be polled on the market any more, most update status when variable change above a certain %. Even less devices which need to get their zwave routing updated every 30min. To all the devs, including the new firmware, please disable these features by default.
For the 7.30 release please disable wakeup poll when the zwave polling option is disabled.
Another event this morning reinforcing again how flawed the vera forced zwave implementation is:
I had one of my locks do a poll which happened within a few milliseconds of me tripping some sensors combined with 2 other sensors waking up at the same time and some mysterious Got CAN (unrelated to instant status since no devices with instant status were involved) and boom! the vera zwave radio hangs leading to 5 mins delay in a couple of scenes, missed device untrip signals, since I had other devices poll within the 5 mins, they went can’t detected and then detected again etc… complete chaos. Luup did not reload and eventually recovered. When @edward gets back, please disable the wakeup poll. Also please take a look at the got CAN implementation. I get the feeling that it is coming from the zooz 4in1 sensors sending various sensor readings when the vera is expecting something else, just a guess. I definitely get much fewer of these when I am not home tripping these sensors.
I looked at my PC controller from silabs and am sure that it is unique to the vera and therefore not an implementation problem from the zwave stack related to instant status since I never see these dropped frames or CAN frames and no other zwave controller I have tested does this. (hubitat, homeseer, openzwave)
@rafale77 I’m having occasional issues with Z-wave commands being sent to a device and Vera registering the device as changing state, however, the device hasn’t changed state and needs to be toggled to restore correct state tracking.
Very occasionally Vera will report my garage door has opened when it hasn’t too - again togling the state in vera restores normality. I wasn’t having these issues on 7.29.
I’m using your recommended setting on 7.30 - any ideas?
Blockquote[quote=“rafale77, post:83, topic:210661”]
My sensative strips which are setup to wakeup only once every 24hrs and have a battery rated for 10years are now out of battery after only little more than 3.5years. I am very irritated because these devices don’t have a replaceable battery and are expensive. I now have to replace the device.
[/quote]
I have one that was sent to me as a sample and panicked when I read this, on further inspection it appears that they are rechargeable using the USB port.
IT might be a later version, I’m not sure but will now use it and see how long the battery lasts.
Yes I have one sensor which has been acting up strangely, having ghost trips. It is always the same sensor so I thought it was a sensor problem until I saw someone else reporting the same thing and now you are the third one. I have not gotten to the bottom of it an appears to be related to the device waking up. It is also very inconsistent and not very reproducible…
That’s odd as none of my devices are battery powered (due to the power drain issues you have had too).
Recently converted all my time triggered scenes to reactor triggers so I could turn off reload on time jumps. Successfully was able to do so, but now my a/c powered devices are failing to be polled. I am having to manually poll all nodes to get correct device statuses. Besides the scene changes, the reload on time jumps was the only other thing that was changed since. To my understanding the other changes recommended only effect polling on battery powered devices.
Rafale, as me I have told this before. Since the “code” from your to not poll devices, I see this behaviour as ell… state is not always correct in Vera or takes longer time be be correct. Before this was of no issue.
@Pabla, @slelieveld, Nothing prevents you from enabling polling on these particular devices which require it. To do so, just go into the device itself set the polling interval variable to a number different from 0 and reload luup. I too also have a handful of devices which are still getting polled.
The code I posted does 3 things:
I think the issue is not a polling one. I am almost sure before the status was also instantly updated in Vera despite the previous polling values.
Are you then thinking that instant status is disabled? I don’t know how this is possible since instant status is a configuration of the device and none of lua code affects it. I am not seeing this at all. Instant status is not dependent on the vera. It is a communication triggered by the device sending its status back when it changes back to the controller. What @Pabla Is describing seems to be a polling problem which is triggered by the vera and which indeed gets disabled because most devices don’t need it (devices which have instant status).
I do not know what is wrong. And I dont know how to troubleshoot (sniff) zwave…
Oh that makes more sense now I was under the impression that polling on battery devices was turned off! I have a few non-instant status switches so I’ll keep polling on, any recommendations for a good polling interval?
depends on how many devices are getting polled. A polling event takes down the controller for 1-5s, averaging at 3s. So you can do your own math. I would recommend to keep the polling at <1% of the time.
For example: if you poll every 30min (vera default) and have 10 devices, you will have 10*3s=30s every 30min so it is 1/60 of the time or 1.667%. That would be a bit too much and I would go to 1hr. You can also vary the interval depending on your usage of the device. I mostly poll my devices to update their battery status (FLiRS like sirens and door locks which are battery operated but constantly on) and I poll them once a day.
If you have battery operated devices which wakeup, then you need to increase the interval even more because they will keep your controller busy too so keep that in mind. When you set the polling busy time to 1%, know that it means that there is a 1% chance that you will either get some delay in your command or that you will have a 1% chance to miss a sensor status change.
Rafale, do you have any lead or tip to start finding where in a device this setting should be enabled? I currently have about 10 devices which do not have proper status in Vera after manually using them.
Could you please list what type of devices they are? This rather odd because I am not observing this on my setup though I want to verify if instant status is still working when I get home tomorrow. The rest of my sensors all report properly whether AC or battery powered. You are the only one reporting this so I am curious as to why. None of the setting changes should be able to cause this.
2x Fibaro FGS211
one not known (cant see model in vera anymore)
Qubino ZMNHDD1
I also logged this with Vera support. But there a numerous other issues which are still on their investigation list and response is very slow (1 mail a day) and no real solution yet. BTW, the support I expect from vera is for officially supported devices going into strange modes (can’t detect device, creating ghost devices, not responding, etc.) And the device has been already swapped 2 times for replacement.
Hi @slelieveld ,
I have the same devices, but no problems with status updates. I use both with Zwave.me controllers via association and the Vera picks up the changes in Status or dim level pretty much instantly. Originally on a Lite, then Edge and now Plus.
Cheers Rene
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules