AtmoOrb does not work using Hyperion.ng

manzel · 3. Juli 2022

I have been using Hyperion for about eight years now on a Pi 2, which controlled an APA102 strip, one AtmoOrb, and some Hue lamps. It has been working flawlessly ever since. Now I decided to give Hyperion.ng a go (using 2.0.13 at the moment) and have some problems. While the Hue lamps work, the Orb does not.

The AtmoOrb is discovered automatically using the wizard, but Hyperion is unable to control it, the LEDs just stay dark. Using the Windows AtmoOrbApp it works without problems however using the following settings.

This is my old config (before upgrading to ng), which also worked:

Spoiler anzeigen

Code

// Automatically generated configuration file for 'Hyperion daemon'
// Generated by: HyperCon (The Hyperion deamon configuration file builder)
// Created with HyperCon V1.00.0 (11.03.2016)

{
    /// Device configuration contains the following fields:
    /// * 'name'       : The user friendly name of the device (only used for display purposes)
    /// * 'type'       : The type of the device or leds (known types for now are
    /// APA102, Adalight, AdalightAPA102, AmbiLed, Atmo, Hyperion-USBASP-WS2801, Hyperion-USBASP-WS2812, Lightberry, Lightpack, LPD6803, LPD8806, Multi-Lightpack, P9813, Paintpack, PhilipsHUE, PiBlaster, SEDU, Test, ThinkerForge, TPM2, WS2801, WS2812b, None)
    /// * [device type specific configuration]
    /// * 'colorOrder' : The order of the color bytes ('rgb', 'rbg', 'bgr', etc.).
    ///
    /// * 'Specific for AtmoOrb:
    /// * 'transitiontime'     : Set the time of transition between color of Orb (not implemented)
    /// * 'port'           : Multicast UDP port
    /// * 'numLeds'     : Number of leds in Orb
    /// * 'orbIds'     : The Orb ids to use
    /// * 'switchOffOnBlack': Define if Orb is to switch off when black is detected
    "device" :
    {
        "name"       : "MyPi",
        "type"       : "atmoorb",
        "output"     : "239.15.18.2",
        "transitiontime"     : 0,
        "useOrbSmoothing"     : true,
        "skipSmoothingDiff"     : 230,
        "port"     : 49692,
        "numLeds"     : 24,
        "orbIds"   : "1",
        "colorOrder" : "rgb"
    },

    /// Color manipulation configuration used to tune the output colors to specific surroundings.
    /// The configuration contains a list of color-transforms. Each transform contains the
    /// following fields:
    ///  * 'id'   : The unique identifier of the color transformation (eg 'device_1')    ///  * 'leds' : The indices (or index ranges) of the leds to which this color transform applies
    ///             (eg '0-5, 9, 11, 12-17'). The indices are zero based.    ///  * 'hsv' : The manipulation in the Hue-Saturation-Value color domain with the following
    ///            tuning parameters:
    ///            - 'saturationGain'  The gain adjustement of the saturation
    ///            - 'valueGain'       The gain adjustement of the value
    ///  * 'red'/'green'/'blue' : The manipulation in the Red-Green-Blue color domain with the
    ///                           following tuning parameters for each channel:
    ///            - 'threshold'       The minimum required input value for the channel to be on
    ///                                (else zero)
    ///            - 'gamma'           The gamma-curve correction factor
    ///            - 'blacklevel'      The lowest possible value (when the channel is black)
    ///            - 'whitelevel'      The highest possible value (when the channel is white)
    ///
    /// Next to the list with color transforms there is also a smoothing option.
    ///  * 'smoothing' : Smoothing of the colors in the time-domain with the following tuning
    ///                  parameters:
    ///            - 'type'            The type of smoothing algorithm ('linear' or 'none')
    ///            - 'time_ms'         The time constant for smoothing algorithm in milliseconds
    ///            - 'updateFrequency' The update frequency of the leds in Hz
    ///            - 'updateDelay'     The delay of the output to leds (in periods of smoothing)
    "color" :
    {
        "channelAdjustment" :
        [
            {
                "id"   : "default",
                "leds" : "*",
                "pureRed" :
                {
                    "redChannel"        : 230,
                    "greenChannel"        : 15,
                    "blueChannel"        : 7
                },
                "pureGreen" :
                {
                    "redChannel"        : 92,
                    "greenChannel"        : 235,
                    "blueChannel"        : 9
                },
                "pureBlue" :
                {
                    "redChannel"        : 0,
                    "greenChannel"        : 30,
                    "blueChannel"        : 130
                }
            }
        ],
        "temperature" :
        [
            {
                "id"   : "default",
                "leds" : "*",
                "correctionValues" :
                {
                    "red"     : 255,
                    "green"    : 255,
                    "blue"     : 255
                }
            }
        ],
        "transform" :
        [
            {
                "id"   : "default",
                "leds" : "*",
                "hsl" :
                {
                    "saturationGain"    : 0.9000,
                    "luminanceGain"        : 0.8000,
                    "luminanceMinimum"        : 0.0000
                },
                "red" :
                {
                    "threshold"     : 0.0000,
                    "gamma"         : 2.5900
                },
                "green" :
                {
                    "threshold"     : 0.0000,
                    "gamma"         : 2.5400
                },
                "blue" :
                {
                    "threshold"     : 0.0000,
                    "gamma"         : 2.5400
                }
            }
        ],
    // SMOOTHING CONFIG
        "smoothing" :
        {
            "type"            : "none",
            "time_ms"         : 120,
            "updateFrequency" : 60.0000,
            "updateDelay"     : 0
        }
    },

    /// The black border configuration, contains the following items:
    ///  * enable                : true if the detector should be activated
    ///  * threshold             : Value below which a pixel is regarded as black (value between 0.0 and 1.0)
    ///  * unknownFrameCnt        : Number of frames without any detection before the border is set to 0 (default 600)
    ///  * borderFrameCnt        : Number of frames before a consistent detected border gets set (default 50)
    ///  * maxInconsistentCnt     : Number of inconsistent frames that are ignored before a new border gets a chance to proof consistency
    ///  * blurRemoveCnt        : Number of pixels that get removed from the detected border to cut away blur (default 1)
    ///  * mode                 : Border detection mode (values=default,classic,osd)
    "blackborderdetector" :
    {
        "enable" : false,
        "threshold" : 0.01,
        "unknownFrameCnt" : 600,
        "borderFrameCnt" : 50,
        "maxInconsistentCnt" : 10,
        "blurRemoveCnt" : 1,
        "mode" : "default"
    },

    /// The configuration of the effect engine, contains the following items:
    ///  * paths        : An array with absolute location(s) of directories with effects
    ///  * color         : Set static color after boot -> set effect to "" (empty) and input the values [R,G,B] and set duration_ms NOT to 0 (use 1) instead
    ///  * effect         : The effect selected as 'boot sequence'
    ///  * duration_ms    : The duration of the selected effect (0=endless)
    ///  * priority     : The priority of the selected effect/static color (default=990) HINT: lower value result in HIGHER priority!
    "effects" :
    {
        "paths" :
        [
            "/usr/share/hyperion/effects"
        ]
    },

    /// The configuration of the Json server which enables the json remote interface
    ///  * port : Port at which the json server is started
    "jsonServer" :
    {
        "port" : 19446
    },

    /// The configuration of the Proto server which enables the protobuffer remote interface
    ///  * port : Port at which the protobuffer server is started
    "protoServer" :
    {
        "port" : 19447
    },

    ///  The configuration for each individual led. This contains the specification of the area
    ///  averaged of an input image for each led to determine its color. Each item in the list
    ///  contains the following fields:
    ///  * index: The index of the led. This determines its location in the string of leds; zero
    ///           being the first led.
    ///  * hscan: The fractional part of the image along the horizontal used for the averaging
    ///           (minimum and maximum inclusive)
    ///  * vscan: The fractional part of the image along the vertical used for the averaging
    ///           (minimum and maximum inclusive)
    "leds" :
    [
        {
            "index" : 0,
            "hscan" : { "minimum" : 0.5000, "maximum" : 1.0000 },
            "vscan" : { "minimum" : 0.0000, "maximum" : 1.0000 }
        }
    ],

    "endOfJson" : "endOfJson"
}

Alles anzeigen

These are my current settings for the orb in Hyperion.ng:

Code

[
  {
    "hmax": 1,
    "hmin": 0.6,
    "vmax": 1,
    "vmin": 0
  }
]

I cannot seem to find any problems with this config. Also checked the logs, which did not show problems. Anything else I can try to make the orb work?

Lord-Grey · 3. Juli 2022

Does a static Color Effect work?

Could you share a Debug Log?

Set System->Log to Debug and then restart Hyperion.

manzel · 3. Juli 2022

No, a static color also does not work.

I attached the debug log. Therein, I restarted the system and set some static colors via web UI.

Lord-Grey · 4. Juli 2022

manzel I did a fresh compile and upload of the AtmoOrb sketch my my ESP8266 with the default multicast group (239.255.255.250), as well as with yours (239.15.18.2).
Both groups work even over PowerLAN (which sometime is a problem for multicast).

Any chance to show the debug output via a serial device of your AtmoOrb (sketch to be build be debug on)?

There you could see, if the ESP receives the Color updates
Sample:

You could also see what is reported during discovery and identification:

Did you validate that the LEDs are connected to the correct data PIN in line with the compiled sketch?

Edit: You might also install Hyperion on your Windows PC and see, if it is working there (similar to the other test tool). Then you could ring-fence the issue hopefully.

manzel · 4. Juli 2022

Thanks a lot for investigating. My AtmoOrb is not built with an ESP, but a Particle Photon. Had to do quite some digging to get the desired log output, but managed in the end.

When I use the test tool (AtmoOrbApp) on Windows, the Orb lights up and output is as follows:

Code

Received 77 bytes from 192.168.1.129, port 51849
UDP packet contents: 2 1 9 13 31
Received 77 bytes from 192.168.1.129, port 51849
UDP packet contents: 2 1 10 13 31
Received 77 bytes from 192.168.1.129, port 51849
UDP packet contents: 2 1 11 13 31
Received 77 bytes from 192.168.1.129, port 51849
UDP packet contents: 2 1 12 13 31
Received 77 bytes from 192.168.1.129, port 51849
UDP packet contents: 2 1 13 13 31
Received 77 bytes from 192.168.1.129, port 51849
UDP packet contents: 2 1 14 13 31
Received 77 bytes from 192.168.1.129, port 51849
UDP packet contents: 2 1 15 13 31

Alles anzeigen

When I change colors within Hyperion on the Pi, nothing happens (Orb stays dark and no serial output). I also installed Hyperion on Windows and tried using that. Same behavior as on the Pi. So it does not seem to be related to the Pi, but to Hyperion.

manzel · 6. Juli 2022

I managed to get it figured out. I use this code for my Particle Photon. It is pretty similar to the ESP8266 code, but has one crucial difference. The UDP packets are only evaluated when matching the expected size (line 99)

Code

    if(packetSize == BUFFER_SIZE){

This is done to filter out all the talk to the Particle cloud, I assume. On the ESP8266, there is no evaluation of the packet size. This buffer size is set to be dependent on the number of LEDs, however (line 27)

Code

#define BUFFER_SIZE  5 + 3 * NUM_LEDS

This is pretty pointless, since all LEDs are set to the same color anyway. Now, why it works with the Windows test app and the old Hyperion (not ng, how do you refer to this?) is because you can set the LED count in both of those. Hyperion.ng, however, fixes the LED count to 1. This is reasonable, since the rest of the data is never evaluated. Even for the official Windows test app, with LED count set to 24, there was only data present for the first LED and the rest was just filled with zeros.

Thus, I fixed my problem by adjusting the buffer size to 8 and can now control the orb using Hyperion again.

Code

#define BUFFER_SIZE  8

Since all the (assumed) communication with Particle cloud seems to have packet size 0, one could also adapt line 99 to

Code

    if(packetSize > 0 && packetSize < BUFFER_SIZE+1){

I guess, to not lose compatibility with previously configured control devices. But I think adjusting the buffer size and limiting the LED count to 1 just makes more sense, as the sketch has to be changed anyway.

manzel · 6. Juli 2022

Updated sketch is available here, if anyone is interested.

Lord-Grey · 26. Juli 2022

manzel Sorry for coming back earlier...
Great that you resolved the issue with an updated sketch.

I would like to store it with the other firmware sketched on the Hyperion repository.
Then others can find it too.

I did some additional changes, like identification, to align the behaviour to the esp8266 sketch.

Unfortunately, I cannot compile not test it.

Would you mind testing the updated sketch and report back?

Jetzt mitmachen!