Controlling individual bulbs

[evanpurkhiser]

I have 3 tikteck lamps. Connecting to any of the 3 lamp addresses and calling set_state causes all of the lamps to be set to that state.

I suspect for whatever reason these bulbs have some knowledge of the 'groups' they belong to? I'm not quite sure.

I can provide a HCI snoop log from my android device. I'd also be willing to donate a bulb to help diagnose the issue (especially since it looks like we're both in the bay area).

[mjg59]

I've got two bulbs, so I'll take a look at this in the next few days. It's certainly possible that I'm using group commands when I should be using something else.

[evanpurkhiser]

I was wondering how it actually does end up controlling all bulbs, reading through the app itself it does indeed mention that the bulbs "network themselves together" to allow for extended range. I haven't had the opportunity to investigate what's going on here however.

[evanpurkhiser]

@mjg59 I was curious if you could offer any pointers on reading the binary output from the HCI snoop log? Is there a tool I can use to parse it out to be understandable at the GATT layer? Though I suspect the command may be buried under the application level encryption.

[acgourley]

I'm seeing the same thing. Bulbs near each other tend to trigger their neighbors when I use this library.

I have't tried using the official app to break them into the groups to see if that fixes it, have you @EvanPurkhiser ?

[evanpurkhiser]

@acgourley I haven't tried. I actually gave in and bought a set of Philips Hues since the API is supported much better.

[Leiaz]

I don't have this light bulb, but it looks like the one I have Awox mesh light is very similar. @mjg59 If those form a mesh network too, there may be a command to set the address, and msgid in send_packet would be the destination address for the command.

[blakemlloyd]

Anyone have any ideas for this? I tried brute forcing the commands setting the colour and whatever happened on one of them was also duplicated on the other. But the mesh idea @Leiaz raised could be a possibility? However looking through the HCI snoop log the exact same commands are being sent from the app without having the same consequence?

[Leiaz]

@Driftall The structure of the packet is similar the light bulb I have. You can try to change calls to send_packet to use 0 as msgid instead of 0xffff. With my light this is the "mesh id", and the light always answer to 0, even after assign it a different number. I think 0 could designate the light that you are directly connected to, and 0xffff would "broadcast" to all, but that is just an idea. I have only one light, so I didn't test the mesh features.

Edit : Perhaps also try removing the |0x80 added to msgid in send_packet. With my light, id > 0x8000 seem to be used for group ids. (Also, is there a shift missing ? Only the lowest byte of msgid is used)

[blakemlloyd]

@Leiaz I didn't see your edit, but that seemed to be the key! Did some more looking into adb logcat when creating groups only to find the messages being sent after creating groups contained the last byte of the MAC address. So replacing the msgid with the last byte of the MAC address along with removing the second byte now means they can be controlled individually

[acgourley]

This is really exciting - if you could merge in a script showing that functionality or post a gist I would appreciate and use it.