Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thing page: Support invoking Thing actions & Viewing their output #2818

Merged
merged 3 commits into from
Oct 22, 2024

Conversation

florian-h05
Copy link
Contributor

@florian-h05 florian-h05 commented Oct 21, 2024

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.

image

This PR marks the cold related to the old config actions as deprecated, my wish is to get rid of those config actions and have Thing actions used instead.

…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>
@florian-h05 florian-h05 added enhancement New feature or request main ui Main UI labels Oct 21, 2024
@florian-h05 florian-h05 added this to the 4.3 milestone Oct 21, 2024
@florian-h05
Copy link
Contributor Author

@digitaldan WDYT?

Copy link

relativeci bot commented Oct 21, 2024

#2388 Bundle Size — 10.84MiB (+0.04%).

cd8abd9(current) vs 85c3c31 main#2386(baseline)

Warning

Bundle contains 2 duplicate packages – View duplicate packages

Bundle metrics  Change 2 changes
                 Current
#2388
     Baseline
#2386
No change  Initial JS 1.9MiB 1.9MiB
No change  Initial CSS 577.21KiB 577.21KiB
Change  Cache Invalidation 23.61% 22.77%
No change  Chunks 226 226
No change  Assets 249 249
Change  Modules 2923(+0.1%) 2920
No change  Duplicate Modules 149 149
No change  Duplicate Code 1.8% 1.8%
No change  Packages 96 96
No change  Duplicate Packages 2 2
Bundle size by type  Change 1 change Regression 1 regression
                 Current
#2388
     Baseline
#2386
Regression  JS 9.06MiB (+0.05%) 9.05MiB
No change  CSS 864.03KiB 864.03KiB
No change  Fonts 526.1KiB 526.1KiB
No change  Media 295.6KiB 295.6KiB
No change  IMG 140.74KiB 140.74KiB
No change  HTML 1.38KiB 1.38KiB
No change  Other 871B 871B

Bundle analysis reportBranch florian-h05:thing-actionsProject dashboard


Generated by RelativeCIDocumentationReport issue

@lolodomo
Copy link
Contributor

I assume you display the action output label.
To be not too much specific I would suggest you consider two output names: result and qrCode.
Then @digitaldan could adjust his code to return a map with entries "result" and "qrCode" and set proper labels to each output like "Manual pairing code" and " QR pairing code".
WDYT?

@florian-h05 florian-h05 marked this pull request as draft October 21, 2024 21:39
@florian-h05
Copy link
Contributor Author

Sounds good 👍
I will adjust the code tomorrow.

@lolodomo
Copy link
Contributor

lolodomo commented Oct 21, 2024

Do not forget to consider actions without any input.

I am bluffled, you did that so fast!

@lolodomo
Copy link
Contributor

I will have to check again all existing thing actions with output(s) to check that output "name" is properly defined.

Copy link
Member

@ghys ghys left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No notes.

If it's good for everybody, it's good for me.

@florian-h05
Copy link
Contributor Author

Do not forget to consider actions without any input.

Those are considered as well as actions without any output — in both cases a specific message is displayed instead of the inputs or output.

I am bluffled, you did that so fast!

The only thing missing at the moment is to render the outputs based on the output definition provided by the API — currently the pretty output rendering is hard-coded, but the raw output can be seen.

Signed-off-by: Florian Hotze <dev@florianhotze.com>
@florian-h05
Copy link
Contributor Author

The output rendering now renders all keys of the response object and takes the labels from the output definition.
If an output is named qrCode or has type qrCode, it is rendered as QR code.

@digitaldan For the matter binding, you can either define:

@ActionOutputs({ @ActionOutput(name = "qrPairingCode", label = "QR Pairing Code", type = "qrCode"), @ActionOutput(name = "manualPairingCode", label = "Manual Pairing Code", type = "java.lang.String") })

or

@ActionOutputs({ @ActionOutput(name = "qrCode", label = "QR Pairing Code", type = "java.lang.String"), @ActionOutput(name = "manualPairingCode", label = "Manual Pairing Code", type = "java.lang.String") })

Signed-off-by: Florian Hotze <dev@florianhotze.com>
@florian-h05 florian-h05 marked this pull request as ready for review October 22, 2024 15:09
@florian-h05
Copy link
Contributor Author

FYI it seems the ActionsOutput annotation is used wrong in many bindings given the core implementation of annotation parsing, I have created a doc PR to fix that: openhab/openhab-docs#2388

@lolodomo
Copy link
Contributor

lolodomo commented Oct 22, 2024

FYI it seems the ActionsOutput annotation is used wrong in many bindings given the core implementation of annotation parsing

We will have to check and fix all existing thing actions returning something.

Do we really need the @ActionsOutputs annotation when there is only one @ActionsOutput annotation?

@lolodomo
Copy link
Contributor

I find 0 trace of ActionOutputs in our code base.
Are you sure it is needed?
If true, that means we would have none thing actions with return properly defined!

@florian-h05
Copy link
Contributor Author

We will have to check and fix all existing thing actions returning something.

If I understand the current docs, the annotation is only to be added if you return a Map<String,Object>.
If you return a single value, you don’t need an annotation, some add-ons have it but it can be removed.

My correction to the docs is, that if you return a Map<…>, you need to annotate with ActionInputs for core to recognise the annotation — see the linked core code in my doc PR.

@florian-h05
Copy link
Contributor Author

@lolodomo But let us continue this discussion in openhab/openhab-docs#2388 as this is not related to the UI.

@florian-h05
Copy link
Contributor Author

@digitaldan I think I will merge this PR so you can use it in the latest snapshot, from my testing it works fine.

Please refer to #2818 (comment) for the required annotation for the Thing action.

@florian-h05 florian-h05 merged commit 5febf02 into openhab:main Oct 22, 2024
8 checks passed
@florian-h05 florian-h05 deleted the thing-actions branch October 22, 2024 21:26
@jlaur
Copy link
Contributor

jlaur commented Oct 23, 2024

@florian-h05, @lolodomo - I just updated to latest snapshot to have a look at Energi Data Service actions:

image

Can you help me assess:

  • What should now be fixed in the binding?
  • And are there any regressions to be considered for the UI?

The first issue is the method overloads, i.e. multiple actions with the same name. This cannot be seen in the list in the UI, so I think this needs to be improved in the UI, since there are no rules (at least to my knowledge) against method overloads for actions?

Next, I have this action:

https://github.com/openhab/openhab-addons/blob/a6bb5373ea21fabbc55b5319c5c1e45547ead3d5/bundles/org.openhab.binding.energidataservice/src/main/java/org/openhab/binding/energidataservice/internal/action/EnergiDataServiceActions.java#L82-L84

This results in:

2024-10-23 21:00:38.772 [ERROR] [dule.handler.AnnotationActionHandler] - The return type of action method 'public java.util.Map org.openhab.binding.energidataservice.internal.action.EnergiDataServiceActions.getPrices()' from module type 'energidataservice.getPrices' should be Map<String, Object>, because class java.time.Instant cannot be cast to class java.lang.String (java.time.Instant and java.lang.String are in module java.base of loader 'bootstrap')

I don't think there have been any rules against returning any particular types, like Map<Instant, BigDecimal> in this case, or maybe I missed something?

And of course, I now have to add the @ActionOutputs annotation for the actions that happens to return Map<String, Object> - see also openhab/openhab-docs#2388 (comment). This is no big deal, but to be honest, I didn't know this had a special meaning, I just used that in order to be able to provide multiple return values. 🙂

@florian-h05
Copy link
Contributor Author

The first issue is the method overloads, i.e. multiple actions with the same name. This cannot be seen in the list in the UI, so I think this needs to be improved in the UI, since there are no rules (at least to my knowledge) against method overloads for actions?

This cannot be improved in the UI as the UI only gets what core provides. For the Fronius Thing actions, I have overloads in place to allow the use of ZonedDateTime in addition to LocalTime for convenience of scripting, but I have only annotated the Thing actions with LocalTime so only those show up in the UI. The UI will only support pretty input for LocalTime, for ZonedDateTime there is text input only.

In your case, I would consider only annotating the overload that supports the most parameters. Set required = true in the annotation for required inputs and make the other inputs accept null. A different solution (but IMO less elegant) would be give different names & labels to the overloads in the annotation.

I don't think there have been any rules against returning any particular types, like Map<Instant, BigDecimal> in this case, or maybe I missed something?

FYI, the docs state:

If you return values, you do so by returning a Map<String,Object> and annotate the method itself with as many @ActionOutputs as you will return map entries.

But I strongly agree that it wouldn't make sense to only allow this return value as scripts can utilise other return values as well.

The problem with outputs that are not Map<String, Object> and are not primitives is, that they are difficult to handle for those interested in the output of the AnnotationAction I guess. Those "interested" are other modules in rules taking that as input (cannot be done yet I think) and the REST API, which needs to serialise to JSON.
I just don't know how we can make that work with the UI ...

@lolodomo
Copy link
Contributor

lolodomo commented Oct 24, 2024

I tested quickly yesterday evening and I encountered two difficulties.

First problem: decimals are limited to 2 decimals. If I try to fill 123,456, it is rejected. 123,45 is accepted. Is this restriction hardcoded in UI?

Second oroblem: it looks like the execution of action is failing for java primitive types if I don't fill a value while there is a default value displayed. Can you tell me what you do in that case ? Maybe I should set required to false in core to avoid this issue?

@florian-h05
Copy link
Contributor Author

Is this restriction hardcoded in UI?

Type of yes and no - it default to that, but can be modified by setting stepsize in the config description.

it looks like the execution of action is failing for java primitive types if I don't fill a value while there is a default value displayed. Can you tell me what you do in that case ? Maybe I should set required to false in core to avoid this issue?

The default value needs to be applied inside core. The UI has never applied the default, it is displaying it only.

@lolodomo
Copy link
Contributor

The UI has never applied the default, it is displaying it only.

Can you then at least block and do not call the action if one required parameters is not yet filled ?
Either by greying the execute link until all required parameters are filled or by checking first the required parameters when clicking the link and for example showing in red missing parameters?

@lolodomo
Copy link
Contributor

lolodomo commented Oct 25, 2024

Type of yes and no - it default to that, but can be modified by setting stepsize in the config description.

What value do you suggest ?
What does stepsize represent exactly? Is it the number of decimals?
9 decimals would probably cover most of usages, no?

@florian-h05
Copy link
Contributor Author

Can you then at least block and do not call the action if one required parameters is not yet filled ?

If a parameter is marked as required in the annotation, this is already done in the UI. If a required parameter is not filled, the UI displays an error and does not execute the action.
If ActionInputsHelper says there are default values for parameters, it is also responsible to apply them later!

What value do you suggest ?
What does stepsize represent exactly? Is it the number of decimals?
9 decimals would probably cover most of usages, no?

That’s difficult to say that generic. Stepsize is for example 0.01 and determines how the number changes when pressing arrow up or down buttons as well as what is rendered. So 9 decimals won’t be a good idea here … I’ll check if we can allow the user to manually enter any number of decimals.

@florian-h05
Copy link
Contributor Author

florian-h05 commented Oct 25, 2024

@lolodomo Wrt to decimal parameters:
We can make the UI allow any number of decimals, this requires the UI to pass the any value to the underlying HTML element. I will implement support for this by allowing any step size if the step of a config description parameter is set to 0, as 0 is no value one will normally use as stepsize. WDYT?

Refs #2832.

@lolodomo
Copy link
Contributor

If a parameter is marked as required in the annotation, this is already done in the UI. If a required parameter is not filled, the UI displays an error and does not execute the action.

Looks like it does not work like that, I mean the action is always called even if required parameters are not filled and it leads to an exception.
I will check again to be 100% sure.

@lolodomo
Copy link
Contributor

We can make the UI allow any number of decimals, this requires the UI to pass the any value to the underlying HTML element. I will implement support for this by allowing any step size if the step of a config description parameter is set to 0, as 0 is no value one will normally use as stepsize. WDYT?

Looks like a good idea.
Do we have to change core to set stepSize to 0?

@florian-h05
Copy link
Contributor Author

Looks like it does not work like that

I have tested that during development IIRC. If the config description says it’s required, the UI will display a warning if it’s missing.

Do we have to change core to set stepSize to 0?

This is already possible, we just have to set it to that in the ActionInputHelper and document it. I can do that.

@lolodomo
Copy link
Contributor

This is already possible, we just have to set it to that in the ActionInputHelper and document it. I can do that.

Ok, I let you do it. Do not forget to adjust unit tests.

@lolodomo
Copy link
Contributor

lolodomo commented Oct 25, 2024

Looks like it does not work like that

I have tested that during development IIRC. If the config description says it’s required, the UI will display a warning if it’s missing.

Unfortunately, it does not work.

Try with this action:

    @RuleAction(label = "test3", description = "Test action 3")
    public void testAction3(
            @ActionInput(name = "intParam", label = "int parameter", required = true, description = "Descr int parameter") int intParam) {
        logger.info("testAction3");
    }

Click on the action to open the popup

image

and just click on the Execute Action link. There is no warning, the action is run and it leads to this exception:

image

19:46:59.995 [ERROR] [dule.handler.AnnotationActionHandler] - Could not call method 'public void org.openhab.binding.astro.internal.action.AstroActions.testAction3(int)' from module type 'astro.testAction3'.
java.lang.IllegalArgumentException: null
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
	at org.openhab.core.automation.internal.module.handler.AnnotationActionHandler.execute(AnnotationActionHandler.java:119) ~[?:?]
	at org.openhab.core.automation.rest.internal.ThingActionsResource.executeThingAction(ThingActionsResource.java:248) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
	at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:3.6.2]
	at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.6.2]
	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.6.2]
	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.6.2]
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.6.2]
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[bundleFile:3.6.2]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) ~[bundleFile:3.6.2]
	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.6.2]
	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.6.2]
	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.6.2]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.6.2]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.6.2]
	at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.6.2]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:304) ~[bundleFile:3.6.2]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:217) ~[bundleFile:3.6.2]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:681) ~[bundleFile:?]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:279) ~[bundleFile:3.6.2]
	at org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet.service(OsgiInitializedServlet.java:102) ~[bundleFile:?]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1656) ~[bundleFile:9.4.54.v20240208]
	at org.ops4j.pax.web.service.spi.servlet.OsgiFilterChain.doFilter(OsgiFilterChain.java:113) ~[bundleFile:?]
	at org.ops4j.pax.web.service.jetty.internal.PaxWebServletHandler.doHandle(PaxWebServletHandler.java:334) ~[bundleFile:?]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:234) ~[bundleFile:9.4.54.v20240208]
	at org.ops4j.pax.web.service.jetty.internal.PrioritizedHandlerCollection.handle(PrioritizedHandlerCollection.java:96) ~[bundleFile:?]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487) ~[bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732) [bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479) [bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) [bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) [bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) [bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) [bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) [bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) [bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) [bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) [bundleFile:9.4.54.v20240208]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) [bundleFile:9.4.54.v20240208]
	at java.lang.Thread.run(Thread.java:833) [?:?]

IMHO, the UI should detect that some required parameters are not filled and should show a warning and certainly not call the action.

Now if I enter 1 in the input field and click the Execute Action link, then it works.

The result is the same with this action, that is not a surprise but I wanted to test it also:

    @RuleAction(label = "test4", description = "Test action 4")
    public void testAction4(
            @ActionInput(name = "intParam", label = "int parameter", description = "Descr int parameter") int intParam) {
        logger.info("testAction4");
    }

@lolodomo
Copy link
Contributor

lolodomo commented Oct 25, 2024

An improvement would be to sort the actions by their label when displaying them.

image

Maybe it should be done by the REST API ? With a new parameter ?

And maybe you could also display the action description ? Maybe below the action label in smaller font ? I let you think to something consistent with what we have in Main UI elsewhere.

@lolodomo
Copy link
Contributor

lolodomo commented Oct 25, 2024

I also tried with this action with an unsupported input type to see how you handle that:

    @RuleAction(label = "test5", description = "Test action 5")
    public void testAction5(
            @ActionInput(name = "listParam", label = "List parameter", description = "Descr List parameter") List<String> listParam) {
        logger.info("testAction5");
    }

The action is listed but nothing happens when you click on it. I like that you display it. Maybe the text color could be different to distinguish supported and unsupported actions ? Or something else to distinguish like a "supported" badge for example in front of the action ?

florian-h05 added a commit to florian-h05/openhab-webui that referenced this pull request Oct 25, 2024
…tions

Follow-up for openhab#2818.

Signed-off-by: Florian Hotze <dev@florianhotze.com>
@florian-h05
Copy link
Contributor Author

florian-h05 commented Oct 25, 2024

Unfortunately, it does not work.

I don't think that is the UI's fault. The config description parameter tells the UI there is a default value of 0. It has never been the case with the config sheet that the UI applies that default to what it sends to the server, instead it is the job of the server to apply the default he announces himself. This is not the case here, this has to be fixed inside openHAB Core.

An improvement would be to sort the actions by their label when displaying them.
And maybe you could also display the action description ?

Sure 👍

The action is listed but nothing happens when you click on it. I like that you display it.

It should not be displayed IMO as the UI isn't able to use it - I will fix that and hide it instead. The user will notice there are unsupported actions when checking the log.

#2834 implements these improvements.

openhab/openhab-core#4424 implements the step size 0 param and also applies the default values for primitives as announced by the ActionInputsHelper when creating config descriptions.

florian-h05 added a commit that referenced this pull request Oct 25, 2024
…ons (#2834)

Follow-up for #2818.

Signed-off-by: Florian Hotze <dev@florianhotze.com>
@lolodomo
Copy link
Contributor

lolodomo commented Oct 26, 2024

@florian-h05 : what will happen for an input parameter being marked as required and with no default (not a java primitive type) ? Will the action be called anyway, meaning the "required" property is in practice ignored by UI ?

I am going to test again all your last changes but I am sure we are tending to something very good.

@florian-h05
Copy link
Contributor Author

what will happen for an input parameter being marked as required and with no default (not a java primitive type) ?

In that case the UI won’t be too happy and will not call the action:
IMG_4911

@lolodomo
Copy link
Contributor

Excellent. Will test that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request main ui Main UI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for invoking Thing actions from the Thing details page
4 participants