This thread is meant to discuss technical and design details of new openHAB Blocks.
Original post:
to whom it may concern and in particular @Kai and @ysc.
Kai and Yannick,
as discussed on Saturday I am planning to step in to develop Blockly further within openhab. I would in particular do the commands first I am missing myself which would be:
say (text)
play (sounds)
schedule timers
From then on I’d be open to tackle other stuff as well. The itch already got me started to scratch it and I have actually already started implementing “say” which already works and in the midst of doing a timer…
I would really like to see the Blockly editor extended with even more features. I can’t write dsl rules so Blockly is the way to go for me. Most of my old (copy and paste) OH2.5 rules are now converted into Blockly and I love it.
So thank you for developing it even more.
I would like to mention one thing about the „say“ feature. Afaik no one is working at the integration for the OH3 MainUI as an audiosink.
Maybe it would be possible to think about in your discussion about the further development to integrate/combine this feature with the new Blockly commands.
I think this would be a really nice enhancement to write a Blockly script which is able to use the say command via the MainUI.
As I said @dirkdirk this thread is not supposed to be a wishlist for blockly (and even not with regards of implementing new features in OH3) but rather how to implement missing “blocklies” and how to do it best.
Thank you very much @stefan.hoehn for stepping up.
As you might have seen there’s already a WIP PR: https://github.com/openhab/openhab-webui/pull/875
but it’s been stale for some time now - partly my fault.
Maybe you could get in touch with the author to collaborate or take over and get it done.
Also make sure to get the feedback of people with experience in rule development to make sure the code is correct!
Ok, I need to see what has been done there. Do you by chance know who “bigbasec” (user at GitHub) is here in the forum, so we can join forces?
Also, if anyone who is experienced in writing good rule code and who would like to help me generating the right code with the blocklies, please get in touch with me.
is there any detailed detailed description of the intentional functionality? I really feel a bit hesitant to take over someones PR without even know what the intention is. I left a comment to the developer to ask what the intention / description of the functionality is and if it should be merged as such.
btw, shouldn’t every PR have a comprehensive description? I usually do this myself but I am never able to find that description somewhere. Any hint where this can be found is appreciated.
Yannick, do you mind reviewing the code so the PR can be merged and I can start from there?
On the other hand, by looking through the PR there is a LOT of new blocks provided that should all be tested first and checked (as you mentioned above) that they generate the correct rules code…Have you done that already, Yannick?
No I haven’t done that - I remember testing it a while ago, though, and found things that I wasn’t sure of (I’m not an expert in the tricks to know wrt. rules).
If the author doesn’t respond then I guess you could open a new PR, perhaps taking some inspiration from his code and the discussion at [Blockly] Add missing openHAB calls and features · Issue #810 · openhab/openhab-webui · GitHub.
810 is really nicely put together by @rlkoshak (as usual )
It seems that the PR contains some good ideas that it would be a shame if I neglected it. I think we / I should appreciate what has already been done here. More and more I understand the blockly topic, so I really want to integrate what he has done here, though I think he hasn’t been active sind Feb (maybe because the PR wasn’t taken care of). As bigbasec is currently not answering (though I haven’t waited maybe long enough)…
So, what is the best way to “take over” or work or at least test the PR and make sure everything is fine so it can be merged:
What would you recommend is the best practice to get the stuff understood and tested locally on my system, so we can finally merge the PR and get on from that?
Just clone HIS repo and work with that one?
… but what if I need to make changes…
I would need some git/PR guidance how to approach this best.
Thanks
Stefan
PS: Rich: From then on I hope I can slowly start working on your ideas over the next months …
I’ll be happy to review and test where able. I don’t have a build environment though so will need a binary to test with or instructions on how to build and run the new code.
Could you run npm / node locally because that is “all” you need locally to run the UI and redirect to your openhab server using your own OH3 installation. I could guide you how to set this up (actually it is pretty straight forward). And then I am happy to provide you with the UI code to run for testing.
Another easier option is that I show you the blocklies we will provide and you review if the design makes sense and then additionally I would provide the code it generates and you could just use the rule code that is generated and test that locally if it is sound code that really runs and is best practice.
Yes, I can run node and npm. I’ve other stuff that needs it too (e.g. MqttExplorer) so that’s not too hard (with some basic instructions of course ).
I’m also pretty good at reviewing code like that so just looking at the blocks and the code they generate might be enough. The gotcha is finding and managing the unexpected interactions between blocks.
I have now downloaded what the original developer whom I unfortunately can’t get in touch with, has already done. It is a lot and it is a pity we haven’t used it yet (no offense Yannick! - I know how time you have provided ). So either the original developer will appear again ( ) or I will use it as much as possible to provide everything eventually (though the main kudos of course go to him).
I post some images below, so we have an overview. As he has already provided SO MANY new blocks (which is great), I think we need to approach them one by one or group by group to make sure we do not break anything.
I think what has to be done is the following:
I need to move over the changes to a “fork” to my repo and apply all those changes, maybe step by step and the provide individual new PRs
COMPATIBILITY / REGRESSION TESTING: The biggest challenge I see is that I / we have to make sure it does not break old rules. This might not be a problem as I haven’t investigated the code yet regarding that but this is my biggest worry.
He has put the blocks into sub groups which is a good idea but I am not sure if that has an impact. (see (2))
I already noticed that some of the blocks generate code that throw errors in the UI - this may be due to changes over the last months as I am sure that by the time he did that he would have seen that. So I need to fix these first before testing.
All code being generated needs to be reviewed, so it follows best practice and (your) patterns.
As you can see, there is so much that I would propose, we should prioritise, implement, check, test and release in steps and not everything. What do you think?
@stefan.hoehn, the PR is marked as draft by the author, hence it wasn’t yet ever meant to be merged - and @ysc nonetheless already provided a lot of timely feedback to the author, who unfortunately fell quiet since April.
I think it is therefore perfectly fine, if you take over the code and create a new PR from it, to get things moving again. The code of the PR is provided under the EPL license, so also from a legal perspective, there is no issue at all with using it and building upon it. Just make sure to mention him in the commit message with an “Also-by: …” (or directly take over his commits into your PR).
If the original author comes back again, I am pretty sure that both of you are willing to drive the implementation forward together.
I have already started working on it. Some of blocks need some upfront work in OH3 (like all the multimedia stuff) which might be frustrating for people to use eventually. This is not due to the blocks but due the complexity that comes along with it.
Therefore, to make sure that Blockly really provides some easy entry of OH3 users I would like to provide some comprehensive help pages for that. Do we already have help pages already on blockly? (I wasn’t able to find it - maybe my fault) ?
I would actually propose to add a new section of pages below:
My Intent would be provide one page per Group (see above) where each block would be described how to be used and give guidance for the usage.
Rich: I know you are an openHAB master on this - so you are more than welcome to jump in here.
@dirkdirk Sorry, I didn’t mean to be offensive. I hadn’t expected that there was already so much existing. It is not totally clear to me what your requirement is but what I can tell you is that with the blocklies that are work in progress and which I have taken over to finalize (see images above), it will be possible to send audio files to and say text at a given audio device. It is actually one of the first things I am working on.
@stefan.hoehn There is no need to apologize, I just wanted to give some input of the functionality for the say command in combination with the OH3 MainUI. This is not what the thread was made for, so your answer was justified.
For clarification:
At the moment you can use different devices as an audiosink e.g. like Sonos or Onkyo audio devices.
But for my understanding you can also use a webaudio device (tablet, smartphone etc.) for the playback. At the moment only HABpanel supports this.
OH3 is able to control and setup (nearly) everything via the MainUI, but you can’t use the MainUI as a webaudio device to say text or play MP3’s.
So maybe this implementation needs to be also done in blockly (just a guess) and this is why I wanted to mention this.
Whoops… sorry Dirk, I see you already posted a link to github issue, sorry.
there is actually an open issue on github asking for the new main UI to be able to be used as webaudio audiosink like PaperUI was in v2. Doesn’t seem to have gotten much attention lately
Here is a link
Please also take note of the ongoing discussion at https://github.com/openhab/openhab-core/issues/2433 regarding the fact that we have two JS scripting engines available, and their API to access OH objects are currently incompatible with one another.
(I for one would advocate for the GraalVM JS add-on to be standardized as the default JS script engine, since Nashorn is due to be removed anyways, and it would be foolish to keep capitalizing on it, especially if it would prevent from upgrading supported JVM versions.)
But until we reach a decisive conclusion on that matter it will remain a major hurdle for generating dependable JS code from Blockly blocks.
Ok, I currently test it against the rules that says ECMAscript in the UI. Not sure what I can do more, though I will read the thread thoroughly.
If we generate scripts that are incompatible, the worst thing would be that if we update the engine, we also change the code generation at the same time and then the would only habe to opened once to regenerate the code basically (not really optimal but at least a solution)
)
).
) or I will use it as much as possible to provide everything eventually (though the main kudos of course go to him).
