Doh! I must be tired. Of course it needs to be or. Can’t believe I missed that.
That assumes that the function called by ‘MyTimer’ will always be the same. You couldn’t have an if statement and schedule a different function to be called in different circumstances under the same Timer name.
Of course you can just use a different Timer name in that case but it might force the user to writing more complicated code than they otherwise would have to.
Yes that would be great. I can’t accept any more features but bugfixes are still ok.
you mean make another one? To avoid Git snafus for single-file edits you can use the GitHub edit file feature (Sign in to GitHub · GitHub).
Sign-off in the commit message is still required, get it from a previous commit.
Sorry for the confusion. I hadn’t seen you have merged the PR. Thanks. Will hopefully be only minor things to fix this issue above.
I would create a new PR for that fix.
New features will then come with a new PR and as you mentioned lately I will target them with small PRs.
I can confirm it works now as expected. This is how I tested it (for the curious, I used two different trigger items and I distinguish those with the new block that retrieves event information, i.e. in this case the event item’s name):
can you do me a favor and merge this last PR. It is a small extension to allow retrieving rules parameters within a script that was written with blocklies. This concludes the blockly “Run & Process” section.
We have now released this major update of openhab blocklies as part of openhab 3.2.0. It now contains almost 50 specialised openHAB blocks. Thanks to all who helped by contributing their ideas, reviews and feedback.
Thank you Stefan for your great work on the blockly blocks.
Are there any plans to integrate binding actions like sending a telegram notification or a push notification through the myopenhab service?
I work with telegram notifications and this is the last point I need to change to the blockly editor.
Check the Blockly section of the Marketplace. A number of these Actions have already been built and published there. And as @stefan.hoehn pointed out, there is a really good tutorial for writing your own.
Unfortunately Collections is probably too generic. Do you know if it’s a List, Map, or Set? I think List and Set are treated the same but a Map is different.
It’s almost certainly a List or Set though given what is being returned. In my Nashorn rules I tended to just keep them as Java and used Java’s Stream API to do the filters, forEach, map and reduce. It also works with for(var I in list) .
There is a way to convert too a JS array and back though. I think it’s Java.from(list) which will convert the Java List or Set to a JS array.
which isn’t really surprising but of course OH doesn’t understand #ff0000.
I wonder if we should make the send command block smarter by detecting the color-# (note that I am not able to recognize that there is a color block - I can only parse the output) and convert it into “255,0,0”.
The other option would be to provide an OH-Block that converts the normal color block to a OH Color.
I don’t have anything that uses color in my setup so I wouldn’t have ever noticed that.
They both have their pluses and minuses. The former means that users can manually send an RGB string in other ways, not just the color block. However if there is ever a case (and there will be cases) where someone needs to use a # for any other reason that use case will break.
The latter would be a bit more transparent to the user though and it should avoid breaking anything so if that’s possible I’d use that approach.