Textual vs. Ui driven configuration

Setup, Configuration and Use Migration
24

Hello,
I am migrating to OH3.1 and I’d like to keep textual definitions. However, I am struggling to get my MQTT Setup in a text file and the Main UI definitions.

Whenever I modify something on the UI this huge json file is changed:
./userdata/jsondb/uicomponents_ui_page.json
All pages go in here. Is it possible somehow to have the main ui config in the conf folder and hierarchic (meaning a json file per page for example)?

in OH 2.x the mqtt broker could be defined here:
conf/services/mqtt.cfg

Seems not be possible either.
Now the mqtt definitions using the automatic approach go here:
./userdata/jsondb/org.openhab.core.thing.Thing.json

25

AFAIK no.

Err, no. That was in OH 1.x (or in compatibility mode).
MQTT for OH 2.3 and newer is different since this was implemented.

Well in theory you should be able to define any Thing via .thing file.
You “just” have to figure out the format. Haven’t tried with MQTT but there’s a section in the link I gave above.

1 Like
26

Hi Markus,
this didn’t work for me:

Bridge mqtt:broker:myUnsecureBroker [ host="192.168.0.42", secure=false ]
{
    Thing mqtt:topic:mything {
    Channels:
        Type switch : lamp "Kitchen Lamp" [ stateTopic="lamp/enabled", commandTopic="lamp/enabled/set" ]
        Type switch : fancylamp "Fancy Lamp" [ stateTopic="fancy/lamp/state", commandTopic="fancy/lamp/command", on="i-am-on", off="i-am-off" ]
        Type string : alarmpanel "Alarm system" [ stateTopic="alarm/panel/state", commandTopic="alarm/panel/set", allowedStates="ARMED_HOME,ARMED_AWAY,UNARMED" ]
        Type color : lampcolor "Kitchen Lamp color" [ stateTopic="lamp/color", commandTopic="lamp/color/set", rgb=true ]
        Type dimmer : blind "Blind" [ stateTopic="blind/state", commandTopic="blind/set", min=0, max=5, step=1 ]
    }
}

Should this be possible in OH3.1?

I have mqtt working but only using the “Magic”.

27

Dunno, as I wrote I didn’t try that myself. Possibly the syntax has changed, might be worth to cross-check with these binding docs.

28

You might look at Roomba980-Python/roomba.things at master · NickWaterton/Roomba980-Python · GitHub as an example for configuring MQTT. The structure looks a bit different from yours. Did work for me.

29

Following this

the following worked for me:

Bridge mqtt:broker:myUnsecureBroker [ host="192.168.0.42", secure=false ]

Thing mqtt:topic:mything "mything" (mqtt:broker:myUnsecureBroker) {
    Channels:
    Type switch : lamp "Kitchen Lamp" [ stateTopic="lamp/enabled", commandTopic="lamp/enabled/set" ]
    Type switch : fancylamp "Fancy Lamp" [ stateTopic="fancy/lamp/state", commandTopic="fancy/lamp/command", on="i-am-on", off="i-am-off" ]
    Type string : alarmpanel "Alarm system" [ stateTopic="alarm/panel/state", commandTopic="alarm/panel/set", allowedStates="ARMED_HOME,ARMED_AWAY,UNARMED" ]
    Type color : lampcolor "Kitchen Lamp color" [ stateTopic="lamp/color", commandTopic="lamp/color/set", rgb=true ]
    Type dimmer : blind "Blind" [ stateTopic="blind/state", commandTopic="blind/set", min=0, max=5, step=1 ]
}

PS: probably worth to update the binding docs with a (corrected) example like in the blogpost - any takers?

30

Hi Markus,
yes this works for me too. This eases the whole configuration quite a lot.
Thank you for the input.

31

I’ve put this into the docs.

32

The experimental file config simulation of things and items defined in UI is hanging up in the air since April. We all should force @mstormi and openhab band to pay some attention to this, as this is a necessary feature.

33

@11194, I’d appreciate if you could reconsider your choice of words. No one can “force” any of our volunteers to do anything, and the mere suggestion shows a lack of respect for Markus and all of the developers and maintainers who put their own time and effort into this project.

If you don’t like what’s going on with openHAB, no one will “force” you to use it. If you think you’re owed something because you downloaded free software, then you’re wrong. The only thing we owe each other here is mutual respect.

I hope I’ve misread your intention, in which case I apologize for over-reacting. However, in my 2.5 years in this community, I don’t recall anyone ever suggesting that users should try to force developers to do something.

I also hope that others will give you a chance to respond before this gets out of hand. Instead of letting a moment of frustration define us, let’s all take the high road. There’s enough negativity in the world, and I personally come to the openHAB community to get away from it.

5 Likes
34

What do you mean here? I am not aware of any simulation for configs.

Who decides what a necessary feature is ?

35

@rpwong Don’t worry Russ, I didn’t meant we should rope volunteer maintainers and actually force them to apply some feature with a help of soldering iron =) But as a new user I actively search community forum for solutions and I often see other users asking questions and having issues with items or things, added with textual or UI config. Old users have issues when migrating from Oh2.5, new users see Oh2 recipes, apply them, then cannot find out how to edit their newly created items to add them to semantic model.
I personally got an issue with the very start to Oh while using RGroll’s example widget for OpenWheatherMap - there are two options how to create 667 needed items, by .items or by 667 clicks in UI, I’ve chosen file config and had to redo everything later to UI items to apply semantic model, tags and so on.
I think that those two approaches, UI and textual-based, have their own advantages and disadvantages, the first is better for fast changes of single item or fine tuning, the second is better for sharing solutions and initial setup, so we all have to use both of them, so we really need interaction between them.

36

No, you could have clicked „select all“ at the end of the channel list and have all items created at once and added to the model.

2 Likes
37

This!

Just FTR, I am openHABian maintainer but no core developer i.e. just a user like everybody else.
So even if I agreed to what @11194 wrote (which I do by no means even if I disregarded his wording),
I could not do anything about it other than to enhance the docs.
Which is what I did while @11194 was busy texting his lack of respect.

38

FYI, and as mentioned in an earlier post on this thread, you don’t need the UI to generate the semantic model.

2 Likes
39

This way my browser window just hanged up and never recovered. And in the end I decided to have just a 7-day forecast, as 14-days is too far from truth for my location and has no sense. And remember - I was totally new to Openhab, and this widget was a first try for me, as it was for many other users.

Here it is, a compromise between the two approaches.

40

I am not shure if that proposal will allow editing GUI created things/items/etc. via VS-Code, as you cannot edit the JSON-DB where those are stored while openHAB is running. This might need some core changes for the way those entities are stored internally which will introduce breaking changes….

41

Are they supposed to apply changes on-the-go? There could be a VScode shortcut for stopservice-apply-startservice.
Oh wait. We do edit JSON-DB when Oh is running, with UI, ain’t we? I hope REST-API could help to manage everything online.

42

Stopping openHAB and restarting will interrupt the connection to the LSP, so really a bad idea.
Yes, MainUI does this „on the fly“, but this needs to be implemented in VS-Code. Possible, yes, should be, easy to implement, I don‘t know.

43

Thanks for taking the time to respond. Deadpan sarcasm generally doesn’t translate well in written English, so your comment appeared to be an angry rant, not humour. When I see things going sideways (often due to language choices), I try to right the ship so that we can have productive conversations.