Play buttons on the Set Reaction area
-
Hi
The button I have highlighted in Red doesn't seem to work ?
The lamps are not turned on when I press that play button.
However the other play button I have not highlighted on the left hand side, that one when I press it runs both actions OK.
So the lamps turn on and the HTTP request is sent out to node-red OK.
-
Open a bug in the tracker, please?
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
Open a bug in the tracker, please?
@toggledbits Yes I can do that, but as I don't know what I am doing with Reactor or MSR, I am not sure what is actually a bug or me not knowing what I am doing LOL.
-
Understood, but that, too, is useful information!
Helps me with documentation, at least.FYI, the issue is that
cover.openhasn't been implemented yet (for the individual action, the right-side button on the same row as the action). That's an easy fix... I have a long list of actions I need to implement for every platform. I tried to hit the most common/most used, and let the community tell me what others are needed and with what priority. But the intention is to catch everything, at least for the basic/intrinsic devices and the actively-supported plugins (on the Vera side). -
Understood, but that, too, is useful information!
Helps me with documentation, at least.FYI, the issue is that
cover.openhasn't been implemented yet (for the individual action, the right-side button on the same row as the action). That's an easy fix... I have a long list of actions I need to implement for every platform. I tried to hit the most common/most used, and let the community tell me what others are needed and with what priority. But the intention is to catch everything, at least for the basic/intrinsic devices and the actively-supported plugins (on the Vera side).@toggledbits said in Play buttons on the Set Reaction area:
Understood, but that, too, is useful information!
Helps me with documentation, at least.I have a long list of actions I need to implement for every platform. I tried to hit the most common/most used, and let the community tell me what others are needed and with what priority.
Do you have a list of what is implemented and what is on the list to implement? Where should we let you know what is needed? Top of my list thermostats and alarm panels.
-
@toggledbits said in Play buttons on the Set Reaction area:
Understood, but that, too, is useful information!
Helps me with documentation, at least.I have a long list of actions I need to implement for every platform. I tried to hit the most common/most used, and let the community tell me what others are needed and with what priority.
Do you have a list of what is implemented and what is on the list to implement? Where should we let you know what is needed? Top of my list thermostats and alarm panels.
@kfxo said in Play buttons on the Set Reaction area:
Top of my list thermostats and alarm panels.
I briefly looked at code and it's obfuscated, but that's a vera_devices.json file and alarms are indeed missing from this. my partition is recognized, and I could use its raw variables:
I didn't tried actions, but I guess an HTTP request could do it in the meantime.
EDIT: actions are not shown, in fact.
--
On a mission to automate everything. -
@kfxo said in Play buttons on the Set Reaction area:
Top of my list thermostats and alarm panels.
I briefly looked at code and it's obfuscated, but that's a vera_devices.json file and alarms are indeed missing from this. my partition is recognized, and I could use its raw variables:
I didn't tried actions, but I guess an HTTP request could do it in the meantime.
EDIT: actions are not shown, in fact.
@therealdb said in Play buttons on the Set Reaction area:
actions are not shown, in fact.
Right, if it doesn't know the capabilities of the device, it can't show actions because it doesn't know what they are. But it can copy existing attributes, which is the "x_vera" stuff.
It exists today that you can write your own rules for defining a device (for all HA controllers types, not just Vera). I'm not releasing this as a documented feature yet because I still have much other work to do, and I'm trying to keep the number of variables down for the moment until things stabilize. It's also the case that if you have a local device definition and later a system definition is added, your local config would hide the system config and make debugging more difficult: for any device problem, I first have to investigate if you've made a local override or not. There are many administrative/logistical issues that go beyond just what's possible in the code.
For things like thermostats, though, very necessary for you to be able to self-configure, because Vera itself does not provide sufficient information. You really can't reliably tell from looking at a Vera thermostat device if it's auto-changeover, dual setpoint or single with differential (or not), has fan control or not, what fan modes it has, has humidifer, has dehumidifier, etc. I don't see not relying on local user intelligence to get this done, at least for Vera. But that's slightly different from defining a device class. Overrides for a single device are planned as well, so that will encompass not just defining what capabilities the device has, but other convenience things like giving the device a nicer or more distinct name than the source controller uses (no 20 char limits!).
-
T toggledbits locked this topic on
