I don’t think, that happens soon. But on the other side it is also not that difficult to convert a OH1 binding. All the logic is in place, you just use the skeleton binding and move the logic over. That is still one day of time, but from this point on, you have a Thing status with error output, auto-discovery if you want to and so on.
IMHO yes, yes we do.
It is a stated goal and it will be the only way that we can get past this extended transitional period as OH leaves 1.x and matures into 2.x. There is plenty of legacy stuff hanging around that is holding OH back from a technical perspective and from usability perspective that we will never be able to get past without eventually replacing the old OH 1.x bindings, at least for the core bindings like HTTP.
Don’t undervalue consistency. As a 1.x binding, HTTP would continue to remain “different” and, for those who never grow beyond PaperUI, off limits.
Also, this gives us an opportunity get more information back from HTTP requests. Right now we basically can only get the body of the response. With Things we can also get:
- the return code
- status on whether we are waiting for a response
I was skeptical myself when the Exec2 binding came out but now I really appreciate how I can interact with it and get more information than is possible with a 1.x binding. It really helps identify problems and enables new and different use cases that impossible with a 1.x style binding.
I think we really do need a new HTTP 2 binding.
I have no idea if the new in work binding will support anything I listed above but it will at least be possible.
Those are fair and valid points.
I guess the take away is, when explained properly, even old timers who don’t want their cheese moved could be convinced
And a (command-line?) import tool for current .thing/.item files including comments and file association.
For me, this was the first time, I read you say, you agree we need an upgrade tool.
I can imagine you thought it was needed. And maybe you even wrote it. It was the first time I saw you write it.
Somehow after the whole MQTT debacle and how you wrote about it, it felt to me like you were against upgrade paths.
Now I feel a big relieve to read this.
Thanks for making this clear.
On my 2.4 upgrade I never lost Mqtt 1.
yet I do everything from files.
also a addons.cfg that tells openhab what bindings to load.
Did this save me?
I would guess that was exactly what saved you.
So sticking to files has some extra advantages…
who would have known…
Sorry for my bad English.
I am a normal user of openhab. I mainly use the PaperUI. That works pretty well for most things and I like the auto-discovery. I do not have to worry about the individual channels, I just have to assign, great.
I miss the possibility to assign tags to the items. I do not want to edit files. But sometimes I have to go to the json files. Therefore, it would be nice if there is a kind of table for editing Things and Items. Or, you distribute the data to one file per binding. In the PaperUI, everything that is possible per file must also be configurable.
It would be a way, if the PaperUI gets to the current extent an expert mode in which everything is tabular edit, similar to a text file.
The line in addons.cfg that enabled legacy bindings saved you ^^.
Many people hat problems with their addons.cfg file after upgrading, because the periodic file change watcher
made openHAB uninstall/install bindings in an endless loop (a bug, I guess?).
Just a short side story to understand that textual configuration can help, but doesn’t necessarily help.
Just to iterate on that a little more.
In many cases the Things/Channels/Links/Items terminology works because it all makes sense, you have different kinds of information that your actual physical device exposes and you want to link them to a conceptual model, and in most cases it is a valid approach since that physical thing’s binding has predefined configuration and behavior for that very thing. Even the Sun and the Moon for the astro binding make sense in that context.
What I believe many users are struggling with is the fact that HTTP or MQTT are perceived as merely protocols, not a way to define Things. You just want your MQTT topic or HTTP response to end up in a item so you can act on it or show it in an UI, not have the whole Thing/Channel/Link on top of it since it might not even make sense
Maybe it’s just a terminology issue, not a conceptual one.
Many people hat problems with their addons.cfg file after upgrading, because the periodic file change watcher made openHAB uninstall/install bindings in an endless loop (a bug, I guess?).
Wow, I hope that is investigated how that came to be and also how that did not happen with me.
It is like object oriented programming. Everything can be seen as an object.
For MQTT its the same. The broker configuration need to be configured. Make it a Thing. Multiple topics form an entity -> Make it its own Thing with variable channels.
And even for HTTP you find a fitting schema: The http server requires configuration (http auth credentials) -> Make it a Thing with variable channels.
From the Docs a Thing is
Things are the entities that can physically be added to a system and which can potentially provide many functionalities in one. It is important to note that Things do not have to be devices, but they can also represent a web service or any other manageable source of information and functionality.
So if we apply this definition to MQTT, the Thing in my mind would be a connection to an MQTT broker and a collection of topics to publish and subscribe to that represents a single device. For example, I’d recommend creating an individual Thing to represent each individual Sonoff/Tasmota in your system.
From the Docs a Channel is
Things provide “Channels”, which represent the different functions the Thing provides.
So if we continue our Sonoff/Tasmota example, each topic that is associated with that individual device would have it’s own Channel.
Some devices may have many Channels and some may have only one or two. That is why we create the Channels dynamically. But it still remains that a Thing is supposed to represent a “device” so MQTT Things should be created in this way. The fact that the device is using MQTT really shouldn’t matter once it is created.
If done so, it becomes more apparent how the device is represented in your home automation and the connection between the concepts of Things and Channels and MQTT will be a little more apparent.
As a user migrating from MQTT 1.x to 2.x I don’t think this will be completely obvious. In fact I myself only had the light bulb go off over my head while writing a previous reply. I think the natural inclination of a user migrating will be to create one Generic MQTT Thing and create a Channel for all the topics they current publish/subscribe to in that one big Thing. That is what I did the first time I played with it. I’m now convinced that is a bad approach because the device isn’t MQTT, the device is what ever is on the other side of that MQTT topic.
Creating Things in this way I think will make the ways MQTT relates to Things and Channels more apparent and it will more closely match the whole intent of Things in the first place.
The same will go for HTTP I’m sure.
Does this help?
That’s why I don’t want to take down the whole approach, it definietely does make sense in many ways.
But it has to be explained to users that don’t see it that way.
I’m perfectly at ease with this, but I can also understand users might have a hard time mapping protocol specifics to a physical concept - a Thing - because “HTTP” or “MQTT” just implies “use that protocol to get info for me” whereas “Hue” or “Nest” is more obvious, it means “just take care of that particular device for me”.
This sort of thing is really a problem will all of the lower level generic bindings (HTTP, Exec, TCP/UDP, Serial) and it is why all of these bindings are so hard for some users to figure out. They have to be generic by necessity but that generic nature means they have a lot of rope to hang themselves with.
But why MQTT implies just use that protocol to get that information for me, we are still getting that information from a device. It will be a long time before I have time to write something up, but I’m already formulating an MQTT 2.4 Best Practices tutorial which might help address some of this.
That is actually my approach, and I have therefore 19 MQTT “Things” in my smallish setup. Most of them Sonoff switches or environment sensors based on Wemos D1 PCBs.
Incidentally, creating them as seperate Things also allows me to put those things into seperate Locations, which makes the Paper UI Control tab very useful.
One point is missing in this discussion: performance and memory consumption on the openHAB server. Normally the machine where openHAB is running is much slower and has less memory than the user’s machine that is used to edit the configuration.
This means, the backend of a new or modified configurator frontend must also work on weaker machines (like Raspis) without completely blocking the openHAB server functionality.
We already have this problem sometimes with the VSCode and the LSP that is running on the server. Therefore some functionality has been moved or maybe moved in the future from the server-side LSP to a local implementation within VSCode.
That performance is not necessarily bad with the current architecture even if the server is just the minimum (a RPI), so this is not an argument for the architecture to change.
BUT there happens to still be a number of bugs in the current implementation leading to lockup of up to several seconds on some specific actions. See my post #99 for some pointers. Some of them I believe are related to VScode struggles.
Difficulty is to drive development in a way that working on shiny new developments mustn’t stop (yeah, annoying) maintenance and bug fixing work from happening. I sometimes feel there’s too much of a bias on new stuff.
I think the thing with VScode is not about new ideas (as per this thread) but about improving bottlenecks the “classic” way (i.e. without going right for a new architecture).
I fully agree with you. I am quite happy with the performance of OH on my raspi.
Therefore I wanted to emphasize that any new or modified frontend should not negatively affect performance or memory consumption on the server.