Don’t miss what I said last though. No matter what we do now, when we switch to JSScripting we can have 1 without the extra complicated code.
So wait and see might be better and go with clearer names for the blocks.
If we wait and see and do nothing for now, then we have the problem why the whole thread was started, haven’t we? Honestly, I was trying to help and now the discussion has cost me much more time than everything else which frustrates me. Maybe I should rollback the PR and someone else takes over. 
I didn’t say do nothing. That’s not really acceptable in my mind because it doesn’t solve this problem.
I’m proposing we solve it but changing the names of the blocks to be more clear what’s going on.
When we move to JSScripting the whole problem goes away I think because if how the helper library already implements items. So even if we implement 1 or 2 more, it will have to change in the not to distant future anyway. Since it’s controversial, maybe it’s better to wait a little bit and revisit when we do move to JSScripting.
To state again, I’m not suggesting doing nothing. But I am suggesting we not spend too much time and stress over something we know will change soon anyway.
1 Like
We are actually discussing one line of code which looks a bit more complicated that allows the blocks to be much more resilient. Instead of doing that we would rename the block? I am against that but if the community thinks this is the better way if doing it, then please @ysc or anyone else take over and finalize the fix because it probably doesn’t make sense to explain me what should be done and then I do it but rather the ones who have the intended idea in mind finalize it. Thanks.
I would actually propose to take out the group handling fix discussed here from the mentioned PR because it blocks the other 2 fixes and if we ever come to a conclusion how to handle groups we can simply do one separate PR for that.
1 Like
I’ve not had time to reply fully here but I want to explain my position a bit further.
I completely agree that it’s just one line of code and it really does make a much better experience for the end user. Were I in charge of but hesitate to accept it as is.
However, we know that sometime soon we will be moving Blockly to JSScripting with openhab-js and when that happens then all of these blocks will need to be revisited and perhaps reimplemented.
Based on my own experience with JSScripting I’ve recently learned, I think this whole problem will simply go away on its own when that happens.
Given that, I just don’t think it’s worth fighting over this one line of code.
I do think it’s worth implementing the block to support but the item name and Item Object. I did think that the benefits to the end users fat out weights the cost of the slightly more complicated code.
I just don’t think it’s worth fighting for right now. Not when I’m a year or so from now (or how ever long it takes for JSScripting to become a default) the whole issue will need to be readdressed.
I’ve fought for so much in OH and lost so many battles I’ve learned to be patient and to pick my battles. This isn’t the ditch I want to die in. One the end I think it will all come out right now matter what we decide here.
So I’m ok with doing the bare minimum too address the op issue until a more permanent solution comes in JSScripting.
Ok, then let me ask maybe one closing thing: I have not heard a concrete alternative solution for the following problem from above:
Would you like me to document that as a solution in the blockly reference on how to officially use “get members of group”?
PS: Just for the record: I have asked the change I did to be taken out of the pull request. So nothing will happen regarding that topic and it will stay as is for the time being.
For me it’s ok. But I don’t know if that’s a good solution.
When will the switch to JSScripting take place?
@ysc Yannick I realize your stance on making the generated code clean so as to provide good example code for people trying to learn but…
I would like to add my (meaningless) vote that we consider making this small exception to that rational
I just bumped into this issue with a similar solution-in-mind as Christian, I wanted to check the battery status of my blinds. Thanks for the workarround!
I’m not sure if it’s clear from the discussion above. In the loop, this works:
But this doesn’t work:
On another note, I’m quite an experienced programmer but I’m currently converting my rules as much as possible to blockly. I don’t really care how the generated code looks like and actually expect to find it ‘sterile’, ‘heartless’, ‘more complicated then necessary’, in a way I would not write it. It might turn out to be useful later for some snippets. But then more in the general sense ‘how do I need to get from the output of this to the input of that’.
The biggest reason I’m converting my rules to blockly is to get my wife and kids onboard as well. A big thanks to you all for making this possible!
3 Likes
Thanks for providing this solution. I actually found this thread as a “Your topic is similar to …” suggestion as I was creating my own post about it.
I’m using openHAB3.3M2 on this installation, so whatever solutions are discussed above, they haven’t been implemented as of that release.
I have really enjoyed Blockly. I’m in the slow process of converting Rules I wrote in files using Rules DSL. Many of them were altered copy and pastes from the community from my early days when I had no idea what I was doing. I realize “if it ain’t broke, don’t fix it”, but Blockly makes things more intuitive and easier to improve or modfity.
This was my first experience where Blocky was not intuitive - where something that looked like it should work flat out didn’t. I’m glad I found this work around, which solved my problem.
(The only other frustration I have had with Blockly has been a few times where a discarded fragment ended up hidden behind the block, and I got some strange error messages. Sometimes the fragments are really well hidden.)
Thanks to all of you who have done so much to provide this new, powerful tool.
1 Like
I can explain the difference between the blocks to why this might be neither straight forward nor intuitive to understand (I should mention that possibly in the blockly docs)
This block already existed for a very long time. It has always a block output of type String
When I implemented this block it is kind of smart. It detects depending of what attribute you select the different output type - though state is String equal to the block above.
So it should behave differently nor generate a different code when choosing state.
What I don’t understand is what you mean with
In the loop, this works… but this doesn’t work:
can you give an example where the two blocks behave differently along with the code it creates, so I can investigate it?
If you use both blocks wit Items they behave the same, but if you use them with a variable they are different.
itemRegistry.getItem('MyItem').getState();
itemRegistry.getItem('MyItem').getState();
var i_list = Java.from(itemRegistry.getItem('MyItem').members);
for (var i_index in i_list) {
i = i_list[i_index];
logger.info(itemRegistry.getItem(i).getState());
logger.info(i.getState());
}
The first block is checking the itemRegistry for “i” but the variable is not stored in the itemRegistry
The second block is, as you said “smart”, and is just checking “i” for it’s State.
This is the log
2022-03-13 17:24:55.084 [WARN ] [e.automation.internal.RuleEngineImpl] - Fail to execute action: 2
java.lang.RuntimeException: org.openhab.core.items.ItemNotFoundException: Item 'Z9F_State (Type=ContactItem, State=CLOSED, Label=Z09, Category=Contact, Tags=[OpenState, Z-OG-F], Groups=[Z9F, Windows])' could not be found in the item registry
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:531) ~[jdk.scripting.nashorn:?]
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:456) ~[jdk.scripting.nashorn:?]
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:413) ~[jdk.scripting.nashorn:?]
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:409) ~[jdk.scripting.nashorn:?]
at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:162) ~[jdk.scripting.nashorn:?]
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264) ~[java.scripting:?]
at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.lambda$0(ScriptActionHandler.java:62) ~[?:?]
at java.util.Optional.ifPresent(Optional.java:183) ~[?:?]
at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.execute(ScriptActionHandler.java:59) ~[?:?]
at org.openhab.core.automation.internal.RuleEngineImpl.executeActions(RuleEngineImpl.java:1181) ~[?:?]
at org.openhab.core.automation.internal.RuleEngineImpl.runNow(RuleEngineImpl.java:1033) ~[?:?]
at org.openhab.core.automation.internal.RuleEngineImpl.runNow(RuleEngineImpl.java:1049) ~[?:?]
at org.openhab.core.automation.rest.internal.RuleResource.runNow(RuleResource.java:327) ~[?:?]
at jdk.internal.reflect.GeneratedMethodAccessor337.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:3.4.5]
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.4.5]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.4.5]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.4.5]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.4.5]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[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.openhab.core.items.ItemNotFoundException: Item 'Z9F_State (Type=ContactItem, State=CLOSED, Label=Z09, Category=Contact, Tags=[OpenState, Z-OG-F], Groups=[Z9F, Windows])' could not be found in the item registry
at org.openhab.core.internal.items.ItemRegistryImpl.getItem(ItemRegistryImpl.java:86) ~[?:?]
at jdk.nashorn.internal.scripts.Script$Recompilation$7831$\^eval\_$cu1$restOf/0x85686ab8.:program(<eval>:9) ~[?:?]
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655) ~[jdk.scripting.nashorn:?]
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513) ~[jdk.scripting.nashorn:?]
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527) ~[jdk.scripting.nashorn:?]
... 67 more
That’s what i figured out.
1 Like
It is the same with this block
If you connect a variable you get a warning, it is the same warning as i posted above.
this workaround is working
1 Like
I just experienced the same on openHAB 3.4.2. Thanks for the workaround.