Blockly: cannot split() text string from String Item

[hafniumzinc (T)]

Click here for system info

runtimeInfo:
  version: 3.2.0
  buildString: Release Build
locale: en-GB
systemInfo:
  configFolder: /etc/openhab
  userdataFolder: /var/lib/openhab
  logFolder: /var/log/openhab
  javaVersion: 11.0.13
  javaVendor: Azul Systems, Inc.
  javaVendorVersion: Zulu11.52+13-CA
  osName: Linux
  osVersion: 5.11.22-5-pve
  osArchitecture: amd64
  availableProcessors: 2
  freeMemory: 61696984
  totalMemory: 299892736
bindings:
  - astro
  - gpstracker
  - http
  - mqtt
  - network

I have the following Item defined via the UI:

{
  "link": "http://openhab.lan/rest/items/strSolarData",
  "state": "{2021-12-29=569, 2021-12-30=469}",
  "stateDescription": {
    "readOnly": true,
    "options": []
  },
  "editable": true,
  "type": "String",
  "name": "strSolarData",
  "label": "Solar data",
  "category": "",
  "tags": [],
  "groupNames": []
}

It is linked to an HTTP Binding Channel, and receives a JSON string. Currently, the Item has the following value:

{2021-12-29=569, 2021-12-30=469}

I have been trying to use Blockly to split this string at the comma. Below is my first attempt:

Code

var i;

var logger = Java.type('org.slf4j.LoggerFactory').getLogger('org.openhab.rule.' + ctx.ruleUID);


var i_list = itemRegistry.getItem('strSolarData').getState().split(',');
for (var i_index in i_list) {
  i = i_list[i_index];
  logger.warn(i);
}

Unfortunately, I get the following error in the log when clicking Run Now:

[ERROR] [.internal.handler.ScriptActionHandler] - Script execution of rule with UID '6caf048c18' failed: TypeError: (itemRegistry.getItem("strSolarData").getState()).split is not a function in <eval> at line number 6

OK, so there’s a TypeError. Strange, because it’s a String Item, and I’m trying to perform a function (split) which is usually performed on Strings. Maybe the get state of item block isn’t returning a String? To test this, I modified the code to force the variable to store itself as a String by deliberately appending “”:

Code

var item_state, i;

var logger = Java.type('org.slf4j.LoggerFactory').getLogger('org.openhab.rule.' + ctx.ruleUID);


item_state = itemRegistry.getItem('strSolarData').getState();
item_state += '';
var i_list = item_state.split(',');
for (var i_index in i_list) {
  i = i_list[i_index];
  logger.warn(i);
}

Success! I get the following in the log:

15:47:31.970 [WARN ] [org.openhab.rule.6caf048c18          ] - {2021-12-29=569
15:47:31.992 [WARN ] [org.openhab.rule.6caf048c18          ] -  2021-12-30=469}

According to the current reference documentation the get state of item block should be returning a String.

returns the state of an item as a String like ON/OFF, the temperature value etc.

but that doesn’t seem to be the case for me.

Do I have something mis-configured?

[Andrew_Rowe]

I didn’t want this to slip to far down before replying. When I started trying to write some documentation for blockly, I ran into a similar issue trying to write a simple example. It has been awhile so I can’t recall the exact syntax I was trying but it involved using the make ‘list from text’ block. I think I was trying to extract the hour out of the state of a DateTime item. (the state of which is a string) The ‘get state of item’ block is the subject of another thread see here for further reading

[hafniumzinc (T)]

I’ve been loosely following that thread, but most of it has flown over my head! Sounds like on the surface the two issues are separate, but intrinsically linked in the background.

Appreciate the reply!

In the meantime - reckon it’s worth making a note in the documentation thread?

[Andrew_Rowe]

@hafniumzinc

separate, but intrinsically linked

yes, the common link is the ‘get state of item’ block

@hafniumzinc

reckon it’s worth making a note in the documentation thread?

yeah T, I think Stefan has been furiously attempting to document the known issues in the reference thread but the reference thread is a wiki so anyone can add to or edit the thread.

[hafniumzinc (T)]

I’ve made a small edit to the relevant section which should help others hitting the same issue for now.

[Andrew_Rowe]

excellent!
We need all the help we can get

[stefan.hoehn (Stefan Höhn)]

Thanks for trying but it is even a bit more complex:

It doesn’t say that it returns a String but a State. Even though a state most often is a String it doesn’t necessarily need to be one. I am not sure in your case what kind of State is returned and why it is not a String.

see openHAB-State

I would re-rewrite and make a note as above, agreed?

[hafniumzinc (T)]

To be clear, this was the original bullet point in the documentation:

returns the state of an item as a String like ON/OFF, the temperature value etc.

So the documentation said that get state of item returns the state of an Item as a String. To the end user, they would expect a string.

I added the word Should in front of that sentence, and then the Note below that bullet point to help new users workaround the issue.

@stefan.hoehn

Even though a state most often is a String it doesn’t necessarily need to be one.

For an end-user this isn’t helpful so I wouldn’t add that to the documentation at the moment - especially as using this function on a String Item doesn’t seem to be returning a String.

[stefan.hoehn (Stefan Höhn)]

@hafniumzinc

So the documentation said that get state of item returns the state of an Item as a String.

True, fair enough, but I don’t like the work “should” in a documentation because it basically says it should but sometimes it doesn’t which sounds you cannot trust it. We should ( ) rather find something that is clear and correct. I wouldn’t also like to reference a thread but make the reference the core documentation to point at.

@stefan.hoehn

Even though a state most often is a String it doesn’t necessarily need to be one.

which is why I linked to the State-documentation. Basically when user work work with complex states there is eventually no way of understanding their complexity. I think there is no easy way to hide that with blocks.

I really appreciate your effort and I am not arguing - I am just looking for a clear and concise wording for the reference (which I am currently working at).

[hafniumzinc (T)]

@stefan.hoehn

it basically says it should but sometimes it doesn’t which sounds you cannot trust it

Which is true right now, isn’t it?

@stefan.hoehn

Basically when user work work with complex states there is eventually no way of understanding their complexity.

Is my use-case working with a complex state?

@stefan.hoehn

I am just looking for a clear and concise wording for the reference

Agreed, but we should document what the user should expect to see, not say

@stefan.hoehn

Even though a state most often is a String it doesn’t necessarily need to be one.

because that won’t mean anything to most users. Linking to the state-documentation also isn’t helpful for most users. It means nothing to me, and I don’t know how it would have helped solve my issue.