Arming Envisalink panel from MSR

[cw-kid]

Yes I hard refreshed the browser. I'll have another look again later, I'm not near my laptop.

However just looking with my phones browser (Chrome) it's the same.
x_vera_state is still present and x_vera_svc is not.

I'll try restarting MSR on the Pi or something.

Thanks.

[kfxo]

I'm seeing all the new stuff on mine. Got to say, its going to be a pain going through and fixing everything but I see the benefit as all the things that were not mapped before now have available actions and attributes.

[cw-kid]

OK after restarting MSR for a second time I can now see all the new svc stuff.

Side note, I can see a SubMasters1 service ID listed. I uninstalled that plugin ages ago, looks like some traces have been left behind.

[toggledbits]

Vera's implementation of services is very "loosey goosey". If any device has a state variable in a service, Vera considers that service "supported" by the device (even if the device doesn't actually implement any of its actions or manage that state variable). It has the advantage of not being overly strict, so that you can set variables that (a) aren't declared in a service that a device is declared to support; (b) are (declared or not) in a service the device does not explicitly support; and (c) have nothing to do with any defined service at all. This is useful, but also leaves Vera with a tendancy to accumulate a lot of garbage state variables that can't be easily cleaned out as your configuration changes over time. Vera themselves use this flexibility extensively, and it is available to plugins as well. Complicating matters, plugins are not notified when they are uninstalled, so there is no opportunity for a plugin to clean up after itself before heading out the door.

[LibraSun]

I used to take pains to remove (by setting to a null value using Luup, I believe) any extraneous device parameters I had introduced due to typos, etc. Now, I'm much less fussy about them and tend to leave bogus variables in place.

As @kfxo had worried (above), I thought my couple of dozen or so Rules in MSR would require major editing with the changes introduced in rev. 21072, but happily found only TWO occurrences of x_vera_state in my workflow. Lucky!

[toggledbits]

You will only find them in rules and getEntity expressions, too. There were no actions in x_vera_state, so no need to worry about reactions.

[kfxo]

@librasun said in The x_vera_state capability is gone:

As @kfxo had worried (above), I thought my couple of dozen or so Rules in MSR would require major editing with the changes introduced in rev. 21072, but happily found only TWO occurrences of x_vera_state in my workflow. Lucky!

Ended up not being too bad but I had to click through like 300 rules just to make sure I did not miss anything.

This release is top notch. I had a list of Hass mappings I wanted to start requesting @toggledbits and now they are all there.

[toggledbits]

It should still be the case that the most frequently-used device types should get mappings with their most-frequently-used attributes, but now we can take our time about it. The Reactor system capabilities are just simpler wrappers for the native controller ones. Eventually, they will also facilitate moving a device from one controller type to another. If, for example, you are using the Reactor binary_sensor capability in a Rule, and you move that device to another controller, it should still work as a binary_sensor on the new controller. On the other hand, if you've decided to use x_vera_svc_micasaverde-com_SecuritySensor1.Tripped in your rule and you move the device to HomeAssistant or Hubitat, you won't get that benefit.

[cw-kid]

@toggledbits said in The x_vera_state capability is gone:

for example, you are using the Reactor binary_sensor capability in a Rule, and you move that device to another controller, it should still work as a binary_sensor on the new controller.

Genius !

I am keeping all mine as the Reactor System ones then.

Unless there is some specific requirement where I can only use x_vera_svc_

[cw-kid]

@librasun said in The x_vera_state capability is gone:

I used to take pains to remove (by setting to a null value using Luup, I believe) any extraneous device parameters

So how can I manually remove this SubMasters1 Service ID ?

Looking in the list in the Entities area of MSR, that SubMasters is the only Vera plugin that I have uninstalled but a Service ID for it remains.

When I select it, it lists these devices:

Looking at those devices Variables in Vera I cannot see any Variables related to SubMasters I don't think.

Thanks

[LibraSun]

This post is deleted!

[toggledbits]

If you expand those entities and look at their attributes, you will likely find x_vera_svc_toggledbits_com_Submasters1.xxxx where xxxx is some name. The variables on Vera will have the same xxxx name.

[cw-kid]

x_vera_svc_toggledbits_com_Submasters1.Random="0.5573104607556194"

So the variable is called "Random" it appears. I can see that in Vera on the Variables tab of the device.

[toggledbits]

It's living up to its name! Run this on your Vera, putting in the device number where indicated:

luup.variable_set( "urn:toggledbits-com:serviceId:Submasters1", "Random", nil, DEVNUM )
luup.reload()

You'll also need to restart MSR, since there's no indication from the Vera when a state variable is deleted, it can't know.

[LibraSun]

I vote that the above -- namely, Vera Variable Zapper -- be included among the Tools planned for MSR. Or is that too purpose-specific?
I've always hoped for a programmatic/UI means of pruning unwanted Variables from my Devices without resorting to Luup code on Vera.

[cw-kid]

I have run that command against each device number and now all those affected devices no longer have a "Random" variable.
After restarting MSR I can now no longer see the SubMasters1 service ID so its all gone now.

Thank you.

[Crille]

@librasun I believe that is fixed in Vera fw 7.32
"12. Fixed the issues with not being able to remove or set an attribute or variable to the empty value".