Extending Blockly with new openHAB commands

Yes, Christian, you can do it as follows - I just did the following and it works fine for me:

The reason is that the timer requires a number-block. The only way to trick it is to provide the value through a value which is “neutral” and is allowed to plug in as a replacement for the number type.

1 Like

Hi Rich and Yannick (@ysc),

I have worked on the date comparisons which seem to be work pretty well now. By design it didn’t want to go for complex blocks that allow individual input for all datetime fields like day, month, year, hour, minute, second … but generating them from a String is much more convenient.

So from now on you can create a date-block from three different formats

  • yyyy-MM-dd (only format that was allowed to be provided)
  • yyyy-MM-dd HH:mm:ss (new)
  • yyyy-MM-dd HH:mm:ss +HH:mm (new)

Therefore I have renamed the label of the block from “date” to “datetime” which is still compatible with blocks that have already been used (-> backward-compatible).

I have also added the comparison block and with the help of the above we can do a lot of things which I all tried out




btw, I have also moved all date functions out of ephemeris and persistence into its own block:

This should conclude the comparison part.

Datetime offsets

Again I pursued a more textual approach for adding and subtracting dates and times to keep the handling of the blocks concise and dense. This allows adding and substracting years, months, days, hours, minutes and seconds from a given date

Of course this also works with a different way of providing the date:

I am actually thinking about providing a now-block with any offset …

And it is a bit unfortunate that the today-block has been introduced for ephemeris which actually is not a zonedDateTime but just an offset of 0. I would rather rename that label to something else and also add a real today block being a zonedDateTime. Any opinions on that?

1 Like

Yannick, I have a question:

I was always looking for a way how we could provide a direct link from the blockly toolbox to the blockly documentation (the blockly reference which will soon go to the openhab documentation and the tutorial that Rich is writing). The problem is that it is usually more or less coincidence that people stumble over that and even know that it actually does exist. Therefore it would be nice if we could provide that as an entry directly into the toolbox menu.

Someone else had a similar idea about that. Can you have a look at that and think about it if that would be an approach that we could implement and would lead to many more people discovering our documentation right away:

Don’t be misguided by the title of the entry. It is not really only about adding the SVG but also providing info and a URL in the toolbox itself:

https://groups.google.com/g/blockly/c/HjY_KHA8680

What about getting the date time from a DateTime Item and comparing it with one of these datetime blocks? That’s the only thing I see that might be missing. I’m not sure the best way to go about that. The toString() version of a datetime is ISO8601 which is different from what the current datetime block accepts.

One can directly pull the ZonedDateTime from the state with items['MyDateTimeItem'].getZonedDateTime() but a whole new block would need to be exposed and I’m not sure if there is enough type information to expose that.

So you are looking for a block that retrieves the datetime (from a state) and converts it into the format that can applied to the blocks I proposed? If that is what you want it should be rather easy to be added

To avoid the XY Problem, the ultimate goal is to be able to do stuff like see if the state of a DateTime Item is before/after one of these “datetime” blocks.

I presume you’re both aware of this Blockly Add-On in the marketplace, which seems to offer some similar functionality to what is currently being discussed?

How does this all work considering one of the Marketplace rules is

Publishing add-ons that compete directly with an official add-on is not allowed; by “compete” we mean “forks” or alternative implementations offering similar functionality.

Don’t get me wrong: I’d love the core openHAB blocks to have these features implemented, but also wouldn’t want anyone to be dissuaded from publishing ‘missing’ blocks if sometime later their contribution gets pulled (if, indeed, that will actually happen - I suspect not, but probably best to work out what does happen first!)

1 Like

I don’t know that we have a policy set for this.

In a similar note, we don’t want Marketplace postings to limit what can be added to core either.

2 Likes

Yes, I I know it and I verymappreciated. I was rather coming from a more condensed block approach and some things are a bit easier to implement (I think) if you have full control over the blocks during implementation in pure blockly code (I am generating functions that covers some logic of the blocks to allow simplifying the logic). I wouldn’t say that my design is better but rather different.

In your case you were earlier than these blocks I just provided, so don’t very. I think both are good alternatives. Don’t even thing about removing it :hugs:

Anyways, it is good to have an option in the marketplace, I just thought it is such an important functionality that it should be available in the core and I already had mostly done but hadn’t have the time to publish earlier and also didn’t want to make the last pull request too big for the review.

Next up for me is not writing blocks but really move the huge reference documentation to the core openhab documentation.

Having said that if you feel there are important blocks missing that should become part of the core eventually, let me know.

Oh, they’re not mine - I’m not that clever! Kudo goes to @deibich.

It’d probably help if we have a policy that covers this sort of case, or an extra exemption in the Marketplace rules for this scenario.

And I repeat - I’d much rather see the functionality in the core, so don’t stop!

1 Like

A very good point, I’ll check if zdt-states can be easily compared to each easily. This of course must be the case.

This really does pose the question of what is “built-in material” and what should be delegated to block libraries (with the “out-of-band” possibilities they offer).

To me it deals with both subject domain and complexity of the subject matter.

For instance, I wouldn’t support blocks that do administrative operations - like alter items or things - in the built-in library, because I believe rules in essence are for acting on items, or eventually things (through things actions), but not modifying the configuration.
But if you do want to modify the configuration with Blockly scripts, then you can, but you should install this “admin” block library which will allow you to do that.

On the other hand, while date & time manipulation is desired in rules in general, it is such a complex subject matter that we could perhaps have “go-to” block libraries in the marketplace (the brilliant Date and Time is proof that we can solve such problems with block libraries) for those subject matters. It comes from the observation that we would struggle to get it exhaustively “right” no matter the effort, and libraries would allow a more organic progress.

This is interesting, but I’d say we’ll have to get stable links to reference docs before we do that.
“Stable” docs can be in this forum too but it has to be clarified.

We have a primitive system of “canonical URLs” which is used in some places around the UI - for instance when you click the “Learn more about profiles” link:

See for instance https://openhab.org/link/profiles

This allows to change them if the docs get reorganized without modifying the UI code.

I’m not sure the complexity of the problem should be the deciding factor.

In my mind, if it’s something that most average user is going to need to at some point it should probably go into the core. Testing whether now+X seconds is before/after the state of a DateTime Item is a pretty common task in all sorts of rules. Something so fundamental feels like it should be in the core.

I don’t think that the core blocks need to exhaustively cover every single possible date time operation. But I would expect it to cover maybe the top five or so most common ones. In my experience, comparing now to a DateTimeType is way more common of an operation than most any other date time operation short of comparing a variable saved last time the rule ran to now.

But instead of a core or Marketplace decision maybe it’s more appropriate to set up some sort of Marketplace to core pipeline. The Marketplace posting looks pretty complete and functional. How challenging would it be to migrate that into core (with @deibich’s permission and hopefully participation of course)?

1 Like

If you both feel that this is a better approach, then I’ll stop mine and I am sure, Yannick could migrate that one into the core blocks.

I agree.

Not sure if you saw it but I am currently in the process of moving the blockly reference to openhab docs (I am already discussing a few things with @Confectrician how to do it best). I have already forked the repo and moved over the intro and some minor parts. It will take another few (hopefully not too many) weeks though, until I have done that as I am also refining the images, so everything looks very pretty.
The final blockly-docs link is the one that I would then want to put the toolbox only when I am done with that, e.g.

 /link/blocklib    /docs/configuration/rules-blockly-main.html

So, I am on it.

Would be nice to see more blocks for date and time in core. Please feel free to use the blocks as you like.

Actually not too hard, the logic to translate block libraries into actual block categories is already there. It does not have the same level of complexity as actual code, and the performance is probably subpar, but it could work still. Same for widgets, we could have additional sources for widgets than what the user creates or imports from the marketplace in Developer Tools > Widgets.
The question is where we make the split between built-in blocks defined in actual JS, built-in block libraries, and “ad-hoc” imported libraries. I don’t have a definitive answer.

I don’t know where the divider is either. But I do firmly believe that at least the most common time operations should be core blocks. We don’t necessarily need to cover them all, but being able to compare the state of a DateTime Item with now plus or minus some time delta would be among those. Being able to post update a date time derived from now plus or minus some time delta would also be among those.

I can see everything else like Duration operations and stuff like that being left to a library or the inline script block.

I’ve not used Blockly enough yet to discover any other major missing piece but I don’t think there are any after this. I suspect anything else will be mostly focused on dealing with refinements like Units of Measurement and stuff like that.

I agree, the datetime blocks are really important I would definitely vote for adding them to the core. At least in my rules I often use it and the datetime block we should also do is a way to add to dates and times similar what I had in mind (adding or subtracting something in one block because otherwise I think it becomes pretty quickly confusing and convoluted)