[SOLVED] Auto-Uninstall Bindings - WHY?

Hi, i hardly made myself start moving to OH2 after years of peaceful living together with OH1…

So, started to get used to the new UI and the way how config works…did install several bindings via PaperUI…but after restart all the time my selected and installed bindings vanish…like you can see in the logs…

WHY???

2017-08-20 23:26:52.760 [INFO ] [core.karaf.internal.FeatureInstaller] - Uninstalled ‘openhab-binding-weather1’
2017-08-20 23:26:56.536 [INFO ] [core.karaf.internal.FeatureInstaller] - Uninstalled ‘openhab-binding-systeminfo’
2017-08-20 23:27:00.739 [INFO ] [core.karaf.internal.FeatureInstaller] - Uninstalled ‘openhab-binding-exec’

1 Like

I suppose you should add them through services/addons.cfg
Something like this:
binding = systeminfo,weather1,...

Here is the migration guide.

Not recommended anymore:

1 Like

Thanks for the feedback.

So, what is written in the migration doc is not valid anymore?
bindings=…

should all be done via GUI?

How about action, transform…the same needs to be applied?

I guess I understand the reason for this mix of text+gui (as to have a migration path)…for me its still not 100% clear and do not understand if i can configure items via items file and they will show up in the paper ui configuration for things or items…

@sihui, thanks, missed that change.

1 Like

It is still valid, but not recommended because after some core changes it can lead to confusion (vanishing bindings like your are experiencing)

Yes, still possible and a lot of users still do it that way.

Manually configured items will show up but note that you only have “Things” for 2.x bindings, not for 1.x bindings.

If I remember correctly the migration tutorial makes it clear that you should not mix addons.cfg and ui management of addons. If it isn’t there it should be but I remember writing that somewhere.

And this is still a reasonable approach, particularly if you are running in a container.

But it is no longer the recommended approach as the UIs have caught up in capability and functionality. Over time the UIs will catch-up on the other areas as well (items, rules, sitemap, etc) but it it isn’t there yet (actually it probably is there for Items).

Unlike with addons.cfg, you CAN mix text and ui for the rest of the config toes but anything you do in text configs will be read only from the UIs.

Thanks, i remember that there was written to not touch config files if you go the “UI” path along…
but here is my problem that i in parallel discuss with Chris.

If finally you want zwave to be running for new devices via UI (which definitely makes sense to me)…you will not be too happy with the legacy running via old items files. at that point you either put the new items again in the old files, or you bring all old items in the UI. As my new understanding is that zwave-1 and zwave-2 binding do not work in parallel…

So its nice to have a fast migration but in the end as soon as this is up and running you still have to move on quickly to UI, as you only delayed the point where you have to touch each legacy device and bring it into UI.

My question to that: if now i create new OH2 zwave devices, the only additional effort is to change the names in sitemaps and rules, and persistence files…right?

Does this mean that the issue of the cfg file and the UI installations not being able to live together is gone.

I use the cfg file because for manual installation of bindings not available through the Paper UI. And till recently it was impossible to combine cfg file for those and Paper UI for published bindings see Reinstall bindings after restart OH2

This forced me to install all bindings through cfg.
Does this mean this issue is solved now and I can install some bindings (the manual not published ones) via cfg and the other through the Paper UI without them being deleted every time on restart ?

If not? then how should one install manual not published bindings via the Paper UI (if this is now recommended instead of cfg file)

For manually installed bindings, you don’t need to configure anything in addons.cfg

just drop the *.jar in $OPENHAB_RUNTIME/addons and that’s it.

Yes I know but when I do that ALL bindings installed through the Paper UI will automatically uninstall on restart. (At least a short while ago).

So I don’t understand how Paper UI can be the recommended binding install method as long as it cannot handle manual bindings or cannot co-exist with cfg install files.

So the issue is not that I’m unable to manually install bindings, it’s that when you do so for 1 binding you need to install all bindings through cfg and can’t use Paper UI anymore for binding install.

that’s normal. It’s either all or nothing with addons.cfg
The recommended method is nothing :slight_smile:
(meaning: don’t type up anything in the bindings = line (or other addon types) and use PaperUI to manage them)

If you want to use this line, you should define all of the addons that you want to maintain (independent if you installed them via PaperUI or via the addons.cfg)

In this case, you can install an addon from PaperUI but if you forget to ammend the appropriate line (e.g. bindings, ui, etc) it will be uninstalled on the next restart since OH2 will read what you have explicitly defined in the addons.cfg.

The only thing that will change is the stuff between the { } for your existing items. Item names, rules, Persistence, sitemap can all remain unchanged. You are just switching from a 1.x style binding config to a link to the ZWave Thing’s channel.

Or if you prefer to define all your items through the UIs, then you can delete them from your .items files and create them a new in the UIs with the same name and you won’t have to change anything else.

Rich, thanks a lot for this information.

I will definitely move forward rather soon to “ALL-2.1” mode of operation.
e.g. right now i’m struggeling with “simple date time from NTP”.

I removed the old item from the OH1 items file and tried to go forward like this:

  • create a thing/item called localtime_date of type datetime…and replace the name of the old OH1 item with the new item in the sitemap of interest…nothing shows up…any idea what can be a problem?..in paper UI i can see the time updating however.

  • in addition, if now i’m not using item files anymore and all is somewhere behind a DB, where can i change the time/date format or the icon i want to set for an item?

I guess this is somehow the still missing link for myself…how to transfer from the GUI created items to the sitemap. Do i still have to make items files with the new thing/item structure…as i find no other place to move icons/custom formatings…

Regards
Norbert

Just to be clear, Things and Items are different entities in OH 2.x. And you very seldom give a Thing a name (i.e. autodiscovery Things) and when you do give it a name it takes the form of binding:channel:yournamegoeshere. See the binding readme for specifics. Then this channel gets linked to an Item.

Given this, creating a “thing/item called localtime_date” is kind of nonsensical. So what exactly are you doing?

This statement and some of your other confusions makes me think perhaps you skipped the what’s new section of the migration tutorial and you have not read the Concepts section of the user’s guide because I do not get the feeling you understand the difference between a Thing and an Item.

Also, there are two versions of the NTP binding, an old 1.x version and a 2.x version and they are configured and used very differently. Which one do you have installed?

PaperUI provides fields for both. Groups too. Are you just creating Things and thinking they are Items?

All of this is covered in the second half of the migration tutorial.

Thanks for your reply.

I get the difference between items/things and really believe that this is a good way to organize everything better than before…more structured. Also read the migration several times and also the thing concept,…

To your NTP question, using NTP2 and created a thing and later the item. Tried to use this item in my sitemap, but nothing happens, but guess this is the case because i still do not get what is written below.

But still what i struggle with is, if I go for the 2.0 approach:

I first create items via things in paperUI. But what is next - if simply i want to use these items in my classic UI style.

  • Do I add these items again in a plain text items file?
  • where do i add information like which icon to use, or what should be the number formatting.
  • Do I again have to create a text sitemap like before in OH1.9

Maybe there is a document that best describes my questions above, at least i did not find/understand from there.

Regards
Norbert

You first create Things.

You then create Items. You can create Items either via the UIs it but creating .items files or both.

In PaperUI you can create new Items in the Configuration > Items section. Make sure you have Simple Mode turned Off in Configuration > Server (or something like that, I don’t have access to PaperUI right now). In Simple Mode OH automatically create new Items for every channel of every thing and the item name matches the channel I’d.

The page that comes up when you create a new item let’s you set everything you can set in a .items file including label, icon, tags, binding config or link to a channel, etc.

At this point an item is an item. It is used in rules and persistence and sitemap just like it has always been used in 1.x.

Yes you do need to create a text sitemap like before as the UIs do not support creation of sitemaps.

But my main point, and the main point of the migration trial is that if you follow the tutorial your existing sitemap, rules, .items files, persistence etc al will work with only minimal changes. You can then move over to the 2.x way of doing things as you have time.

But the key point here is that if you use the same Items names you need change nothing to your existing sitemap.

hm, regarding “you can set everything in UI for the item” is not reproduce-able from my Paper UI. I did setup an item for date/time in datetime format. When i go to config and press the edit button for this item i see the following:

Label
Category
Type
Parent Group

Thats it…i would have expexted a field for icon,…
Where would i do that, or for example the value formatting?

Maybe i still miss the point. Thanks a lot. Norbert

Hmmmm. Now that I can bring my PaperUI up I see no icon field. I thought I’ve seen that in the past but I guess I’m misremembering.

I suppose that people set the icon on the sitemap instead at the Item when they use the UI. That is the more appropriate place to do it anyway. It has caused lots of people confusion to have two places to define the Item’s icon so perhaps that is why they have left it out.

I don’t know what you mean by value formatting. You enter the label just like you always have in the Label field. If you want to, for example, show one decimal place for a floating point Number Item the label would be:

Some Value [%.1f]

See http://docs.openhab.org/configuration/items.html#label for details.

If you are talking about using visibility and color on the sitemap that works the same way as it always has. See http://docs.openhab.org/configuration/sitemaps.html#dynamic-sitemaps

If you are looking for dynamic icons, that works almost the same as it always has. The two differences are:

  • apparently, if you use PaperUI to define the Item you can only define the icon on the sitemap
  • there must be a default icon (e.g. if you have a bunch of wunderground icons like wunderground-snow.png, there must be a wunderground.png default)

See http://docs.openhab.org/configuration/sitemaps.html#icons

I believe the icon name should go in the category field.