so finally today I took a look at it and the reason is more than simple: We have actually addeda check on that block so that it only allows Strings to be connected. Even though this makes sure it is fool-proof but in most cases it does work with everything else as JavaScript is pretty clever to convert a Number to a String or many blocks return a String anyway (even if it was complex object) like here
So in a nutshell: I would recommend taking out the check as it would make a lot quite a bit simpler when the user wanted to log it (instead of artificially adding a " " or apply it to a variable first).
Sounds reasonable but one wonders why the check was put in there in the first place? There might be some reason the check is needed that I don’t know. Or it might have been a default and we don’t need it.-
I checked it in the repo and it was originally added by Yannick as the 2nd commit of the blocklies, probably because a log expects a string. Anyways, I have worked with it intensively over the last days and works pretty well and it so much more convenient. Hence, I’ll remove the check with the next PR.
A new major addition to Blockly has been contributed to the lastest version 3.3M6. It contains the following
Auto-Expansion of openHAB section
From now on the openHAB section is automatically expanded (on non-mobile devices)
A new Help Button
From now on, each openHAB section contains a “button” that sends you directly to the documentation page of that section by clicking on the grey “Help” button. For example this Help button
I hope that this will allow learning the blocks even faster because more people will know that there is comprehensive documentation without having to search for it (thanks Tweini from the blockly community for helping me here)
Comprehensive Extension to Datetime
Based on @deibich 's block library many new blocks are now available in openHABs Blockly and have been made even more flexible (note that it is not completely the same). Here is a visual representation of the blocks available:
(thanks Tweini from the blockly community for helping me on some of the really tricky things here)
Logging
The log block has become more flexible. Previously you were only able to attach string blocks. Now you can attach any block returning a value and it tries to do its best to print out the blocks return value.
CRLF block
In some cases it is necessary to insert a line feed into a string. This can now be achieved via the CRLF block like in the following example (thanks to @Confectrician for requesting it). It can be found in the text section:
What type is waste? Is it an item that returns a datetime? The block will not accept it as it only accepts a block of type datetime. Use the a datetime block with an item-getState like so:
Hi . not sure if that is the right place to ask this question…
I really start liking blocky, as it now can do nearly everthing i was scripting before and is - for me - easier readable (specialy month or years later).
However i have the following challenge: I want to iterate trough a group and if an item is a groupitem iterate through that again…thats how i tried:
Ok, I found out what the root cause is: The condition block seems to make sure that the block type of both blocks you add have to be the same. If you add either one (dateblock or number block) of each it stays there.
As variables are neutral type you can use the following workaround (which isn’t nice but at least works for the time being):
As a quick side note as most people aren’t aware of it: the colors actually ought to express the return type and as you can see the colors are different here. With the fix I have now implemented (it is done already) it will then become blue expressing a number type.
Also the additional values have been now provided for the following block:
There is a group called lights, which contains several subgroups which themselves contains items.
I intentionally used variables here to make the “code” more explicit.
Just to be clear, and because I promised you a GIF:
The days between now and waste on the left is made from the Marketplace (@deibich) block, using the now block from the same library. This creates the code:
var deibich_blockly_ChronoUnit = Java.type('java.time.temporal.ChronoUnit');
var deibich_blockly_ZonedDateTime = Java.type('java.time.ZonedDateTime');
deibich_blockly_ChronoUnit.DAYS.between(deibich_blockly_ZonedDateTime.now(), waste);
The days between now and waste on the right is made from the openHAB (3.3M6) block, using the now block from the same openHAB Dates & Times library. This creates the code:
var chronoUnit = Java.type("java.time.temporal.ChronoUnit");
var zdt = Java.type("java.time.ZonedDateTime");
chronoUnit.DAYS.between((zdt.now()),waste);
Save for the variable names, the code looks identical to me.
The block from the Marketplace is able to be inserted into the comparison block.
The block from openHAB is not able to be inserted into the comparison block
So I’m still not quite sure why it’s not working. Is the Marketplace block identifying as a number, and the openHAB one isn’t?
Before I fixed my block it had the type “datetime” which is not equal to “number” on the right hand side. When I say type this is something that is defined in the code by the developer of the block (which is me). You can define what the output type of that block is and you can define what type is allowed as input for “holes” in a block. The library version is defined as “Number” (i double checked it), mine was mistakenly defined as datetime. The equals block makes sure that the left and the right hole get the same type (the blue “0” is a number type block), so it worked with the library block but not with the core block. This is why it it didn’t match the type in the comparison and it prevented it to connect.
However, I have fixed that and will provide the fix today (note that it needs to be reviewed and merged first before the fixes will become available)
