openHAB 3.3 Milestone discussion

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?


It should still be there. I have not tested by myself these “week/month” channels. Maybe there is a typo in the documentation example ?

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
MESSAGE:	java.lang.NullPointerException
SERVLET:	org.ops4j.pax.web.service.spi.model.ServletModel-34
CAUSED BY:	java.lang.NullPointerException
Caused by:

	at org.openhab.core.ui.internal.items.ItemUIRegistryImpl.getLabel(
	at org.openhab.ui.basic.internal.render.AbstractWidgetRenderer.preprocessSnippet(
	at org.openhab.ui.basic.internal.render.TextRenderer.renderWidget(
	at org.openhab.ui.basic.internal.render.PageRenderer.renderWidget(
	at org.openhab.ui.basic.internal.render.PageRenderer.processChildren(
	at org.openhab.ui.basic.internal.render.PageRenderer.processChildren(
	at org.openhab.ui.basic.internal.render.PageRenderer.processPage(
	at org.openhab.ui.basic.internal.servlet.WebAppServlet.service(
	at javax.servlet.http.HttpServlet.service(
	at org.eclipse.jetty.servlet.ServletHolder.handle(
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(
	at org.eclipse.jetty.servlet.ServletHandler.doScope(
	at org.eclipse.jetty.server.session.SessionHandler.doScope(
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
	at org.eclipse.jetty.server.Server.handle(
	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(
	at org.eclipse.jetty.server.HttpChannel.dispatch(
	at org.eclipse.jetty.server.HttpChannel.handle(
	at org.eclipse.jetty.server.HttpConnection.onFillable(
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
	at org.eclipse.jetty.util.thread.QueuedThreadPool$
	at java.base/

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.

Also, with M4 I was unable to add a non semantic tag to an item (as part of the Scene Control Suite). With M5, I was able to add it.

The issue (Sitemap not available) is fixed with the M5 milestone, and there was no need to get data back from any backup. Sitemap config is available as it was before with M3.
Thanks for the quick fix! :+1:

Problem using Homie protocol via MQTT-Binding:

After updating to Milestone 4 and now on Mileston 5 the problem still is available:
I have trouble to add my Homie 3.0.1 device.

In logs I receive the following warning:

2022-05-09 09:38:50.781 [WARN ] [.core.thing.binding.BaseThingHandler] - Attempt to update thing 'mqtt:homie300:mosquitto:5ccf7fb97572' with a thing containing invalid configuration 'Configuration[{key=deviceid; type=String; value=5ccf7fb97572}, {key=removetopics; type=Boolean; value=false}, {key=basetopic; type=String; value=homie}]', blocked. This is most likely a bug.

The Thing is shown as “online”, but no channels are shown in UI any more.

And this did work on M3? IIRC nothing has changed on the code that validates configuration. Do you think the provided configuration should be accepted?

Sorry, I am not sure if it worked on M3 because I reactivated my Pool just now. It worked in previous releases the last three years:
Is it possible to downgrade to M3 to verify it?

1 Like

I have downgraded to Version 3.2.0 now and the Homie 3.x integration works. Something seems to be broken within MQTT-Binding since 3.2.0