Bulbs is somtimes sending data outside spec

Hi
Since my parser

is fairly strict it throws exceptions when undefined messages are seen.
And the show up once in a 200 received messages.

Should i Just ignore the offending data ? or is it a “small” bug in the bulbs ?
/Regards
/Per
Attached i a short log of with two offending messages.


2016-02-07 09:40:55.00 : 192.168.0.85:56700:LIFX.Tests.Applications.On_StateWifiInfo
Header => ()
Signal => 1.99526E-08,
Tx => 1015596,
Rx => 1043689

2016-02-07 09:40:57.00 : 192.168.0.85:56700 : raised CONSTRAINT_ERROR : Unknown message => 111
Call stack traceback locations:
0x412a8d 0x404a1b 0x4273a6 0x7f8710286553 0x7f870f2abb9b 0xfffffffffffffffe
Call stack traceback locations:
0x412a8d 0x404a1b 0x4273a6 0x7f8710286553 0x7f870f2abb9b 0xfffffffffffffffe
00: 26 00 00 54 42 52 4B 52 D0 73 D5 00 6B AC 00 00 “&??TBRKR\D0s\D5?k\AC??”
10: 4C 49 46 58 56 32 00 00 C4 BB 01 11 3B 9C 30 14 “LIFXV2??Ļ??;\9C0?”
20: 6F 00 00 00 7E 0D “o???~?”

2016-02-07 09:41:01.00 : 192.168.0.85:56700:LIFX.Tests.Applications.On_StateWifiInfo
Header => ()
Signal => 1.25893E-08,
Tx => 1015734,
Rx => 1043799

2016-02-07 09:41:03.00 : 192.168.0.85:56700 : raised CONSTRAINT_ERROR : Unknown message => 406
Call stack traceback locations:
0x412a8d 0x404a1b 0x4273a6 0x7f8710286553 0x7f870f2abb9b 0xfffffffffffffffe
Call stack traceback locations:
0x412a8d 0x404a1b 0x4273a6 0x7f8710286553 0x7f870f2abb9b 0xfffffffffffffffe
00: 28 00 00 54 42 52 4B 52 D0 73 D5 00 6B AC 00 00 “(??TBRKR\D0s\D5?k\AC??”
10: 4C 49 46 58 56 32 00 00 C4 77 A2 76 3C 9C 30 14 “LIFXV2??\C4w\A2v<\9C0?”
20: 96 01 00 00 54 0B 00 00 “\96???T???”

There are some messages that are currently undocumented. Your application should ignore these.

Still, it seems a bit weird that the bulb would reply with an undocumented message if the application is only sending documented messages. I guess that from the sequence number it should be possible to determine which message the bulb thinks it’s replying to.

You are right, you should be able to check the source and sequence numbers to see if these are replies to information requested by your application.

If the source and sequence numbers indicate that it is a reply, and you can’t find documentation for the message type this is something we will need to fix.

HI
I Updated the program to log both outgoing and incoming messages so I uploaded a complete log to:
https://drive.google.com/file/d/0BzoDupCTOXWiaFhDVFhpUjFneFE/view?usp=sharing

One thing i find interesting is that the sequence number is 0

Just search for On_Unknown in the Log.
Do you want me to get other printouts.

/Regards
/Per

Okay, so all the messages marked On_Unknown in that file were responses to a packet sent by a service internal to the LIFX Cloud. For legacy reasons these messages get broadcast to port 56700, this is something that is in the firmware teams list if things to deprecate.

The best way to avoid reception of these is to listen on an ephemeral port, and when sending use the same socket. This way the packets that you send will have their source port set to the ephemeral port, and as long as you set the source field to non zero the replies will be sent back to that port as unicast. It also means you can run several LIFX supporting applications at the same time.

If you must listen on port 56700 you can simply ignore these messages.

Thanks then i understand and i will just ignore them and use a ephemeral port.
And the problems i had with discovery was firewall rules.

/Per

Excellent! I’m glad you got it all sorted. :smiley: