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).
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
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?
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:
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?
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!)
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
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.
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:
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)?
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.
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)
is there a way to build the openhab-docs locally, so I can check how my my writing would look like before I commit and push it.
I looked at your block post about vuepress and also the ruby files in the repo but I wasn’'t sure what has to be run (I checked the README, the files in .vuepress and also tried to figure out the build process online but couldn’t). Sorry if overlooked something.
UPDATE (SOLVED):
I installed vuepress via npm install vuepress
I then ran npm run build-preview
It runs fine and creates all the files in the vuepress folder.
There is a downside with that method though because as it runs “ruby prepare-docs.rb --delete-sources” it deletes a lot of files in the git repos which appears to become lots of deleted file. The alternative would be to do the following two step individually
npm run prepare-docs
npm run build-only
which doesn’t delete the files and does render the html but in the end ends with an error like
error Error rendering /addons/actions.html: false
undefined
error Error rendering /addons/bindings.html: false
undefined
error Error rendering /addons/io.html: false
undefined
error Error rendering /addons/transformations.html: false
undefined
error Error rendering /addons/persistence.html: false
undefined
error Error rendering /addons/voices.html: false
undefined
TypeError: Cannot read property 'label' of undefined
at Proxy.render (addons/actions.md?547e:1:72156)
at VueComponent.Vue._render (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue/dist/vue.runtime.common.dev.js:3559:22)
at resolve (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue-server-renderer/build.dev.js:8444:27)
at waitForServerPrefetch (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue-server-renderer/build.dev.js:8316:3)
at renderComponentInner (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue-server-renderer/build.dev.js:8455:3)
at renderComponent (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue-server-renderer/build.dev.js:8412:5)
at renderNode (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue-server-renderer/build.dev.js:8323:5)
at resolve (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue-server-renderer/build.dev.js:8450:5)
at waitForServerPrefetch (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue-server-renderer/build.dev.js:8316:3)
at renderComponentInner (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue-server-renderer/build.dev.js:8455:3)
at renderComponent (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue-server-renderer/build.dev.js:8412:5)
at RenderContext.renderNode (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue-server-renderer/build.dev.js:8323:5)
at RenderContext.next (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue-server-renderer/build.dev.js:2611:23)
at cachedWrite (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue-server-renderer/build.dev.js:2464:9)
at renderStringNode$1 (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue-server-renderer/build.dev.js:8530:5)
at RenderContext.renderNode (/Users/xxxx.xxxx/Development/checkout/openhab-docs/node_modules/vue-server-renderer/build.dev.js:8321:5)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! openhab-docs@3.0.0 build-only: `vuepress build .`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the openhab-docs@3.0.0 build-only script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
Can you explain that?
Wouldn’t it be a good idea to add that to the README.md?
