I’ve created another feature branch on my GitHub repo for the Canvas device support. Please bear in mind that I am stepping in the dark here, because I don’t own such a device, and only rely on the API docs. So all of this remains experimental. However, I hope the issue with the firmware version number is fixed in the JAR which you can try for testing here.
This JAR also works with OH 2.4 - I’ve tested it with my production instance, which also still runs on the current stable release.
i installed your fix for the canvas device and successfully connected to my canvas! thanks a lot for providing this binding!
this is what was able to do in the paper UI:
display the device state
turn the device on/off
control color, brightness, saturation, color temperature
read the name of the current effect (not perfectly in sync, though)
switching the color mode is not possible, the control is read-only
in effect mode, i can type the name of an effect and switch to it. when i type the effect while in solid color mode, nothing happens. that means, there seems to be no way to switch to an effect mode from an arbitrary mode.
i cannot turn on rhythm mode (control is read-only)
Hi Martin.
After copying the new jar file i get this error:
==> /var/log/openhab2/openhab.log <==
2019-07-16 00:06:36.221 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.nanoleaf-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.nanoleaf [256]
Unresolved requirement: Import-Package: com.google.gson; version="[2.8.0,3.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]
Can you help?
Oh, i got the firmeware 3.1.1, not 3.1.2? But i can’t get a newer one in the app.
And the old jar file is working good!
can you try to install this JAR file? This modified version of the binding does not require a minimum version of 2.8 of the GSON lib, which is not fulfilled by openHab 2.4 (which I assume you are running, correct?)
Strange that you don’t get 3.1.2 offered by the app…?
So it seems that in Firmware 3.1.1, the position coordinates of the Rhythm module are still integers… no idea why that changed in 3.1.2…
Great! Thanks a lot for testing the binding with your Canvas device.
You could try to set the refreshInterval to smaller value, e.g. 30 (sec.), which will update the state of the channels more frequently.
Yes, this channel is read-only by design, and changes based on settings made on the other channels (e.g. setting a effect) will change the value of this channel as well (e.g. to Effect mode)
I thought this is possible, but will test if this is the same behaviour with my Aurora device
Do you have a Rhythm module connected to your Canvas device?
thanks for your reply. in the canvas device, the rhythm module is built in, and it seems to behave differently. i made the following observations:
when i turn on a rhythm effect on the device, the “effect” indicator in the paper ui updates to the correct effect name. the “rhythm state” and “rhythm active” controls remain disabled.
i can switch the device to a rhythm mode in openhab by entering its name in the “effect” control.
Hey all,
first of all thanks for your great binding. I bought an Aurora starter kit and been very happy with the integration so far.
I tried finding the most recent JAR and installed
openhab> bundle:list |grep -i nanoleaf
304 x Active x 80 x 2.5.0.201907121940 x openHAB Add-ons :: Bundles :: Nanoleaf Binding
But when doing the second inbox search for the panels, they are found, but remain offline with error message in logfile:
2019-08-12 11:23:53.520 [WARN ] [nternal.handler.NanoleafPanelHandler] - Panel data could not be retrieved: OpenAPI request failed. HTTP response code 404
Since the rest is running fine, I may not have the most recent binding installed? Where can I grab the most recent JAR from?
And there is one thing I need to verify after making sure the most recent version is active. When changing the brightness, the module resets the current effect to just a single color.
I’m just about to write a small bash cli to also parse the Nanoleaf-API in order to see which values are changed, when changing the brightness value in OH.
Thanks
Hi Martin.
Yesterday i updated to OH m3. The bridge is online but no reaction by sending ON/OFF. I delete the binding out of the addon folder and install the M3 binding over Paper UI. Now i get the old problem update job failed. I have the firmeware 3.2.0.
Do you have any ideas?
Thanks and greetings, Markus
Hi, a new pull request with fixes for the known issues (problem with number format of Rhythm module position since firmware version 3.1.2, and setup with missing Rhythm module) has been created, and latest JAR file can now be downloaded from here. This version has been tested successfully on OH 2.4 and 2.5 (latest snapshot).
More stability and Canvas Touch Support is out (2.5.1 / 2.5.2)
To all who are using the nanoleaf binding:
I have put a lot of work into the binding lately and with 2.5.x being out, the binding finally has been made available publicly. So, if anyone doubted the binding being maintained , I can assure you, we are still working on it (I joined forces with Martin).
I highly recommend moving to at least OH 2.5.1 as I worked a lot on the binding to make it more stable in particular with the canvas panel and to use the new touch support. 2.5.2 has even been more stabilized and contains some more debug possibilities in case you run into issues and get in touch with @mraepple or me @stefan.hoehn. 2.5.2 at the time of writing is only available as snapshot though.
New Features
From my own experience it is much more stable now.
Canvas is now officially supported (if I ever get one of the new hex panels, I am happy to work on that, too)
Touch support has been implemented for the Canvas
it detects single and double taps on the panel which can be used in rules to trigger other things
Imagine you click on a panel and the main ceiling light goes on or a rollershutter goes down
Basically, the canvas panels have become home automation switches
see Readme on how to use the touch support on items and in rules.
The Readme of the binding contains much more information regarding Discovery, Configuration, Hints and the new Canvas touch support.
So, we hope that you will like the new functionality as much as we do.
It is now officially part of 2.5.x and touch support for canvas since 2.5.2.
Note: I added a lot to the readme which is very much recommended to be read as it contains a lot of hints how to work successfully with the binding: https://www.openhab.org/addons/bindings/nanoleaf/
Also make sure that you delete your things and readd them as the structure has changed and OH does only pickup the new structure when the things are being recreated.
Hey there,
I had troubles using Nanoleaf binding from the beginning. So I waited for your much appreciated update on the binding. After a long time, I reactivated the setup. So did Nanoleaf update to firmware 3.3.3, and updated the app as well. So now, Nanoleaf works flawlessly using the app.
Then I installed the new Nanoleaf binding
openhab> bundle:list |grep -i nano
247 x Active x 80 x 2.5.2 x openHAB Add-ons :: Bundles :: Nanoleaf Binding
and searched for a new thing using PaperUI discovery. My lamp was found and after pressing the button, nanoleaf item came online.
Then I added some items in order to ON/OFF/dim the Nanoleaf. And this is where it gets wired.
Nanoleaf was still on, when I added the items. This was never picked up by the item. It remained OFF.
So I switched the lamp OFF using the smartphone app. And turned it on using openhab. Which worked. But after 30 seconds the item was set automatically to OFF while the Nanoleaf an the wall is still light up.
Here’s some excerpt from the events and openhab.log
events.log
2020-03-08 18:51:18.436 [ome.event.ItemCommandEvent] - Item 'eg_wz_nanoleaf' received command ON
2020-03-08 18:51:18.437 [nt.ItemStatePredictedEvent] - eg_wz_nanoleaf predicted to become ON
2020-03-08 18:51:18.500 [vent.ItemStateChangedEvent] - eg_wz_nanoleaf changed from OFF to ON
2020-03-08 18:51:50.343 [vent.ItemStateChangedEvent] - eg_wz_nanoleaf changed from ON to OFF
2020-03-08 18:51:50.345 [me.event.ThingUpdatedEvent] - Thing 'nanoleaf:controller:EA00C809CD2D' has been updated.
openhab.log
2020-03-08 18:47:50.232 [INFO ] [al.handler.NanoleafControllerHandler] - Panel layout and ids for controller nanoleaf:controller:EA00C809CD2D
2020-03-08 18:48:50.248 [INFO ] [al.handler.NanoleafControllerHandler] - Panel layout and ids for controller nanoleaf:controller:EA00C809CD2D
2020-03-08 18:49:50.285 [INFO ] [al.handler.NanoleafControllerHandler] - Panel layout and ids for controller nanoleaf:controller:EA00C809CD2D
2020-03-08 18:50:50.324 [INFO ] [al.handler.NanoleafControllerHandler] - Panel layout and ids for controller nanoleaf:controller:EA00C809CD2D
2020-03-08 18:51:50.339 [INFO ] [al.handler.NanoleafControllerHandler] - Panel layout and ids for controller nanoleaf:controller:EA00C809CD2D
I will switch the binding to DEBUG and update this comment. Any idea in the meantime how to get OH and Nanoleaf in sync?
Thanks much
Sebastian
Update:
heres the debug log while events shows the same, heres some DEBUG info at the second when Nanoleaf item gets updated to OFF:
2020-03-08 19:04:51.300 [DEBUG] [al.handler.NanoleafControllerHandler] - Run update job
2020-03-08 19:04:51.300 [DEBUG] [al.handler.NanoleafControllerHandler] - Update channels for controller nanoleaf:controller:EA00C809CD2D
2020-03-08 19:04:51.319 [DEBUG] [nding.nanoleaf.internal.OpenAPIUtils] - API response code: 200
2020-03-08 19:04:51.321 [DEBUG] [al.handler.NanoleafControllerHandler] - Set to device type lightPanels
2020-03-08 19:04:51.325 [DEBUG] [al.handler.NanoleafControllerHandler] - Thing property: key serialNumber value S19082A0713
2020-03-08 19:04:51.327 [DEBUG] [al.handler.NanoleafControllerHandler] - Thing property: key firmwareVersion value 3.3.3
2020-03-08 19:04:51.327 [DEBUG] [al.handler.NanoleafControllerHandler] - Thing property: key modelId value NL22
2020-03-08 19:04:51.328 [DEBUG] [al.handler.NanoleafControllerHandler] - Thing property: key vendor value Nanoleaf
2020-03-08 19:04:51.329 [INFO ] [al.handler.NanoleafControllerHandler] - Panel layout and ids for controller nanoleaf:controller:EA00C809CD2D
2020-03-08 19:04:51.330 [DEBUG] [al.handler.NanoleafControllerHandler] - NOT starting TouchJob for Panel nanoleaf:controller:EA00C809CD2D because it has wrong device type lightPanels
Hi Sebastian.
I have the same problem. I am just writing with Stefan.
30 seconds ist your refresh Intervall?
Perhaps you can help too, to find the problem.
If you use the 2.5.0 Version from October, it should work.
Greetings,
Markus
Thanks Sebastian for providing the detailed logs (especially TRACE helps in that case which is available since 2.5.2).
I was finally able to fix the bug overnight and have built a new binding (Merge request is currently pending) which will then be available with 2.5.3.
Btw, it will also contain an improvement regarding suppressing manually configured things during auto-discovery.
In the meantime, I will dm you and provide you with a link where you can download a version that I built locally, so you can try out if it works for you.
thank you