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.
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?
In my view that would be a dirty kludge though
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.
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.
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.
You little maniac! 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:
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.
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â.
get thing state: probably should be get thing status
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.
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
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.