Beiträge von Rick164

    The problem might be that an if else still expects the function QHostAddress::AnyIPv4 to exist during compile right?
    As that is the case with C# at least because during compile it runs thru and checks against its included libraries (Qt4 or Qt5 in this case) and if they don't exist it breaks, workaround would be 2 branches for the different Qt versions but believe we are only gonna support Qt5 in upcoming releases.


    It's still a bug in Qt5 as well which has yet to be fixed according to their bug tracker, normally ::Any should not fail if an IPv6 interface isn't usable / non-existent (fallback to IPv4) as that's how it works under Java / .NET atm :)

    Best guess is that /dev/ttyUSB0 isn't the correct device or that AmbiLed needs an update to support recent Hyperion changes, hard to tell how this hardware works since none of use this.
    What you could try is this:


    - Connect via SSH to machine running Hyperion
    - Execute command: "lsusb"
    - Check output and make sure ttyUSB0 is your AmbiLed device
    - To double check execute command: "ls -lh /dev/" and check for ttyUSB0 listing.


    If all else fails best to ask the seller for further support though as they know their product and maybe have a preinstalled image for you which works ootb :)

    Yeah we might have a few more here and there as socket binding was changed (mostly for IPv6 I think) :)
    @Brindosch if you could commit this change to beta branch that would be great :thumbup:


    Commit message: Updated AtmoOrb device socket binding to comply with Qt5
    File: /libsrc/leddevice/LedDeviceAtmoOrb.cpp
    [MEDIA=gist]RickDB/20f2eff2dc4a2d97248bb611e4275ca8[/MEDIA]

    Do notice an odd error there:


    Code
    QAbstractSocket: cannot bind to QHostAddress::Any (or an IPv6 address) and join an IPv4 multicast group
    QAbstractSocket: bind to QHostAddress::AnyIPv4 instead if you want to do this


    Might be something new in beta branch but willl double check as it's currently working here (stable release).


    // Update


    Hmm known Qt5 bug as when there's ipv6 device it will fail.


    https://bugreports.qt.io/browse/QTBUG-30949


    QHostAddress::AnyIPv4 only exists in Qt5 so most likely you are building it against that (can't reproduce it here atm), if so can change try changing the line in this file:


    <hyperion git dir>/libsrc/leddevice/LedDeviceAtmoOrb.cpp


    From:


    Code
    udpSocket->bind(multiCastGroupPort, QUdpSocket::ShareAddress | QUdpSocket::ReuseAddressHint);


    To:


    Code
    udpSocket->bind(QHostAddress::AnyIPv4, multiCastGroupPort, QUdpSocket::ShareAddress | QUdpSocket::ReuseAddressHint);


    And re-compile afterwards :)

    In step 4 of the guide it's for OpenElec so might not exist under other RPi distros as OpenElec and forks of it do most things read-only by default :)
    The lag could be that the buffer size hasn't been increased yet, it's in the troubleshooting chapter if needed.

    Hi Guys,


    Noticed we got a lot more development going lately which is great and wondering if some of you like @redPanther and @penfold42 want to join our Hyperion-project as official team members :) , what we're currently lacking in the development area is:


    - Review process


    We already do our best to go over every commit however we aren't dedicated C++ developers so makes it harder and more time consuming while also running the risk of bugs.


    - Road map


    What features or improvements does the community want, we already have a list for this however no easy way to know if someone wants to pick this up so remains in limbo.

    - App development


    Thanks to other developers we got this going already which will support all the new Hyperion features (auto-discovery / calibration), I'm currently assigned to this but might need some additional help later on so anyone with Xamarin expertise to supply a few pointers is much appreciated :)
    Was hoping to get a working version this week but work / RL stuff got in between so first release delayed till next week.

    RGBW kan nog wat nadelen hebben mbt kalibratie en dat zal dan ook nog uitvoerig getest moeten worden aangezien je wit balans lastig kan zijn, mocht je ze gaan bestellen hou er dan wel rekening mee dat je 2 keuzes daarin hebt namelijk cool (RGBCW) en warm (RGBWW) wat door een fysieke fosfor laag voor de led geregeld wordt dus niet meer aan kan passen achteraf.


    Lastig te zeggen welke beter is op dit moment aangezien APA102 ook prima te kalibreren is dus zou nog even wachten met bestellen zodat we meer feedback krijgen of een klein aantal SK6812 leds bestellen zodat je kan testen :)

    Update: Do you know why it might have displayed the same behavior when connected to the GPIO pins? I prefer to use the Arduino anyway, but curious if running off GPIO is inadvisable or maybe I was doing something wrong. Thank you


    Not completely sure but could be that the system load was too high or the polling (rate) was too low :)
    Using an Arduino in between is nicer for sure, did drop that one for the APA102 setup (RPi -> SPI) but for anything else still prefer it.


    AtmoOrb is a pretty straight forward setup, only thing that comes down to personal preference is smoothing but if you use the sample config from the wiki you should be good to go :D
    Nearing 2 month Photon uptime for the dual setup here without issues so it's as stable as it can be.

    Sounds like the baud rate wasn't increased yet, would check chapter 4 which explains how to increase the baud rate in the Arduino sketch and on the RPi itself:


    https://hyperion-project.org/t…-ws2801-ws2812b-apa102.8/


    There are also a couple of sample config attached there which are worth a try :) , also best to use Arduino IDE version 1.0.6 as that was used in the guide for increasing the buffer limit on the Uno R3 (listed under Tips & Troubleshooting chapter).
    WS2812 is plenty fast it's just that under certain low brightness conditions it will have lower response times (less smooth transitions) over the LED SPI variants.

    Not an expert on linux init scripts especially since per distribution they can change but would add it as a cronjob instead like so:


    Code
    crontab -e


    Text editor (Nano) will show up, add the follow line at the end and press F2 to save.


    Code
    @reboot sleep 30 && LD_LIBRARY_PATH=/storage/hyperion/bin /storage/hyperion/bin/hyperiond /storage/.config/hyperion.config.json


    sleep 30 being a 30 second delay :) , can skip the extra parameters (crop etc..) if you want as those should be in the config already.

    What might be happening is that the capture device isn't ready on boot but shortly after, when you run this command does it start correctly:


    Code
    killall hyperiond
    service hyperion start


    The periodic flashes could mean there's some local interference (cable) or like you said a defective HDM2AV converter :) , do recall the short white flashes but since you removed the framegrabber from the config that can no longer be the cause.
    Does it happen on fixed intervals corresponding with log entries like below?


    Code
    V4L2GRABBER INFO: Signal lost
    V4L2GRABBER INFO: Signal detected