It is actually documented here.
I took a break for better reading 
and testing.
I also recorded the behavior dynamically via gif (see below) and tested it with just a lightbulb, once via items file and once via main ui with separate items names. Also restarting openhabian was involved.
As I assume this shall not happen anyhow, I posted a issue here.
Innerdoor location card while toggling state
Lightbulb location card while toggling state
I hope we can find and solve the root cause.
There is a ton of stuff to read through and the screen shots are too small to understand so I can’t offer much. But what I can offer is what works for me.
-
Each door has an Equipment Group. I use “BackDoor”, “FrontDoor”, “GarageDoor”, and “SideDoor” to tag these Groups based on which door is represented. This Group is a member of the Location Group.
-
The door sensor is represented with a Contact type Item. This Item is a member of the Equipment Group.
-
The door sensor is tagged with “OpenState” as the Point and “Opening” as the Property.
With these, when a door is open in a location it is shown on the Locations card as a badge.
The animated gifs show the location cars reacting on an item state change. In my opinion this behavior of just extending the distance of the text does not make sense. My assumption: The symbols of the badges should be visible but do not appear due to some bug. But just an assumption of course!
Thanks for the help - it confirms what I tried to use. I set up a dedicated test location with equipment and point as follows:
Group gTestlocation "Testlocation" ["Room"]
Group gTestequipment "Testequipment" (gTestlocation) ["FrontDoor"]
Contact Testdoor "Testdoor" (gTestequipment) ["OpenState","Opening"]
Switch testswitch "Testswitch"
To be able to operate the door contact, I use the following rule:
rule "test"
when
Item testswitch changed
then
if (testswitch.state == ON) {
Testdoor.postUpdate(OPEN)
}
if (testswitch.state == OFF) {
Testdoor.postUpdate(CLOSED)
}
end
When toggling the testswitch the testdoor changes state if I trust the log output while nothing happens on the location card:
2022-02-03 20:57:07.865 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'testswitch' received command ON
2022-02-03 20:57:07.870 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'testswitch' changed from OFF to ON
2022-02-03 20:57:08.044 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Testdoor' changed from CLOSED to OPEN
2022-02-03 20:57:18.813 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'testswitch' received command OFF
2022-02-03 20:57:18.818 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'testswitch' changed from ON to OFF
2022-02-03 20:57:18.826 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Testdoor' changed from OPEN to CLOSED
I have done a second test and removed all things, items and rules and restart openhab. I then only copied the files above => same behavior.
I have done a third test: I removed again the items file and configured the items manually via main ui with identical setting => same behavior.
Absolutely no idea what the problem is!
Just to share with you for completeness, below some screenshot of my setup which works (I was on mobile yesterday):
I still, even after looking through your screenshots the 4th time, cannot find anything wrong.
Dear all,
thank you for the intensive support and energy! It took me the night thinking about the problem: As the UI reacts on the item state shown with the gif images above, I was thinking: Maybe the icons are just not there (even though for temperature they are). As I reinstalled the latest openhabian freshly, I did a quick research and found this older issue.
With the following command from Kai in the karaf / openhab console the issue is fixed:
feature:install openhab-iconset-classic
Issue solved but I think a fix is needed => I’ll update the github issue.
Thanks anyhow - great support on finding and solving the problem!
2 Likes
Good that it works for you now!
Correct, anyhow I hope in case somebody has similar issues one can derive a solution.
It actually does not make a difference if it is windows, door, innerdoor etc. All work now. Even it can be a switch item with state ON/OFF or a contact item with state OPEN/CLOSED. I decided for contact as it feels more correct.
And I could learn something - not too bad 
3 Likes
Hi everyone,
Not sure if I am running into a similar issue or if I’m making a simple mistake. I have a door contact that has been verified to show the correct values in the item (Closed, Open) but I do not manage to have it represented on the badge of the location. I have the temperature and humidity of the room on the badge but no door sensor.
Running OpenHAB 3.2.0 on a QNAP NAS in a docker container.
This is what I have, related to the item (of course, there’s a Thing, other rooms, etc.):
Group gWohnzimmer “Wohnzimmer” (gErdgeschoss) [“LivingRoom”]
Group gTuere “Tuere” [“Door”]
Contact HM_Gartentuer_Wohnzimmer “Gartentuer Wohnzimmer” (gWohnzimmer, gTuere) [“OpenState”, “Opening”] { channel=“…” }
I also executed the install command for the iconset in the openhab console but the door does not show up on the badge.
When I click on the badge, I find it in the “Properties” tab of the room, together with the temperature and humidity.
Is there anything wrong with the definitions? Any other ideas?
Finally made it work. This is the correct item definition:
Contact HM_Gartentuer_Wohnzimmer “Gartentuer Wohnzimmer” (gWohnzimmer, gTuere) [“Opening”, “Door”] { channel="…" }
The key part is to use [“Opening”, “Door”] and not have “OpenState” there. It is not relevant whether the item is in the group “gTuere” or not.
Is there any documentation that explains when to use “OpenState”, “Opening”, etc. … I know the lists on GitHub etc. but it’s not really explaining what and how to use.
This is one of the reasons I guide people away from trying to use the semantic model in .items files. There really isn’t any documentation. But, looking in the UI we see that OpenState is a Point tag and Opening is a Property tag.
So you could have “Door,OpenState,Opening”, or “Door,Status,Opening”, either of which make some sense.
If you are going to implement the model in .items files, you’ll need to use MainUI to see the list of the tags of each type: Location, Equipment, Point, and Property. That’s the only place they are listed right not that’s easy to get to.
Property tags always must be paired with a Point tag. The two work together. For example, a CO alarm might use “Alarm, CO” while a water leak alarm might use “Alarm, Water”
1 Like
Thank you very much for the quick and helpful reply. Good hint that I could look in the MainUI, I try to remember that. The most helpful sources for me were the Semantic Model setup thread, the linked list of properties, locations, etc. and the Design Specs of the Location Semantic Cards.
I’d love to stop using the config files but as long as there is no simple solution to the OpenHAB configuration backup challenge in the UI, I have no other option. I have everything, the whole semantic model, things, items, rules, persistence, etc. in the text files. It’s the only way known to me how I can easily rebuild the same working OpenHAB system with a fresh install if necessary. Had in the past issues with corrupted installations where not even a file system backup (which I also have in addition) helped with restoring a stable state. Such corruption often happened much earlier and you only realize too late, and there is no backup any more without any corruption, besides the challenge that you would not know when the initial corruption happened.
I still dream of a “Backup” button in the MainUI that saves the whole configuration, i.e. the OpenHAB base config (like timzone, etc.) plus everything you configure (semantic model, things, items, rules, services, persistence, list of add-ons, etc) in a file. Once you have that file, you would be able to do a fresh OpenHAB install, and then use a “Restore” button where you specify that backup file, and a few minutes later everything is up and running again exactly as it was before. I know, there are a lot of threads out there about it and it seems to be a sensitive and emotional topic. No need to discuss it here, just explaining why I still use those text files 
Thanks again for your help, it is much appreciated!
Why is that ?
Config is stored under userdata/jsondb as plain JSON text files that can easily be backed up.
Unfortunately I don’t think either of those are kept up to date. Not that the semantic model has lots of changes to it recently.
I run in docker so I basically rebuild the same working OH system each and every time I upgrade the image and start the container. Like hmerk says, the UI configs are also just text files of a different format in a different folder. But they are still text files. I do nothing in text files (except my persistence which isn’t supported in the UI yet) and I even use git to configuration manage my OH setup.
It’s not in the UI but that’s exactly what openhab-cli backup does. It backs up everything, UI and text file configs and gives you one .zip file. If you are not using openHABian or an installed on Linux version of openHAB, there is a backup.sh/backup.bat script in the runtime/bin folder (and the corresponding restore scripts of course).
It’s only emotional because of how often it’s asserted that the UI configs are somehow different and standard backup and configuration control processes do not work. That is flat out incorrect and it’s frustrating to have to correct this misinformation over and over again. The fact that you have the impression that you can’t backup the config just the same as the text files in /etc/openhab is proof that the FUD is still alive and well.
As for corruption, very early on in 2.0 there were some very significant corruption issues. I haven’t seen any complaints about corruption in quite some time. The last problem was dealing with what happens when the file system fills up, which has already a fix merged into the baseline. There are other mitigations in place also.
Thank you very much for the detailed answer. First of all, let me be clear that I am neither complaining nor accusing anyone or anything around the backup topic. I am an IT professional for more than 25 years and among the dying species that actually does RTFM. I spent countless hours during the past many years to learn about OpenHAB from all sources I could find. OpenHAB is definitely not easy to learn but it is extremely powerful and incredibly stable, this is why I like it so much.
Of course, you can now live your frustration about all the stupid idiots out there like me that are struggling with the backup topic. And it’s obvious that there are lots and lots of users struggling with it, as you recognized yourself. Or, well, you may want to recognize that there is a need for a large part of the OpenHAB user base to clarify and guide the backup topic more than it was done until now. This would be some effort but would in the long-term significantly reduce the amount of such discussions with the community.
When you open the page Introduction | openHAB, you will not find the word “backup” or “restore” at all. I believe it would be a game changer for this topic if, under the “Administration Guide”, there would be a section “Configuration Backup / Restore” that explains what you probably already explained in countless postings.
I am running OpenHAB in docker as well (well, the QNAP Container Station incarnation of docker) and I am backing up all the Persistent Folders (conf, add-ons, userdata) which currently cover all my text files, and the jsondb folder, too. The jsondb folder mainly covers Things, Items, Pages, Widgets, Rules, it seems, which is great. So the missing part would be general OpenHAB config (timezone, location, etc.), persistence and bindings, I guess. Would be great to have an alternative to the openhab-cli because on my setup this is not a preferred option. Is there another way to back general config parameters up? And is there anything that is not backed up at all?
So at the moment, to restore an OpenHAB installation, I would need a fresh install of OpenHAB, I’d need to enter the general config, add the bindings, and then I only need to copy back the jsondb folder, restart OpenHAB, and everything is back there and working (all things, items, widgets, rules, etc.)? And I need to manually config the persistence again (or have a copy of the related config text files). So we are with quite a number of manual steps already that are not necessarily straight forward for the average OpenHAB user. Hence, some clear guidance in the “Administration Guide” would be very helpful.
Even more, if openhab-cli can provide a full config backup and restore, why is it not possible to provide a backup / restore option in the MainUI itself that does the same? This together with some guidance in the “Administration Guide” would end this topic once and for all
Also rule templates, and custom widgets for MainUI.
Except for persistence those configs end up in /var/lib/openhab/config.
For the embedded databases, the data is in /var/lib/openhab/persistence. The persistence config is still in /etc/openhab/persist until the new REST API end points are added that allow config through the UIs.
For non-embedded databases (e.g. InfluxDB or MySQL you need to manage backup separately).
docker exec -it openhab /openhab/runtime/bin/backup
Just remember the location of the backup is from the perspective inside the container.
There is an option to do a full backup which will include cache and tmp but generally you don’t need nor really want those unless you are certain to restore on exactly the same version of OH.
Although, if you are running in Docker you should have two volumes mapped to /openhab/conf and /openhab/userdata. So a full backup would be to just tar up those two mapped volumes from the host and you are good to go. There is no config outside those two folders.
If you upgrade, the image entrypoint.sh will see that your config is for a different version of OH than the Image has and do any upgrade stuff for you (after first taking a full backup).
No, if you have a backup created using that backup script, or you have a backup created by just taring up the volumes you’ve mounted to Docker, everything is there. All you would need to do is restore (in the first case) or mount these folders to the new Docker container (in the second case). Everything will be restored, users, persistence data, add-ons (though if it wasn’t a full backup you might need to wait a bit for the add-ons to be downloaded and installed again).
Just one step, not many.
No, if embedded database like rrd4j you’ll have your config and the data. If external you’ll still have your config. It’s all there in userdata.
If you capture the conf and userdata folders, you literally have a full backup of openHAB. The backup scripts are a little choosier and skip the things you don’t really need to restore everything which can take a several gig backup down to a couple megs in size (it’s almost all text after all).
- There is no REST API endpoint to do it.
- It’s actually pretty complicated when you have to deal with as diverse systems as Linux, Windows, OSX and more.
- No one’s implemented it.
That’s the same reason we don’t yet have an upgrade from MainUI too.
Sadly no, it wont because far too few actually read the docs. But adding more backup info to the guide is a great idea. I hope someone volunteers to do it. Just remember to cover all the supported operating systems, not just Linux.
2 Likes
Thanks so much, Rich, this is so valuable and helpful information! I took notes into my private little installation guide and I guess for the first time I feel I kind of understand where all the different configs sit. You also convinced me now that I should get away from the .items and .things files at least and I will dig into that topic as soon as possible (and, if necessary, will potentially open a new thread in case there is no matching other thread about it).
Two thoughts / feedback on the backup topic I’d like to share in addition:
-
I generally was aware before that for the docker installation, a backup of conf/ and userdata/ folders will give you a full backup (I just didn’t understand where the different config files sit). The concern with that backup menthod that I still have is that I had, with OH 2.5.x, a strange situation where something got corrupted (don’t remember the details, I think it was related to a binding) and I could not fix it any more, not even by reinstalling it. Those folder backups also have not helped any more. So I did the “forward strategy” and did a clean install with OH 3.0, just using my .items, .things, etc. files that basically saved my OpenHAB setup at the end, did the reconfig of the rest (bindings, etc.) and it worked again. It was quite some work, though, and it burnt into my brain that the fact of having these .items, .things text files (away from any OpenHAB installation related config files) prevented a major disaster. Hence my reluctance to get away from them.
-
This is related to point 1. and to the question of platform dependent configuration backups, plus the question around the famous “Backup / Restore” button in the MainUI (and I understand now we first need to extend the REST API for that anyway). To come back to my “dream”, it would be fantastic to have one day a platform independent configuration backup feature. One where you don’t need to know where which config files are and where it does not matter on which platform you are. It would be such a magic “Backup” button in the MainUI that would create e.g. one large json backup file with everything in it, from basic configurations like timezones, language, users, bindings, transformations up to everything else (things, items, metadata, custom widgets, persistence config, etc.). Then you could take this one file, restore it onto another clean OpenHAB instance and you would have the same system running again. This would make the backup (and restore) platform independent and also the required documentation would be platform independent. I would not expect this feature to backup data in internal or external persistence services, of course, this would be separate steps one would need to do, depending on the persistence service.
Such a one-file platform independent configuration backup would be my “dream backup feature” somewhen in the future. It would provide confidence that in case my OpenHAB instance gets messed up for any reason, I can remove everything, incl. the userdata and conf directories, spin-up a fresh container and load this one-file backup through the “Restore” feature in the MainUI, and would have exactly my OpenHAB instance running again. I know, this would be a lot of work but I guess it would massively improve, well it would actually remove what I consider one of the major painpoints of OpenHAB.
1 Like
Definitely review the Getting Started Tutorial at least as far as the Semantic Model page (though the full tutorial is worth review, especially for users coming from older versions of OH.
To a large extent, the runtime/bin/backup and restore scripts are this. They just need to be run from the command line. For an installed on Linux OH, these scripts are also made available through openhab-cli, but they exist on all platforms.
But from what you described, this or any other implementation of this would not have addressed your problem in 1. Something weird was going on there and without more details we can’t get any more there is no way to tell what happened.
Note that you can, for example, take a backup using that backup script or openhab-cli on an apt installed Linux instance, copy the zip file to a Windows machine and run the restore script and it will work.
Docker is a little weird because it’s Docker; you have to run the backup script from inside the container. And that alone is going to make any documentation for this not be platform independent. Also, the location of the backup/restore scripts and the presence or not of openhab-cli is going to be different too.
The current backup and restore scripts do handle the internal persistence since that data resides in userdata/persistence.
We are a lot closer to what you want already (and have been for quite some time). The backup and restore scripts that already exist on every OH instance already creates a single file (zip file) platform independent backup that includes everything to instantiate the exact same config on a fresh OH install (or overwrite an existing config on a non-fresh OH install). There’s just the one command to create the backup and the other command to restore it. The backup and restore scripts are also exposed through openhab-cli and through openhbaian-config for those running on those platforms.
1 Like
Thank you very much, Rich.
Note that you can, for example, take a backup using that backup script or openhab-cli on an apt installed Linux instance, copy the zip file to a Windows machine and run the restore script and it will work.
Ah, I was not aware of that either. Agree that OpenHAB is actually surprisingly close to what I would love to have, indeed. It seems the missing part is obviously mostly some visible documentation in the “Administration Guide” and maybe some “convenience treatment” (clicking a button in the MainUI instead of command line; but you already explained why it is not possible at this stage).
Regarding the Semantic Model, I studied it in detail when I upgraded to OH3 and applied it to all (most) of my items to my best knowledge. Defined the locations, etc. via groups in .items file, will be fun to see how I get that into the UI without re-doing it. But let’s reserve that for another thread I’m going to open
Thanks again, Rich, this was very enlightening and helped a lot for my next steps. I am sure a lot of users would benefit massively from all this information when made available e.g. in the “Administration Guide”.
By the way: Didn’t know that either, cool, although I’m using InfluxDB and manage my data backup there.