Strange. I have just restored an M3 backup, and everything works fine.
As I’m at the limit of my skills to fix this I’ll use this as the push to convert to JS Scripting.
Thanks for the reply.
@J-N-K I see that in the meantime the PR was merged. But is there any plan to patch that back into M4? Or should we wait for M5?
There might be a new release over the weekend, so stay tuned….
2 Likes
After upgrading to M4 Openhab does not receive data from Homematic HM-Sen-LI-O (Wireless brightness sensor for outdoor installation)
on the configuration page - things the status shows ERROR:HANDLER, detailed:
Status:
UNINITIALIZED
HANDLER_CONFIGURATION_PENDING
{HMP_1_TX_THRESHOLD_PERCENT=Der Wert muss mindestens 10 sein.}
until upgrade from M3 to M4 the sensor was working.
Werner
I don’t know if something in the HomeMatic binding changed, but the message is clear: the minimum value for this parameter is 10. If you fix that, the thing will probably work again.
OK, changed threshold_percent from 0 to 10, now working again. But something was changed from M3 to M4, so a note should be written to check this value after upgrading …
Latest change for homematic binding was introduced with M3 and mentioned in the release notes.
It was mentioned in the release notes Release openHAB 3.3.0 Milestone 3 · openhab/openhab-distro · GitHub
Upgraded to M5 today and just noticed that some rain channels are no longer present in the revised Netatmo binding:
This has been also changed in the latest 3.3 documentation. Question: Does Netatmo no longer support this in the API or was this just a change in the binding?
Because in the Doc there is still a configuration example that is no longer valid with the current version:
If Netatmo has removed this from the API, I need to find another solution with persistence. Otherwise can we have back these channels?
Thanks
Michael
It should still be there. I have not tested by myself these “week/month” channels. Maybe there is a typo in the documentation example ?
@glhopital
I believe we should open a new dedicated topic for the revamped Netatmo binding.
Topic opened
Same for me, too. After reverting back to Milestone 3 everything is working again.
M5 should be fine, too.
Yes HABPanel is working with M5 but BasicUI is now not able to load.
HTTP ERROR 500 java.lang.NullPointerException
URI: /basicui/app
STATUS: 500
MESSAGE: java.lang.NullPointerException
SERVLET: org.ops4j.pax.web.service.spi.model.ServletModel-34
CAUSED BY: java.lang.NullPointerException
Caused by:
java.lang.NullPointerException
at org.openhab.core.ui.internal.items.ItemUIRegistryImpl.getLabel(ItemUIRegistryImpl.java:450)
at org.openhab.ui.basic.internal.render.AbstractWidgetRenderer.preprocessSnippet(AbstractWidgetRenderer.java:101)
at org.openhab.ui.basic.internal.render.TextRenderer.renderWidget(TextRenderer.java:57)
at org.openhab.ui.basic.internal.render.PageRenderer.renderWidget(PageRenderer.java:194)
at org.openhab.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:160)
at org.openhab.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:181)
at org.openhab.ui.basic.internal.render.PageRenderer.processPage(PageRenderer.java:124)
at org.openhab.ui.basic.internal.servlet.WebAppServlet.service(WebAppServlet.java:182)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550)
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:74)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:294)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:90)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:516)
at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:555)
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:410)
at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:164)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
at java.base/java.lang.Thread.run(Thread.java:829)
So also the iOS App is not working and throwing an error:
Response status code was unacceptable: 500
I try to troubleshoot a bit.
And this did work in M4?
I didn’t try it, just reverted directly as I saw, that HABPanel is not working. I use HABPanel to Display the home status on touchscreens. So that is why that one is a killer feature on my side. Basic UI I only use on my mobilephone with the iOS app.
I also changed all the netatmo stuff, so reverting is no option at the moment.
Maybe start with a stripped down sitemap and add blocks one by one. If you find the offending block, please let me know. There has been no change to the offending code (also I see that it could be hardened at some point).
Yes, I think you are right! I testet in my test Setup M5 and created just a small sitemap. That one works fine. And also my test sitemaps are still working on my productive setup. So the problem must be in my sitemap. I will try to find out where.
… A bit later I figured out, that my netatmo rain sensor and my used label with manipulating the value was causing the issue. Fixed it, Basic UI and iOS are running fine again!
Thanks for the M5 Release, runs well for me since 4 hours now.
Just returning and reporting that as expected, M5 fixed the Blockly library issue I reported earlier.
Thanks to all for the quick resolution.