The x_vera_state capability is gone
-
-
The bad news (Vera users): If you are using x_vera_state attributes in your rules, you will need to edit them and choose the newer capability. Good news: this [new] model will probably never change.
-
I don't know if I was using any x_vera_state attributes or not. Maybe a few here and there I can't remember I've setup that many rules.
I've updated to version 0.1-21072.
Looking in Entities on the main menu, x_vera_state is still listed and it does then filter and bring up some of my devices. Which appear to be the various plugin devices within Vera.
I can't see x_vera_svc in this drop down list however.
Looking in a Rule and an Entity Attribute that drop down list there I don't see anything new or different ?
So how do you access this x_vera_svc and see all of a devices ServiceID's and Variables ?
Thanks
-
Did you hard refresh your browser after the upgrade?
Mine looks like this for a binary sensor (partial):
And this for the dropdown:
-
Be sure to check any Expression in your Rules, as well, where for example...
The old expression pre-21072:
getEntity( "vera>device_325" ).attributes.x_vera_state.cd_jackson_com_systemmonitor_systemluuprestarttimeWith release 21072+ becomes:
getEntity( "vera>device_325" ).attributes.x_vera_svc_cd_jackson_com_SystemMonitor.systemLuupRestartTime -
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.
-
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.
-
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!
-
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. -
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!
@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.
-
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_sensorcapability in a Rule, and you move that device to another controller, it should still work as abinary_sensoron the new controller. On the other hand, if you've decided to usex_vera_svc_micasaverde-com_SecuritySensor1.Trippedin your rule and you move the device to HomeAssistant or Hubitat, you won't get that benefit.Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
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_sensorcapability in a Rule, and you move that device to another controller, it should still work as abinary_sensoron the new controller. On the other hand, if you've decided to usex_vera_svc_micasaverde-com_SecuritySensor1.Trippedin your rule and you move the device to HomeAssistant or Hubitat, you won't get that benefit.@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_
-
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!
@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
-
If you expand those entities and look at their attributes, you will likely find
x_vera_svc_toggledbits_com_Submasters1.xxxxwhere xxxx is some name. The variables on Vera will have the same xxxx name. -
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.
-
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.
