Enhance ThingActions UI support #4392
Conversation
|
For the following action The GET API now returns: An example with the POST API using these input values in API explorer: The logs: And the returned response body: |
...ation.rest/src/main/java/org/openhab/core/automation/rest/internal/ThingActionsResource.java
Outdated
Show resolved
Hide resolved
...ation.rest/src/main/java/org/openhab/core/automation/rest/internal/ThingActionsResource.java
Outdated
Show resolved
Hide resolved
...ation.rest/src/main/java/org/openhab/core/automation/rest/internal/ThingActionsResource.java
Outdated
Show resolved
Hide resolved
lolodomo
force-pushed
the
enriched_actions_api
branch
from
7bf450e to
2ca7f24
Compare
lolodomo
changed the title
lolodomo
force-pushed
the
enriched_actions_api
branch
from
2ca7f24 to
9e04605
Compare
|
@lolodomo The |
|
I don't understand, Thing actions can already be invoked from rules. ??? |
|
After reading #1745 completely, yes they could in theory - the problem is however the same we attempt to fix with this PR: The Thing action module types only contain the inputs like the |
|
@lolodomo Please do not force push from now on - I will start working on your PR as well and create a PR to your PR branch afterwards. |
|
@lolodomo I have created lolodomo#3, which adds support for invoking Thing actions through UI-based rules. Please merge it with rebase merge to keep commit history. |
lolodomo
force-pushed
the
enriched_actions_api
branch
from
f582e92 to
f1e4101
Compare
|
Thanks for integrating my changes ... now we have to update the PR description: Enhance ThingActions UI supportFixes #1745. Return config description parameters for the ActionInputs of ThingActions for the REST GET Enhance the REST POST This will be used by the UI's Thing page and rule editor to allow invoking Thing actions through the UI or adding them to UI-bases rules. |
|
When PR is ready for review, I will squash everything, provide a proper description and mention you as co-author. |
...on/src/main/java/org/openhab/core/automation/util/mapper/SerialisedInputsToActionInputs.java
Outdated
Show resolved
Hide resolved
.../java/org/openhab/core/automation/util/mapper/ActionInputsToConfigDescriptionParameters.java
Outdated
Show resolved
Hide resolved
.../java/org/openhab/core/automation/util/mapper/ActionInputsToConfigDescriptionParameters.java
Outdated
Show resolved
Hide resolved
lolodomo
force-pushed
the
enriched_actions_api
branch
from
47e8144 to
c6d8c3c
Compare
.../java/org/openhab/core/automation/util/mapper/ActionInputsToConfigDescriptionParameters.java
Outdated
Show resolved
Hide resolved
|
@florian-h05 : I believe it is almost ready now. Can you please have a look to my last commits before I squash everything and update the 2 first messages ? |
|
I am tempted to change the expected format for "datetime" context. |
I will do.
Agreed, having seconds is better than not having seconds - and as it is not yet used, there should be no problems. |
Done. I also updated my second message with a full example when using GET and POST API. |
There was a problem hiding this comment.
LGTM, thanks for your work as well as improving what I have contributed!
Please update the PR title and description, I have already proposed a new one in #4392 (comment),
and add a joint sign-off.
Just two comments:
....core.config.core/src/main/java/org/openhab/core/config/core/ConfigDescriptionParameter.java
Outdated
Show resolved
Hide resolved
...in/java/org/openhab/core/automation/thingsupport/AnnotatedThingActionModuleTypeProvider.java
Outdated
Show resolved
Hide resolved
...c/main/java/org/openhab/core/automation/internal/module/handler/AnnotationActionHandler.java
Outdated
Show resolved
Hide resolved
Fixes openhab#1745 Return config description parameters for the ActionInputs of ThingActions for the REST GET /action/{thingUID} and REST GET /module-types endpoints. The config description parameters are only provided if all input parameters have a type that can be mapped to a config description parameter (String, boolean, Boolean, byte, Byte, short, Short, int, Integer, long, Long, float, Float, double, Double, Number, DecimalType, QuantityType<?>, LocalDateTime, LocalDate, LocalTime, ZonedDateTime, Date, Instant and Duration). Enhance the REST POST /actions/{thingUID}/{actionUid} endpoint (allows invoking Thing actions via REST) and the AnnotationActionHandler (allows invoking Thing actions from UI-rules) in order to be more flexible regarding the type of each provided argument value and to map the value to the expected data type. Number and string values will be accepted as inputs and the expected data type will be created from this value. This will be used by the UI's Thing page and rule editor to allow invoking Thing actions through the UI or adding them to UI-bases rules. Signed-off-by: Laurent Garnier <lg.hc@free.fr> Signed-off-by: Florian Hotze <florianh_dev@icloud.com>
lolodomo
force-pushed
the
enriched_actions_api
branch
from
95ddb01 to
b308cd7
Compare
…utput Refs openhab/openhab-core#4392. Closes openhab#2817. This adds a new section "Actions" to the Thing tab of the Thing page, which provides a button for each UI-supported Thing action. Clicking on that button will open a popup, where action input can be configured and action output can be viewed. Currently, action output is displayed for actions with a single output, as well as for the `result`, `qrPairingCode` and `manualPairingCode` keys of the response object. Signed-off-by: Florian Hotze <dev@florianhotze.com>
…utput Refs openhab/openhab-core#4392. Closes openhab#2817. This adds a new section "Actions" to the Thing tab of the Thing page, which provides a button for each UI-supported Thing action. Clicking on that button will open a popup, where action input can be configured and action output can be viewed. Currently, action output is displayed pretty for the `result`, `qrPairingCode` and `manualPairingCode` keys of the response object. In addition to that, the raw output can be viewed. Signed-off-by: Florian Hotze <dev@florianhotze.com>
) Refs openhab/openhab-core#4392. Closes #2817. This adds a new section "Actions" to the Thing tab of the Thing page, which provides a button for each UI-supported Thing action. Clicking on that button will open a popup, where action input can be configured and action output can be viewed. All keys of the action output response object from REST are rendered as list Items, the labels are taken from the action output definitions and fallback to the key. If the key is `qrCode` or its output type is defined as `qrCode`, its value is rendered as QR code. For actions without inputs or without outputs, messages are shown indicating that there is no such. --------- Signed-off-by: Florian Hotze <dev@florianhotze.com>
…te context docs This changes the default format for the datetime context to the ISO standard. This context is not used by add-ons and supported by the UI, so it should be possible to change it (again after openhab#4392.) Also update the context docs from https://next.openhab.org/docs/developer/addons/config-xml.html#supported-contexts and the UI code. Signed-off-by: Florian Hotze <dev@florianhotze.com>
…te context docs (#4428) * ConfigDescriptionParameter: Change default format for datetime & Update context docs This changes the default format for the datetime context to the ISO standard. This context is not used by add-ons and supported by the UI, so it should be possible to change it (again after #4392.) Also update the context docs from https://next.openhab.org/docs/developer/addons/config-xml.html#supported-contexts and the UI code. Signed-off-by: Florian Hotze <dev@florianhotze.com>
|
I don't know if this is the right place to ask, but it's somewhat on topic: I'm working on a binding where one of the Actions is to set a new API key in the device. It enables encryption and, in short, you don't want to make a mistake when setting it. Thus, I have a need for a longer/more elaborate description for this Action. I erroneously thought that I could use the same limited set of HTML tags in the Action description as is possible in Configuration descriptions (I need some bold text and a couple of line breaks). But, it doesn't work as of now - the tags are just printed out, in MainUI at least. Is this intentional or is the "rendering" just not implemented yet? If it's the latter, I prefer to just leave the description as it is, and it will start to work properly later. If it's not planned, I'll just have to remove the formatting. A nice bonus would also be support for a |
|
The action description itself does not support HTML tags, but for parameter descriptions HTML can be used as for config descriptions (the parameter input is the same component as all other config input in the UI).
@lolodomo WDYT? |
|
Sorry, I am not aware of this existing verification feature. So feel free to do what you think is good. |
What is your exact use case for that? I don't see a general use for this. |
The thing I would want it for is for an Action that sets the API-key in the device. This should NOT be done by mistake, as you need to factory reset the device if you lost control over the key. Now that Actions are available from the UI, they are more accessible, which is good, but it also makes it easier to do something like this without intending to. I think that a confirmation dialog would be helpful to make sure that the user really intends to set a new API key in the device. |
|
I don't think we should implement actions that change thing configuration. It is not the purpose of a thing action. |
|
The user already needs to select the action from a list, which will open a popup where the user has to enter the action inputs and can see the action output. To execute the action, the user needs to click on execute action in that popup. I don’t think we need another dialog there to avoid accidentally invoking a Thing action. |
I had a rather long discussion with others on the forum about where to place this (channel, configuration, action), and the conclusion was that an action was "the best fit". |
|
@lolodomo: |
I am afraid you were badly adviced. |
It was just a suggestion. In this case, doing a factory reset will result in losing all your device configuration and that you have to go through configuring the Wi-Fi of the device again, which includes setting it up as an AP, connecting to it, several reboots etc., so I just want to do whatever I can to make sure nobody does this when they don't intend to. You do get a dialog when clicking the Action, but if you don't read the text closely because you think you have clicked a different action, so I would think that and extra "Are you sure?" would be helpful for "potentially destructive actions" like this. |
In case of Matter, the action is setting up nothing, it just creates a new pairing code. |
The discussion isn't just about that, so it's quite a lot to read, but it kinda starts here: That said, one of the things that made me use Action for this was that it doesn't have the problem of being persisted. Both channels and configuration has the "problem" that I can't know that the input actually comes from the user, it could also come from storage. As there's no way to "read" the API key, I can't compare the value to see if it's different from the current one. With an action, at least I know that there's a user action on the other side of this. After setting the key, even if it's the same as the existing key, the device must be rebooted - so it's not something that "doesn't matter" if you just set the existing key. |
If you really want a confirmation no one just clicks away, I would propose to add a text input where the user has to type something predefined (and explained in the input description) to confirm that the user wants to execute the action. @lolodomo You have a good point with your last argument, anyway I don’t want to decide here if Thing actions should do that. |
Yes, it has crossed my mind to do something like that. It's probably what I'll have to do, I was just explaining why I "wished" for a confirmation dialog. |
|
Just to elaborate, I agree that Actions aren't "ideal" for configuring devices. But, I don't think any of the available "means" are. I guess you could say that Channels is what is the intended way to do this, and for many things that is fine. But, when it comes to "one time setup" type of configuration options, I don't think they fit that well. The user will have to create and link an Item, just to be able to set it this one time. Also, I have situations where there are "more complex" configurations that require you to send e.g 5 parameters together when sending it to device, or the device will reject it. Doing that with Channels and Things quickly gets "complicated", trying to give the user feedback that it must configure and set all of them before it will work. The persisting of Channel and configuration values are also a problem when it comes to device configuration. It's not easy to know where the "change" originates, and if it indeed is a real change. It's also confusing to users if a new value seems to have been set, but in reality something went wrong but OH persisted the new value. I suggested on the forum that there should be a "new type" of configuration parameter, that isn't persisted. They would be populated with information from the device, and any changes would be persisted in the device. But, this suggestion was quickly shot down. Regardless, the binding has to work the way OH is now, now how it might be in the future, so for now, I think an Action is what fits best. |
Fixes #1745
Return config description parameters for the ActionInputs of ThingActions for the REST GET
/action/{thingUID}and REST GET/module-types endpoints.The config description parameters are only provided if all input parameters have a type that can be mapped to a config description parameter (String, boolean, Boolean, byte, Byte, short, Short, int, Integer, long, Long, float, Float, double, Double, Number, DecimalType,
QuantityType<?>, LocalDateTime, LocalDate, LocalTime, ZonedDateTime, Date, Instant and Duration).Enhance the REST POST
/actions/{thingUID}/{actionUid}endpoint (allows invoking Thing actions via REST) and theAnnotationActionHandler(allows invoking Thing actions from UI-rules) in order to be more flexible regarding the type of each provided argument value and to map the value to the expected data type. Number and string values will be accepted as inputs and the expected data type will be created from this value.This will be used by the UI's Thing page and rule editor to allow invoking Thing actions through the UI or adding them to UI-bases rules.
Signed-off-by: Laurent Garnier lg.hc@free.fr
Signed-off-by: Florian Hotze florianh_dev@icloud.com