Porting arduinolifx, a LIFX bulb

bko · September 9, 2014, 2:08am

I think you need to put this in a separate file myUDP.h. You would #include "myUDP.h" in arduinolifx.cpp and keep the myUDP Udp; line in arduinolifx.cpp.

lightx · September 9, 2014, 2:18am

ohh great, that worked. I did manage to get another type of packet on the core before it stop responding.

-UDP 24 0 0 34 0 0 0 0 0 0 0 0 0 0 0 0 4C 49 46 58 56 32 0 0 0 0 0 0 0 0 0 0 65 0 0 0 
  Received packet type 65
+UDP 58 0 0 1 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 0 0 0 0 0 0 0 0 0 0 6B 0 0 0 0 0 0 0 FF 1 D0 1 0 0 FF 1 52 6F 73 65 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
-UDP 24 0 0 34 0 0 0 0 0 0 0 0 0 0 0 0 4C 49 46 58 56 32 0 0 0 0 0 0 0 0 0 0 65 0 0 0 
  Received packet type 65
+UDP 58 0 0 1 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 0 0 0 0 0 0 0 0 0 0 6B 0 0 0 0 0 0 0 FF 1 D0 1 0 0 FF 1 52 6F 73 65 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

here is packet 65 and also the packet that was sent 6b?

https://github.com/magicmonkey/lifxjs/blob/master/Protocol.md#0x65---get-light-state

0x65 - Get light state

Sent to a bulb to request its current light state (which includes its color, dim level, power level, label, and tags).

Payload (0 bytes)

payload {
  // None
}
Subsequent actions

Will generally be followed by one or more 0x6b packets in response.

progress??

Hootie81 · September 9, 2014, 10:44am

It looks like the response from the core is twice the size of the arduino, could it be that the core is 32bit vs arduino 16bit

I found that when comparing printed hex numbers size i had to pad all the single numbers with a leading 0 otherwise its hard to line them up and compare.

I’ll spend a bit of time now and see what i can see difference wise… if you could let the arduino run for a while and get a good amount of data for me to compare that would make it easier. and maybe some changes to get a good mix of different codes

lightx · September 9, 2014, 3:09pm

OK, great @Hootie81. How would you like to receive this log? There is quite a bit of information.

Hootie81 · September 9, 2014, 3:26pm

@kennethlimcp Is there a reason why we drop the baud down to 9600? can we bump it back up to 115200? i dont know if it will make much difference but i did have issues once.

also the pins are defined as below, should they be changed to the mapped pins like D1 or D4??

// pins for the RGB LED:
const int redPin = 3;
const int greenPin = 5;
const int bluePin = 6;

kennethlimcp · September 9, 2014, 3:27pm

No reason other than Coolterm always defaulting to 9600 which becomes a hassle to switch it everytime

I think the numerical values for the pins shouldn’t interfere at all. It’s going to call the Digital pins and the main thing making this work is the UDP/TCP.

You probably just have a non-functional “bulb” with the incorrect pins but the interaction with the LIFX app should still work.

lightx · September 9, 2014, 3:32pm

@kennethlimcp did you try adding the myUDP.h from on top of this thread?

kennethlimcp · September 9, 2014, 3:33pm

I have yet to do so but will do it in a while. Been messing with other Spark stuff!

Things seems much better now:

LIFX bulb emulator for Arduino starting up...
AD:DE:AD:DE:AD:DE
IP address for this bulb: 192.168.1.80
Config does not exist in EEPROM, writing...
Done writing EEPROM config.
EEPROM dump:
65 114 100 117 105 110 111 32 66 117 108 98 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 
Set light - hue: 0, sat: 0, bri: 65535, kel: 2000, power: 65535 (on)
-UDP 24 0 0 34 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 
  Received packet type 2
+UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 1 7C 1 0 0 
+UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 2 7C 1 0 0 
-UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 1 7C 1 0 0 
  Received packet type 3
  Unknown packet type, ignoring
-UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 2 7C 1 0 0 
  Received packet type 3
  Unknown packet type, ignoring
-UDP 24 0 0 34 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 
  Received packet type 2
+UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 1 7C 1 0 0 
+UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 2 7C 1 0 0 
-UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 1 7C 1 0 0 
  Received packet type 3
  Unknown packet type, ignoring
-UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 2 7C 1 0 0 
  Received packet type 3
  Unknown packet type, ignoring
-UDP 24 0 0 34 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 
  Received packet type 2
+UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 1 7C 1 0 0 
+UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 2 7C 1 0 0 
-UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 1 7C 1 0 0 
  Received packet type 3
  Unknown packet type, ignoring
-UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 2 7C 1 0 0 
  Received packet type 3
  Unknown packet type, ignoring
-UDP 24 0 0 34 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 
  Received packet type 2
+UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 1 7C 1 0 0 
+UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 2 7C 1 0 0 
-UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 1 7C 1 0 0 
  Received packet type 3
  Unknown packet type, ignoring
-UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 2 7C 1 0 0 
  Received packet type 3
  Unknown packet type, ignoring
-UDP 24 0 0 34 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 
  Received packet type 2
+UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 1 7C 1 0 0 
+UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 2 7C 1 0 0 
-UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 1 7C 1 0 0 
  Received packet type 3
  Unknown packet type, ignoring
-UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 2 7C 1 0 0 
  Received packet type 3
  Unknown packet type, ignoring
-UDP 24 0 0 34 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 
  Received packet type 2
+UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 1 7C 1 0 0 
+UDP 29 0 0 1 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 3 0 0 0 2 7C 1 0 0

It hung here which indicates it might be stuck in if (Client == true) loop?

Someone might really want to attempt to port again from the original github repo as there might be stuff i changed incorrectly. (which i hope not :p)

I believe the UDP is working except for some of the unknown packet. Used http://virtualbulb.lifx.co/ to change the lightbulb settings and the core received the commands and even set the parameters!

Is the mac address LSB or MSB first for the values?

lightx · September 9, 2014, 4:10pm

I changed the EEPROM setting in lifx.h to

#define EEPROM_CONFIG "AL2" // 3 byte identifier for this sketch's EEPROM settings
#define EEPROM_CONFIG_START 72 // store EEPROM_CONFIG at the end of EEPROM
//#define EEPROM_CONFIG "AL1" // 3 byte identifier for this sketch's EEPROM settings
//#define EEPROM_CONFIG_START 253 // store EEPROM_CONFIG at the end of EEPROM

and added the myUDP.h. I can see the core from within the LIFX app AND Im able to turn on and turn off the LEDs on my core!!!

-UDP 24 0 0 14 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 1 0 0 0 0 0 0 0 0 0 E 0 0 0 
  Received packet type E
  Unknown packet type, ignoring
-UDP 24 0 0 14 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 
  Received packet type 4
  Unknown packet type, ignoring
-UDP 24 0 0 14 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 
  Received packet type 4
  Unknown packet type, ignoring
-UDP 26 0 0 14 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 0 0 0 0 0 0 0 0 0 0 15 0 0 0 0 0 
  Received packet type 15
Set light - hue: 0, sat: 0, bri: 65535, kel: 2000, power: 0(off)
+UDP 26 0 0 54 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 0 0 0 0 0 0 0 0 0 0 16 0 0 0 0 0 
-UDP 26 0 0 14 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 0 0 0 0 0 0 0 0 0 0 15 0 0 0 0 0 
  Received packet type 15
Set light - hue: 0, sat: 0, bri: 65535, kel: 2000, power: 0(off)
+UDP 26 0 0 54 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 0 0 0 0 0 0 0 0 0 0 16 0 0 0 0 0 
-UDP 26 0 0 54 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 0 0 0 0 0 0 0 0 0 0 16 0 0 0 0 0 
  Received packet type 16
  Unknown packet type, ignoring
-UDP 58 0 0 54 0 0 0 0 D0 73 D5 0 13 2A 0 0 4C 49 46 58 56 32 0 0 0 0 0 0 0 0 0 0 6B 0 0 0 0 0 0 0 74 E9 F0 A 0 0 FF FF 4C 69 76 69 6E 67 20 52 6F 6F 6D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 
  Received packet type 6B
  Unknown packet type, ignoring
-UDP 58 0 0 54 0 0 0 0 D0 73 D5 0 13 2A 0 0 4C 49 46 58 56 32 0 0 0 0 0 0 0 0 0 0 6B 0 0 0 0 0 0 0 74 E9 F0 A 0 0 FF FF 4C 69 76 69 6E 67 20 52 6F 6F 6D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 
  Received packet type 6B
  Unknown packet type, ignoring
-UDP 26 0 0 14 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 0 0 0 0 0 0 0 0 0 0 15 0 0 0 1 0 
  Received packet type 15
Set light - hue: 0, sat: 0, bri: 65535, kel: 2000, power: 1 (on)
+UDP 26 0 0 54 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 0 0 0 0 0 0 0 0 0 0 16 0 0 0 1 0 
-UDP 26 0 0 54 0 0 0 0 DE AD DE AD DE AD 0 0 DE AD DE AD DE AD 0 0 0 0 0 0 0 0 0 0 16 0 0 0 1 0 
  Received packet type 16
  Unknown packet type, ignoring
-UDP 26 0 0 54 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 0 0 0 0 0 0 0 0 0 0 16 0 0 0 1 0 
  Received packet type 16
  Unknown packet type, ignoring

YEAH!! Lets see if its stable! I haven’t tried all the commands yet.

kennethlimcp · September 9, 2014, 4:15pm

I tried the same without success but i’m glad you somehow got it to work.

Let’s figure out if it’s stable and the code changes needed to have it working.

Just wondering how did you figure out that the EEPROM needed to be changed?

lightx · September 9, 2014, 4:18pm

I was looking at the spark EEPROM documentation and it has 100 byte so I though why not change it so that its way under to be on the safe side. Lucky guess!?

One thing that help me is using the webIDE and then flashing the core locally with spark-cli putting it in DFU mode.

Before your debug was missing the EEPROM configuration and now if you try again, you see the bulb name and tags. Like the following…

LIFX bulb emulator for Arduino starting up...
IP address for this bulb: 10.0.3.113
Config exists in EEPROM, reading...
Bulb label: Rose............................
Bulb tags: ........
Bulb tag labels: ................................
Done reading EEPROM config.
EEPROM dump:
82 111 115 101 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 65 76 50 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 65 76 49 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 
Set light - hue: 0, sat: 0, bri: 65535, kel: 2000, power: 65535 (on)
-UDP 24 0 0 14 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 1 0 0 0 0 0 0 0 0 0 E 0 0 0 
  Received packet type E
  Unknown packet type, ignoring

lightx · September 9, 2014, 4:20pm

added #include myUDP.h in the arduinolifx.ino and the following

 //----- UDP + overloading the inappropriate UDP functions of the Spark Core (REQUIRED !)
class myUDP : public UDP {
private :
    uint8_t myBuffer[128];
    int offset = 0;
public :
    virtual int beginPacket(IPAddress ip, uint16_t port){
        offset = 0;
        return UDP::beginPacket(ip, port);
    };
    virtual int endPacket(){
        return UDP::write(myBuffer, offset);
    };
    virtual size_t write(uint8_t buffer) {
        write(&buffer, 1);
        return 1;
    }
    virtual size_t write(const uint8_t *buffer, size_t size) {
        memcpy(&myBuffer[offset], buffer, size);
        offset += size;
        return size;
    }
        UDP myUDP;
};

kennethlimcp · September 9, 2014, 4:26pm

I’ll try that in the morning. Good catch! Always feeling fishy about that part not being displayed with serial terminal.

How about the mac address? MSB to LSB?

Let me know if it’s working stable for you after playing around?

Bedtime zZzz

Hootie81 · September 9, 2014, 4:28pm

Awesome! so glad you got it going

lightx · September 9, 2014, 4:29pm

I change it to a random mac address. The arduinolifx and the sparklifx are sometime mimicking their behavior meaning when I turn the arduinolifx off the sparklifx turns itself off also. Not sure why that is tho, I’m guessing UDP packet and the parsing of those.

It still working… !

lightx · September 9, 2014, 4:44pm

Ive added a youtube video to see what it does, quickly recorded.

kennethlimcp · September 9, 2014, 10:03pm

Can you zip up the code and share it? Just in case i still can’t get it to work there’s something i can refer to.

Time to update the repo!

lightx · September 10, 2014, 1:54pm

of course… how would you like me to share the zip?

kennethlimcp · September 10, 2014, 1:56pm

Can you dropbox it or something? I would like to figure out why mine isn’t working

kennethlimcp · September 10, 2014, 3:09pm

Great job everyone! I have pushed the code to github and made the library public for everyone’s use.

Also credited everyone for their work.

I’m going to use this as yet-another-demo for the October event!

Topic		Replies	Views
Library List + Porting How To Libraries	2	3543	December 21, 2014
Lixie driver library import Libraries	21	1438	June 21, 2019
Rand or Random for random numbers? Firmware	8	5061	July 28, 2015
v0.2.3 Firmware RAM Optimizations Shipped! Firmware	46	3774	August 5, 2014
Porting HT1632C driver to Spark Core, need help! Firmware	21	5424	February 13, 2016

Porting arduinolifx, a LIFX bulb

Related topics