This is a rather general issue:
When I started looking at OpenHAB3, I used the proven approach of madly trying out a lot of things.
EDIT: I am talking about MY OWN use of the System and the things I did. I am not blaming the system!
Both in the literal OpenHAB sense and in a more general sense. Semantic model? Who cares about the semantic model?
EDIT: I didn’t, when I started - which is one of the main problems.
And it (EDIT: MY configuration) looks like a piece of software written without prior planning. That is not a compliment.
What it needs is something like a refactoring.
But which approach is the best?
A) Add syntactic model data to existing objects. Clean up and rename stuff.
This is not as simple as it appears.
B) Delete everything but the Things, rebuild everything else with a syntactic model and better name standards in place.
C) Reinstall OpenHAB (after backup) or “reset it to factory settings (how?)”
Some time in software engineering told me that that hurts the most at first, but will result in a much better system.
Actually is it designed to be very flexible, empowering the User to optimize it for their environment. The User is expected to understand the concepts and make wise choices based on reading the documentation.
This is not a system designed with rigid choices optimized for the neophyte or lazy user who refuses to spend the time necessary.
This is a system totally developed by volunteers. If you want a more structured system there are plenty of companies happy to take your money.
I intrepreted the “This is not a compliment” to be aimed not at OH but the OPs own first implementation. I do not think any insult to the maintainers or other volunteers was intended.
Short answer: it’s up to you. As Bruce mentioned, flexibility is one of the primary design goals. From my experience, A is not worth your time and too error prone. And binding installation and thing configuration are mostly automatic so B and C are roughly the same process (assuming you are not using one of the few bindings that still works best off of extensive manual configuration).
Best is a matter of opinion and specific circumstances.
You are not clear on where you are coming from. Are you migrating an existing OH 2 or OH 1 installation to OH 3 or starting with OH 3?
What is your ultimate goal here? To learn about the semantic model, convert your existing OH config to use it, or are you looking for a good foundation to get started?
Your answers could change the answer.
My circumstances were different perhaps as I migrated from a 2.5 mostly text based config instance to OH 3 all UI based config. So the process I took was:
Install a binding
Discover/create the Things
Create the Items by using the “Create Equipment from Thing” in the Model
Repeat 1-3 for each binding
Item names are their unique ID. Item names, like Thing IDs and Rule IDs cannot be changed. You either have to delete the Item and recreate it or cheat by editing the JSONDB manually.
Depends on how you installed it and how close to “factory settings” you want to get. If your main concern is Items and Things and such, stop openHAB and delete the contents of $OH_USERDATA/jsondb. That will wipe out your Items, Things, Rules, etc (assuming you did everything through the UI) but leave stuff like installed bindings and generic openHAB configs in places (e.g. locale).
If you want to do a complete start over, you’ll want to uninstall by reversing the process you followed to install then reinstall. Without known how you installed it’s impossible to be more specific.
One note though. It is important to spend at least a little effort trying to get your Items right so I applaud your desire to rework your Items. Items are the hub around which all the rest of OH works. They are the abstraction layer and communications channel between all the different parts of OH. And unfortunately because they are so central, it can be challenging to change them around and refactor them because changing an Item’s name will impact so many other parts and OH concepts too.
A is something I tried with an item - and the cleanup required showed me that that could not be the intended use of OH3, as flexible as it is.
I was worried about the Zigbee devices needing re-pairing, but noted that Mosquitto is it’s own entity, so is zigbee2mqtt.
but there is the official zigbee binding that is part of openHAB. You decided to use something else that required an external MQTT broker. Many people choosing zigbee2mqtt need to flash special software on their coordinator to support that instead of using the vendor’s firmware designed for the hardware…
Depending on how much time you already invested I would start over.
I personally did the same when moving from OH2 to OH3. Even though there’s a migration possible I took the opportunity to start from scratch. This way you can apply what you’ve learned so far and in my experience you have a better view of what you want once you’ve played around. Just my 2ct, the more people you’ll ask, the more opinions you get. There’s no ‘wright’ or ‘wong’ here.
New to home automation, a short flirt with Home Assistant and Alexa, new to OpenHAB 3.
My current configuration was a product of my attempts to understand, basically, what the stuff was for and how it connected. Tons of ad hoc decisions, a number of changes.
I want to set the system up in a way which makes it more self-documenting (naming standards rule) and logical. Adding the semantic items helped, but as I hadn’t designed with them in mind, the result was as expected. Time for a fundamentally sound change/redo.
…and renaming items does not automatically edit the scripts.
Thanks! Deleting the database will probably be sufficient. If not, a reinstall is always an option.
I have a background in software and networking - you learn over time that sometimes, redoing stuff makes it much easier to take advantage of all the lessons learned. And OpenHAB makes it easy, compared to working through a gazillion lines of old, promiscuous (lots of people had fun with it before you) code.
One thing you’ll probably learn over time though is that if you stick with the UI for Items management, the label of the Item will be what you end up working with day to day. It’s the label you see in the Model tree. It’s the label you see in the Items page. It’s the label you see when selecting an Item when configuring a widget or pinning it to the developer sidebar. And the label can be changed. So even if you get your Item names “wrong”, it’s not the end of the year because most of the time you’ll actually be working with the Item’s label.
So you can do something like I do where I have a Peanut Plug (Zigbee smart plug). The Item name is PeanutPlug5 (or something like that). But the label is “Master Bedroom Humidifier”.
Also, be sure to go through the Getting Started Tutorial. It’s not fully completely yet (missing rules) but it does cover the model and some of the best practices for creating the model.
Not only for that reasond. I had some issues with Aqara devices and a cheap Zigbee dongle - the recommendation was z2m. Another thing I want to use is RTL_433 (see How to integrate rtl_433 sensors into openHAB via MQTT · merbanan/rtl_433 Wiki · GitHub
which is supposed to work well with Mosquitto. I actually prefer an independent MQTT broker and OpenHAB 3 claims to be agnostic. (Its workings with OpenHAB are smooth - no autodetect, but everything working nicely.
V1 was basically playing around with stuff, V2 will use the documentation, advice like the one here and lessons learned.
A bit which is still a bit confusing is the “default” scripting language. I wasn’t able to locate a language reference. Some excellent examples which save tons of work, though.
