No commands sent to AtmoOrb

  • I have built a nice AtmoOrb using an ESP8266. It works fine using the Android-App, or by manually crafting+sending UDP packets (i.e. I can send \xC0\xFF\xEE\x04\x01\x00\xFF\x00 to 239.15.18.2:49692 to make it very green)


    But I can't figure out how to get Hyperion working with it. The configuration looks ok to me, I get no frightening error messages:
    [MEDIA=pastebin]B8E06nUV[/MEDIA]
    [MEDIA=pastebin]tLZKeqRZ[/MEDIA]
    but it does not send any packages to the device -- except when I kill the daemon, then it sends an "switch off all lights" (C0FFEE0101000000), which successfully switches off the LED


    I try controlling the daemon with hyperion-remote,

    Code
    $ hyperion-remote -c Red --print
    hyperion-remote:
      version  : master (brindosch-f92bfa8/21a4f0c-1462453483
      build time: Jun  5 2016 17:11:38
    Connected to localhost:19444
    Set color to 255 0 0
    Command: {"color":[255,0,0],"command":"color","priority":100}
    Reply: {"success":true}


    which did not trigger any packages to the device. I also tried hyperion-x11 (I can see packages going to localhost:19445), but this also led to no data sent to the device (checked with wireshark).


    Any suggestions? I fear it's something super-simple, and I'm going to feel stupid... :)

    • Offizieller Beitrag

    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 :)

    • Offizieller Beitrag

    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]

    • Offizieller Beitrag

    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 :)

  • Testing QT4:
    On Pi before your PR: no error
    after your PR: no error


    Ubuntu 14.04 64bit
    can´t say, i get this:

    Code
    In file included from /home/sascha/hyperion/src/hyperion-x11/hyperion-x11.cpp:12:0:
    /home/sascha/hyperion/include/utils/Profiler.h:9:3: error: #error "Profiler is not for productive code, enable it via cmake or remove header include"
      #error "Profiler is not for productive code, enable it via cmake or remove header include"


    @redPanther
    is there something i missed. This is the run with the crosscompile during the native x64 compile of hyperion

  • When this command is a valid output
    pkg-config --modversion QtCore
    4.8.2


    OT:
    Could just move to QT5?
    It makes no sense to build now a comp layer after comp layer. It sucks?
    Already @redPanther did cause of the old c++ wich leads to deprecate wheezy?
    *plop*



  • I had the exact same problem. I updated my Hyperion and the strange thing was that imediatly after an update it would work, but after a reboot the problem would come back.
    Then I figured out then when the Rasberry Pi was already running killing Hyperion and starting it again after an reboot would fix te problem.
    Then I realised the problem arises probably because hyperion starts to quickly before the Rasberry Pi has astablised its network connection and therfore it fails.
    So I implemented a 30 second delay (sleep 30) in my autostart.sh script on the Pi that starts Hyperion after an reboot.
    This worked and fixed my problems.


    So for people that have the same problem, a delay in the \Configfiles\autostart.sh script might solve your problems.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!