[DIY] AtmoOrb - A Hue like mood lamp based on Particle Photon with NeoPixel - *Tutorial added* (2 Viewers)

shoogashooks

New Member
October 9, 2016
4
0
Home Country
United States of America United States of America
In case anyone is curious (like I was), this does work with the Particle Internet Button instead of the NeoPixel Ring. I already had an Internet Button so I was happy to see it worked. Probably not the best way to go if you're building from scratch though - the Internet Button won't be as bright and costs a bit more.

To get it working you just need to modify the Orb UDP sketch to change the defined data pin from 6 to 3. Very easy change of just one character on line 21 in the sketch. Otherwise just follow the tutorial.
 

Rick164

MP Donator
  • Premium Supporter
  • January 7, 2006
    1,335
    1,005
    Home Country
    Netherlands Netherlands
    Yeah have the internet button as well and in the lamp here couldn't get it bright enough for my liking but was great for testing :)

    Btw we made a sketch recently with HSV support which offered brightness support and FastLED temporal dithering as a result, not good enough yet but might make it in Hyperion soon.
     
    Last edited:

    shoogashooks

    New Member
    October 9, 2016
    4
    0
    Home Country
    United States of America United States of America
    I just found a knock-off of the 24 LED NeoPixel ring on Amazon for $10. Going to give that a try. I don't mind doing a little soldering to save $15 :)

    How would you recommend controlling these via python? I'd like to use the orb to indicate some other smart home stuff when the TV is not in use. I don't have any experience with UDP multicast, but I can probably find a tutorial if that's the best way.
     

    Rick164

    MP Donator
  • Premium Supporter
  • January 7, 2006
    1,335
    1,005
    Home Country
    Netherlands Netherlands
    Not sure with Python tbh but the protocol is fairly straightforward, made a standalone client in ASPX (for web interface) recently with a couple of lines and basically comes down to this:

    - Create UDP socket and join the multicast group (239.15.18.2)
    - Create a byte array containing your colors and commands, send over previously created UDP socket (C# example)

    Code:
    // Orb ID we want to send to
    int orbId = 1;
    
    // Options parameter: 1 = force off | 2 = use lamp smoothing and validate by Orb ID | 4 = validate by Orb ID 
    int commandType = 2;
    
    // Needs to match AtmoOrb sketch
    int ledCount = 24;
    
    // Byte array we send to Orbs
    byte[] bytes = new byte[5 + ledCount* 3]; 
    
    // Command identifier: C0FFEE
    bytes[0] = 0xC0;
    bytes[1] = 0xFF;
    bytes[2] = 0xEE;
    
    bytes[3] = commandType;
    
    // Orb ID
    bytes[4] = byte.Parse(orbId);
    
    // RED / GREEN / BLUE
    bytes[5] = red;
    bytes[6] = green;
    bytes[7] = blue; 
    
    Socket.Send(bytes, bytes.Length, SocketFlags.None);

    - In the Python client you could control it like this with arguments:

    Code:
    AtmoOrbClient.py <red>  <green>  <blue> <OrbIDs>

    - Then it will execute previous function.

    Full C# code here:

    https://github.com/ambilight-4-medi...ight.Core/Targets/AtmoOrb/UDPMultiCastLamp.cs

    Python example of multicast socket here:

    http://stackoverflow.com/questions/603852/multicast-in-python
     

    Baserunner

    MP Donator
  • Premium Supporter
  • November 19, 2012
    229
    147
    Home Country
    Germany Germany
    Hi,

    first of all many thanks for the tutorial and providing the code.

    However I have some strange problems with it - strange because it worked exactly one time ... after about 10 minutes waiting (!?)
    I never managed to get it working again. (Other samples not related to AtmoORB work)

    I am using the UDP sketch. Other tests with the TCP sketch or using the IP adress of the Particle directly were also not positive.

    Update Debugging Status:
    Found out that at
    int packetSize = client.parsePacket();
    the packetSize is always 0.
    WiFi.ready() is true and WiFi.connecting() is false. That means the Photon should be connected to WiFi and listen?

    The Android App works. The Nexus is connected at WLAN, my HTPCs are via Ethernet. Is this logical that it cannot work? Need to refresh my network know-how ...
     
    Last edited:

    Rick164

    MP Donator
  • Premium Supporter
  • January 7, 2006
    1,335
    1,005
    Home Country
    Netherlands Netherlands
    It should work the same yeah, so the Windows app isn't working from any machine in your LAN network?

    Some switches can filter out multicast requests but those aren't that common, TCP sketch we kept for legacy purposes as UDP is the way to go with these Orbs because they will work faster and no need to worry about reconnects or IP addresses.
    Since the Android app works we can rule out the hardware or sketch issues, what we can try:

    - Connect a Windows machine to WLAN if possible and check if the Windows app or AtmoLight works there.
    - Check firewall rules for anything blocking the apps or multi-cast traffic specifically.
    - Check router / switch config for any multicast throttling or blocking options.

    If packet size is 0 it means it isn't receiving any commands on the multicast group which is normal when idle at least, once it starts receiving it will show a shorts bursts of packets :)

    If all else fails in AtmoLight we do have the UDP IP option (loose apps don't) to directly sent to the Orbs, the way the default UDP multicast works is as follows:

    - Orbs join a shared multicast group on a reserved IP (239.15.18.2)
    - Apps join in on that same shared multicast group.
    - Now on color changes in apps it sends those commands to the group and the Orbs will pick those up if the Orb ID matches.
     

    Baserunner

    MP Donator
  • Premium Supporter
  • November 19, 2012
    229
    147
    Home Country
    Germany Germany
    Works now with UDP IP.

    Recognized that my Fritzbox somehow filters the multicast packages when it goes from wired to non-wired. Not sure wether this is a bug or a feature. Here http://superuser.com/questions/7302...ulticast-packets-going-from-wired-to-wireless are some good explanations why it is difficult and error-prone to implement this.

    Another question ... :
    Code:
     if(!WiFi.ready() || !WiFi.connecting())
            {
                initWiFi();
            }
    Is this on purpose? According to https://docs.particle.io/reference/firmware/photon/#connecting- WiFi.connecting() returns false if it is successfully connected to the WiFi. Would this be better?
    Code:
    if(!WiFi.ready() || WiFi.connecting())
            {
                initWiFi();
            }
    Again thanks for the great work and pointing me to that great devices and opportunities.

    Wishing you all the best for 2017!
     

    Rick164

    MP Donator
  • Premium Supporter
  • January 7, 2006
    1,335
    1,005
    Home Country
    Netherlands Netherlands
    Good to hear it's working :)

    Is this on purpose? According to https://docs.particle.io/reference/firmware/photon/#connecting- WiFi.connecting() returns false if it is successfully connected to the WiFi. Would this be better?

    That does indeed look like a bug, do recall there was an issue with a certain Photon firmware so it might not have had the intended behavior before.
    On the ESP this workaround isn't needed but Photon for some reason doesn't re-create its clients on reconnects.

    Will test it again and fix if needed, thanks for spotting it and have a good new years (y)
     
    Last edited:

    Rick164

    MP Donator
  • Premium Supporter
  • January 7, 2006
    1,335
    1,005
    Home Country
    Netherlands Netherlands
    Tested successfully with latest Photon firmware, pushed to repo:

    https://github.com/ambilight-4-mediaportal/AtmoOrb/commit/703c951106dcd085f415c7c49d8224b65540a781

    Btw Fritzbox probably has a poor implementation or bug when it comes to multicast as it should allow broadcast / multicast independent of the interface :) , tested with other brands like Apple / Asus / Netgear / Routerboard here without issues only for Routerboard needed to disable multicast buffering as it would slow down processing.

    That article does mention why on WiFi it's important to limit but to completely block it out is kinda excessive especially since plenty of discovery services rely on it nowadays.

    Originally the design for the Orbs was to use multicast discovery then get IP returned and send that way, however during initial testing found out that it worked pretty well to just send directly over multicast en skip the discovery part.
    While not best practice it allows for much simpler code and easier usage as you don't need to keep checking if IP changes for instance, since the rate we send is 60 p/s tops to a single group the network load is minimal as well.
     
    Last edited:

    Users who are viewing this thread

    Similar threads

    Hello guys , i have a little question about this project. I really want to use this project with the software "aurora" but i want to use it by USB connection (so without the ESP8266), and i'm wondering if it's possible. I plan to use it only with my computer so the USB is not a problem. I also plan to replace the LED by a LED strip ^^
    Hello guys , i have a little question about this project. I really want to use this project with the software "aurora" but i want...
    Hi, I would like to showcase a project of mine, that I have been working on for quite some time. What is it? AtmoOrb is a lamp...
    Replies
    50
    Views
    54K
    MP1 MP2 WS2812B DE
    // AtmoduinoV2 by NevCairiel, based on RickDB Atmoduino V1 #include <FastLED.h> // Set the number of leds in the strip. #define NUM_LEDS 188 // type of the LED controller #define LED_TYPE WS2812B // data and clock pins #define DATA_PIN 10 CRGB leds[NUM_LEDS]; void setup(){ Serial.begin(115200); FastLED.addLeds<LED_TYPE...
    // AtmoduinoV2 by NevCairiel, based on RickDB Atmoduino V1 #include <FastLED.h> // Set the number of leds in the strip. #define...
    Hello guys. For a long time now i was thinking of getting myself a new project :) Well recently i decided to start the ambilight...
    Replies
    14
    Views
    4K
    DC12V is the correct power. The LC8808 is a 3-channel constant current LED drive with resumable data transfers and internal display patterns. There are three open-drain constant current outputs, with a build-in PWM of gray scale. The range of input power is from +9V to +15V, and voltage-endurance of LED port is +12V. There is a...
    DC12V is the correct power. The LC8808 is a 3-channel constant current LED drive with resumable data transfers and internal...
    Introduction Over time there have been many Windows alternatives to Atmowin and under Linux there is Bobilight however there is...
    Replies
    352
    Views
    194K
    • Sticky
    @HomeY, never mind found my own answer by looking at close-up of the board on Amazon: pin 11 is marked as "~11" defined as being part of the digital PWM group that must be needed for AmbiBox software, but not for the FastLED.show() command during setup.
    @HomeY, never mind found my own answer by looking at close-up of the board on Amazon: pin 11 is marked as "~11" defined as being...
    First of all a BIG TNX to both Lightning303 & azzuro for helping me out setting this up properly. Since we already have a great...
    Replies
    21
    Views
    43K
    • Sticky
    Is this the right thread for downloading the latest version of Atmolight MP1? Extension Manager URL for Atmolight returns HTTP error. For AtmoWin the same. Thanks
    Is this the right thread for downloading the latest version of Atmolight MP1? Extension Manager URL for Atmolight returns HTTP...
    Overview AtmoLight is a process plugin that interfaces with different ambilight solutions and brings Ambilight to MediaPortal. The...
    Replies
    390
    Views
    110K
    Top Bottom