I found a few problems with openLuup or maybe missing features vs. Vera:
Security Sensors do not update the “ArmedTripped” variable automatically. I suspect the Vera runs a routine which automatically checks the Armed device variable whenever the Tripped variable changes for all SecuritySensor1 devices. This is missing on openLuup.
Scene schedule handler. I use conditional execution of scenes. If I write a scene which returns false, the scene handler shows it did not execute, which is perfect, but the issue is that it does not update the next time the scene is supposed to run so I get a next run time in the past. I need a luup reload to reset the next run date. If my scene runs with if conditions instead of a return false, I don’t seem to get a problem.
This is related to amg0’s iPhone locator and maybe to problem 2 above: I have had occasions where the iPhone Locator would stop updating location. I have not quite figured out why. I would just need to force a location refresh to get it going again. I have not seen this on the vera but I suspect it is related to a luup.delay function in the plugin crashing once and not able to restart itself. I suspect that the crazy luup reload frequency of the Vera addresses this but since openLuup is so stable… Note that this is pretty rare (happened at least twice in the past month.)
on 2) can depend on where the conditional code is placed. In my case I have some Lua code as part of the main scene. Sometimes that code does something, sometimes it doesn’t. But I always have to return true, otherwise the timestamp is not updated. This was true for both Vera and openLuup. I note your situation may be different.
Yeah it’s a bit different. I use the return false to cancel running the entire scene.
I am looking through the openLuup code and found that the reset of the next time run is done within the scene itself so if I cancel the entire scene, it will not update. It needs a pulse on the side to do this. The same thing is true for the Security sensors.
On the scene schedule handler, I am finding out more:
It maybe an issue with ALTUI.
I have 2 schedules for the same scene executing at a different time daily:
The scene is conditional: It means that if the lua code returns “false”, it does not execute and does not update the last_run parameter but does not update the next_run parameter for the schedule which was skipped either. However, if the morning one is skept, ALTUI should be displaying the next schedule one which is in the evening but it doesn’t…
I pulled the scene json and indeed the next schedule in the evening remains correct but not displayed and the morning scheduled next_run is in the past.
I noticed that switching the scene off and back on updates ALTUI to the evening schedule but also updates the scene json for the next morning schedule as well.
Edit:
So it is a timer issue. When a scene runs it stops and reset the scene.timers. If the scene does not run then the timers do not get reset and goes into the past. The next_run parameter for the scene is stored in the user_data.json and gets updated only when the timer job is restarted. ALTUI displays the earliest of any of the timers even if it is already passed which should not be a problem. openLuup just needs to find a way to reset the scene.timers even if the scene returns “false”. Probably need akbooer to look at it whenever he comes back. It’s a bit over my head. I think it may also add robustness to problem 3 which I also think is a timer job reset issue.
The problem 1 can fairly easily addressed an additional function which could be in a scene or added to the pulse job.
So I came up with a workaround for this timer reset issue which be quite elegant but I hope will be temporary:
I am going to create a timer scene which will trigger these scenes. This timer scene will always return true and the conditionals will remain in the action scene so it will always update to the next time correctly. Not ideal…
I have a few “created sensors” which are passive devices from an openluup perspective. At each Luup reload, they seem to lose their category_num and sub_category_num attributes which should be written into the user-json.