String Item content "parses" input at update

[mebe1012]

Copied from the following Thread: https://community.openhab.org/t/bug-string-item-parses-content-after-update/36773/2

• Platform information:
  • openHAB version: openHAB 2.2.0~20171126174916-1 (Build #1099)

Hi,

following Situation: I initialize an array in habpanel for a dropdown list through an String Item, which contains a json string. (Its about fixed values)

Im not sure since which Version, but somehow the behaviour changed of updating a String Item with a json String via the smarthome CLI.

The following json was to be stored in a String item:

{"temperaturen": [{"temperatur": "25"}, {"temperatur": "23"}, {"temperatur": "21"}, {"temperatur": "19"}]}

I had to escape the " like this, which is understandable and the outcome of the String Item state was exact the same:

"{\"temperaturen\": [{\"temperatur\": \"25\"}, {\"temperatur\": \"23\"}, {\"temperatur\": \"21\"}, {\"temperatur\": \"19\"}]}"

BUT if I update an item with build #1099 via the smarthome CLI with the json string, now the following state is the output:

"\"temperaturen\": [{\"temperatur\": \"25\"}  {\"temperatur\": \"23\"}  {\"temperatur\": \"21\"}  {\"temperatur\": \"19\"}]"

as you can see, the curly brackets got parsed and also the commatas disappeared.

This cant be really a wanted behaviour - raw String Items shouldnt manipulate the content in any way.

---

I already filed this issue at the ESH repo (https://github.com/eclipse/smarthome/issues/4654), but as someone pointed out, it looks like a Bug of the Karaf CLI.

And indeed, as I updated the item via the REST API, the behaviour mentioned above was gone.

BR

[kaikreuzer]

If you identified it to be a bug in Karaf, shouldn't you report the issue there? Btw, it would help if you'd simplify your report to the bare minimum like showing that you cannot use quotes in a string when doing a certain (which?) smarthome:update call in the console.

[mebe1012]

Ah thanks for pointing that out. I assumed that Karaf is part of openhab since at the ESH issue someone said it looks like an openhab problem.

I'll close this issue and will move it to the Karaf repo, together with an optimized problem report.

Cheers

[kaikreuzer]

But please make sure you can reproduce a problem on a plain Karaf (not on openHAB) - otherwise the guys there won't be interested much in it.

If the issue is ONLY with the smarthome:update command on the console, I would say that the issue is in ESH after all - but this would need to be checked, that's why I was asking for very minimal step-by-step instructions on how to reproduce the issue.

[mebe1012]

Alright, sry Im not that familiar with the whole issue reporting process yet (and which software in openhab is doing which job).

Step by step to reproduce:

1. Create String Item, e.g.

   String  Wohnzimmer_ZielTemperatur_Auswahl

2. Log into openhab CLI and fire the command

   smarthome:update Wohnzimmer_ZielTemperatur_Auswahl "{\"temperaturen\": [{\"temperatur\": \"25\"}, {\"temperatur\": \"23\"}, {\"temperatur\": \"21\"}, {\"temperatur\": \"19\"}]}"

3. Check outcome of the update at http://openhabianpi:8080/rest/items/Wohnzimmer_ZielTemperatur_Auswahl

   "state": "\"temperaturen\": [{\"temperatur\": \"25\"}  {\"temperatur\": \"23\"}  {\"temperatur\": \"21\"}  {\"temperatur\": \"19\"}]",

[kaikreuzer]

This is what I meant with minimal example:

my.items:

String Test

On the console:

openhab> smarthome:update Test "{[1,2]}"
Update has been sent successfully.
openhab> smarthome:items list
Test (Type=StringItem, State=[1 2], Label=null, Category=null)

So we see that the state is indeed manipulated and not correctly set in the item. Interestingly, I do not see the same behavior in the IDE, which uses the Eclipse console instead, so I guess @maggu2810 is right that it is somehow related to Karaf. I am just not sure whether it is a bug in Karaf itself or in the ESH Karaf Console support.

Did you say that the very same used to work on recent openHAB builds?

[mebe1012]

I'll remember that. :-)

Correct, max. one month ago this still worked properly via console. As I am upgrading the unstable build pretty often (~once a week), the build back then can't be that old.

[wborn]

This seems to be a Karaf issue. It can also be reproduced using the build in echo command:

openhab> echo "{[1,2]}"
[1 2]

I also checked the behavior on some older openHAB versions:

• It still worked with openHAB 2.1.0 (Karaf 4.0.8, jline 2.14.1)
• It no longer works since openHAB 2.2.0 (Karaf 4.1.3, jline 3.5.1)

It's probably determined by how jline handles this.