Z-wave device migration error with z-wave light switch channel

edit: :person_facepalming:
Solution: delete thing, rescan z-wave and re-add thing. It uses the same node number, and nothing has to be updated. The switch now works as intended.

Original message:
I think I have an interesting version of the integer/float problem with updating to OH3.
I have a lot of Inovelli z-wave switches.
Since the migration, I have noticed that many of the red series switches are not initializing successfully. These switches are able to initiate scenes based on button pushes, as well as display patterns/colors to their LED.

The information for the light/blinking pattern are coded in a byte in channel 8.

This particular switch in question is an LZW30-SN Red Series On/Off switch, and all of the LZW30-SNs are affected. Interestingly, the LZW31-SN Red Dimmer switches are not, and the plain LZW30’s are also unaffected.

For the LZW30-SN’s:
The error is:

Status:

UNINITIALIZED

HANDLER_CONFIGURATION_PENDING

{config_8_4_000000FF=The value 89.0 does not match allowed parameter options. Allowed options are: [ParameterOption [value=“0”, label=“Red”], ParameterOption [value=“21”, label=“Orange”], ParameterOption [value=“42”, label=“Yellow”], ParameterOption [value=“85”, label=“Green”], ParameterOption [value=“127”, label=“Cyan”], ParameterOption [value=“170”, label=“Blue”], ParameterOption [value=“212”, label=“Violet”], ParameterOption [value=“234”, label=“Pink”], ParameterOption [value=“255”, label=“White”]]}

From @chris Jackson’s z-wave database, this device has definitions for channel 8:

8 LED Strip Effect LED Strip Effect
8 LED Strip Effect (Color) LED Strip Effect (Color)
8 LED Strip Effect (Brightness) LED Strip Effect (Brightness)
8 LED Strip Effect (Duration) LED Strip Effect (Duration)
8 LED Strip Effect (Effect) LED Strip Effect (Effect)

I thought I used to have the XML files for this device, but cannot find them at this time, and my old login to chris’ old website don’t work for the current one, …
This is probably all looking at too great a depth for this. I assume this was because of whatever color I chose to assign the LED previously, and the way that value was persisted.

I believe the problem is that the color value appears to range from 0 to 255 as integers, and the (?historical) value of 89.0 isn’t compatible with this. I believe this is stored in a byte, however, making finding the value in influxdb to convert difficult to find.

Is there a best way to clear this?
Delete the node? Exclude/re-include?
It seems odd that it is affecting only the LZW39-SN, not the (very similar) LZW31-SN

Thanks!

Edit:logs

2022-11-05 22:29:32.105 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:device:a204e4d4:node76' changed from UNINITIALIZED (HANDLER_CONFIGURATION_PENDING): {config_8_4_000000FF=The value 197.0 does not match allowed parameter options. Allowed options are: [ParameterOption [value="0", label="Red"], ParameterOption [value="21", label="Orange"], ParameterOption [value="42", label="Yellow"], ParameterOption [value="85", label="Green"], ParameterOption [value="127", label="Cyan"], ParameterOption [value="170", label="Blue"], ParameterOption [value="212", label="Violet"], ParameterOption [value="234", label="Pink"], ParameterOption [value="255", label="White"]]} to UNINITIALIZED

2022-11-05 22:29:32.128 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:device:a204e4d4:node76' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)

==> /var/log/openhab/openhab.log <==

2022-11-05 22:29:33.478 [ERROR] [st.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at 'things/zwave:device:a204e4d4:node76/config'

java.lang.IllegalStateException: Thing with UID zwave:device:a204e4d4:node76 has no handler attached.

	at org.openhab.core.thing.internal.ThingRegistryImpl.updateConfiguration(ThingRegistryImpl.java:96) ~[?:?]

	at org.openhab.core.io.rest.core.internal.thing.ThingResource.updateConfiguration(ThingResource.java:498) ~[?:?]

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

	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]

	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]

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

	at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:3.4.5]

	at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.4.5]

	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.4.5]

	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.4.5]

	at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.4.5]

	at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[bundleFile:3.4.5]

	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.5]

	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.4.5]

	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.4.5]

	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.4.5]

	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.4.5]

	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.4.5]

	at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.4.5]

	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298) ~[bundleFile:3.4.5]

	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPut(AbstractHTTPServlet.java:234) ~[bundleFile:3.4.5]

	at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) ~[bundleFile:3.1.0]

	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273) ~[bundleFile:3.4.5]

	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550) ~[bundleFile:9.4.46.v20220331]

	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:74) ~[bundleFile:?]

	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) ~[bundleFile:9.4.46.v20220331]

	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:294) ~[bundleFile:?]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.46.v20220331]

	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:90) ~[bundleFile:?]

	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487) ~[bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732) [bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479) [bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) [bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) [bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) [bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) [bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) [bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) [bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) [bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) [bundleFile:9.4.46.v20220331]

	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) [bundleFile:9.4.46.v20220331]

	at java.lang.Thread.run(Thread.java:829) [?:?]

edit: :person_facepalming:
Delete thing, rescan z-wave and re-add thing. It uses the same node number, and nothing has to be updated. The switch now works as intended.

It might most likely be related to the following issue that was introduced and then later fixed: Fix config validation for integer values by J-N-K · Pull Request #3010 · openhab/openhab-core · GitHub