I have several Blockly rules that use the “in text” block to gather information from the “contextual info” “triggering item name” block. They worked just fine in openHAB 3.
After migrating to openHAB 4, I find that the “contextual info” block has been rejected by the text block. If I had a “create text” block, it then works.
4:
Since there is no easy way to see orphan blocks, in a complex rule one might easily miss this.
Show the code behind the not working version and the working version. Triggering Item Name is a String so it should have worked unchanged. This might be a regression.
When I get home and can fire up the 3.4 on my spare Pi I will post what you have requested.
I’m seeing the similar behavior with the “distance between” GIS block. The block will no longer accept the “textual info” block “new state of item” for a Location item.
In 3.4.4, I didn’t need the “create text with” block. I could directly use the “contextual info/triggering item name”
openHAB 3.4.4
code
if (event.itemName.indexOf('Kathleen') + 1 > 0) {
events.sendCommand('KathleeniCloudConnectedSwitch', 'ON');
openHAB 4.0
if (String(event.itemName).indexOf('Kathleen') + 1 > 0) {
items.getItem('KathleeniCloudConnectedSwitch').sendCommand('ON');
The OH 4 version of the code is with or without the “create text with” block? I’m guessing it’s with and you said above that works, right?
What code is generated without the “create text with” block?
The OH 4 is with the “create text with” block. It won’t allow me to attach the “contextual info” block to the “in text” block w/o first attaching an additional block, the “create text with” block.
Whether this is good or bad, I don’t know. I just know that it is different.
@stefan.hoehn, this sounds like a data typing issue. The contextual info block can return all sorts of different data types so I’m guessing that the block doesn’t know the itemName is a String and that’s why it won’t let you link it to a plug that expects a String.
Does that track? Can anything be done?
I finally found the cause
I have lately changed the block types to be more accurate.
Actually the triggering item name is not the item string but the item type (internally called “oh_item” as type). So the triggering item name is a oh_item and therefore not just a string. The change was needed in other places to detect the oh_item better to evaluate and generate the right code where people would not care to either add the real oh_itemtype (as returned by getItem) or the oh_item (when picking an item). This allows me in OH4 to be much more forgiving on other places.
Unfortunately the in text block is blockly standard, otherwise I could make it more forgiving to oh_item as text. So, yes, that seems to be breaking (which I definitely tried to avoid as much as possible over the last months!) but it think it is worth it here.
At least I would agree that I should mention it in the docs more clearly which types are returned. In almost all other places I did document the return type which I forgot here.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.
