openHAB 3.3 Milestone discussion

I would personally like to use the new full “minimal” concept as is now active, I like it and have around 200 items. Stripping away parts of the path would make this not work (for me) very well as I have similar duplicated setups with the same upper hierarchy. A good way to support Google Home / Alexa integration would still be needed.

I fully support the opt-in though, as it’s clear that this does not work for everyone.

getting this when changing UI to Location tab:

2022-04-16 22:56:26.054 [WARN ] [ache.cxf.phase.PhaseInterceptorChain] - Interceptor for {http://internal.id.core.openhab.org/}UUIDResource has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.
	at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:67) ~[bundleFile:3.4.5]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.5]
	at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:90) ~[bundleFile:3.4.5]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:217) ~[bundleFile:3.4.5]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) ~[bundleFile:3.1.0]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273) ~[bundleFile:3.4.5]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550) ~[bundleFile:9.4.43.v20210629]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) ~[bundleFile:?]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1434) ~[bundleFile:9.4.43.v20210629]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:294) ~[bundleFile:?]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1349) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.43.v20210629]
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:82) ~[bundleFile:?]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:386) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) [bundleFile:9.4.43.v20210629]
	at java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: org.eclipse.jetty.io.EofException
	at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:279) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:422) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:277) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:381) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpConnection$SendCallback.process(HttpConnection.java:829) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:223) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:550) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:915) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:987) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpOutput.channelWrite(HttpOutput.java:285) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpOutput.close(HttpOutput.java:638) ~[bundleFile:9.4.43.v20210629]
	at org.apache.cxf.transport.http.AbstractHTTPDestination$WrappedOutputStream.close(AbstractHTTPDestination.java:791) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.http.AbstractHTTPDestination$BackChannelConduit.close(AbstractHTTPDestination.java:722) ~[bundleFile:3.4.5]
	at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63) ~[bundleFile:3.4.5]
	... 48 more
Caused by: java.io.IOException: Broken pipe
	at sun.nio.ch.FileDispatcherImpl.writev0(Native Method) ~[?:?]
	at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:51) ~[?:?]
	at sun.nio.ch.IOUtil.write(IOUtil.java:182) ~[?:?]
	at sun.nio.ch.IOUtil.write(IOUtil.java:130) ~[?:?]
	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:493) ~[?:?]
	at java.nio.channels.SocketChannel.write(SocketChannel.java:507) ~[?:?]
	at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:273) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:422) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:277) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:381) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpConnection$SendCallback.process(HttpConnection.java:829) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:223) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:550) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:915) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:987) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpOutput.channelWrite(HttpOutput.java:285) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpOutput.close(HttpOutput.java:638) ~[bundleFile:9.4.43.v20210629]
	at org.apache.cxf.transport.http.AbstractHTTPDestination$WrappedOutputStream.close(AbstractHTTPDestination.java:791) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.http.AbstractHTTPDestination$BackChannelConduit.close(AbstractHTTPDestination.java:722) ~[bundleFile:3.4.5]
	at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63) ~[bundleFile:3.4.5]
	... 48 more
2022-04-16 22:56:26.345 [WARN ] [ache.cxf.phase.PhaseInterceptorChain] - Interceptor for {http://internal.id.core.openhab.org/}UUIDResource has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: XML_WRITE_EXC
	at org.apache.cxf.jaxrs.interceptor.JAXRSDefaultFaultOutInterceptor.handleMessage(JAXRSDefaultFaultOutInterceptor.java:106) ~[bundleFile:3.4.5]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.5]
	at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:112) ~[bundleFile:3.4.5]
	at org.apache.cxf.phase.PhaseInterceptorChain.wrapExceptionAsFault(PhaseInterceptorChain.java:374) ~[bundleFile:3.4.5]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:332) ~[bundleFile:3.4.5]
	at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:90) ~[bundleFile:3.4.5]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:217) ~[bundleFile:3.4.5]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) ~[bundleFile:3.1.0]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273) ~[bundleFile:3.4.5]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550) ~[bundleFile:9.4.43.v20210629]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) ~[bundleFile:?]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1434) ~[bundleFile:9.4.43.v20210629]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:294) ~[bundleFile:?]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1349) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.43.v20210629]
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:82) ~[bundleFile:?]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:386) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) [bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) [bundleFile:9.4.43.v20210629]
	at java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: com.ctc.wstx.exc.WstxIOException: Closed
	at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:262) ~[?:?]
	at org.apache.cxf.jaxrs.interceptor.JAXRSDefaultFaultOutInterceptor.handleMessage(JAXRSDefaultFaultOutInterceptor.java:104) ~[bundleFile:3.4.5]
	... 51 more
Caused by: org.eclipse.jetty.io.EofException: Closed
	at org.eclipse.jetty.server.HttpOutput.checkWritable(HttpOutput.java:769) ~[bundleFile:9.4.43.v20210629]
	at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:793) ~[bundleFile:9.4.43.v20210629]
	at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:51) ~[bundleFile:3.4.5]
	at com.ctc.wstx.sw.EncodingXmlWriter.flushBuffer(EncodingXmlWriter.java:742) ~[?:?]
	at com.ctc.wstx.sw.EncodingXmlWriter.flush(EncodingXmlWriter.java:176) ~[?:?]
	at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:260) ~[?:?]
	at org.apache.cxf.jaxrs.interceptor.JAXRSDefaultFaultOutInterceptor.handleMessage(JAXRSDefaultFaultOutInterceptor.java:104) ~[bundleFile:3.4.5]
	... 51 more

Hello,

Regarding the UI topic:

I would suggest a opt-out for it, as I really like it. It’s definitely better for most users and others have the possibility to get the current behaviour.

However, some things that need to be fixed:

-Trendings don’t work right with multiple items having the same Label (and show the item name in the header by the way, which also should not be)

-item overview: I would suggest making the item name the big one, and the hierarchy/label underneath. It does not make sense to have 20 temperatures here

-maybe a separate voice label or sth (don’t use voice but was mentioned here before)

I think that would make everyone happy together with the opt out.

I upgraded from 3.3M2 to 3.3M3
Everything was just fine in M2… I just have a compulsion to live on the bleeding edge.
After the upgrade (using apt in ubuntu), 3 of the 13 zwave devices would not initialize.
They were 3 of 4 Leviton Fan controllers.
The errors all were

HANDLER_CONFIGURATION_PENDING

{config_7_1=The value -1 does not match allowed parameter options. Allowed options are
[ParameterOption [value=“0”, label=“LED Off”], ParameterOption [value=“254”, label=“Status Mode”],
ParameterOption [value=“255”, label=“Locator Mode”]]}

On one of the failing devices, in the UI, I updated parameter 7, and it came online.
The other 2, the updated value appeared to save but would not and the devices remained in the above error state

I uploaded a gist of my zwave.log file.

Any suggestions to avoid redoing my zwave things?

The Z-Wave databade probably needs an update/fix.
Did ypu open an issue?

There are already some similar problems reported but no solution so far.

Not sure if this is a M3 problem, but…
I cannot get the old or new state, nor the command of an event in JS 2021 scripting.

Neither with Command triggers nor item changed triggers. The only thing I can get is
event.itemname

All others are undefined, like
event.state/newstate/previousstate/command

I trey to get the state myself with items.getitem().state, but at the command time the state is not always right yet.

Any suggestions? Is this a milestone problem?

Well, I finally just went in and edited org.openhab.core.thing.Thing.json file.

I found the 2 Things and changed the parameter 7 value for each.

I restarted OH and everything was hunky dory.

@chris
Would you guess this is a zwave binding issue or a OH core issue?

The property names are different with jsscripting. Try these

event.itemName,
event.itemState,
event.oldItemState,

Source Some JS Scripting UI Rules Examples - #2 by rlkoshak

I also find it hard to find the canonical documentation on this…

1 Like

Hello @ssalonen @openhabber,

in file-based JS Scripting the event has these properties:

For UI-based however it is really different, I would recommend using utils.dumpObject(event) to analyse it.

This is due to JS Scripting is able to format the event data in file-based but not in UI-based.

I think it will probably take some time until this docs get merged into the JS Scripting docs.

@ssalonen thank you!
For commands, it is event.itemCommand, if anyone is wondering.

I really searched for that. Maybe the docs should at least mention them?
It’s not mentioned at
GitHub - openhab/openhab-js: openHAB Javascript Library (only file-based, as you said)
Home - Documentation
JavaScript Scripting - Automation | openHAB

In addition, the autocorrect on the UI editor predicts the wrong elements.

Also the dump does not seem that helpful.


utils.dumpObject(event)
console.log(event.itemState)
console.log(event.oldItemState)
console.log(event.itemCommand)

For an item change:

2022-04-24 11:05:43.254 [INFO ] [org.openhab.automation.script.utils ] - Dumping object...

2022-04-24 11:05:43.257 [INFO ] [org.openhab.automation.script.utils ] - typeof obj = object

2022-04-24 11:05:43.259 [INFO ] [org.openhab.automation.script.utils ] - Java.isJavaObject(obj) = true

2022-04-24 11:05:43.260 [INFO ] [org.openhab.automation.script.utils ] - Java.isType(obj) = false

2022-04-24 11:05:43.263 [INFO ] [org.openhab.automation.script.utils ] - Java.typeName(obj.class) = org.openhab.core.items.events.ItemStateChangedEvent

2022-04-24 11:05:43.267 [INFO ] [org.openhab.automation.script.utils ] - getAllPropertyNames(obj) = [object Array]

2022-04-24 11:05:43.270 [INFO ] [nhab.automation.script.ui.b81e419f18] - Automatik

2022-04-24 11:05:43.271 [INFO ] [nhab.automation.script.ui.b81e419f18] - Aus

2022-04-24 11:05:43.273 [INFO ] [nhab.automation.script.ui.b81e419f18] - undefined


For an item command:

2022-04-24 11:07:27.843 [INFO ] [org.openhab.automation.script.utils ] - Dumping object...

2022-04-24 11:07:27.846 [INFO ] [org.openhab.automation.script.utils ] - typeof obj = object

2022-04-24 11:07:27.852 [INFO ] [org.openhab.automation.script.utils ] - Java.isJavaObject(obj) = true

2022-04-24 11:07:27.853 [INFO ] [org.openhab.automation.script.utils ] - Java.isType(obj) = false

2022-04-24 11:07:27.863 [INFO ] [org.openhab.automation.script.utils ] - Java.typeName(obj.class) = org.openhab.core.items.events.ItemCommandEvent

2022-04-24 11:07:27.874 [INFO ] [org.openhab.automation.script.utils ] - getAllPropertyNames(obj) = [object Array]

2022-04-24 11:07:27.878 [INFO ] [nhab.automation.script.ui.b81e419f18] - undefined

2022-04-24 11:07:27.879 [INFO ] [nhab.automation.script.ui.b81e419f18] - undefined

2022-04-24 11:07:27.887 [INFO ] [nhab.automation.script.ui.b81e419f18] - Automatik


Hello @openhabber,

For commands, it is event.itemCommand, if anyone is wondering.

You mean UI-based, right?

I really searched for that. Maybe the docs should at least mention them?

Maybe, but I think would be better if it event is the same in UI-based and file-based. In file-based, the event is formatted by this function: openhab-js/rules/rules.js at 394fb9959ce92f57766d495fb98c298276d78615 · openhab/openhab-js · GitHub
If I am able to apply this in UI-based, it would be the same - I will take a look at it later.

In addition, the autocorrect on the UI editor predicts the wrong elements.

Yes, I have also noticed this, that’s one of the things that have to be changed in the codecompletion.

Also the dump does not seem that helpful.

Oh sorry, I forgot that dumpObject() had an issue that was recently solved but no new version was published yet.
On my system (with the fixed dumpObject()), it looks like the following for file-based ItemCommandTrigger:

2022-04-24 12:12:43.326 [INFO ] [org.openhab.automation.script.utils ] - Dumping object...

2022-04-24 12:12:43.329 [INFO ] [org.openhab.automation.script.utils ] -   typeof obj = object

2022-04-24 12:12:43.332 [INFO ] [org.openhab.automation.script.utils ] -   Java.isJavaObject(obj) = false

2022-04-24 12:12:43.335 [INFO ] [org.openhab.automation.script.utils ] -   Java.isType(obj) = false

2022-04-24 12:12:43.340 [INFO ] [org.openhab.automation.script.utils ] -   getOwnPropertyNames(obj) = eventType,triggerType,receivedCommand,oldState,newState,itemName,module

2022-04-24 12:12:43.353 [INFO ] [org.openhab.automation.script.utils ] -   getAllPropertyNames(obj) = eventType,triggerType,receivedCommand,oldState,newState,itemName,module,__proto__,constructor,hasOwnProperty,isPrototypeOf,propertyIsEnumerable,toLocaleString,toString,valueOf,__defineGetter__,__defineSetter__,__lookupGetter__,__lookupSetter__

@florian-h05
Thanks for your fast reply.
Yes, indeed, in UI-Based rules.

I also noticed that event.itemCommand for example is of type “Object”, and a comparison to its value as a String fails.

This is false:
event.itemCommand === “Kino”
event.itemCommand == “Kino”

This is true:
String(event.itemCommand) === “Kino”
String(event.itemCommand) == “Kino”

If this is not okay to discuss here, please tell me, and we can move somewhere else.

1 Like

@openhabber @florian-h05 I introduced PR to improve the docs and explain the gotchas: Docs: document UI rules event and @runtime by ssalonen · Pull Request #110 · openhab/openhab-js · GitHub

EDIT: Good example that one with String items, it’s worse than I thought… I added that one to documentation.

EDIT2: I also found out that the autocomplete is incorrectly suggesting entries, causing further confusion. Ticket created: Autocomplete incorrect with ECMAScript 2021+ · Issue #1358 · openhab/openhab-webui · GitHub

2 Likes

oh, i see. You even described the conversion I was having problems with. :slight_smile:

One more problem:

event.itemState and so on seem to always be strings.
So I get something like “21.5 °C” or “220 kcal”.
When accessing items with items.getitem, I am using .rawState instead of state for that reason.

Do I overlook something, or what is the correct way to get a number out of an event?

In DSL you could just say event.newState as Number.

Not if you are dealing with units of measurement. Even in Rules DSL you have to deal with that differently, ultimately calling .floatValue() or converting the value you are doing math with to a QuantityType with proper units too.

And you can do the same in JS Scripting too.

If it’s just a plain old number, JS itself is smart enough to recognize when you have the String representation of a number and do the conversion to number for you.

The vast majority of the time, the string version of the state will work exactly as you need it to work. The only two exceptions are quantity types and datetime types.

Is it because I have state descriptions?
My temperatures should only have one decimal, so I have %.1f °C in place, allthough being tagged as number: temperature. I will try this out later. Thank you.

Just to not leave this hanging out, it’s because you have the Item defined as a Number:Temperature. If you need help beyond this, I recommend opening a new thread to keep this thread on topic.

I have a beginners Issue which I suppose is not related to 3.3, thus I posted a dedicated discussion thread here.
However I am using the latest image from docker hub (3.3.0-snapshot-alpine from Today (April 27th)) which for the sake of completeness I post this here as well, just in case it could be a version-related Issue after all.