[SOLVED] Lutron pico " Unable to determine channel for component 2 in keypad update event message" warning

daz10000 · March 11, 2019, 12:10am

Platform Pi

Linux 14.71-v7+ #1145 SMP armv7l GNU/Linux
Java: openjdk version “1.8.0_152”
OpenJDK Runtime Environment (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 1.8.0_152-b76)
OpenJDK Client VM (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 25.152-b76, mixed mode, Evaluation)
Openhab v 2.4.0-1

Issue

I am attempting to integrate a lutron pico into OH2 via the lutron bridge. The bridge is otherwise working fine (I have controlled various devices from OH2 to the bridge). This is the first time I am going the other way, having a switch inside the lutron bridge attempt to communicate with OH2

I have the pico switch configured according to the docs here (note the last line defines the pico switch in question “nook”.

Thing lutron:ipbridge:radiora2 [ ipAddress="X.X.X.X", user="X", password="X" ]
Thing lutron:switch:lobby "Lobby" (lutron:ipbridge:radiora2) @ "Lobby" [ integrationId=7 ]
Thing lutron:switch:kitchen "Kitchen" (lutron:ipbridge:radiora2) @ "Kitchen" [ integrationId=6 ]
Thing lutron:pico:nook (lutron:ipbridge:radiora2) [ integrationId=11, model="4B",autorelease="true" ]

The OH2 instance does sort of acknowledge the pico switch, but with some caveats / errors within PaperUI. It is uninitialized and there is a java cast error which is not super instructive, string that should be a bool… hmm.

The log event entries tell a similar story of failed initialization

2019-03-10 15:33:31.474 [hingStatusInfoChangedEvent] - 'lutron:pico:nook' changed from UNINITIALIZED (HANDLER_INITIALIZING_ERROR): java.lang.String cannot be cast to java.lang.Boolean to UNINITIALIZED (HANDLER_MISSING_ERROR)
2019-03-10 15:33:31.482 [hingStatusInfoChangedEvent] - 'lutron:pico:nook' changed from UNINITIALIZED (HANDLER_INITIALIZING_ERROR): java.lang.String cannot be cast to java.lang.Boolean to INITIALIZING
2019-03-10 15:33:31.497 [hingStatusInfoChangedEvent] - 'lutron:pico:nook' changed from INITIALIZING to UNINITIALIZED (HANDLER_INITIALIZING_ERROR): java.lang.String cannot be cast to java.lang.Boolean

Status: UNINITIALIZED - HANDLER_INITIALIZING_ERROR java.lang.String cannot be cast to java.lang.Boolean

The only other odd thing is that in the properties in the paper UI, the pico model field is empty (even though I specified it in the thing file) and you can’t edit it (409 ERROR conflict) if you try to manually edit it. I am pretty sure 4B is a valid config value in the docs.

When I press a button on the pico, it does send an event to OH2, but the log entry suggests that OH2 can’t handle it. This is from the openhab logs as I press the button. It refers to component 2. Not sure where the 2 is coming from, the pico is integrationId 11 according to my dump of the system.

2019-03-10 16:06:59.946 [WARN ] [n.internal.handler.BaseKeypadHandler] - Unable to determine channel for component 2 in keypad update event message

Any thoughts appreciated. I will continue to randomly mutate things in the interim to see if I can get success. I will say the lutron docs are good as far as they go, but plenty of guessing involved. It took me a lot of trial and error for example to work out how to include location in the Thing configuration and it didn’t match any of the examples ( you have to split the “name” @ “location” string with the bridge name in the middle )

Thing lutron:switch:kitchen "Kitchen" (lutron:ipbridge:radiora2) @ "Kitchen" [ integrationId=6 ]

Addendum

I decided to tidy up the pico entry and add a location to the thing definition, specifically

Thing lutron:pico:nook (lutron:ipbridge:radiora2) @ "Nook" [ integrationId=11, model="4B",autorelease="true" ]

and this delivered this beautiful traceback in the openhab logs which might be helpful in pinpointing where the type cast error is happening. Going to peek at the source myself now.

2019-03-10 16:13:10.932 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.lutron.internal.handler.PicoKeypadHandler@5297ee': java.lang.String cannot be cast to java.lang.Boolean
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean
        at org.openhab.binding.lutron.internal.handler.BaseKeypadHandler.initialize(BaseKeypadHandler.java:173) ~[?:?]
        at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.10.0.oh240]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]
2019-03-10 16:13:10.945 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'lutron:pico:nook': java.lang.String cannot be cast to java.lang.Boolean
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean
        at org.openhab.binding.lutron.internal.handler.BaseKeypadHandler.initialize(BaseKeypadHandler.java:173) ~[?:?]
        at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.10.0.oh240]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

daz10000 · March 11, 2019, 12:27am

Incidentally, the lutron docs seem to be inconsistent on the syntax for the things

In particular openhab2-addons/addons/binding/org.openhab.binding.lutron/README.md

has variations on whether there is a comma between the model and autorelease sections. These examples have none

Thing lutron:keypad:entrykeypad (lutron:ipbridge:radiora2) [ integrationId=10, model="W7B" autorelease="true" ]
Thing lutron:ttkeypad:bedroomkeypad (lutron:ipbridge:radiora2) [ integrationId=11, model="T10RL" autorelease="true" ]

This one and others does have the extra comma and it seems to break (more) without the comma, that with, so assuming this is the correct syntax.

Thing lutron:pico:hallpico (lutron:ipbridge:radiora2) [ integrationId=12, model="3BRL", autorelease="true" ]

daz10000 · March 11, 2019, 12:49am

The string to boolean conversion problem might be unrelated to the core warning about being unable to determine channel for component 2. As an experiment, I removed the autorelease="true" part of the config line and the type conversion is presumably related to that. The component channel errors still occur when I press the button. Experimenting a little more I get a different component number for each button pressed. On very close examination of the pico switch, it actually has 5 buttons, not 4 which is puzzling, as the valid options for model are 2B, 2BRL, 3B, 3BRL, 4B, Generic (default).

So, as a final experiment, I took the quotes off the “true” part of the config line so it reads

Thing lutron:pico:nook (lutron:ipbridge:radiora2) [ integrationId=11,model="4B",autorelease=true ]

and this no longer throws the string to boolean error (which makes sense). The docs are just wrong

daz10000 · March 11, 2019, 2:34am

So solved this in the end. The final problem was the model. It turns out my 5 button pico is a “3BRL” and if I used “4B” I get the error messages about the channel / components. Overall my takeaway is the lutron docs could use a few small improvements. I will try to put in a PR with my discoveries.

BobA · July 13, 2019, 1:07am

Hi Darren. Thanks very much for pointing out the problems with the docs for the Lutron binding. I had known that the config file examples were in need of a rewrite, but I wasn’t aware that the existing examples were quite that broken.

I’ve created openhab2-addons PR #5823 for a documentation update using new configuration examples that I’ve tested myself. The new Thing configuration examples use the Bridge construct documented here which I think is much simpler than the other way of referencing a bridge in Thing definitions.

The examples could still probably be better and more comprehensive, but at least they are no longer incorrect!