Beiträge von Lord-Grey

    Hi Marko



    what 5.x QT version are you using?


    I try setup my build environment and run into some compile issues.
    I tried "latest" (5.14)... what may not be a good idea ;)


    On Ubuntu, I always make use of the available Qt5 packages per apt.
    As I lately migrated my Ubuntu environment to 19.10, it is Qt version 5.12.4 in /usr/lib/x86_64-linux-gnu


    In addition, I installed Qt version 5.14. to make use of the latest Qt Creator version.
    There I do not have any compile issues.



    Beside that: for the configure step the QT configure step the build requires a device....
    I have an Raspi 4... that seem not supported yet.
    ../qt-everywhere-src-5.14.0/configure -opengl es2 -device linux-rasp-pi3-g++ ...


    On the Raspberry Pi, I suggest you install the packages as per instructions, too

    Code
    sudo apt-get install....


    For the cross-compile environment set-up, you should make use the same Qt5 version which you installed on the Raspberry Pi.
    (I may need to update the instructions to reflect this). Otherwise you will see "moc" compile errors.


    For Raspian buster it seems to be Qt 5.11.3.

    HTML
    http://download.qt.io/archive/qt/5.11/5.11.3/qt-opensource-linux-x64-5.11.3.run


    To find out which Qt version is installed, run

    Code
    qmake --version


    On the toolchain, I will check, if one can go to the latest version

    HTML
    https://developer.arm.com/-/media/Files/downloads/gnu-a/9.2-2019.12/binrel/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf.tar.xz?revision=fed31ee5-2ed7-40c8-9e0e-474299a3c4ac&la=en&hash=76DAF56606E7CB66CC5B5B33D8FB90D9F24C9D20


    Important: If you change the Qt version and/or toolchain file, please update the respective entries in


    Code
    $HYPERION_DIR/cmake/Toolchain-rpi.cmake
    
    
    SET(TOOLROOT ${PITOOLCHAIN}/gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabihf )
    SET(QT_BIN_PATH ${CROSSROOT}/Qt5/5.7/gcc_64/bin)



    I suggest you go with the original one first and check that your Qt compile errors will go away.

    Hi Marko


    let me share my development environment. Others chime in, if there are other alternatives worth considering.


    I make use of the following components:


    OS: Ubuntu 18.10 in a VM-Ware player (I successfully compiled in Ubuntu 16 and 19, too).
    IDE: QT Creator, as it nicely fits with the QT framework
    GIT Repository: SmartGit
    Qt app inspection: GammaRay
    SQLight: DB Browser for SQLite, in case you want to update the hyperion.ng configuration DB without UI


    I build and run via command-line using the ./bin/create_all_releases.sh script (disabling some steps to avoid package building, etc.)
    You can also build and run via QT Creator (which I do in case I need to execute an interactive Debugger).


    To test hyperion.ng on a Raspberry Pi 3B+, I cross-compile in the Ubuntu environment.
    Step by step details you find in the CrossCompileHowto document (you may need to change the firmware & toolchain elements for rpi 4).
    Alternatively, you can compile on the rpi itself or in a docker container.
    As I am an impatient person, I have chosen the cross-compile way leveraging the power of the host system to get the job done.


    Testing the LED output:


    Besides testing the LED-output on my Nanoleaf network device, I find it handy to do some structured testing via the
    a) "File "device, here you can check the individual output records and timings against your expectation...
    b) HyperSim LED device simulator (I lately did a fork to support hyperion.ng LED layouts)


    Hoping that gives you a start...
    In case of questions, do not hesitate to come back.


    Happy development!

    Hi @milhouse
    the current hyperion.ng master branch does not include the latest fix which ensures that Aurora FW 3.2.0 will work (due to the fact that nanoleaf changed the protocoll).
    You either need to wait until the PR has beend merged, or as an interim, you test with the code from my repository https://github.com/Lord-Grey/hyperion.ng.


    "What I expected was that the LED Layout tab would at least have the right number of LEDs which would be an indicator that it was connecting and getting the LED list."
    That is also my expectation, but hyperion does currently not get this automatically updated after a device resolved the number of Led.
    In case nanoleaf gets more Led configured than in place, it will not start the device. You should see this as an Error in the log.


    To circument this, I would suggest you define a number of Leds equal or less your physical ones and restart hyperion.ng.
    Then it shoudl work on the right codebase.


    In case of further problems, please switch "Debug" logs on and share your log file.

    Hi @milhouse


    you should find the nanoleaf-device as per picture below. The code currently supports Light-Panels (Aurora), as well as Canvas.
    The configuration steps are as @Anthrax outlined.


    Token is a must, IP-adress can be discoverd automatically, if left empty.
    Note: This is not always working, as Nanoleaf seems sometimes not to react on the SSDP-Discover request in time.


    In case you have Light-Panels (Aurora), and it is not working, you may want to update the firmware to the latest version.
    Nanoleaf did an update to the protocoll in June. FW 3.2.0 was tested with @Anthrax successfully.


    In case you get stuck, do not hestiate to share further details....


    Du kannst Hyperion auch mit “./hyperiond &” starten. Dann läuft es als eigener Unterprozess und beendet sich nicht beim Schließen des Terminals.
    Allerdings musst Du Dir zum Stoppen den Prozess heraussuchen (ps | grep hyperiond) und ein “kill” auf die Prozessnummer absetzen.
    So kannst Du erstmal testen.
    Nach einem pi Restart musst Du allerdings hyperiond erneut starten.