Aeotec Multisensor 6 + FW 1.1 + OpenHab 2.2


I’ve recently setup OpenHab 2.2 on a Raspberry Pi. I have a Aeotec Z-Wave USB stick and have set up a few Aeotec Multisensor 6 units (firmware 1.1). They are fully recognised and working and I’m using them to control my Hue lights without issue. However, I cannot configure them via OpenHab PaperUI as it appears to be attempting to write to parameter 9, which is a read only parameter as per the Aeotec engineering doco. They are on USB power, not battery.

I’ve seen a brief mention of the same issue deep in an old thread on the sensors here, but it appears to have been fixed a long time ago. Has it reappeared with the recent sensor FW update in combination with the z-wave 2.2 binding? Any idea how to fix this? I really want to increase my polling interval given it defaults to 60 min and i’m on USB power


1 Like

I’ve updated to the newest snapshot Z-wave binding (2.3), but it hasn’t made any difference. Still fails to config the sensor due to issue with param 9

I opened a Track with Aeotec Support. I have received a response, but it certainly didn’t have a resolution. I think we might have to get a couple of Debug logs for Dev review.


My suggestion is to request an update on that parameter setting to update it, this is only GET command so if you send a SET command, it may report the wrong setting. Refreshing this information or unpairing and pairing your device should help.

Alternatively, make sure that your unit is paired on battery power only and used on battery power. If paired on USB, then changed to battery, unpair and pair back your Multisensor 6.


Aeon Labs

On Thu, 8 Feb at 4:51 AM , wrote:
Multisensor parameter 9 is reporting a value of 256 when the documents say it should be a 2 digit value.

The parameter is the Battery configuration and is for reporting only. See attached screenshots. Specs and Device UI in OpenHAB.

1 Like

I have now managed to update my config via HabMin and it seems to be working thus far. Still broken in PaperUI.

I’m guessing maybe Habmin only sends the specific parameter you update whereas PaperUi sends them all?
Maybe the fix is as simple as changing the PaperUI config to make that param read only instead of read/write.

Anyways, short term I guess we just use Habmin for config of these sensors.

In case it’s useful to anyone that knows how to fix this, here is the error from attempting to update in PaperUI:

2018-02-09 13:47:15.053 [ERROR] [st.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at ‘things/zwave:device:18d56795:node15/config’

java.lang.NullPointerException: null

at org.openhab.binding.zwave.handler.ZWaveThingHandler.handleConfigurationUpdate( [233:org.openhab.binding.zwave:]

at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.updateConfiguration( [116:org.eclipse.smarthome.core.thing:0.10.0.b1]

at []

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]

at sun.reflect.NativeMethodAccessorImpl.invoke( ~[?:?]

at sun.reflect.DelegatingMethodAccessorImpl.invoke( ~[?:?]

at java.lang.reflect.Method.invoke( ~[?:?]

at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke( [178:org.glassfish.jersey.core.jersey-server:2.22.2]

at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$ [178:org.glassfish.jersey.core.jersey-server:2.22.2]

at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke( [178:org.glassfish.jersey.core.jersey-server:2.22.2]

at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch( [178:org.glassfish.jersey.core.jersey-server:2.22.2]

at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch( [178:org.glassfish.jersey.core.jersey-server:2.22.2]

at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke( [178:org.glassfish.jersey.core.jersey-server:2.22.2]

at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply( [178:org.glassfish.jersey.core.jersey-server:2.22.2]

at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply( [178:org.glassfish.jersey.core.jersey-server:2.22.2]

at org.glassfish.jersey.server.ServerRuntime$ [178:org.glassfish.jersey.core.jersey-server:2.22.2]

at org.glassfish.jersey.internal.Errors$ [177:org.glassfish.jersey.core.jersey-common:2.22.2]

at org.glassfish.jersey.internal.Errors$ [177:org.glassfish.jersey.core.jersey-common:2.22.2]

at org.glassfish.jersey.internal.Errors.process( [177:org.glassfish.jersey.core.jersey-common:2.22.2]

at org.glassfish.jersey.internal.Errors.process( [177:org.glassfish.jersey.core.jersey-common:2.22.2]

at org.glassfish.jersey.internal.Errors.process( [177:org.glassfish.jersey.core.jersey-common:2.22.2]

at org.glassfish.jersey.process.internal.RequestScope.runInScope( [177:org.glassfish.jersey.core.jersey-common:2.22.2]

at org.glassfish.jersey.server.ServerRuntime.process( [178:org.glassfish.jersey.core.jersey-server:2.22.2]

at org.glassfish.jersey.server.ApplicationHandler.handle( [178:org.glassfish.jersey.core.jersey-server:2.22.2]

at org.glassfish.jersey.servlet.WebComponent.serviceImpl( [175:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]

at org.glassfish.jersey.servlet.WebComponent.service( [175:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]

at org.glassfish.jersey.servlet.ServletContainer.service( [175:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]

at org.glassfish.jersey.servlet.ServletContainer.service( [175:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]

at org.glassfish.jersey.servlet.ServletContainer.service( [175:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]

at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service( [15:com.eclipsesource.jaxrs.publisher:]

at org.eclipse.jetty.servlet.ServletHolder.handle( [88:org.eclipse.jetty.servlet:9.3.22.v20171030]

at org.eclipse.jetty.servlet.ServletHandler.doHandle( [88:org.eclipse.jetty.servlet:9.3.22.v20171030]

at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle( [191:org.ops4j.pax.web.pax-web-jetty:6.0.7]

at org.eclipse.jetty.server.handler.ScopedHandler.handle( [87:org.eclipse.jetty.server:9.3.22.v20171030]

at []

at org.eclipse.jetty.server.session.SessionHandler.doHandle( [87:org.eclipse.jetty.server:9.3.22.v20171030]

at org.eclipse.jetty.server.handler.ContextHandler.doHandle( [87:org.eclipse.jetty.server:9.3.22.v20171030]

at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle( [191:org.ops4j.pax.web.pax-web-jetty:6.0.7]

at org.eclipse.jetty.servlet.ServletHandler.doScope( [88:org.eclipse.jetty.servlet:9.3.22.v20171030]

at org.eclipse.jetty.server.session.SessionHandler.doScope( [87:org.eclipse.jetty.server:9.3.22.v20171030]

at org.eclipse.jetty.server.handler.ContextHandler.doScope( [87:org.eclipse.jetty.server:9.3.22.v20171030]

at org.eclipse.jetty.server.handler.ScopedHandler.handle( [87:org.eclipse.jetty.server:9.3.22.v20171030]

at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle( [191:org.ops4j.pax.web.pax-web-jetty:6.0.7]

at org.eclipse.jetty.server.handler.HandlerWrapper.handle( [87:org.eclipse.jetty.server:9.3.22.v20171030]

at org.eclipse.jetty.server.Server.handle( [87:org.eclipse.jetty.server:9.3.22.v20171030]

at org.eclipse.jetty.server.HttpChannel.handle( [87:org.eclipse.jetty.server:9.3.22.v20171030]

at org.eclipse.jetty.server.HttpConnection.onFillable( [87:org.eclipse.jetty.server:9.3.22.v20171030]

at$ReadCallback.succeeded( []

at []

at$ []

at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume( [90:org.eclipse.jetty.util:9.3.22.v20171030]

at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume( [90:org.eclipse.jetty.util:9.3.22.v20171030]

at [90:org.eclipse.jetty.util:9.3.22.v20171030]

at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob( [90:org.eclipse.jetty.util:9.3.22.v20171030]

at org.eclipse.jetty.util.thread.QueuedThreadPool$ [90:org.eclipse.jetty.util:9.3.22.v20171030]

at [?:?]

I captured a DEBUG log of setting Parameter 9 to 1 in an attempt to set the parameter to something the binding might be expecting. It is rejected multiple times. We know this parameter is supposed to be READ ONLY, so it doesn’t surprise me that it is rejected, but I don’t see why the device is reporting the 256 value for Parameter 9. I’ll attempt to reinitialize the device to capture what it reports.

I woke the device up so it could complete a Reinitialize request, and I see a Parameter Unknown for PARAM_9. That can’t be good.

Really? The database is not configured like this that’s true…

A value of 256 means its battery powered I believe (at least from reading the comment that is in the database).

It’s not an issue - it just means that the log viewer couldn’t connect to the database to get the name of the value, or, the log viewer probably didn’t know the device type in order to get the database information from the database.

Just so we are on the same page, there are multiple firmwares, I’m referring to the All after 1.10. I’m not an expert by any means on the data exchange (but I’d like to understand more). Is this an issue with the Allowable Range (0 to 1) on Parameter 9?

I find it interesting that the Log Viewer cannot find this particular parameter in question. Note that we got here because many (don’t want to say All, but I have yet to hear that someone can ) are not able to Save the Configuration parameters for this Device in Paper UI. The PaperUI has RED underlined this particular parameter as well. Same reason that the Log Viewer cannot find Param 9?

While that’s not set correctly in the database, I think the real issue is if this is really a read-only parameter, then it should be configured as read-only otherwise your original problem of the binding trying to write to the parameter will still be there - even if you change the allowable range.

It looks like the best thing would be to break this into 2 parameters, but either way, it MUST be set to read-only if it is a read-only parameter.

Even if it’s only this one parameter it can’t find (is this the case?) it’s really totally irrelevant. The log viewer is simply doing a lookup of the database - it’s not linked in any way at all to any sort of issue with PaperUI.

This is very easily explained.

The current value is 256 (this is correct from the log you provided). The database only allows a value of 0 to 1. 256 is outside of the range 0 to 1, so PaperUI marks it red and doesn’t allow you to save.

See this link for more information -:

No, as above - it’s completely unlinked and unrelated…

In my investigation, I reviewed Parameter 9, and it is set as such in the DB. We are not trying to edit it. It just displays that way.

Ok, thanks. There’s a bug in the database exporter that doesn’t seem to be adding this flag - I’ll update that.

I’ll also split this into 2 parameters so it’s more useful/obvious…

1 Like

Thank you @Chris!

Again, you are very good at what you do.


It’s now 2 parameters -:


What Nightly might we expect this change to be in?
I just upgraded to 2.3 Build#1210, and am still seeing the incorrect 256 value for Parameter 9.

Do we need to reinitialize the device to pickup the parameter changes?

It was added a few days ago so will be included in the current builds. Builds are currently not running - once this is resolved it should be there.