2.5 Milestone 5 Issues

Well, I am running the whole oh environment usermode in my home dir, so basically I have ~/oh on my server, which is the current version. When I up/downgrade, I stop it, and make a copy to e.g. ~/oh_2.4.0 and then clears the oh/userdata/tmp + cache as well as removing runtime, copy the new version on top of it all and start it up.

This way, I can go back in about a minute by renaming the dirs.
I have done it like this since I started with oh (some early version of 2.0), has worked fine. Maybe this is not the way to do it nowadays?

Iā€™m not sure it was a recommended way to do it back then either, or even for OH 1.

I think the number one recommendation is to use openHABian. It currently works on Ubuntu and other Debian based distros. Short of that to install it using apt or rpm. In both cases openHAB will end up running as a non-privledged user without a shell which is a best practice for running services on Linux.

In both cases, use openhab-cli backup to make a full backup of your OH and openhab-cli restore to restore a backup. And when openHAB is installed, clearing the cache is automatically done for you as part of the upgrade/downgrade process. But if you ever have to clear the cache for other reasons, openhab-cli has an option to do that too.

Even for people who manually install OH on Linux for some reason, the instructions have you create an openhab user and a service file to run openHAB as the openhab user.

For a manual install, I think you ca call the backup and restore scripts directly instead of using openhab-cli. But using that to backup and restore your OH config is the recommendation. And it is definitely not the recommendation to run openHAB as a normal user. You donā€™t want to give OH that much power.

1 Like

Yeah, Iā€™m on gentoo, so no debian stuff here. :slight_smile: But thank you for the clearing things up, and describing whatā€™s available, and how it is meant to be used! Reading the update script does about what Iā€™m doing manually, so at least this should not be part of my M5 issues then.
At some point in time, when thereā€™s no other issues(!), Iā€™ll come around and create a specific oh user on my server.

Hi,

on M5 the moquette MQTT issue as described here still exists :frowning_face:

Thanks for advise!

I figured out why I couldnā€™t generate logs. Unfortunately there isnā€™t much useful info there now that I can generate the logs. The broker thing continues on happily thinking itā€™s still connected when the Broker goes down but then starts to generate errors on each publishMQTT call it makes.

MQTT binding logsā€¦

26-Nov-2019 10:41:27.045 [TRACE] [inding.mqtt.internal.TopicSubscribeMultiConnection] - Found suitable bridge mqtt:broker:argus for listing to topic homeassistant/#
26-Nov-2019 10:41:27.084 [TRACE] [inding.mqtt.internal.TopicSubscribeMultiConnection] - Found suitable bridge mqtt:broker:argus for listing to topic +/+/$homie
26-Nov-2019 10:43:03.911 [DEBUG] [org.openhab.binding.mqtt.action.MQTTActions       ] - MQTT publish to dads-openhab/status performed
-------- 10:52 shut down Mosquitto -------------------
26-Nov-2019 10:53:00.211 [WARN ] [org.openhab.binding.mqtt.action.MQTTActions       ] - MQTT publish to dads-openhab/out/vDad_Heartbeat/command failed!
26-Nov-2019 10:53:00.242 [WARN ] [org.openhab.binding.mqtt.action.MQTTActions       ] - MQTT publish to dads-openhab/out/vDad_Heartbeat/state failed!

events.log

2019-11-26 10:41:23.407 [hingStatusInfoChangedEvent] - 'mqtt:broker:argus' changed from UNINITIALIZED to INITIALIZING
2019-11-26 10:41:23.561 [hingStatusInfoChangedEvent] - 'mqtt:broker:argus' changed from INITIALIZING to OFFLINE
2019-11-26 10:41:25.957 [hingStatusInfoChangedEvent] - 'mqtt:broker:argus' changed from OFFLINE to ONLINE
2019-11-26 10:42:00.139 [ome.event.ItemCommandEvent] - Item 'vDad_Heartbeat' received command ON
2019-11-26 10:42:00.186 [vent.ItemStateChangedEvent] - vDad_Heartbeat changed from NULL to ON
2019-11-26 10:42:00.189 [GroupItemStateChangedEvent] - PubItems changed from NULL to UNDEF through vDad_Heartbeat
2019-11-26 10:43:00.135 [ome.event.ItemCommandEvent] - Item 'vDad_Heartbeat' received command ON
2019-11-26 10:44:00.142 [ome.event.ItemCommandEvent] - Item 'vDad_Heartbeat' received command ON
2019-11-26 10:45:00.135 [ome.event.ItemCommandEvent] - Item 'vDad_Heartbeat' received command ON
2019-11-26 10:46:00.136 [ome.event.ItemCommandEvent] - Item 'vDad_Heartbeat' received command ON
2019-11-26 10:47:00.135 [ome.event.ItemCommandEvent] - Item 'vDad_Heartbeat' received command ON
2019-11-26 10:48:00.135 [ome.event.ItemCommandEvent] - Item 'vDad_Heartbeat' received command ON
2019-11-26 10:49:00.135 [ome.event.ItemCommandEvent] - Item 'vDad_Heartbeat' received command ON
2019-11-26 10:50:00.135 [ome.event.ItemCommandEvent] - Item 'vDad_Heartbeat' received command ON
2019-11-26 10:51:00.141 [ome.event.ItemCommandEvent] - Item 'vDad_Heartbeat' received command ON
2019-11-26 10:52:00.136 [ome.event.ItemCommandEvent] - Item 'vDad_Heartbeat' received command ON
-------- 10:52 shut down Mosquitto -------------------
2019-11-26 10:53:00.138 [ome.event.ItemCommandEvent] - Item 'vDad_Heartbeat' received command ON
2019-11-26 10:54:00.142 [ome.event.ItemCommandEvent] - Item 'vDad_Heartbeat' received command ON

NOTE: I cut out a bunch of zwave and Rules events from the events.log above.

There is nothing in openhab.log.

The binding just seems to fail to recognize that the connection to the broker was lost and therefore it never attempts to reconnect.

As described by rossko57 on that thread, that error is coming from Moquette. And Iā€™ve seen on another thread, or maybe it was on github, that Moquette has essentially been abandoned by itā€™s developer so a fix is probably not forthcoming. Your best bet will be to move to Mosquitto for your broker if you experience any problems with Moquette.

2 Likes

Iā€˜ll try to reproduce that

Migrating from version 2.4 I started with 2.5-M3 successfully, updated M3 successfully to 2.5-M4 and updated M4 successfully to 2.5-M5 a couple days ago.

First I want to say that you made a very good job.

According openHAB 2.5-M5 there are some points I want to ask and mybe to get them fixed/clarified prior or with the final release of 2.5:

SNMP Things/Items shows/stores values even the host is down. Please do not store values, if the thing is not available.

When creating items on things the link button is active even you already clicked on it e.g. to create a new item, this leads to duplication items in the database.

The item naming language changed from enlish (last seen) to german (zuletzt gesehen) while creating items on some things, even though the system regional language and the user interface was set to english. Even deleting and recreating the items did not change to english.

when creating items on things and you want to reuse existing items the drop down list ist not sorted alphabetically by type/short-name nor by the real item name and very small. It would be helpful to change the ā€œreuse itemā€ functionality in a way that it could be used in a better way, e.g. sorting by real name and/or searching by part of name and resizable.

A little bit of information would be needed to know which thing or item is producing this error:
[.smarthome.model.script.actions.HTTP] - Fatal transport error: java.util.concurrent.TimeoutException: Total timeout 5000 ms elapsed

On the control view of the paperui it would be nice to see if a thing has been disabled within the configuration.

Multiple databases would be nice to store measurements like LAN statistics e.g. into influx-db and others e.g. into my sql or into multiple databases on the same sql engine. This should be configured by groups of things and/or directly on things an/or on by dedicated items or groups of them on different things.

How to delete automatic created items in paperui.

The paperui does not refresh every time you install or uninstall addons e.g bindings.

It would be nice to have in paperui/addons an overview of what you installed in a sum of all sub sections or by section. Otherwise you have to go thruw all sections.

There is for sure more to define by some points I wrote down, so please do not mind me for keeping so short worded.

I hope that some points, e.g. SNMP would be fixed prior major release of 2.5

Could it be possible that you change to minor versions to fix subsets of openHAB e.g. from 2.5 to 2.5.1 to get some updates into major releases faster?

Please reply with questions or concerns.

Thanks and best regards
Marc

Donā€™t expect major changes in PaperUI, as it is deprecated and an admin UI only. There will be a new admin UI with new features soon.

Please open an issue on github

Thatā€™s the plan for the 2.5 release, like Kai wrote in his announcement.

1 Like

This comes from PaperUI so will likely not be fixed like hmerk said.

This has been possible since at least OH 1.6. Only persistence is for Items, not Things. See Design Pattern: Group Based Persistence.

If you have simple mode turned on you canā€™t. With simple mode turned off, click on Items, search or browse to the item and click the trash can icon. You can not delete items defined in .items files in this way.

Many of these are feature requests, not bugs. A thread like this is more to discuss something that is supposed to work but doesnā€™t, not new stuff to be added.

For feature requests, often it is best to state a separate thread and file a GitHub issue. But donā€™t expect much from anything on PaperUI. It will be replaced before any new features or minor bugs like you list are fixed. The German/English problem might be significant enough for someone to look at so you should file an issue on that.

Paper UI in 2.5m5 shows ā€œKitchen MAP(on-off.map)ā€ instead of ā€œKitchen OFFā€
In Basic UI itā€™s ok

anybody now why click on bindings in PaperUI only brings up Binding Misc and Voice?
There is no Actions or UIs
???
edit: setting package = expert in addons,cfg fix this

Also is new rules engine installed by default because it is???
Not a upgrade, brand new install of 2.5M5 on a fresh Mint install

I had weird Paper UI issues a while back due to the browser caching in Chrome. Try clearing your browser cache.

ok, is firefox but Iā€™ll give it a try
edit: nope didnā€™t work

1 Like

canā€™t find expire binding???
edit: setting package to expert in addons.cfg did the trick

Which setup package did you select? My guess is that you selected the Simple (purely UI) package, which includes the new rule engine, since you would need it for UI-based rules. I believe you also will not see any 1.x bindings, including expire, since they cannot be configured through the UI. You can change the setup package in your addons.cfg.

2 Likes

you are exactly right on all of this Scott. Iā€™ll not pick simple again, what a nightmare

2 Likes

openHAB Pushover Action:
After upgrade to 2.5 m5 there are two bundles of Pushover and Pushover isnā€™t working:
2019-12-02 07:35:15.557 [WARN ] [ab.action.pushover.internal.Pushover] - Application API token not specified.

There are two versions in karaf:
openhab> bundle:list|grep -i push
274 ā”‚ Active ā”‚ 80 ā”‚ 1.14.0.M5 ā”‚ openHAB Pushover Action
275 ā”‚ Active ā”‚ 80 ā”‚ 1.12.0.201804032255 ā”‚ openHAB Pushover Action

after uninstalling 1.12.0ā€¦ all is working as expected, but after restart unwanted bundle is back.

/Sas

Perhaps try uninstall both, restart and install the latest only.

Already tried. After restart I get same situation.

/Sas