Null Pointer Exception on Group items

Hello,

until now, I’ve successfully used the following in my sitemap:

Switch item=gHeatingEG label="Heizung EG" icon="radiator" mappings=[4="Aus", 21="Mittel", 28="An"]

This allowed me to set all my radiator thermostats with one click. So far, so good. With the lastest update from a mid-April version to 2.1.0~20170508211313-1 (I’m using the unstable apt packages from the jfrog repository on Raspbian) I get the following exception for the above Switch. If I remove the switch from the sitemap, the exception is gone:

HTTP ERROR 500

Problem accessing /basicui/app. Reason:

    Server Error
Caused by:

java.lang.NullPointerException
	at org.eclipse.smarthome.core.items.GroupItem.getStateAs(GroupItem.java:242)
	at org.eclipse.smarthome.ui.internal.items.ItemUIRegistryImpl.convertState(ItemUIRegistryImpl.java:492)
	at org.eclipse.smarthome.ui.internal.items.ItemUIRegistryImpl.getState(ItemUIRegistryImpl.java:472)
	at org.eclipse.smarthome.ui.basic.internal.render.SwitchRenderer.renderWidget(SwitchRenderer.java:74)
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.renderWidget(PageRenderer.java:166)
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:128)
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:149)
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processPage(PageRenderer.java:92)
	at org.eclipse.smarthome.ui.basic.internal.servlet.WebAppServlet.service(WebAppServlet.java:174)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:287)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
	at org.eclipse.jetty.server.Server.handle(Server.java:499)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
	at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
	at java.lang.Thread.run(Thread.java:748)
Powered by Jetty://

Thereby I have to say that the radiator thermostats are all set to 4 degree, which I see when I look at each as a separate item. So none is undefined or null.

I think this is a regression that came in through https://github.com/eclipse/smarthome/pull/3314.
Afaik, it should be fixed by https://github.com/eclipse/smarthome/pull/3411, which is not yet available in the openHAB distro. I will release a new ESH stable build tomorrow that will include this fix.

2 Likes

Hello @Kai

thank you for your quick response. :slight_smile:

Hello @Kai,

just a short question to the pull request that you linked. There it seems to me, that the function “switch ON group” is not desired any more for future versions? What’s the rationale behind it? Actually enjoy it that I can change a lot of devices by changing their group.

What I’m missing is that when one item of a group changes the group gets at least notified (currently, when an item in a group is ON and a second item turns ON the groups won’t fire my rule any more). I would be glad, if groups actually could be enhanced so that they a) are always notified when a member changes (thought the group value might not change) and that it’s easier to access the item that changed than via the allMembers.lastupdate.sort thing (which I expect is also more resource consuming).

Anyway - thanks a lot!

Hello @Kai,

sorry for third reply, but I don’t know whether you’d notice otherwise. As this might be related to my first post, I haven’t opened a new topic for now. I’m seeing a lot of the following notifications in my log files and it seems that rules don’t work reliable any more when triggered by groups:

2017-05-10 20:58:01.025 [WARN ] [pse.smarthome.core.items.GenericItem] - failed notifying listener '[gLights (Type=GroupItem, BaseType=SwitchItem, Members=4, State=ON, Label=Beleuchtung, Category=light, Groups=[All]), gLightsEG, null]' about state update of item java.lang.NullPointerException: {}

Is that related to the issue you mentioned before? What is actually going to be the solution to groups now? Is it going to behave as expected again, or is there some major changes in group behavior?

This all worked before the update to the 2017-05-08 version.

Sorry - I’m a bit confused right now :astonished:

Hello @antares2001,

sorry for the confusion, I guess that was me who is responsible :slight_smile:

A couple of weeks ago we had an issue about a warning that a group was using the function “Equality” instead of “OR”. To fix this I cleaned up the specifications of group functions which is describes in the openHAB docs once https://github.com/openhab/openhab-docs/pull/373/files gets merged.

The question is how your items file looks like, i.e. how you defined the group gHeatingEG. If you do NOT specify a function which is probably the case as you get the Nullpointer (which is fixed by https://github.com/eclipse/smarthome/pull/3411), then you only have a collection of switches whereas the member state do NOT affect the group state. However if you click the group switch, all members should react.

I guess what you want is: Group:Switch:AND(ON,OFF) gHeatingEG. With this configuration all member states of gHeatingEG are combined with logical AND and your gHeatingEG switch goes to ON if all members are ON.

So basically the change I introduced does not remove any functionality but one has to specify more precisely how the group should behave. If you have a group without a function it should only collect the members or send the same command to all members. If you specify a function the group has to have a baseItem, i.e. the Switch in Group:Switch, otherwise the function does not know how to deal with different states from different item types.

The only 2 group definition that are valid now are: just Group and with baseItem and function Group:baseItem:function(Values).

Regarding your last point: It was a design decision that if you have a group with a function attached, the group state does change if a member changes, but only if the group state will also change. So if a member changes but that would lead to the same group state that the group already has, then there won’t be a GroupChangedEvent.

1 Like

Hello @triller-telekom

thank you for your extensive reply. Okay - that helps me to understand things a bit better. However, in my case the group is based on number items, as the thermostats (Danfoss living connect) can be set between 4 and 28. That’s why the definitions are as follows:

Group								gHeating				"Heizung"					<heating>				(All)
Group			 					gHeatingEG				"Erdgeschoss" 				<heating>				(gHeating)
Number 	HEAT_EG_WoZi_Front			"Wohnzimmerfront [%.1f]"		<heating>		(gHeatingEG)		{ channel="zwave:device:15b738a5:node32:thermostat_setpoint_heating"}
Number 	HEAT_EG_WoZi_Fenster		"Wohnzimmer Fenster [%.1f]"		<heating>		(gHeatingEG)		{ channel="zwave:device:15b738a5:node33:thermostat_setpoint_heating"}
Number 	HEAT_EG_Leseecke			"Leseecke [%.1f]"				<heating>		(gHeatingEG)		{ channel="zwave:device:15b738a5:node34:thermostat_setpoint_heating"}

Switch item=gHeatingEG label="Heizung EG" icon="radiator" mappings=[4="Aus", 21="Mittel", 28="An"]

I must admit that for number items, I have no idea of how to use them with a function to work (i.e., how would AND relate them? Would it set all to, e.g., 4?). I thought for numbers I can just have mathematical functions used like average.

Just a side question, as it affects, e.g., my tries to have an alarm system trigger each time a PIR reports ON in a group, even if the group is already ON. Is there any way (i.e. that will also trigger the cameras along the way of the theft), or do I really have to specify each Item separately as changed in the rule declaration and connect them with or?

For my light switches (for which I got the other NullPointerException)

2017-05-10 20:58:01.025 [WARN ] [pse.smarthome.core.items.GenericItem] - failed notifying listener '[gLights (Type=GroupItem, BaseType=SwitchItem, Members=4, State=ON, Label=Beleuchtung, Category=light, Groups=[All]), gLightsEG, null]' about state update of item java.lang.NullPointerException: {}

I’ve been using ever since OR(ON,OFF) as you described above. So that’s not the problem’s root:

Group:Switch:OR(ON,OFF)					gLights					"Beleuchtung"				<light>					(All)
Group:Switch:OR(ON,OFF)					gLightsEG				"Erdgeschoss"				<light>					(gLights)

Thanks a lot for your help and clarification.

I just tried your heating configuration and I see a Switch that has 3 buttons Aus, Mittel, An. if I click on any of them all members, ie. HEAT_EG_WoZi_Front, HEAT_EG_WoZi_Fenster, and HEAT_EG_Leseecke receive the new state, i.e. a click on Aus leads to:

12:01:17.775 INFO  s.event.ItemStateChangedEvent[:43] - HEAT_EG_WoZi_Front changed from 21 to 4
12:01:17.776 INFO  s.event.ItemStateChangedEvent[:43] - HEAT_EG_WoZi_Fenster changed from 21 to 4
12:01:17.777 INFO  s.event.ItemStateChangedEvent[:43] - HEAT_EG_Leseecke changed from 21 to 4

So this is all working as expected for you. For your use case you do not need a function, because all you want is to group the heaters and send the same event to all of them. Since you do not have a function attached to the group the group state will only change by clicking on the group switch, but not if you change the state of one member. But I guess thats what you expected, right?

The only problem that you are facing is the Nullpointer which has been fixed and will be available once Kai builds a new openHAB release.

Can you provide more details about the second Nullpointer? You said its related to rules, so how do your rules look like? And please also provide the members of the switch group and describe what you did or what happened prior to this Nullpointer.

Hello @triller-telekom

I can confirm @Kai that the groups for the heating work again (i.e., no NullPointerException when opening the sitemap).

For the second null pointer, it is not happening through rules, but just affects those that listen to groups. The exception is induced when a group member changes. The log looks like this:

==> /var/log/openhab2/openhab.log <==
2017-05-11 18:24:17.340 [WARN ] [pse.smarthome.core.items.GenericItem] - failed notifying listener '[gPIR (Type=GroupItem, BaseType=SwitchItem, Members=12, State=OFF, Label=Bewegungsmelder, Category=motion, Groups=[All]), PIR_DG_Kinderzimmer, null]' about state update of item java.lang.NullPointerException: {}

==> /var/log/openhab2/events.log <==
2017-05-11 18:24:17.345 [ItemStateChangedEvent     ] - PIR_DG_Kinderzimmer changed from ON to OFF

So when PIR_DG_Kinderzimmer goes to OFF, the above “failed notifying listener gPIR” appears in the log. Sometimes the entry in events.log is first, this time it was after the openhab.log message. This didn’t happen before the update to the 2017-05-08 version.

Thanks again for your effort and extensive coverage of the problem. :slight_smile:

EDIT: @triller-telekom this second NullPointerException has also disappeared with the latest 2017-05-11 build. Thanks a lot @Kai and @triller-telekom for your help, support and quick reaction. I know you do this voluntarily and that I cannot expect such an extensive help, the more thankful I am when you give such a great support. I will continue using the latest snapshots and help as much as I can to improve the software by reporting bugs :slight_smile:

Hello @triller-telekom and @Kai,

sorry that I have to resurrect this thread, but it seems there’s again a problem with Rollershutter groups, that lead to NullPointerExceptions.

I have the following line in my sitemap:

Switch item=gFensterRollos label="Fensterrolläden" icon="rollershutter"

and items like

Rollershutter ROLL_WZ_Fenster "Wohnzimmer Fenster" (gFensterRollos) { channel="rfxcom:rfy:2ac13127:shutter" }

that leads when opening it in Basic UI to the following stacktrace:

==> /var/log/openhab2/openhab.log <==
2017-05-28 12:35:57.112 [WARN ] [eclipse.jetty.servlet.ServletHandler] - /basicui/app
java.lang.NullPointerException
	at org.eclipse.smarthome.core.items.GenericItem.getStateAs(GenericItem.java:93)[99:org.eclipse.smarthome.core:0.9.0.201705261932]
	at org.eclipse.smarthome.core.items.GroupItem.getStateAs(GroupItem.java:264)[99:org.eclipse.smarthome.core:0.9.0.201705261932]
	at org.eclipse.smarthome.ui.internal.items.ItemUIRegistryImpl.convertState(ItemUIRegistryImpl.java:510)[137:org.eclipse.smarthome.ui:0.9.0.201705261932]
	at org.eclipse.smarthome.ui.internal.items.ItemUIRegistryImpl.getState(ItemUIRegistryImpl.java:485)[137:org.eclipse.smarthome.ui:0.9.0.201705261932]
	at org.eclipse.smarthome.ui.basic.internal.render.SwitchRenderer.renderWidget(SwitchRenderer.java:74)[199:org.eclipse.smarthome.ui.basic:0.9.0.201705261932]
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.renderWidget(PageRenderer.java:167)[199:org.eclipse.smarthome.ui.basic:0.9.0.201705261932]
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:129)[199:org.eclipse.smarthome.ui.basic:0.9.0.201705261932]
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:150)[199:org.eclipse.smarthome.ui.basic:0.9.0.201705261932]
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processPage(PageRenderer.java:92)[199:org.eclipse.smarthome.ui.basic:0.9.0.201705261932]
	at org.eclipse.smarthome.ui.basic.internal.servlet.WebAppServlet.service(WebAppServlet.java:175)[199:org.eclipse.smarthome.ui.basic:0.9.0.201705261932]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)[82:org.eclipse.jetty.servlet:9.2.19.v20160908]
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)[82:org.eclipse.jetty.servlet:9.2.19.v20160908]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)[173:org.ops4j.pax.web.pax-web-jetty:4.3.0]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)[81:org.eclipse.jetty.server:9.2.19.v20160908]
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)[80:org.eclipse.jetty.security:9.2.19.v20160908]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)[81:org.eclipse.jetty.server:9.2.19.v20160908]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)[81:org.eclipse.jetty.server:9.2.19.v20160908]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:287)[173:org.ops4j.pax.web.pax-web-jetty:4.3.0]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)[82:org.eclipse.jetty.servlet:9.2.19.v20160908]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)[81:org.eclipse.jetty.server:9.2.19.v20160908]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)[81:org.eclipse.jetty.server:9.2.19.v20160908]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)[81:org.eclipse.jetty.server:9.2.19.v20160908]
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80)[173:org.ops4j.pax.web.pax-web-jetty:4.3.0]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)[81:org.eclipse.jetty.server:9.2.19.v20160908]
	at org.eclipse.jetty.server.Server.handle(Server.java:499)[81:org.eclipse.jetty.server:9.2.19.v20160908]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)[81:org.eclipse.jetty.server:9.2.19.v20160908]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)[81:org.eclipse.jetty.server:9.2.19.v20160908]
	at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)[72:org.eclipse.jetty.io:9.2.19.v20160908]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)[84:org.eclipse.jetty.util:9.2.19.v20160908]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)[84:org.eclipse.jetty.util:9.2.19.v20160908]
	at java.lang.Thread.run(Thread.java:748)[:1.8.0_131]

I’d be glad if that could be fixed as I currently cannot control my rollershutters as group but have to run each separately. Thanks a lot!

Thanks for the infos. May I ask you to enter an issue at https://github.com/eclipse/smarthome/issues, so that it is correctly tracked and can be addressed? Thanks!

1 Like

Hi @Kai

Thanks. I’ve added the issue https://github.com/eclipse/smarthome/issues/3530