Using the new OpenHAB 5.0.2 trying to link an existing Switch item to a String channel in the HTTP binding. When trying to select the switch through existing items, the MainUI seems little bit restrictive and only shows me all my existing String items and I’m lost how to select the switch I want to use. Obviously I will use a JSON profile transformation to get the correct value after selecting the switch.
The workaround for this specific situation is obviously to create a Switch channel in the HTTP Thing, but I would like to prevent repeating the same HTTP call for retrieving the status for every switch. My application returns a ‘serverinfo’ JSON string that contains the state information for all switches. Or, recreate all the switches (where the UI isn’t restrictive at all), but that is a lot of work and I would like to prevent that too
Does anybody have a clue how to get my existing switches to show (and being able to select link it to the String-channel)?
Move to the items list and select your item. In the lower left corner of the displayed item properties select ‚add link‘ and select the thing (channel) you like to link to the item
That’s not how the HTTP binding works. If you have one Thing with multiple channels that point to the same URL for the state, it will only make one request and process the one response across all the Channels. It doesn’t make a separate request per Channel. Your workaround is in fact the proper way to us the HTTP binding.
I addition to @Mclupo’s suggestion, you can change the type of the Item to a String temporarily. Once linked you can change it back to a Switch.
I’m 99% certain. The HTTP binding was written by the same author as the MQTT binding, and I am certain that’s how the MQTT binding works. Furthermore, that’s the general way all bindings work. If they get more than one piece of data in a single message, that single message is parsed and all the relevant Channels are updated from that one message. It makes the most sense. Finally, that’s how the old HTTP 1.x binding used to work too (only there were no Channels, but it would cache the response and reuse it rather than making a separate request for every Item).
But it’s easy enough for you to test if you don’t believe me. Put the binding into debug logging, and you’ll see the requests being made in the log. You can even add a couple of Channnels with bogus transformations that will throw errors every time the Channel is updated.
