As mentioned here, sshd is not working on
As mentioned here, sshd is not working on
Thanks weakfl for reporting this issue. From reading your thread it sounds like you tried it but then reverted to previous working version without having time to debug? Can you provide any additional details. If you raised an issue on git please provide a link.
RPi 3B rev 1.2
OH2.5M3 (openhabian) (note: Just reinstalled from a manual install that have worked over the years (mainly nightly releases from 2.0 and lastly 2.5M3) but started to get problems (couldn’t add Sonos Beam) so reinstalled everything).
Amazon Echo Control
Hue Emulation - Unable to get this working with my Logitech harmony Hub.
Can’t use Rest GIU but it seems to be a known problem with m3.
Except for Hue Emulation and Rest GUI, everything works just fine at the moment.
REST docs work well with 2 caveats:
- The binding was moved to
2.5M1which causes upgrade issues for some people.
- There are known dependency conflicts with a handful of other bindings.
Thanks for checking in Jacop. So you are still running 2.5M3 right?
Yes indeed Hue emulation and REST interface are biggest issues with what otherwise seems a good working version
Not many, I’m afraid. I tried a reboot, checked my config, but couldn’t find anything. Just found the exception in my log.
I originally reverted to
M3 and then tried a few snapshots. All working up to and including
I have not raised an issue on gh yet. I wanted to wait until someone else would confirm it, to rule out a configuration issue.
I posted this under the installation thread, but at the suggestion of Andrew Rowe I am reposting this here to capture this issue as part of the 2.5M3 testing.
I’m a relative newcomer but I have been running OpenHAB 2.4 stable in a Docker without any issue for the past 6 months. With the recent release of 2.5M3, and the pending final release at years end, my curiosity was piqued and so I decided to give it a try. After making a backup and testing that it worked, I proceeded to install/upgrade 2.5M3 over my 2.4 Docker. The installation went fine fine and after a few minutes I was able to load WebUI. PaperUI and BasicUI were both accessible with my items and site map intact. I used PaperUI to install the REST API Docs per the change log, but HapanelUI would not load even though Paper showed it was installed. I deleted all of the cache and tmp items, uninstalled HabPanel using PaperUI, restarted and reinstalled HabPanel, but still no HabpanelUI. I used the console to list the bundles and HabPanel 2.5M3 is shown as active. I stopped it and restarted it, but again no improvement.
I restored 2.4 and next tried to remove all of the cache and tmp items before upgrading to 2.5M3 but I got the same result. If I do a clean install to a new docker container, using a standard install HabPanel is shown in the WebUI.
Any ideas as to what may be causing this issue or approaches I should try? For now I am back to using my 2.4 Docker without issue, and I am content to stay there for now if this is a known issue that has yet to be fully addressed in 2.5.
Thanks in advance for ideas and thoughts.
I have continued to dig into this searching the forums for clues, and have identified the culprit that is causing HabPanel not to load in the 2.5M3 WebUI. It is the habpanel.config file located in userdata/config/org/openhab/. I’m not sure why this should be causing the problem as it loads fine in 2.4 and works without issue, but 2.5M3 chokes on it. If I remove the file then HabPanel appears as expected in WebUI. Going forward I doubt that I will be the only one with this issue when upgrading from 2.4.
To fix this problem I made a duplicate docker of my 2.4 install and removed the 2.4 HabPanel config file from /userdata/config/org/openhab directory prior to upgrading to 2.5M3. I then installed 2.5M3 over top of my 2.4 duplicate docker. The upgrade created a fresh hapanel config file in /userdata/config/org/openhab directory. Then, because I am running Docker I am able to have both 2.4 and 2.5M3 installed and running in separate Dockers, so I was able to use the PaperUI in 2.4 and 2.5M3. I navigated within 2.4PaperUI tabs to the Services/UI/HabPanel/Configure Tab and copied the Habpanel json. I then pasted this into 2.5PaperUI/Services/UI/HabPanel/Configure Tab on my 2.5M3 docker installation and restarted. Now everything seems to work fine with 2.5M3. I don’t know the exact nature of the root cause for this behavior, but this solution works and may help some one else done the road as we migrate to 2.5 and beyond.
Thank you John for posting your issue and I have one other habpanel issue here:
And AWESOME job researching the issue and finding a solution!
M3 running in Docker since about 1 week
Experience so far:
- VS Code LSP connection is not working (see https://github.com/openhab/openhab-vscode/issues/141)
- I had to rename manual config of BasicUI due to changed namespace (from
- I deinstalled
restdocsbefore to upgrade and reinstalled it later > no issues
- No further issues, M3 is running really stable as of now! Great job
I shall do that in the next milestone
No need. I do not think the path is expected to change again, at least for OH2.
I’m not sure this rises to the level of a bug, but more of an FWIW that should get cleaned up prior to a final release or at least should be made known. In upgrading my DOCKER 2.4 to 2.5M3 I noticed logging errors related to the RESTDOCS API not being found in Misc. In checking my addons.cfg file I see that the RESTDOCS API appears twice. Once in misc and once in ui. I manually removed it from misc and as expected no more log errors. I wasn’t able to correlate these errors with any malfunction of M3, but the when 2.5 is installed it should attempt to remove the RESTDOCS from the addons.config file, or it should be prominently noted to at least make the user aware that it needs to be done manually. Perhaps it already is, but I just missed it. Otherwise no issues with M3 after 5 days running.
When I first moved to 2.5 there were warnings displayed & saved in the log files about the API docs location change. There is a conflict in M2 & M2 between the API docs and some bindings due to conflicting dependencies.
I can’t say that I saw any warnings during or after upgrading my installation from 2.4 directly to M3, but again I may have glossed over them or just plain missed it. I knew that REST API had moved so I made sure to reinstall it straight away from ui, but leaving it hang in addons.cfg as misc is what surprised me. Again, I couldn’t trace this any specific malfunction of M3 beyond the repetitive logging errors.
I use these bidings:
Xiaomi Mi IO Binding
Xiaomi Mi Smart Home Binding
Biggest issue is that rules are not running as they run before. Especially the ones what uses virtual switches. After full reboot virtual items need to be reloaded and rules what uses virtual items as first boot fails due to items loaded later than rules. I want to start debug the root cause. I had installed experimental rule addon but it was worse so I uninstalled it.
OpenHAB loads data in a random fashion Here is one person’s solution - delay rule loading by renaming the rules files.
Since this has been confirmed by other users meanwhile, I’ve raised an issue on GitHub.
UPDATE: resolved by upgrading to
@Andrew_Rowe Unfortunately I still haven’t figured out what is causing my instability/startup issues, I can only guess that it’s somehow related to the amount of items, bindings and rules I have.
I remember you stating you had over 600 items. While a lot of items, it should not cause the problems you describe running on your odroid. Perhaps start another thread to explore this issue in greater detail as this one is probably no longer getting much attention. Feel free to ping me from the new thread if you do
just to add to this, I was reading earlier today in another thread and a user quoted over 1500 items, I know I probably have 200 or 300 for a two room flat so I can imagine a large house having easily thousands
Just one small observation for M3 running Debian 10 on Intel hardware: everytime I start OH it immediately logs the following error as the first log entry in
2019-10-14 17:54:53.410 [INFO ] [org.openhab.ui.paper ] - FrameworkEvent INFO - org.openhab.ui.paper org.osgi.framework.BundleException: The bundle class path entry "patch/" could not be found for the bundle "osgi.identity; type="osgi.bundle"; version:Version="2.5.0.M3"; osgi.identity="org.openhab.ui.paper"" at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassPathEntry(ClasspathManager.java:174) ~[?:?] at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.buildClasspath(ClasspathManager.java:152) ~[?:?] at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.<init>(ClasspathManager.java:81) ~[?:?] at org.eclipse.osgi.internal.loader.EquinoxClassLoader.<init>(EquinoxClassLoader.java:43) ~[?:?] at org.eclipse.osgi.internal.loader.BundleLoader.createClassLoaderPrivledged(BundleLoader.java:316) ~[?:?] at org.eclipse.osgi.internal.loader.BundleLoader.getModuleClassLoader(BundleLoader.java:233) ~[?:?] at org.eclipse.osgi.internal.loader.BundleLoader.searchHooks(BundleLoader.java:503) ~[?:?] at org.eclipse.osgi.internal.loader.BundleLoader.findResource(BundleLoader.java:600) ~[?:?] at org.eclipse.osgi.internal.loader.buddy.DependentPolicy.loadResource(DependentPolicy.java:82) ~[?:?] at org.eclipse.osgi.internal.loader.buddy.PolicyHandler.doBuddyResourceLoading(PolicyHandler.java:157) ~[?:?] at org.eclipse.osgi.internal.loader.BundleLoader.findResource(BundleLoader.java:649) ~[?:?] at org.eclipse.osgi.internal.loader.buddy.DependentPolicy.loadResource(DependentPolicy.java:82) ~[?:?] at org.eclipse.osgi.internal.loader.buddy.PolicyHandler.doBuddyResourceLoading(PolicyHandler.java:157) ~[?:?] at org.eclipse.osgi.internal.loader.BundleLoader.findResource(BundleLoader.java:649) ~[?:?] at org.eclipse.osgi.internal.loader.ModuleClassLoader.getResource(ModuleClassLoader.java:200) ~[?:?] at org.eclipse.osgi.internal.framework.EquinoxBundle.getResource(EquinoxBundle.java:532) ~[?:?] at org.apache.servicemix.specs.activation.Activator.register(Activator.java:58) ~[?:?] at org.apache.servicemix.specs.locator.Activator.start(Activator.java:70) ~[?:?] at org.apache.servicemix.specs.activation.Activator.start(Activator.java:46) ~[?:?] at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:779) ~[?:?] at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1) ~[?:?] at java.security.AccessController.doPrivileged(Native Method) ~[?:?] at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:772) ~[?:?] at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:729) [?:?] at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:933) ~[?:?] at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:309) ~[?:?] at org.eclipse.osgi.container.Module.doStart(Module.java:581) ~[?:?] at org.eclipse.osgi.container.Module.start(Module.java:449) ~[?:?] at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1634) ~[?:?] at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1614) ~[?:?] at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1585) ~[?:?] at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1528) ~[?:?] at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) ~[?:?] at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?] at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
There is no noticeable side effect, so certainly not a major issue. ;o)