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 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. -
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. -
T toggledbits locked this topic on
