Posts by Lord-Grey

    @Paulchen-Panther


    Ich habe auf dem Handy nicht genau den Algorithmus vergleichen können, aber vielleicht kann Variante 4 noch was rausholen.... siehe:
    http://blog.ivank.net/fastest-gaussian-blur.html


    In den Kommentaren findet sich auch ein Link auf eine Cpp Implementierung.


    Ansonsten, wenn ich mir die Processingzeiten so anschaue, scheint ein CPU basierter Ansatz schwierig zu sein.


    Ich habe leider kein HDR, Splitter oder reine LEDs...
    Reicht es nicht das Bild zu verkleinern und damit die Unschärfe zu bekommen? Oder die Bitzahl der Farbräume zu reduzieren? Im dunklen Bereich scheint die Genauigkeit eh nicht so relevant zu sein. Aber vielleicht fehlt mir hier der praktische Bezug.

    @Cosmicbase Portfreigaben in der fritzbox sind dazu da, um Rechner mit Ports gegenüber dem Internet freizugeben.
    Solange Du nicht über das Internet auf den Rechner musst, solltest Du diese Ports schleunigst wieder schließen.


    Gib mal rechnername.fritz.box:8080 im Kodi WebServerfeld ein und drück return.
    Dann Cancel und ruf den Dialog nochmal auf. Bei mir kommt dann die Fehlermeldung nicht mehr.


    Wenn ich mich richtig erinnere, musst Du in Kodi den WebService auch erlauben.

    Wenn Du putty schließt, wir der laufende Prozeß beendet.
    Start Hyperion mal mit


    sudo hyperiond &

    Dann wird ein eigener Prozeß gestartet und Du kannst putty schließen.
    Der Prozess lebt aber nur bis zum nächsten Restart.


    Zum automatischen Start hat @Paulchen-Panther schon etwas geschrieben. Such mal im Forum.



    Aktuell beendet hyperion.ng die LedDevices nicht definiert bei einem Shutdown.
    Es kann sein, dass Du das als Effekt siehst und mit dem IR Fernbedienungsausschalten verbindest.
    Kann aber auch sein, dass es andere Gründe gibt.


    Der PR #654 stellt sicher, dass das Device beendet wird bevor hyperion.ng ganz beendet wird.
    Der PR ist aktuell im Review der anderen Developer. Ein ETA-Date habe ich nicht.

    Nach dem das Hyperion Control mehr oder minder unter CE nicht richtig funktioniert (LEDs werden nicht sauber an oder angeschaltet) wollte ich nach einem shutdown Script fragen.


    @Cosmicbase: Im Rahmen des PR #654 habe ich den LEDDevice-Code dahingehend geändert, dass bei einem Device Switch-off immer nocheinmal "Schwarz" ausgegeben wird. Bei API Devices kann natürlich auch ein API-Switch-off passieren.
    Das sollte eigentlich Dein Problem addressieren.

    Is "just"


    Project > Import Project > Import Existing Project


    Just do a "File > Project Open" and open the "CMakeLists.txt" in the Hyperion.ng root directory.


    I lately reduced the building Kits to two.
    Please find here my QTCreator configuration file"CMakeLists.txt.user": https://ufile.io/252z9rmz


    Just place it in the same directory as "CMakeLists.txt" in the Hyperion.ng root directory and update it in QtCreator to your directory structure.


    While looking at the cross-compile aspect yesterday again, I came across a link which describes the additional configuration on QtCreator to cross-compile, but the deploy and run on the rpi.


    8. Setup Qt Creator for Raspberry Pi cross compilation


    I have not given it a try yet, but you might find it hepful.

    Hi Marko


    Quote

    I got: 5.11.3
    By cross compile version is: 5.12.6 ;(


    You should not trying to intermingle the Ubuntu compile environment and the one use for Cross-Compile.
    Until Paulchen-Panther has the PR not ready to be able to deliver Libs with Hyperion, you have to install the Qt version required to be used during cross-compile.


    That is a different version than the one used during the native Ubuntu compile.


    Net net, you have to have in mind that there is a set of Ubuntu files and in ADDITION another set only used for cross-compiling only (the files you copied from rip, the Qt matching files and the toolchain). Key is that the Qt libs on the rpi and the header and rcc/moc tool on cross-compile environment are in sync.


    Considering the above, you may give it another try and use the elements as per documentation. If you changing too many parts in the initial go, it may be hard to find where the cross-compile breaks.


    I had a hard time too, to get the latest instructions updated and running.

    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.