Blockly Reference

Actually I’d be fine even if the subpages weren’t shown as long as I can have subpages that explain the details of the different blocks sections. Otherwise I think the whole article would become much to long for one page. So I think we are good so far. :+1:

I just read through the docs in the first post and a few things raised a few questions and suggestion ideas, which I want to mention here :wink: :

  • What’s the point of the ‘get item’ block, where’s the difference to the ‘item’ block?
  • Why is ‘get state of item’ a separate block, given one can also get the state with the ‘get item name’ block (which may be better named as ‘get item property’)?
  • Isn’t ‘thread sleep’ a bit too technical given the target audience? I would rather suggest naming it ‘Wait for … ms’ or ‘Delay by … ms’
  • What’s the difference between ‘timer is active’ and ‘timer is running’? Should the former be ‘timer is scheduled’?
  • The notifications category wraps the cloud messages, I assume? If so, is the info/warning/… selection the same as the ‘severity’ in the API? If so, consider making it a free-form field?

See Actions | openHAB

Is active means the timer has gone off and the function is running “is running” will be true. “is active” will return true if the Timer is scheduled to run whether or not it’s expired and id actively executing the function.

Thanks to you feedback, Danny.

Did you read this thread Extending Blockly with new openhab commands ? I think most of it has been discussed there. No offense here (maybe you weren’t aware of it) but it would have been better to discuss that before we were actually releasing it. Changing it later could break people’s rules that are using it already or at least confuse them.

Anyway

  • What’s the point of the ‘get item’ block, where’s the difference to the ‘item’ block?
    • the item block is only a wrapper for an item name which is actually used by the get item, which returns the whole item which can be used as follows

  • Why is ‘get state of item’ a separate block, given one can also get the state with the ‘get item name’ block (which may be better named as ‘get item property’)?
    • this was already available and we cannot remove it. The one I depicted above was added later by me and is more generic
  • Isn’t ‘thread sleep’ a bit too technical given the target audience? I would rather suggest naming it ‘Wait for … ms’ or ‘Delay by … ms’
    • yes, true, I was thinking about that lately but it was already released. If it was only a renaming of the label then that could be easily changed but may confuse people. Rich, what do you think?
  • What’s the difference between ‘timer is active’ and ‘timer is running’? Should the former be ‘timer is scheduled’?
    • please see the help URL of the block that links to the exact description of the above. It is actually a difference.
  • The notifications category wraps the cloud messages, I assume? If so, is the info/warning/… selection the same as the ‘severity’ in the API? If so, consider making it a free-form field?
    • The class that is used is this one and the explanation is here. So you might be right but now after having it released it would break the block-“API”, I would say.

Any additional thoughts, @rlkoshak

Don’t hesitate to join the discussion in the main thread while I am about to implement new blocks as it is better to jump in at that point. :+1:

I think as long as it doesn’t break people’s existing Blockly scripts it makes sense to be consistent and change the wording of the block. I like “wait for” personally as it implies a little more forcefully that the rule will block for that amount of time and there might be less confusion about this and Timers.

Making it free form should break anything. The class indicates that it can be an arbitrary String. The hard coded severities are Strings too so this shouldn’t break anything.

The enhancements are included in a milestone release only so far right? I think it would be ok to make changes now, that is the point of development releases IMHO.

I think Yannick told Rich that if the code behind a block changed, the next time the code is saved, it overwrites the whole thing and uses the new code.

yeah, it probably will do that but again, this is a development version meant for folks who want to help test and should expect changes

True, I don’t worry about generated code changes but about changes in the appearance - also if the block changes in its ‘layout’ it is not compatible anymore.

I only talked above the ones that are in the PR. Milestone releases, at least to me, are perceived to be out in the wild and should not be broken imho.

I followed it loosely, but didn’t catch all of the details, so sorry for being late here - but I’m of the same opinion as @Andrew_Rowe here: as long as API is only in milestone releases it’s subject to changes.

Ugh, that’s confusing. Why doesn’t the green block return the item right away? Too late to change I guess…

Okay. Maybe it should be mentioned in the docs that this block is legacy only/deprecated and one should use the new block. I guess we can’t hide the old block from the selection list without also removing it from existing rule designs, can we?

I know there’s a difference, I’m just not sure the target audience of those blocks will understand it, that’s why I (merely) suggested a wording change :wink: Sorry for being unclear here.

I can answer this part perhaps. In JavaScript, Jython and I’m sure lots of other languages, it’s the Item’s name that gets used the most. Want to send a command to an Item? You need the Item’s name, not the actual Item.

events.sendCommand("MyItem", "ON");

Want to get the state of an Item?

items["MyItem"]

In general practice, one pretty much only needs the actual Item when they want something like it’s labels, tags, members or the like.

That I think is the root of why there are the two different blocks.

Fair enough, but what’s the output of the block? My understanding is that the ‘item’ block just returns the string passed into it, and the ‘get item’ block essentially returns items[input] … is that right?

The “Item block” returns the name of the Item as a String. For example if I choose the Item “Foo” the “Item block” will literally be in the JavaScript

'Foo';

The “get Item” block returns the actual Item Object. Again, using “Foo” the “get Item” block translates to

itemRegistry.getItem('Foo');

items['Foo'] returns the state of the Item Foo. It is the same as itemRegistry.getItem('Foo').getState(). The “get stateof Item” block is smart enough to handle either the “get Item” block as well as the “Item” block. However, I’m sure there are situations where you will only want the name of the Item, such as when logging and such. There are other times when you might need to have the whole Item Object.

Note that the “items and things” section is complete and done now.
(also note that I found two issues, I will fix soon. Also the name of “thing state” was wrong as it is more correct a “thing status”)

cc @MichaelBrunner

PS: note that the issues I have found and mentioned above have been fixed by now and a PR is waiting to be merged for the next releases.

1 Like

Hi all,

I’ve just found Notfications section here.
Maybe it would be nice to add the preconditions to the description.
What I found so far is that for Push the OpenHab app is required. (And the username there has to be the same as the one for myopenhab.org).

For the mail I still stuck. Is it correct that i need to install the Mail binding?
I did so and added the Smtp server as thing, but I do not get any error message in the logs.
Did I do something wrong?

Thanks
/Franz

Hi Franz,

yes, this is what I am planning to do. Note that the blockly reference is currently work in progress and a lot of work. I try my best to getting that finished soon.

Your comment is not only related to notifications, this is even more relevant to voice for example where the Google TTS is not easy to setup.

I will quickly add a note to that above and later provide a more comprehensive info to it.

Regarding mail, yes, that is right, as far as I remember that is true and I will explain that later as well.

1 Like

I have added a lot of information to the “items and things” section. Do you mind rereading and check if it is clear and comprehensive enough?

hi Stefan,

thanks first of all for making blocky so powerfull in OH 3.2.0 !
It’s really great i can do nearly all operations now in Blocky!

@stefan.hoehn : Thanks for adding the references. Just a very smal feedback here, it’s still not clear to me how the Messages are sent. I’ve added the Mail Binding, added an SMTP server it is offline.
Somehow I lack the relation between SMTP Server and the Block.

The Binding says i need to create an Action (get the smtp)

val mailActions = getActions("mail","mail:smtp:samplesmtp")
val success = mailActions.sendMail("mail@example.com", "Test subject", "This is the mail content.")

but I do not find this in Blocky.

Have a good day
/Franz

Hi,

is there a way to check if a rule is started by a trigger event or manually?

I’ve the problem that when i’m testing rules (manually) which uses the “contextual info” block the following error occurs:

2021-12-30 14:18:48.042 [ERROR] [e.script.internal.handler.ScriptActionHandler] - Script execution of rule with UID '6337df794f' failed: ReferenceError: "event" is not defined in <eval> at line number 24

the generated script looks like this:

...
if (event.itemName == bathShutterItemName) {
...

I need to correct myself. The notification block does NOT send mails to any mail. See my new documentation above.

At the moment I have no good idea here because I wouldn’t know how to handle that easily or detect it. Do you know of any way detected this if it was a ECMAScript without blocklies?
@rlkoshak I think we didn’t think of that. Do you have a clever idea how we should / could handle this conveniently? We could provide a block like >“event.xxxx” is defined< ?

1 Like

In this case i would check if the “event”-Property exists and do some stuff (or not). That means a “WasEventTriggeredBlock” is required.

Maybe you can do that with this.hasOwnProperty(‘event’)

(Sorry for pointing this out - maybe I’m too much of a programmer in real life)