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

[shoogashooks]

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]

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.

 

[shoogashooks]

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]

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)

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

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

 

[shoogashooks]

Thanks! I found a python UDP example and got it working.

 

[Baserunner]

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 ...

 

[Rick164]

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]

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

 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?

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]

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

 

[Rick164]

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.