Extending Blockly with new openHAB commands

If that was aimed at me, the simplest ‘quantity’ task is not I think any new block but added capability to existing.

Reproduce functionality of

if (myItem.state > 10 °C ) do xxx

which will require users to enter “10 °C” somehow.
And the execution code behind the scenes to deal with quantity Items and maths.

That’s it, that would cover more than half of the average users encounters with quantities.

There’s a lot of behind the scenes issues too - persistence functions will return Quantity values etc. which the underlying code has to deal with but won’t concern the blockly user.

Yes, I was asking you, thanks :slight_smile:

Understood, is that basically getting rid of metrics under the hood (=in the code) before comparing anything? What is the right algorithm to deal with that?

Not my decision, do what you think right.

In my view that would be a dirty kludge though :wink:
In the other rule systems, we can perform such as
if [Item state 20°F] > [constant 10 °C]
and it just works - “false” in this case, 20°F is colder than 10°C.

And similar maths
new var = [item state 20 feet] + [constant 15mm]
new var will be a quantity itself, 20.027 feet or whatever
Maths can involve both units and non-units
new var = [item state 20 feet] * 2 result quantity 40 feet
*new var = [item state 20 feet] / [ constant 2 feet] * result non-quantity 10
The framework takes care of behind the scenes conversions etc.
And of course we can postupdate or command Items with quantities e,g. thermostat setpoint. (That seems to be a good reason on its own not to just avoid this issue by discarding units)

As I understand it, this is pretty much automated because the “magic” is attached to the Quantity type Java object.
In other rule systems, we must take special action to create a Quantity when typing in “10°C” in order to get this stuff to work properly, e.g. new QuantityType("10 °C")
I guess in the point-n-click UI world, this would be as simple as detecting non-numeric input and making it a Quantity instead of a Number

I may be misleading you here, but I’d guess you would need to code to use Quantity type objects as an alternative to ‘ordinary’ number types you get from constants, states, commands, persistence returns etc.

There are some moves afoot that might impact this discussion.

  1. There is a push to make the JSScripting add-on be the “default” non-rules DSL language. Nashorn, the current JavaScript implementation is deprecated and will be gone when OH moves beyond Java 11 in a year or two. Yannick is already working to make the JavaScript code produced by Blockly compatible with JScripting (for the most part the changes are minor I think.

  2. One of the things that makes coding in non-Rules DSL languages so hard to use is the interface with OH is rather raw and riddled with type gotchas, even more so than Rules DSL. Therefore they all end up implementing a Helper Library. There is an active PR to include the Helper Library for JSScripting as part of the add-on. That means we don’t have to do any “clone from git and copy these files over there” type nonsense.

These are relevant to this discussion because sometime soon we might be in a position to add a good deal of the handling of quantity types and the like to the Helper Library that ships with the JSScripting addon which can then be leveraged by Blockly. So all that would need to be done in Blockly is to somehow allow the user to specify the units on a number block (or maybe there needs to be a new block) that converts to new QuantityType("<number> <unit>") like @rossko57 demonstrated. It will still be up to the user to keep track of when they are using the state of a Number with units or not and choose the right block but I think it will go a long way towards helping ease this pain faced by lots of rules developers.

Unfortunately, the list of units is frequently growing and there are combinations of units that are allowed with prefixes (e.g. k for kilo, m for mega, etc.). And there is no API to pull in the current list of supported units. Given that I don’t think even the docs manage to keep up with the list (note that the units are actually defined by an upstream third party library, not us I think) I would, at least for now, just make the units field of the quantity type block take a free text string to let the user enter arbitrary values for the units.

1 Like

The upstream library provides most of it but openhab core also defines missing units.

You little maniac! :wink: That has really cost me quite some headache because documentation is pretty rare about how to do that. I had to do a lot of trial and error but finally I even found a pretty simple solution. Now it looks like this

When choosing everything but “previous” the block looks like this:

and when choosing “previous” the block has changed to

so we only need one block. Hope you like that.

I do 
 this looks great! :+1:

A :beers: or l :+1: is appreciated :wink:

1 Like

I am pretty excited of this development, really makes everything less error prone, perhaps even for power users like me


One small comment: should we use the term “item state” instead of “item value”. To keep the terminology consistent.

1 Like

Let me ask my co product owner :relaxed: Rich, what do you think?

1 Like

I always vote for consistency where ever possible. Now that it’s been brought to our attention I would recommend the use of “item state” too. That way it’s consistent with the concepts docs and all the millions of posting that refer to Item states.

Can you please be exact where exactly you refer your statement to? Only this here (I already changed it)

Or anywhere else as well?

That cought my eye, yes.

Are there pictures of all widgets I could check?

Only at the beginning of the thread for the first release I did (I will always update when I do a release) and all the images in this thread unless you want to build your own version through the Merge Request here: Blockly enhancements 2 - scripts, ephemeris, persistence by stefan-hoehn · Pull Request #1212 · openhab/openhab-webui · GitHub

average state sounds a bit weird though, doesn’t it? After all, a ‘state’ is only valid at a certain point in time. If anything, IMHO it should be ‘average value of state’, ‘state deviation’, etc.
Or remove both ‘value’ and ‘state’? ‘Average’, ‘deviation’, ‘sum’ etc. look equally descriptive to my eye. Exception: ‘previous state’ needs to keep the ‘state’.

Where do you see “average state”? I only see values and the last one in the the drop-down has state.

Commenting based on the screenshots on the first post

  • send command "value" to item MyItem: replace "value" with "command" (directing reader to understand the meaning of command)


    Similarly for “post update”

  • get thing state: probably should be get thing status
    image

Comments on

  • item XX has changed since: would XX state has changed|updated since YY be better? Also, have the same past tense for changed and updated. I think this would emphasise the difference that we are talking about the state. That’s even more important now with these changes, as blockly commands deal with both item objects and the state values.

Comments on Extending Blockly with new openHAB commands - #176 by stefan.hoehn

  • How about: get state of item XX

@maniac103 broughts good points about the exact spelling of the persistence functions. I will add one more proposal for your consideration

  • get <average/delta/deviation> of item XX state since YY

Best,
Sami

First, Sami, I do appreciate that you take care, though keep in mind everybody like me is doing this whole work in our freetime, so I try to avoid double work (no offense, I just like to make that transparent), which is why I hesitate to do many changes afterwards - therefore I am posting everything I intend to implement here during the implementation before (I am aware you only jumped in now and have probably not seen that) Also every change needs to be reviewed later by someone else which is mostly Yannick who already has a big load of work to do (thx Yannick)

To make my life easier: Can you please edit your post above and add images of the blocks you want to have changed and even better scribble the changes what you want to have changed next to the block or on top of it. This avoids misunderstandings on my side.

Thank you
Stefan

PS:
“get <average/delta/deviation> of item XX state since YY” has already been amended by me, see above

1 Like

Hi Stefan, no offence taken, I do appreciate that.

Let me have a look if I can make it easier to pick up the proposed changes – makes it easier for others to comment as well .

I have updated the above post with pictures.

These are suggestions naturally and my feedback, and mostly bikeshedding. I leave it up to you if the changes make sense considering the effort involved etc.