Why would you do that? (shut down old version first). There is no reason to, unless you want to make a backup first or something simular.
As Bruce say, just update. I believe the update progress will clear the cache and tmp, as well as restart the system when done upgrading.
My experiences is, make another reboot after the first start, when things has settled. Cause the first start would normally show tons of errors and warnings. Second start should go alot faster and with a less more warnings/errors, if any.
1 Like
Frieso, thanks for letting me know how you solved your issue! I’ll see if there’s any extra serial dependent bundles that has arrived with M5 in my setup. (I haven’t installed any, but who knows, every rock needs to be turned over!).
I’m off for a business trip tomorrow, so I let my system stay at M4 so I know my home looks occupied while I’m gone. But in the end of the week, I’ll have a new go at M5.
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. 
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.
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