Updated sketch is available here, if anyone is interested.
Beiträge von manzel
-
-
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)
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)
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.
Since all the (assumed) communication with Particle cloud seems to have packet size 0, one could also adapt line 99 to
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.
-
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
Alles anzeigenReceived 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
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.
-
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.
-
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:
Code
Alles anzeigen// 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" }
These are my current settings for the orb in Hyperion.ng:
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?