Binding Request: Nanoleaf Aurora (LED Design Triangle)

Works like a charm :+1:

Iā€™ve added a ā€œcolorā€ channel to the binding which uses the ā€œdisplayā€ command with animType ā€œsolidā€ to set all panels to the same color. Color channel is of item type ā€œColorā€.

Master and README are updated with the new channel, JAR file as well.

Here is a short video showing the binding in action:

1 Like

Hi Martin,

This is great, Iā€™ve tested this new feature with HabPanel and it works perfectly.
Just one thing, with a regular Dimmer, it react to the ON/OFF command and DIM value. This seem to not be the case for the Brightness channel, it donā€™t react to ON or OFF. Do you think this can be improved ?
Anyway thanks for your works !

Hi!

First of all thanks a lot for testing the new binding with your Nanoleaf.

Iā€™ve played a bit with HabPanel (I am not using it for my home automation) and configured a dimmer widget for the Brightness channel and a switch widget for the Power channel. When the panels are in OFF state and I turn the dimmer wheel, the panels turn on and a second or so later the switch turns on as well. This may be delayed by the refresh period configurable on the thing level.

Is that what you mean? Or did I got it wrongā€¦? :thinking:

Yes, youā€™re right, let me explain a little bit more.

As you can see in the OpenHAB documentation, a Dimmer item must understand OnOff, Increase / Decrease and Percent command type (https://www.openhab.org/docs/configuration/items.html#type).
And of course, in HABPanel, you can link a switch widget to a Dimmer Item because it can understand ON and OFF command and use it like a standard switch.

I think that if the device can dim, we should use only a Dimmer Item, and the switch item is intended to be used only with non dimmable device.

So, Iā€™m used to setup my switch widgets to a dimmer channel even if a switch channel exist, and, with this, I donā€™t need to setup 2 Items to do approximately the same things. (a Switch and a Dimmer).

Of course, I can adapt my setup to reach my need, but if it can be improved without much pain, that would be very nice and more OpenHAB compliant.

Best regards.

Thanks for the explanation. Iā€™ve tested the new color channel with basic UI, and when pressing the up/down buttons next to the palette symbol, the handler receives indeed an OnOff command. This is now also properly handled by the binding.
JAR file is updated (as always :wink: )

Martin, did you try control each pannel separately? :face_with_raised_eyebrow:

as each pannel have own ID ā€¦

Iā€™ve tested ON/OFF command on the Color channel and it works, but each command Iā€™ve got the following error in the openhab.log :
2019-01-18 18:01:51.361 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.nanoleaf.internal.handler.NanoleafHandler@35a8b80c': Failed to send OpenAPI request: org.eclipse.jetty.client.HttpResponseException: HTTP protocol violation: bad response on HttpConnectionOverHTTP@1bfaf522(l:/192.168.0.100:36630 <-> r:/192.168.0.106:16021,closed=false)=>HttpChannelOverHTTP@48a112d5(exchange=HttpExchange@484f14b req=TERMINATED/null@null res=PENDING/null@null)[send=HttpSenderOverHTTP@de2b60e(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@2b0df80b{s=START}],recv=HttpReceiverOverHTTP@6bfa6005(rsp=IDLE,failure=null)[HttpParser{s=CLOSE,0 of -1}]]<-SocketChannelEndPoint@48d7ca98{/192.168.0.106:16021<->/192.168.0.100:36630,OPEN,fill=-,flush=-,to=1/0}{io=1/0,kio=1,kro=1}->HttpConnectionOverHTTP@1bfaf522(l:/192.168.0.100:36630 <-> r:/192.168.0.106:16021,closed=false)=>HttpChannelOverHTTP@48a112d5(exchange=HttpExchange@484f14b req=TERMINATED/null@null res=PENDING/null@null)[send=HttpSenderOverHTTP@de2b60e(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@2b0df80b{s=START}],recv=HttpReceiverOverHTTP@6bfa6005(rsp=IDLE,failure=null)[HttpParser{s=CLOSE,0 of -1}]]

org.openhab.binding.nanoleaf.internal.NanoleafException: Failed to send OpenAPI request: org.eclipse.jetty.client.HttpResponseException: HTTP protocol violation: bad response on HttpConnectionOverHTTP@1bfaf522(l:/192.168.0.100:36630 <-> r:/192.168.0.106:16021,closed=false)=>HttpChannelOverHTTP@48a112d5(exchange=HttpExchange@484f14b req=TERMINATED/null@null res=PENDING/null@null)[send=HttpSenderOverHTTP@de2b60e(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@2b0df80b{s=START}],recv=HttpReceiverOverHTTP@6bfa6005(rsp=IDLE,failure=null)[HttpParser{s=CLOSE,0 of -1}]]<-SocketChannelEndPoint@48d7ca98{/192.168.0.106:16021<->/192.168.0.100:36630,OPEN,fill=-,flush=-,to=1/0}{io=1/0,kio=1,kro=1}->HttpConnectionOverHTTP@1bfaf522(l:/192.168.0.100:36630 <-> r:/192.168.0.106:16021,closed=false)=>HttpChannelOverHTTP@48a112d5(exchange=HttpExchange@484f14b req=TERMINATED/null@null res=PENDING/null@null)[send=HttpSenderOverHTTP@de2b60e(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@2b0df80b{s=START}],recv=HttpReceiverOverHTTP@6bfa6005(rsp=IDLE,failure=null)[HttpParser{s=CLOSE,0 of -1}]] at org.openhab.binding.nanoleaf.internal.handler.NanoleafHandler.sendOpenAPIRequest(NanoleafHandler.java:417) ~[?:?] at org.openhab.binding.nanoleaf.internal.handler.NanoleafHandler.sendEffectCommand(NanoleafHandler.java:148) ~[?:?] at org.openhab.binding.nanoleaf.internal.handler.NanoleafHandler.handleCommand(NanoleafHandler.java:181) ~[?:?] at sun.reflect.GeneratedMethodAccessor114.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.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [102:org.eclipse.smarthome.core:0.10.0.oh240] at com.sun.proxy.$Proxy200.handleCommand(Unknown Source) [275:org.openhab.binding.nanoleaf:2.5.0.201901172300] at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:75) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240] at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:49) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240] at sun.reflect.GeneratedMethodAccessor113.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) [?:?]

ā€¦ but it works :slight_smile:

Do you plan to add this code to the Brightness channel also or must I change my HABPanel config to send switchs commands to the Color Channel ?

Best regards

Yes, Iā€™ve added the OnOff command type handling to all remaining channels of type dimmer (brightness and saturation), so I hope you wonā€™t need to change your config in HABPanel.

Iā€™ve checked my logs for similar exceptions but couldnā€™t find any. May be you can give the updated binding JAR a chance and check the logs again.

Best regards

I just didnā€™t tested it because you wrote about Color channel :slight_smile:
To be sure, I deleted my thing, deleted the jar file, downloaded the latest release, scanned for nanoleaf thing, added it and checked that my items were linked correctly.
And it works like a charm ! ON/OFF command on Brightness channel didnā€™t throw any errors but same command to the Color channel gave me the same error as before, but it also works.
I also tested with OpenHAB REST API just to be sure this is not a HABPanel behavior.

Thanks you so much !

Yes, the API would allow us to control each panel separately - Iā€™ve tested that. So it should be possible to keep the binding as it is today with all the channels (brightness, hue, effects ā€¦) for the controller (probably becoming a thing of type bridge then), and handle each panel as a separate thing, e.g. with just a color channel.

Honestly I thought to get started simple with one thing only, and then explore further extensions if needed. In general I believe that the native Nanoleaf app is still the better tool for designing new scenes/effects. It nicely illustrates the currently chosen layout of the panels in the scene editor where you can configure the individual panels. I donā€™t know if something similar could be done in any of the openHAB UIs, but even if it were possible, I think that ā€œdesignā€ should remain with the native app, but ā€œcontrolā€ should be possible with openHAB.

On the other side, I can imagine that you want to dynamically set a static color per panel out of your rules, e.g. to display a visual message depending on some event that happend. One could certainly just design a scene with the native app, and then set it via the effect channel of the binding. But I still see that controlling individual panels could be of value. If you have other ideas/use cases in mind, please me/us know.

Best regards
Martin

This is actually why I started modeling my binding with a Bridge thing (and then the panels as distinct Things, if required by the user). Basically following the hue model.

Hi Nanoleaf-enthusiasts ;-),

Iā€™ve picked up on @CoolTomā€™s and @hakanā€™s idea and played a bit with my existing binding. I enhanced it with a second thing: ā€œlightpanelā€. I renamed the existing thing type to ā€œcontrollerā€. So we now have two types, representing the light panels controller (similar to a bridge) and the individual light panel(s) connected to it.

The controller thing got a new configuration parameter ā€œdiscoverPanelsā€ which can be turned on and off. If turned on for a controller which is online (i.e. has a valid auth token, ip address etc.), all connected panels will be added to the inbox as new things. In my case, I have 13 panels connected to my controller, so I end up with 14 things (1 for the controller, 13 for the panels).

The channels on the controller did not change - effect, brightness etc. remained the same as before. An individual panel exposes one channel of type Color to set the color with a ColorPicker. When sending On or Off to it, the panel turns dark or white.

If you want to play with the extended version, you can get a new JAR from here. The source code is in a new branch in my git repo. The README is updated with an example for the new setup.

@hakan: Hope this goes into the same direction as you proposed initially. Again, curious for any feedback :wink:

This version is still not tested very well and the code could be beautified, but I hope this goes to the right direction.

Best regards
Martin

1 Like

WOW, very nice. I will try and let you know. Thanks for very fast changes.

Iā€™m very curious to give his a test run. Tomorrow maybe, if my Octoprint stops throwing monkey wrenches into my best laid plans :grin:

Something really wird happend. Pannels just turn on in the night. White and stop responding. Later i find out token changed ā€¦ Not sure what binding version i have now. But didnt changed to new bridge/pannels one yet. Does this happend to someone? Pannels are on separate wifi without internet accessā€¦

The same happens here. After reset the Panels through disconnecting power, all runs okay.
Greetings, Markus

Hi Tom, can you try out the new bridge-enabled binding? I am running my panels now with this version of the binding for two days and havenā€™t detected any strange behaviour. Could you find any suspicious log entries when your panels turned on?

Greetings
Martin

I think it was more like panels related problem. You know, once u power them on, they get white. I was not even able switch them off (holding power button) or connect over app. Panels connect to wifi, but they was not responding. I did reset them and it works fine from that time. I didnt find any message in OH log.
I will test new version and let you know

Thanks Tom. When you play with the new version, you may give the new feature a try and add the individual panels as things. To do so, just add the controller (e.g. via auto discovery) to your openHAB instance. Next, in paper UI, go to your things list, select the Nanoleaf controller from it, and switch on ā€œDiscover Panelsā€ (it is by default off) from its configuration settings. You should see immediately new things listed in your inbox, one for each panel of your Nanoleaf.

Hi, so bit of testing. Something is wrong with briteness channel. When i changing briteness (controller) it say its changing color channel. When changing color channel its fine. Same with single pannel. Can not change briteness (wird I added only color channel but it give me color, briteness, saturation) - I can change only color and saturation of the panel:

2019-01-31 02:11:12.773 [ome.event.ItemCommandEvent] - Item 'TRoomNanoleafColor' received command 42

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

2019-01-31 02:11:12.776 [WARN ] [al.handler.NanoleafControllerHandler] - Unhandled command type: org.eclipse.smarthome.core.library.types.PercentType

==> /var/log/openhab2/events.log <==

2019-01-31 02:11:12.782 [nt.ItemStatePredictedEvent] - TRoomNanoleafColor predicted to become 42

2019-01-31 02:11:12.789 [vent.ItemStateChangedEvent] - TRoomNanoleafColor changed from 236,89,73 to 236,89,42

2019-01-31 02:11:14.939 [ome.event.ItemCommandEvent] - Item 'TRoomNanoleafColor' received command 25

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

2019-01-31 02:11:14.944 [WARN ] [al.handler.NanoleafControllerHandler] - Unhandled command type: org.eclipse.smarthome.core.library.types.PercentType

==> /var/log/openhab2/events.log <==

2019-01-31 02:11:14.946 [nt.ItemStatePredictedEvent] - TRoomNanoleafColor predicted to become 25

2019-01-31 02:11:14.964 [vent.ItemStateChangedEvent] - TRoomNanoleafColor changed from 236,89,42 to 236,89,25


2019-01-31 02:11:31.565 [ome.event.ItemCommandEvent] - Item 'TRoomNanoleafColor' received command 95,89,25

2019-01-31 02:11:31.572 [nt.ItemStatePredictedEvent] - TRoomNanoleafColor predicted to become 95,89,25

2019-01-31 02:11:31.587 [vent.ItemStateChangedEvent] - TRoomNanoleafColor changed from 236,89,25 to 95,89,25

------------------------ PANEL ONLY

2019-01-31 02:17:47.740 [ome.event.ItemCommandEvent] - Item 'PanelColor1' received command 83,64,94
2019-01-31 02:17:47.747 [nt.ItemStatePredictedEvent] - PanelColor1 predicted to become 83,64,94
2019-01-31 02:17:47.758 [vent.ItemStateChangedEvent] - PanelColor1 changed from 83,49,94 to 83,64,94
2019-01-31 02:17:48.998 [ome.event.ItemCommandEvent] - Item 'PanelColor1' received command 83,79,94
2019-01-31 02:17:49.005 [nt.ItemStatePredictedEvent] - PanelColor1 predicted to become 83,79,94
2019-01-31 02:17:49.013 [vent.ItemStateChangedEvent] - PanelColor1 changed from 83,64,94 to 83,79,94
2019-01-31 02:17:51.211 [ome.event.ItemCommandEvent] - Item 'PanelColor1' received command 62
==> /var/log/openhab2/openhab.log <==
2019-01-31 02:17:51.216 [WARN ] [nternal.handler.NanoleafPanelHandler] - Unhandled command type: org.eclipse.smarthome.core.library.types.PercentType
==> /var/log/openhab2/events.log <==
2019-01-31 02:17:51.221 [nt.ItemStatePredictedEvent] - PanelColor1 predicted to become 62