Moving MSR from a QNAP container to RP 5 - some issues

[cw-kid]

Hi

I can't seem to find this, how do you access it ?

Thanks

[cw-kid]

If I select an Aeotec Minimote remote I can see Scene Controller.

However if I select one of my Fibaro Dimmer 2 modules I cannot see the scene items.

I don't think the Fibaro Dimmer 2 module is a Scene Controller per se, but it can be used for Scene Activation which is what I am looking to use with double and triple clicks on wall switches.

Fibaro Dimmer 2 in PLEG

Note this is the related PR ticket here.

[cw-kid]

Well it appears to work with the Aeotec Minimote at least.

When I press various buttons on the remote I can see the numbers changing in MSR and it ran my reaction action when pressing the assigned button.

I only had to set the one trigger

[toggledbits]

If the Fibaro doesn't register as the scene controller device type, it's not going to map with the scene controller mapping.

Follow these instructions to get a device dump for your Fibaro and attach it to a PR request for mapping:

Troubleshooting Entities - Reactor - Multi-Hub Automation

Read and follow the instructions carefully

[toggledbits]

By the way, it would be much more useful if you screen shotted a device you were having problems with from the Entities list with the detail card open. That shows a lot of information that can speed things along.

[cw-kid]

Hi

I've attached a device dump of a Fibaro Dimmer 2 to the PR.

[cw-kid]

This is the Fibaro Dimmer 2 devices information from the Entities area:

dimming.level=0
dimming.step=null
power_switch.state=false
x_vera_device.configured=true
x_vera_device.device_number=140
x_vera_device.device_type="urn:schemas-upnp-org:device:DimmableLight:1"
x_vera_device.failed=false
x_vera_device.mapped_by="*;device_type=/urn:schemas-upnp-org:device:DimmableLight:/"
x_vera_device.mapped_class="generic_dimmer"
x_vera_energy.amps=null
x_vera_energy.day_kwh=null
x_vera_energy.kwh="50.0300"
x_vera_energy.life_kwh=null
x_vera_energy.month_kwh=null
x_vera_energy.power_factor=null
x_vera_energy.volts=null
x_vera_energy.watts="0.0"
x_vera_energy.week_kwh=null
x_vera_energy.year_kwh=null
zwave_device.capabilities="211,156,1,4,17,1,L,R,B,RS,|32S,34,38S:3,39S,49:4,50:3,86,89,90S,94,96S:4,112S,113:5,114,115,117S,122,133S,134,142S,152,"
zwave_device.failed=false
zwave_device.manufacturer_info="271,258,4096"
zwave_device.node_id=52
zwave_device.version_info="3,4,5,3,3"
Capabilities: dimming, power_switch, toggle, x_vera_device, x_vera_energy, zwave_device
Actions: dimming.down, dimming.set, dimming.up, power_switch.off, power_switch.on, toggle.toggle, x_vera_device.set_variable, x_vera_energy.resetkwh, zwave_device.poll

[toggledbits]

You can see the device type has nothing to do with the SceneController device type. Let me pick through the ZWave capabilities listed and see what other interesting things it can do and I'll come up with a pattern for it. The device dump should give me a little more to work with as well. You can undo the config changes for the device dump if you haven't already; that's one and done, no need to leave it that way.

[cw-kid]

Indeed I don't think it is a full on scene controller.

However it supports "scene activation"

Don't know how PLEG sees it then, but its using this service ID

urn:micasaverde-com:serviceId:SceneController1

And shows these properties:

sl_SceneActivated
LastSceneID
LastSceneTime

See PLEG screen shot above.

[cw-kid]

These lines are present in the device dump .json under the section "states"

"urn:micasaverde-com:serviceId:SceneController1/sl_SceneActivated": "1",
    "urn:micasaverde-com:serviceId:SceneController1/LastSceneID": "11",
    "urn:micasaverde-com:serviceId:SceneController1/LastSceneTime": "1614868761",

[toggledbits]

This is what I needed to know:

    "pnp": "5101",

This device is great example of bad device support implementation on Vera's part. The device is using variables in a service that isn't declared on the device type. They're handling it as a plain dimmable light, which has a limited set of services that does not include the variables you see them using in SceneController1. What they should have done is created a new device type, because dimmers/switches with scene activation capability are not unique in the ZWave world (see Cooper, HomeSeer, etc). Hopefully they do a better job at this in the new firmware.

[cw-kid]

OK that makes sense and Vera's fault again !

Yes makes you wonder how such a device like this will be catered for on the new Ezlo firmware.

EDIT

That also likely explains why you could not set this up natively in Vera and use its scene activation. Least I don't think you can.

Richard must of known this and made PLEG so it would see these scene activation properties properly.

[cw-kid]

May I ask what pnp is ?

Thanks

[toggledbits]

@cw-kid said in system capability zwave_scene_controller:

Richard must of known this and made PLEG so it would see these scene activation properties properly

No, PLEG uses the scene activation data from the static JSON file, which is the same data that the Vera scene builder uses. This is one reason why PLEG was always limited to what the scene builder would see, and you had to take another approach to getting at states that weren't related to scene events.

Reactor for Vera uses a different model entirely. It simply reacts to any state variable that is present on the device (which sounds like what you think PLEG does, but it actually is not what it does). Reactor for Vera actually doesn't care what the device type is; it is only looking at states. In that sense, Reactor was far more capable than PLEG in its most basic form, because you didn't have to jump through hoops to make a condition based on some event that wasn't otherwise supported by the scene data, which is often incomplete.

Unfortunately, looking at states cannot tell you what the device type is. There are too many instances in the Vera world of states being present on a device when the state's service is not supported, or only parts of the service are supported. And since users can set a state variable on any device they want, it would too easy for a user to errantly create a state variable on the wrong device. If you look at states for type and to determine behavior, the behavior of that device would/could suddenly change (and you may have no idea why), and that would be no good. Vera is really loose with states. That adds a lot of flexibility, but it kills looking at states for any intelligence as to what the device is. And MSR does need to know. Hence the entirely different mechanism.

The good news for MSR is that the universe of device types is relatively small, and further reduced by what people are actually using today. I don't have to support everything Vera ever supported, only what's in use now. And once I have the per-user device configuration stuff exposed and documented, you'll easily be able to tell MSR "no, this device isn't a dimmer, it's a scene controller with dimming capability". Ultimately, you will fix this problem yourself in less than a minute. For now, though, making me look at every unsupported device helps ensure that the most generic support, the exceptions everyone would to make, are included in the product and therefore function out of the box and not exceptions at all.

[cw-kid]

@toggledbits said in system capability zwave_scene_controller:

PLEG uses the scene activation data from the static JSON file, which is the same data that the Vera scene builder uses

OK.

But you can't just use the Vera scene builder and have a trigger on the sl_SceneActivated state variable of this Fibaro Dimmer 2 device though. Which is why I never knew how to do this natively in Vera. Without PLEG I wouldn't of been able to set this up at all. Unless there is some LUA code examples on the Vera forum somewhere that may of done it.

@toggledbits said in system capability zwave_scene_controller:

Reactor for Vera uses a different model entirely. It simply reacts to any state variable that is present on the device (which sounds like what you think PLEG does, but it actually is not what it does).

Yes I thought PLEG was doing that I think, just reacting to the sl_SceneActivated state variable changes. But you know how all this stuff really works behind the scenes, no pun intended.

These double and triple clicks on the wall switches are quite useful.

I use them for turning on / off (toggle) side table lamps in the room for example, the Fibaro Dimmer 2 module only being physically connected to the ceiling light.

But you could make them do anything, maybe a triple click down to put the house in to Night mode as you are passing that switch at the bottom of the stairs or whatever you want really.

[toggledbits]

As an added bonus, the Fibaro doesn't declare the scene controller or central scene ZWave capabilities, apparently. That's not relevant to getting the device supported in MSR, but it makes me curious what they're using to communicate the activations. They do advertise as having multi-level switch capability, so maybe that? Odd...

[toggledbits]

@cw-kid said in system capability zwave_scene_controller:

But you could make them do anything,

I'm a big user of scene controllers myself actually. There are many on each level of my house, mostly the old Leviton four-button units, but also ZRC-90 and Hank four-button. Support on Vera for the Levitons was useless, so I wrote my own plugin to handle them and light the LEDs the way I wanted them to work, and added some features like the ability to undo up to 8 of the last scene changes, etc.

But, I digress... I have enough info now to get this mapping done, no problem. Sit tight. Thanks for the data dump. If any other device comes up like this, just go ahead and go for the data dump immediately, because I'll need it and be asking for it.

[toggledbits]

OK. I just dropped an updated mapping file on the PR. Go grab that and try it out.

[cw-kid]

Thanks, I've added some notes on the PR.

its kind of working. It works the first time I do the clicks on the wall switch.

But if I do the clicks again it doesn't run the reaction action again.

[toggledbits]

You need to check both the response value and the timestamp (the changes operator is all you need for the timestamp check).