[SOLVED] Short question about Item/Sitemap Text/Strings and their format

  • Platform information: ESXi 6.7.0
    • Hardware: Dell Power Edge R310

    • OS: Ubuntu 18.04 64 Bit

    • Java Runtime Environment:
      java version “1.8.0_191”
      Java™ SE Runtime Environment (build 1.8.0_191-b12)
      Java HotSpot™ 64-Bit Server VM (build 25.191-b12, mixed mode)

    • openHAB version: 2.4


I tried to find answers for my questions on google but could´nt find a suitable answer.

I have an incoming String from Mqtt and display this on Basic UI and iOS App.
I do´nt get the complete text displayed because the textfield is too small.
I also have problems to display Umlaute ÄÖÜ and “ß” correctly.


my item:

String Brennerstatus "MQTT:[%s]" {mqtt="<[mosquittobroker:Home/inside/Heating/Brennerstatus:state:default]"}

my sitemap part:

Text item=Brennerstatus label="Brennerstatus" icon="status"

So, how can I

  • make the Text field bigger or is there a way to get a dynamically size of the textfield depending on the text lenght?

  • How can I display ÄÖÜ and “ß”

Any help and/or suggestion are highly appreciated!



Unfortunately the answer is no. You do have more control and customization over such things in HABPanel though.

In PaperUI, check under Configuration -> System -> Regional Settings and see if the language makes sense.

And make sure your using UFT8 format files.

Thanks for the reply.

Regional settings are:

Both files Items and Sitemap file are UTF8 encoded.

After a short google hunt, I found something that is related to Mqttfx. It seems Mqttfx does not send the Umlaute correct. By trying sending a message from the Mosquitto Broker like:
mosquitto_pub -h -m “ßÄÖÜ” -t Home/inside/Heating/Brennerstatus
OpenHab displays everything in the correct Format. So it is not a OpenHab related problem.
At the moment I am using mqttfx for test purposes until I get my Control Unit for my old Heatingsystem done.

Thanks for the UTF8 suggestion, it brought me right onto the way.

Would it be possible to split the long Text into two Texts with a rule and display this into two text Items?

That would be possible. I’m not sure how good it would look but it would be possible.

I believe this is what the channels are for in openhab. You should be able to parse everything into seperate channels and from there to seperate items. But I´m pretty new to mqtt (still learning), so I may be wrong. @rlkoshak probably know how to.

So, it would be a good idea to learn creating code in Xtend? I am not able to write rules because I do not understand the syntax of it.

I am just thinking about the item “Brennerstatus” is just a variable which holds the long message. I would use this variable to create two new variables which can displayed in two item.

I will try that but have to learn the language syntax first.

Thank U2!

OP is using the MQTT 1.x binding so there are no channels. Furthermore, this really isn’t the sort of thing that Channels are made for, though I imagine one could create a REGEX or JS transform that returns up to X characters in one Channel and the characters after X in another Channel. But that really isn’t the purpose of Channels. Channels are to represent whatever sensor or actuator publishes/subscribes to the MQTT topics. The Channel should therefore keep the whole message in this case, not just split it up because it’s too long. The entire long message represents a single state as best as I can tell.


So, it would be a good idea to learn creating code in Xtend?

You don’t have to use Xtend. You can write in Jython, JavaScript, or Groovy if you prefer. You can create some rudimentary rules using the Experimental Next Gen Rules Engine which will still require you to write Jython, JavaScript, or Groovy code but it will let you do so through PaperUI.

But to get any use out of openHAB, you will have to learn how to write Rules. OH is pretty useless without them.

Another alternative is if the message is static, you can create a mapping in a .map file and use the MAP transform to convert the long message to something that fits on one line.

Damn!.. I have been focusing on mqtt (v2) the last few days. I guess I thought everyone will be using v2 :wink:

Well, if it works, who cares then? :smiley:
Serious - I understand what you say, and I agree about the main purpose of channels, (ofcouse, you know better). But I dont see why it shouldnt work… Well, except he doesnt run v2 ofcouse.

There are lots of things that “work” but potentially cause problems or break concepts. It’s far easier to reason about and keep a model of your Things in your mind if they all “mean” the same thing, i.e. a one-to-one relationship between a sensor or actuator and a Channel. If you violate that, it technically works, but it increases the mental load required for you to understand it and use it. This stuff is complicated and hard enough. I will not recommend any thing that “works” if it increases the mental load on the user, especially if there are equally or less complicated ways to achieve the same thing that doesn’t break the model.