Nice. It started working again 
1 Like
It also fixed my problem with writing to panels individually, so thanks
1 Like
After a reboot, it stopped working again until I saved once more…
I managed to pair my nanoleaf controller and it worked for a couple of minutes (I was able to control colours and scenes through OH3 but next time I looked it, it was offline due to some Runtime error:
I repeated the pairing procedure and the API was successfully filled in but then it went directly into offline state.
I checked the openhab.log but there is nothing related to nanoleaf.
So I checked events.log and found this:
2022-11-05 17:39:05.646 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'nanoleaf:controller:83C9B78B4E12' changed from OFFLINE (COMMUNICATION_ERROR): Communication failed. Please check your network and configuration. to OFFLINE: Runtime error. See openHAB log for more details.
2022-11-05 17:43:29.582 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'nanoleaf:controller:83C9B78B4E12' changed from OFFLINE: Runtime error. See openHAB log for more details. to UNKNOWN
2022-11-05 17:43:29.616 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'nanoleaf:controller:83C9B78B4E12' changed from UNKNOWN to OFFLINE (CONFIGURATION_PENDING): No authorization token found. To start pairing, press the on-off button of the controller for 5-7 seconds until the LED starts flashing in a pattern.
2022-11-05 17:43:59.726 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'nanoleaf:controller:83C9B78B4E12' changed from OFFLINE (CONFIGURATION_PENDING): No authorization token found. To start pairing, press the on-off button of the controller for 5-7 seconds until the LED starts flashing in a pattern. to ONLINE
2022-11-05 17:43:59.732 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'nanoleaf:controller:83C9B78B4E12' changed from ONLINE to OFFLINE: Runtime error. See openHAB log for more details.
2022-11-05 17:44:20.213 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'nanoleaf:controller:83C9B78B4E12' changed from OFFLINE: Runtime error. See openHAB log for more details. to UNKNOWN
2022-11-05 17:44:20.232 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'nanoleaf:controller:83C9B78B4E12' changed from UNKNOWN to OFFLINE: Runtime error. See openHAB log for more details.
I went back to òpenhab.log` to check for anything around these timestamps but there is nothing.
How can I troubleshoot this?
We have to look at both logs.
To analyze it more deeply we need to set it to debug.
Then go to the controller thing, disable it and enable it in again in the UI:
Do you have the log viewer running on :9001? Open it and filter for “nano” and see what’s happening.
(I presume you are the latest version)
By the way, sometimes they do go offline but the controller tries to reconnect within a minute.
Thanks for your quick reply.
How do I do that? I can’t seem to find it in the UI…
No. Is it this I need to install?
If so, I’d add something like this to my docker-compose and see what happens:
Oh, and I forgot to mention: I am on OH 3.3.0.
3.3.0 is okay. Yes, frontail. Makes log viewing much easier. See Rules Blockly - Before Using | openHAB
Being on docker may always be something tricky with networking. The binding has a long running open connection …
Regarding logging see Logging | openHAB
The ‘tap’ channel for a panel is not working. I did see some similar discussion above, but here is what is happening for me.
The lightpanel thing defines a ‘tap’ channel:
<thing-type id="lightpanel">
...
<channels>
<channel id="color" typeId="system.color"/>
<channel id="tap" typeId="system.button"/>
</channels>
...
</thing-type>
When I link it I see:
2022-12-03 09:15:06.215 [WARN ] [nternal.handler.NanoleafPanelHandler] - Channel with id tap not handled
And indeed in the code, in the PanelHandler, handleCommand:
try {
switch (channelUID.getId()) {
case CHANNEL_PANEL_COLOR:
sendRenderedEffectCommand(command);
break;
default:
logger.warn("Channel with id {} not handled", channelUID.getId());
break;
}
there is no case to handle the ‘tap’.
(Using 3.3.0, but source code from current main branch)
Did you check Nanoleaf - Bindings | openHAB ?
As it explains there is no TAP-Channel but rather a Trigger. That was a breaking some months ago as a channel wasn’t the right solution.
What you are looking for in the code is the following
public void updatePanelGesture(int gesture) {
switch (gesture) {
case 0:
triggerChannel(CHANNEL_PANEL_TAP, CommonTriggerEvents.SHORT_PRESSED);
break;
case 1:
triggerChannel(CHANNEL_PANEL_TAP, CommonTriggerEvents.DOUBLE_PRESSED);
break;
}
}
Does that help?
I am 100% sure it is related to the fractional part being saved to the json-db. Can you please check the entries of the panel thing first to make sure it does not contain something like “54086.0”?
I enabled TRACE logging and found this:
2022-12-04 15:38:25.727 [DEBUG] [al.handler.NanoleafControllerHandler] - touch detected for controller nanoleaf:controller:741ADCF0C4B8
2022-12-04 15:38:25.730 [TRACE] [al.handler.NanoleafControllerHandler] - content id: 4
data: {"events":[{"panelId":42633,"gesture":0}]}
2022-12-04 15:38:25.732 [DEBUG] [al.handler.NanoleafControllerHandler] - panel: 42633 gesture id: 0
Now, I only did the re-saving exercise on this one panel out of my 102.
Further down in the log:
2022-12-04 15:38:25.759 [TRACE] [al.handler.NanoleafControllerHandler] - Checking available panel -42995.0- versus event panel -42633-
2022-12-04 15:38:25.760 [TRACE] [al.handler.NanoleafControllerHandler] - Checking available panel -42633.0- versus event panel -42633-
2022-12-04 15:38:25.760 [TRACE] [al.handler.NanoleafControllerHandler] - Checking available panel -3654.0- versus event panel -42633-
Could it be a side effect of not re-saving all panels things?
Oh, and I’m currently on:
openhab> list | grep -i nano
258 │ Active │ 80 │ 3.4.0.M1 │ openHAB Add-ons :: Bundles :: Nanoleaf Binding
You need to save each panel individually that is affected unfortunately afaik or edit the json file.
As long as there is a “.0” in the id it won’t detect it as equal.
But I only use gestures on this single panel. It works fine just after the re-save, but fails again after a OH3 restart.
So what is the Id of that single panel and can you send a trace when press that one?
If that single panel still has a .0 I am kind of confused. I would then say, we should ping the J-N-K and ask him if he has an idea why it behaves that way on your side.
The Id is 42633 as shown in this post:
Ok, so it does say “touch detected” for 42633 but the id is still (or again) 42633.0 (“Checking available panel -42633.0- versus event panel -42633-”). Hence, the json-setting is broken.
Thanks for the reply Stefan!
While I did use the docs to configure my setup I completely missed the part about the triggering channel, which is in fact a new concept to me, so once again thanks for pointing it out!
I did run into another issue after that. It seems the ‘long running client’ httpClientSSETouchEvent never got initialized as seen from this logging:
2022-12-04 16:53:39.206 [TRACE] [al.handler.NanoleafControllerHandler] - tj: touch job 920870700 started for new request -1 controller nanoleaf:controller:836ec07a7213 with null",
‘null’ is where it logs the httpClientSSETouchEvent value.
I tried restarting openHab, restarting the NUC, deleting the things, deleting the binding but it wasn’t working. This morning however I did a simple ‘Pause’ … wait … ‘Unpause’ of the controller in the web interface and now it’s working.
(And indeed in the logging I did see the line:
09:19:28.955 [DEBUG] [nal.handler.NanoleafControllerHandler] - Using long SSE httpClient=HttpClient@274783e8{STARTED} for 836ec07a7213}
which gets logged upon the succesful creation of httpClientSSETouchEvent.
Not sure why this happened. I am using thing/item files to configure everything.
Looking at the initialize I did see that whether or not the httpClientSSETouchEvent gets initialized actually does not depend on the LightPanels/Canvas deviceType configuration but on the modelId property of the device (which is then used to overrule the deviceType).
So possibly, in my case, this got done before the modelId was obtained from the device which resulted in the httpClientSSETouchEvent not being initialized. Then again, that should have resulted in the deviceType being overruled to LightPanels and thus I should not have seen any of the ‘tj:’ lines in the logging, but there was one every second in the trace log.
I’ll keep an eye on it, especially what happens when I have to reboot my system a next time.
1 Like
Hi, apologies to jump on the existing thread but searching has led me to this forum and your code snippet shows exactly what I’m looking for. I am migrating my setup from iobroker, and their binding can also handle a long-press (gesture id = 6, it’s undocumented but it works). I’ve been trying to figure out how to edit my config to handle this case as it allows more flexibility with rules per panel. I was just hoping to test it out with my local install. Is it at all possible for me to only edit my local binding to include this in your case statement, such that:
switch (gesture) {
case 0:
triggerChannel(CHANNEL_PANEL_TAP, CommonTriggerEvents.SHORT_PRESSED);
break;
case 1:
triggerChannel(CHANNEL_PANEL_TAP, CommonTriggerEvents.DOUBLE_PRESSED);
break;
case 6:
triggerChannel(CHANNEL_PANEL_TAP, CommonTriggerEvents.LONG_PRESSED);
break;
If it is not possible, that’s okay, I understand. Or, if this is the wrong place for this comment I apologise. I’ve been searching for any kind of configuration files in my openHAB install so that I could add the gesture id ‘6’ to listen for.
It is not clear to me what you are asking. Nanoleafs do not have “long press”. They have touch and swipe.
- What do you mean with “their binding”?
- Is this related to the Nanoleaf binding?
- What is it that you want to achieve?