Organizing/ structuring rule sets and rules

[therealdb]

I still have some code running on my Vera that I want to port and it's related to scene controllers.

I'm mostly using Fibaro's switch/roller shutter and on the Vera side I'm getting sl_CentralScene/sl_CentralSceneAttr, but it seems too fast to be intercepted by MSR.

What's anyone using? Thanks.

[toggledbits]

@therealdb said in MSR for Scene Controllers:

but it seems too fast to be intercepted by MSR.

I doubt that's the case. I think a lot of people are using those variables, myself included. Can you be (a lot) more descriptive about what you are doing and observing? Also versions and hubs?

[therealdb]

VeraPlus. It could be that it was 5am when I tried it, but it was working well. I'll try again. Latest version, of course. I fear fibaro fgs are too quickly changing these variables, but I'll try again.

[toggledbits]

Yeah, but as soon as the variable changes, Luup should be returning from the long poll request with the modified state variable and value. Does the device change these variables rapidly, or is your code on the Vera doing it?

[therealdb]

@toggledbits code on vera is watching and turning on/off other lights. I removed this code and worked with reactions only. I'll try again later this week and report back. It's probably me doing too many things together and a busy week at work is not the best way to accomplish this task. Thanks for the patience and support.

[therealdb]

So, "later this week" has become "let's wait two months to find some spare time"

I've finally traced the problem (and ported quite everything else), and that's because a couple of devices are only updating sl_CentralScene /sl_CentralSceneAttr, so watching for the regular scene controller capability has no effect. I've since migrated the old code to MSR rule sets and I'm happy now, since there's no code runing on the Vera itself, besides a couple of callbacks to filter wrong values and a notification to know when luup is restarted.

[toggledbits]

This has genesis in Z-Wave, because they have two different mechanisms (basically old and new ways) for signaling activity on scene controllers. I guess Vera tried to adapt to that, and they got close, but I think any offset from complete is forgivable here because it's just dang hard. Z-Wave isn't the standard many think it is, and there's a lot of "free play" in how manufacturers interpret and implement the spec. It's part of what has made ZWaveJSController a heavy lift.

[therealdb]

@toggledbits yeah, I’m still struggling with repeated events, but I’ll eventually win

[toggledbits]

Scene controllers (or more specifically, their buttons) are usually handled with two conditions: one to check the state variable containing the button press for the right number (1 for button 1, 2 for button 2, 77 for triple-click on button 9, etc.), and a second (in an AND group with the first) to check a timestamp that updates (using the changes operator) when the button is pressed. This varies from device to device. I recommend using the detail panel for the scene controller entity (Entities page, click right arrow on device) to monitor what changes when the same button is pressed repeatedly, and you'll soon discover what you need to be testing in the conditions.

[therealdb]

@toggledbits I’ve found an old post with plain reactor and the same problem. So, while getting the buttons is doable, if the same scene happens again, it will not update (while with luup variable_watch you’ll be notified anyway). I’m trying a couple of different approaches, but setting the variables to something different will stop the report until a luup reload. We’ll see.