search

OpenLightingProject / ola

The Open Lighting Architecture - The Travel Adaptor for the Lighting Industry
https://www.openlighting.org/ola/
Other
634 stars 202 forks source link

Nanoleaf Panel id outdated #1730

Open SaiCode-DEV opened 3 years ago

SaiCode-DEV commented 3 years ago

My Panel ID from one of my Nanoleafs is 54510, and i always get the error invaid value returned. (plugins/nanoleaf/NanoleafDevice.cpp:82)

it seems the variable for panels is too small for new gens. (uint_8_t => max 255)

SaiCode-DEV commented 3 years ago

i tried myself to change it to uint_32_t , but build fails

peternewman commented 3 years ago

My Panel ID from one of my Nanoleafs is 54510, and i always get the error invaid value returned. (plugins/nanoleaf/NanoleafDevice.cpp:82)

it seems the variable for panels is too small for new gens. (uint_8_t => max 255)

Are they one of the new shapes like square or something?

i tried myself to change it to uint_32_t , but build fails

What error do you get? You'll need to change the other panels related variable in that function, and the NanoleafNode class.

The real question is how this impacts the animation sending code in here: https://github.com/OpenLightingProject/ola/blob/b666b6f6fb834cb212379543ac0fba691e2f3f2f/plugins/nanoleaf/NanoleafNode.cpp#L117-L120

If that has a completely new format then it will need a bit more rewriting than just changing the size of a field in a few places...

SaiCode-DEV commented 3 years ago

Are they one of the new shapes like square or something? They are the Hexagons, i bought 60 of them and it would be super cool to get it working.

If you have any ideas, i will try them out.

i am not good in programming, but i know that uint8_t is too small, and the programm only allows max 255 as the panel id

peternewman commented 3 years ago

Okay, so I've checked the docs:

Please note the Light panels support streaming control version v1 and v2. Canvas supports stream control version v2 and requires specifying the version in the request. If the extControlVersion key is omitted, v1 is assumed, which would return an error for Canvas.

Light Panels and Canvas use a different external control streaming protocols. Light Panels uses stream control v1 or v2, while Canvas uses stream control v2.

In order to support the much larger number of panels on Canvas, the size of the nPanels, panelId and tranitionTime fields have been increased from 1B to 2B. The nFrames field has been dropped as it was set to 1 in v1 anyway

Note that all the multi-byte fields are represented in Big Endian format

From https://forum.nanoleaf.me/docs/openapi (behind a registration wall).

So it should be fairly easy to fix (or ideally support both), you also get the ability to control the white individually too if you want. Unfortunately I can't work on it for a little while, so either have a go at hacking around with it yourself, or I'll pick it up when I can.

This would also want linking into #1390 and/or #1485

peternewman commented 2 years ago

Hi @SaiBot-YT

Give this a go: https://github.com/OpenLightingProject/ola/pull/1738

I think it should do the trick, if you can test it and let us know would be good.

peternewman commented 2 years ago

@SaiBot-YT have you had a chance to look at this yet?

peternewman commented 2 years ago

Ping @SaiBot-YT are you still interested in testing this?

peternewman commented 2 years ago

Hi @SaiBot-YT are you able to test this so we can get it merged?

erhan- commented 2 years ago

Dear @peternewman ,

I have nanoleaf shapes in some rooms and want to connect them to soundswitch on my denon prime go (engine light).

I am compiling your branch and will try to get it working. I will report back if it works.

edit: Unfortunately I am getting stuck with easy things while compiling for and on a Rpi with raspbian: 

configure: error: Missing cppunit, please install >= 1.9.6
[...]
Package cppunit is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  libcppunit-dev libcppunit-doc
peternewman commented 2 years ago

edit: Unfortunately I am getting stuck with easy things while compiling for and on a Rpi with raspbian:

Ah, which instructions are you following?

However the following packages replace it:
  libcppunit-dev libcppunit-doc

Have you tried installing libcppunit-dev instead?

erhan- commented 2 years ago

Yes, sure. There were quite some packages missing from those listed in the Debian readme here. It might be because of Raspbian but I can find the packages at least here: http://raspbian.raspberrypi.org/raspbian/pool/main/c/cppunit/

erhan:~ $ sudo apt-get install libcppunit-dev libcppunit-1.13-0 uuid-dev pkg-config       libncurses5-dev libtool autoconf automake g++ libmicrohttpd-dev       libmicrohttpd10 protobuf-compiler libprotobuf-lite10 python-protobuf       libprotobuf-dev libprotoc-dev zlib1g-dev bison flex make libftdi-dev       libftdi1 libusb-1.0-0-dev liblo-dev libavahi-client-dev python-numpy
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libcppunit-1.13-0
E: Couldn't find any package by glob 'libcppunit-1.13-0'
E: Couldn't find any package by regex 'libcppunit-1.13-0'
E: Unable to locate package libmicrohttpd10
E: Unable to locate package libprotobuf-lite10

 $ apt-cache search cppunit
cxxtest - lightweight xUnit-like framework for C/C++ applications
libcppunit-1.14-0 - Unit Testing Library for C++
libcppunit-dev - Unit Testing Library for C++
libcppunit-doc - Unit Testing Library for C++
libcppunit-subunit-dev - SubunitTestProgressListener for CPPUnit - Development headers
libcppunit-subunit0 - SubunitTestProgressListener for CPPUnit - C++ shared library
libcunit1 - Unit Testing Library for C
libcunit1-dev - Unit Testing Library for C -- development files
libcunit1-doc - Unit Testing Library for C -- documentation
libcunit1-ncurses - Unit Testing Library for C (ncurses)
libcunit1-ncurses-dev - Unit Testing Library for C (ncurses) -- development files

Activated source via debian. Compiled and installed cppunit 1.15.1: configure: error: Missing cppunit, please install >= 1.9.6

I am interested in getting this running. I had a small poc wrapper for the openapi which acted like the WLED api and let me change the colors via the http api. But at the end I also want to connect to artnet, so I hope I get this running.

peternewman commented 2 years ago

Yes, sure. There were quite some packages missing from those listed in the Debian readme here.

Which Debian readme, the one in the repo?

It might be because of Raspbian but I can find the packages at least here: http://raspbian.raspberrypi.org/raspbian/pool/main/c/cppunit/

It may just be a bit out of date, as they keep releasing new packages.

 $ apt-cache search cppunit
cxxtest - lightweight xUnit-like framework for C/C++ applications
libcppunit-1.14-0 - Unit Testing Library for C++
libcppunit-dev - Unit Testing Library for C++
libcppunit-doc - Unit Testing Library for C++
libcppunit-subunit-dev - SubunitTestProgressListener for CPPUnit - Development headers
libcppunit-subunit0 - SubunitTestProgressListener for CPPUnit - C++ shared library
libcunit1 - Unit Testing Library for C
libcunit1-dev - Unit Testing Library for C -- development files
libcunit1-doc - Unit Testing Library for C -- documentation
libcunit1-ncurses - Unit Testing Library for C (ncurses)
libcunit1-ncurses-dev - Unit Testing Library for C (ncurses) -- development files

Just install libcppunit-1.14-0 then!

Activated source via debian. Compiled and installed cppunit 1.15.1: configure: error: Missing cppunit, please install >= 1.9.6

Can you share your config.log (or just try 1.14.0 instead).

I am interested in getting this running. I had a small poc wrapper for the openapi which acted like the WLED api and let me change the colors via the http api. But at the end I also want to connect to artnet, so I hope I get this running.

Ah cool, yeah I think we should be able to sort it, it wasn't a very complicated change to the API, I just didn't have any ability to test it.

erhan- commented 2 years ago

Yes, the README.debian was used.

I have that package already actually:

~/ola $ sudo apt install libcppunit-1.14-0
[sudo] password for erhan:
Reading package lists... Done
Building dependency tree
Reading state information... Done
libcppunit-1.14-0 is already the newest version (1.14.0-3).
0 upgraded, 0 newly installed, 0 to remove and 13 not upgraded.

[...]

checking SaleaeDeviceApi.h presence... no
checking for SaleaeDeviceApi.h... no
configure: WARNING: SaleaeDevice library is not usable.
checking for cppunit-config... no
checking for Cppunit - version >= 1.9.6... no
configure: error: Missing cppunit, please install >= 1.9.6

Thats why I was trying to get the package cppunit itself. config.log

peternewman commented 2 years ago

Do you have libcppunit-dev too?

Thats why I was trying to get the package cppunit itself.

It's the same thing, just different names for it.

config.log

Sorry, I meant the OLA config.log where it fails to find cppunit.

erhan- commented 2 years ago 
~/ola $ sudo apt list --installed | grep cpp

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

cpp-8/oldstable,now 8.3.0-6+rpi1 armhf [installed,automatic]
cpp/oldstable,now 4:8.3.0-1+rpi2 armhf [installed,automatic]
libcppunit-1.14-0/oldstable,now 1.14.0-3 armhf [installed]
libcppunit-dev/oldstable,now 1.14.0-3 armhf [installed]

Yes, I have it installed.

Which log file to you mean? Thats the log file in the git directory when I try to run ./configure .

configure:16252: checking for cppunit-config
configure:16283: result: no
configure:16293: checking for Cppunit - version >= 1.9.6
configure:16297: result: no
configure:16353: error: Missing cppunit, please install >= 1.9.6
sudo find / -name *cppunit*
/var/lib/dpkg/info/libcppunit-dev.md5sums
/var/lib/dpkg/info/libcppunit-1.14-0:armhf.list
/var/lib/dpkg/info/libcppunit-1.14-0:armhf.triggers
/var/lib/dpkg/info/libcppunit-dev.list
/var/lib/dpkg/info/libcppunit-1.14-0:armhf.md5sums
/var/lib/dpkg/info/libcppunit-1.14-0:armhf.shlibs
/var/cache/apt/archives/libcppunit-1.14-0_1.14.0-3_armhf.deb
/var/cache/apt/archives/libcppunit-dev_1.14.0-3_armhf.deb
/usr/include/cppunit
/usr/local/include/cppunit
/usr/local/lib/libcppunit-1.14.so.0.0.0
/usr/local/lib/pkgconfig/cppunit.pc
/usr/local/lib/libcppunit-1.14.so.0
/usr/local/lib/libcppunit.a
/usr/local/lib/libcppunit.la
/usr/local/lib/libcppunit.so
/usr/local/share/doc/cppunit
/usr/lib/arm-linux-gnueabihf/libcppunit-1.14.so.0.0.0
/usr/lib/arm-linux-gnueabihf/pkgconfig/cppunit.pc
/usr/lib/arm-linux-gnueabihf/libcppunit-1.14.so.0
/usr/lib/arm-linux-gnueabihf/libcppunit.a
/usr/lib/arm-linux-gnueabihf/libcppunit-1.14.so
/usr/lib/arm-linux-gnueabihf/libcppunit.so
/usr/share/doc/libcppunit-1.14-0
/usr/share/doc/libcppunit-dev

I tried using a docker image to build everything on x64 on a totally different system. I had to make some changes to the following image but the error at the end is the same with the right packages installed. I think something is wrong with the check.

configure: WARNING: SaleaeDevice library is not usable.
checking for cppunit-config... no
checking for Cppunit - version >= 1.9.6... no
configure: error: Missing cppunit, please install >= 1.9.6
The command '/bin/sh -c ./configure --disable-all-plugins --enable-e131 --enable-espnet --enable-artnet --enable-dummy --disable-libftdi --disable-libusb --disable-uart --disable-osc --disable-root-check' returned a non-zero code: 1

https://github.com/JustGav/docker-ola changes to get it running up to that point:

# Use phusion/baseimage as base image. To make your builds reproducible, make
# sure you lock down to a specific version, not to `latest`!
# See https://github.com/phusion/baseimage-docker/blob/master/Changelog.md for
# a list of version numbers.
FROM ubuntu:bionic

# Use baseimage-docker's init system.
CMD ["/sbin/my_init"]

# Install updates
RUN apt-get update
RUN apt-get -y dist-upgrade
RUN apt-get install -y wget curl supervisor

# Install OLA dependencies
RUN apt-get install -y git-core
RUN apt-get install -y build-essential

# Download ola development files
RUN apt-get update
RUN apt-get install -y libcppunit-dev libcppunit-1.14-0 uuid-dev pkg-config libncurses5-dev libtool autoconf \
automake  g++ libmicrohttpd-dev  libmicrohttpd12 protobuf-compiler libprotobuf-lite10 python-protobuf libprotobuf-dev \
libprotoc-dev zlib1g-dev bison flex make libftdi-dev  libftdi1 libusb-1.0-0-dev liblo-dev libavahi-client-dev doxygen libcppunit-dev

WORKDIR /tmp
RUN git clone https://github.com/peternewman/ola.git nanoleaf
WORKDIR /tmp/nanoleaf
RUN git checkout nanoleaf
RUN autoreconf -i
RUN ./configure --disable-all-plugins --enable-e131 --enable-espnet --enable-artnet --enable-dummy --disable-libftdi --disable-libusb --disable-uart --disable-osc --disable-root-check --disable-unittests
RUN make
RUN make install
RUN ldconfig
WORKDIR /

# Install avahi pieces required
RUN mkdir -p /var/run/dbus

Could you create a rpm for redhat or a deb for raspbian maybe instead so that I at least can test it for this PR?

edit: Or how can I disable unittests?

https://github.com/OpenLightingProject/ola/commit/f9a4cbad880f5d4d45a65a8f95fd56f5686a4bab

it is --disable-unittests but I dont know where to use it as argument.

Edit2: it is during ./configure . I am trying again now.

The RPI version is still compiling after debuild. The docker x64 version gets stuck here:

protoc/CppGenerator.cpp: In member function 'virtual bool ola::CppGenerator::Generate(const google::protobuf::FileDescriptor*, const string&, google::protobuf::compiler::OutputDirectory*, std::__cxx11::string*) const':
protoc/CppGenerator.cpp:52:3: error: 'template<class> class std::auto_ptr' is deprecated [-Werror=deprecated-declarations]
   auto_ptr<google::protobuf::io::ZeroCopyOutputStream> header_output(
   ^~~~~~~~
In file included from /usr/include/c++/7/memory:80:0,
                 from /usr/include/google/protobuf/descriptor.h:57,
                 from protoc/CppGenerator.cpp:20:
/usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
   template<typename> class auto_ptr;
                            ^~~~~~~~
protoc/CppGenerator.cpp:57:3: error: 'template<class> class std::auto_ptr' is deprecated [-Werror=deprecated-declarations]
   auto_ptr<google::protobuf::io::ZeroCopyOutputStream> code_output(
   ^~~~~~~~
In file included from /usr/include/c++/7/memory:80:0,
                 from /usr/include/google/protobuf/descriptor.h:57,
                 from protoc/CppGenerator.cpp:20:
/usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
   template<typename> class auto_ptr;
                            ^~~~~~~~
cc1plus: all warnings being treated as errors
make: *** [protoc/CppGenerator.o] Error 1

edit:

Unfortunately the rpi rebooted. /tmp/ is gone :) . I am trying again with my server.

 ---> 89aa4776a0b2
Step 28/28 : CMD supervisord -c /etc/supervisor/supervisord.conf
 ---> Running in ddda33ce0c2f
Removing intermediate container ddda33ce0c2f
 ---> 4ee01622b7d2
Successfully built 4ee01622b7d2

Forgot to enable nanoleaf plugin ...

edit:

So everything is up and running. I can see the webinterface and set the configuration for nanoleaf (shapes) and artnet:

192.168.52.64-panels = 15
192.168.52.64-port = 60221
192.168.52.64-version = v2
controller = 192.168.52.64
enabled = true
always_broadcast = true
enabled = true
ip = 192.168.50.10
long_name = OLA - ArtNet node
net = 0
output_ports = 4
short_name = OLA - ArtNet node
subnet = 0
use_limited_broadcast = true
use_loopback = false

Unfortunately there are no changes to the panels and also it is not detected by other artnet devices. I have to tinker around.

grafik grafik grafik

When I add or remove the universe with artnet input, I can see it in the devices list of soundswitch for just a second and then it is gone.

Looking at the documentation of nanoleaf, the port has to be 60222. Still no luck though.

Maybe we can look at other implementations: https://github.com/hyperion-project/hyperion.ng/blob/master/libsrc/leddevice/dev_net/LedDeviceNanoleaf.cpp

peternewman commented 2 years ago

Yes, I have it installed.

Hmm strange, hopefully the log will reveal more.

Which log file to you mean? Thats the log file in the git directory when I try to run ./configure .

That log begins with: It was created by cppunit configure 1.14.0

So it looks like you've uploaded the cppunit config.log from your attempt to compile that, rather than the OLA one. You didn't check them both out into the same directory did you?

sudo find / -name *cppunit*
/var/lib/dpkg/info/libcppunit-dev.md5sums
/var/lib/dpkg/info/libcppunit-1.14-0:armhf.list
/var/lib/dpkg/info/libcppunit-1.14-0:armhf.triggers
/var/lib/dpkg/info/libcppunit-dev.list
/var/lib/dpkg/info/libcppunit-1.14-0:armhf.md5sums
/var/lib/dpkg/info/libcppunit-1.14-0:armhf.shlibs
/var/cache/apt/archives/libcppunit-1.14-0_1.14.0-3_armhf.deb
/var/cache/apt/archives/libcppunit-dev_1.14.0-3_armhf.deb
/usr/include/cppunit
/usr/local/include/cppunit
/usr/local/lib/libcppunit-1.14.so.0.0.0
/usr/local/lib/pkgconfig/cppunit.pc
/usr/local/lib/libcppunit-1.14.so.0
/usr/local/lib/libcppunit.a
/usr/local/lib/libcppunit.la
/usr/local/lib/libcppunit.so
/usr/local/share/doc/cppunit
/usr/lib/arm-linux-gnueabihf/libcppunit-1.14.so.0.0.0
/usr/lib/arm-linux-gnueabihf/pkgconfig/cppunit.pc
/usr/lib/arm-linux-gnueabihf/libcppunit-1.14.so.0
/usr/lib/arm-linux-gnueabihf/libcppunit.a
/usr/lib/arm-linux-gnueabihf/libcppunit-1.14.so
/usr/lib/arm-linux-gnueabihf/libcppunit.so
/usr/share/doc/libcppunit-1.14-0
/usr/share/doc/libcppunit-dev

I'd remove the stuff in /usr/local that's only likely to cause issues if you've got the deb packages installed too.

I think something is wrong with the check.

Maybe, the config.log should help to discern that, but knowing what OS version you're using would help.

Although given your Docker seems to be Bionic, we built fine three months ago like that as you can see on Travis: https://app.travis-ci.com/github/OpenLightingProject/ola/jobs/561310397

You can see the packages we use in the apt config here: https://app.travis-ci.com/github/OpenLightingProject/ola/jobs/561310397/config

The command '/bin/sh -c ./configure --disable-all-plugins --enable-e131 --enable-espnet --enable-artnet --enable-dummy --disable-libftdi --disable-libusb --disable-uart --disable-osc --disable-root-check' returned a non-zero code: 1

FWIW, I'd change the configure line to this and it should build quicker: ./configure --disable-all-plugins --enable-artnet --enable-nanoleaf --disable-root-check

Could you create a rpm for redhat or a deb for raspbian maybe instead so that I at least can test it for this PR?

That's probably not going to be practical/effective given this and it would add yet another step to any diagnostics: https://www.openlighting.org/ola/get-help/ola-faq/#Can_you_add_support_for_the_ltinsert-name-heregt_device

Also if you're having the issue, there's a good chance others will be too, so I'd like to try and fix it for everyone rather than just workaround it here.

edit: Or how can I disable unittests? it is --disable-unittests but I dont know where to use it as argument. Edit2: it is during ./configure . I am trying again now.

Indeed.

The RPI version is still compiling after debuild.

Personally I'd skip the debuild and just compile it standalone/locally until you've got it going. ccache might help speed things up too.

The docker x64 version gets stuck here:

protoc/CppGenerator.cpp: In member function 'virtual bool ola::CppGenerator::Generate(const google::protobuf::FileDescriptor*, const string&, google::protobuf::compiler::OutputDirectory*, std::__cxx11::string*) const':
protoc/CppGenerator.cpp:52:3: error: 'template<class> class std::auto_ptr' is deprecated [-Werror=deprecated-declarations]
   auto_ptr<google::protobuf::io::ZeroCopyOutputStream> header_output(
   ^~~~~~~~
In file included from /usr/include/c++/7/memory:80:0,
                 from /usr/include/google/protobuf/descriptor.h:57,
                 from protoc/CppGenerator.cpp:20:
/usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
   template<typename> class auto_ptr;
                            ^~~~~~~~
protoc/CppGenerator.cpp:57:3: error: 'template<class> class std::auto_ptr' is deprecated [-Werror=deprecated-declarations]
   auto_ptr<google::protobuf::io::ZeroCopyOutputStream> code_output(
   ^~~~~~~~
In file included from /usr/include/c++/7/memory:80:0,
                 from /usr/include/google/protobuf/descriptor.h:57,
                 from protoc/CppGenerator.cpp:20:
/usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
   template<typename> class auto_ptr;
                            ^~~~~~~~
cc1plus: all warnings being treated as errors
make: *** [protoc/CppGenerator.o] Error 1

Adding --disable-fatal-warnings to ./configure should workaround that, but can you raise a new issue for it, as it's something else we ought to fix too.

So everything is up and running. I can see the webinterface and set the configuration for nanoleaf (shapes) and artnet:

That's great to hear!

192.168.52.64-panels = 15
192.168.52.64-port = 60221
192.168.52.64-version = v2
controller = 192.168.52.64
enabled = true

I assume you've seen the plugin help (also available here): http://docs.openlighting.org/ola/conf/ola-nanoleaf.conf.html

Is 15 one of your panel IDs?

Also have you manually enabled the streaming external control effects functionality of the Aurora OpenAPI. The plugin doesn't currently do it automagically (unlike that Hyperion one).

Both of the above are future enhancements listed against #1390 .

Unfortunately there are no changes to the panels and also it is not detected by other artnet devices. I have to tinker around.

I'd start by splitting the problem in two, use the OLA web UI to try and control the Nanoleaf universe, without bothering with Art-Net. Secondly use the monitor part of the web UI to troubleshoot the Art-Net issue. Although if it's in a Docker container you might need to port forward or more.

When I add or remove the universe with artnet input, I can see it in the devices list of soundswitch for just a second and then it is gone.

Hmm, again can we have a new issue for that as it's unrelated to this Nanoleaf issue.

Looking at the documentation of nanoleaf, the port has to be 60222. Still no luck though.

It should set that automatically for the device. Actually I see it used to be 60221 (and that definitely worked for me, maybe it's a change for the V2 API?

Maybe we can look at other implementations: https://github.com/hyperion-project/hyperion.ng/blob/master/libsrc/leddevice/dev_net/LedDeviceNanoleaf.cpp

That certainly looks very nice, I've mentioned it in the existing enhancement issue. PRs welcomed to port some of the other features across...

erhan- commented 2 years ago

Hey,

I dont know why but the build worked without setting that it does not count warnings as errors. I am leaving the rpi build out. I tested different base images and package versions around. I will upload my latest working docker later as the inital version where I got it from was already some years old.

I am using host network mode with the container because so that I more narrow down the problem. I will leave the artnet issue out of this issue now. I think I should be able to control the nanoleaf with the web controls.

The network port is correct but I might have overseen that I have to manually enable external mode in nanoleaf. I am pretty sure that is at least one of the issues getting it to run.

15 is the amount of panels. edit: see below

I wrote a python script activated extControl mode and tested. The ports are correct and work and I can change colors from my script. I guess you know about the documentation? Maybe more things changed from v1 to v2:

"In order to support the much larger number of panels on Canvas, the size of the nPanels, panelId and tranitionTime fields have been increased from 1B to 2B. The nFrames field has been dropped as it was set to 1 in v1 anyway"

Is nFrames dropped? (edit it is dropped: https://github.com/OpenLightingProject/ola/blob/d5cb4fb70bee4aa1db1c4de4ba70b5caf76f55fb/plugins/nanoleaf/NanoleafNode.cpp#L141 )

grafik

https://forum.nanoleaf.me/docs/openapi

No reaction in OLA. After creating an universe and adding the device as output port, what do I have to do? I go to the DMX console and set all lights on but there is no effect.

All in all I think it is something about the panel id. I thought it is a length integer. Looking at how I implemented it in Python, I see that these are the panel ids ...

<controller IP>-panels = [int] The list of panel IDs to control, each panel is mapped to three DMX512 slots (for Red, Green and Blue). There is currently no support for white control via the v2 protocol.

How do I define them here?

192.168.52.64-panels = [35035, 23879, 9880, 26342, 341, 617, 43475, 14462, 20855, 11172, 17294, 36988, 33629, 56498, 8669]

192.168.52.64-panels = 35035, 23879, 9880, 26342, 341, 617, 43475, 14462, 20855, 11172, 17294, 36988, 33629, 56498, 8669

ola_1  | 2022-05-25 09:13:11,773 DEBG 'olad' stderr output:
ola_1  | plugins/nanoleaf/NanoleafDevice.cpp:84: Unknown Nanoleaf protocol version 0, defaulting to v1
ola_1  | common/io/EPoller.cpp:82: EPOLL_CTL_ADD 21, events 2001, descriptor: 0x55873156f310
ola_1  | olad/plugin_api/DeviceManager.cpp:105: Installed device: Nanoleaf Device:24-192.168.52.64

192.168.52.64-panels = 35035, 23879, 9880, 26342, 341, 617, 43475, 14462, 20855, 11172, 17294, 36988, 33629, 56498, 8669
192.168.52.64-port = 60222
192.168.52.64-version = v2
controller = 192.168.52.64
enabled = true

Both did not work. I will continue after work.

See https://github.com/OpenLightingProject/ola/pull/1738/files#diff-34d7f0c8a3b9b6679f9681c478e184e3cc104fb79b5741057df130b44f03f17cR81

This fix works! I can set all colors in the console!

I created a different issue for the artnet problem: https://github.com/OpenLightingProject/ola/issues/1779

peternewman commented 2 years ago

I dont know why but the build worked without setting that it does not count warnings as errors.

Great, yeah I think we ignore some deprecation errors currently so it ought to just work.

192.168.52.64-port = 60222

This fix works! I can set all colors in the console!

So you do need to use port 60222? Is your stuff actually Canvas?

Just to confirm, you compiled my PR, set the port and panel IDs and it just worked when you enabled the streaming API? Would you mind just commenting to that effect on the PR so we've got a baseline if future changes somehow break it.

I created a different issue for the artnet problem: #1779

Great thanks.

Out of interest, did you try the white level control via your custom script? Is it true white level, i.e. with R, G and B all at 0, if white is up, do you get a separate white LED? If so maybe we should add a mode to OLA to allow control of that too (and use four channels per device).

erhan- commented 2 years ago

60222 is for canvas. Yes, with the PR it is possible to set RGB for each panel. It works and can be merged.

I have worked on something else to get artnet to nanoleaf working:

https://github.com/erhan-/artnet-advertise-nanoleaf

It's a bit choppy but it works.

DaAwesomeP commented 1 year ago

I just mistakenly encountered the cppunit-config issue and the warnings as errors issue. The problem was that I was accidentally trying to build an OLA from 2015 on Debian 11 amd64 (I was on the wrong branch). Possibly @erhan- you're building an old OLA?

erhan- commented 1 year ago

Nope, the work was done on https://github.com/OpenLightingProject/ola/pull/1738 But I am also not working on this now and have a functioning setup at home with some other tools.

peternewman commented 1 year ago

Out of interest, did you try the white level control via your custom script? Is it true white level, i.e. with R, G and B all at 0, if white is up, do you get a separate white LED? If so maybe we should add a mode to OLA to allow control of that too (and use four channels per device).

Confirmed with mine running: Type Version
Current Firmware Version 5.0.1
Hardware Version 1.4-0
Bootloader Version 2.1.21

That the white channel does nothing even if set...

Which also agrees with the docs:

Note that the White LED element is currently ignored. The white LED is used automatically during white balancing by Panels based on its internal calibrations.