Strange behavior with devices status

AK,

Not sure since when… But having a strange issue with the status of device.

Something a light switch is off for real but still on under openluup (not under vera)… So I switched it off again in openluup and it stay off but that’s not the case since a while. It come back ON…

The only way to solve that… It’s on openluup to switch to off and on quickly so the light come back on and switch to off again and the status is ok.

Not seen this. Shouldn’t be a situation which persists for long, since openLuup retrieves the complete status data periodically from Vera.

Might it have started when you began using asynchronous mode of the VeraBridge? (If you do…). If so, try turning that off.

@DesT

Trying to investigate this, I’ve set up a Vera scene which toggles the state of a virtual switch every 30 seconds. Looking at the state variable from a bridged openLuup system, I see exactly what I would expect to see. So if there’s a problem, it’s not showing up in this (relatively simple) test.

Not sure what to try next, unless you’ve got more more feedback on this.

AK,

Sorry for the delay.
I think the issue come from the manual trigger instead of from the zwave.

I also disable the async and I think it help. And I also change the code from another post about que zwave/verabridge queue and changing from run to job your line of code and that’s also help.

I’m running like that since a couple of days and looks better.

I also think that in my own LUA code using a couple of loops to deal with devices I will introduce a delay to make sure I’m not flooding something. 'cause I saw that a couple of devices settings are not applied correctly when coming from the “loop”

Are you saying that you changed from JOB to RUN?

Here’s the line I have now…

return {job = job} – TODO: job or run ?

“L_VeraBridge.lua” line 758 of 915

It would seems that you’re not running the latest, then, which already has that line… which version are you using?

openLuup 19.5.16 and verabridge 19.5.11