Possible differences in bulb versions

[biggestT]

This is mentioned in #4 but it seems like it hasn't been solved yet

I had to change the handle for color change to make the library work with my newly bought Magic Blue bulb. I also had issues connecting to the bulb when address type was set to random and therefore changed it to public which made connection work (not sure why, might be an issue within bluepy lib?). Changes can be seen in this commit to my fork. I have tried this on my laptop and a Raspberry Pi, both running Arch Linux.

Here is some gatttool output:

[20:16:03:09:00:A8][LE]> primary
attr handle: 0x0001, end grp handle: 0x0007 uuid: 00001800-0000-1000-8000-00805f9b34fb
attr handle: 0x0008, end grp handle: 0x0008 uuid: 0000fff0-0000-1000-8000-00805f9b34fb
attr handle: 0x0009, end grp handle: 0x000b uuid: 0000ffe5-0000-1000-8000-00805f9b34fb
attr handle: 0x000c, end grp handle: 0xffff uuid: 0000ffe0-0000-1000-8000-00805f9b34fb
[20:16:03:09:00:A8][LE]> char-write-req 0c000c 56FFFFFF00f0aa
Error: Characteristic Write Request failed: Attribute can't be written
[20:16:03:09:00:A8][LE]> char-write-req 0c000b 56FFFFFF00f0aa
Characteristic value was written successfully

In the official magic blue app my bulb is listed with a description saying "Hardware V9", @Betree @don41382 what is the hardware version reported by your bulbs? I bought mine from http://www.miniinthebox.com/ btw.

Perhaps there is a way to query the bulbs version number or something and make the lib more dynamic in those places. Will look into this when I have some more spare time :)

Also thanks for a nice lib!

[Betree]

This is interesting, mine shows "Hardware V7". Your changes seem to work with the V7 too so I may as well merge them.

It may indeed be interesting to check the bulb version in the future. Could you run the following code in a python console and let me know about the result ?

from bluepy.btle import Scanner, DefaultDelegate

class ScanDelegate(DefaultDelegate):
    def __init__(self):
        DefaultDelegate.__init__(self)

    def handleDiscovery(self, dev, isNewDev, isNewData):
        if isNewDev:
            print("Discovered device", dev.addr)
        elif isNewData:
            print("Received new data from", dev.addr)

scanner = Scanner().withDelegate(ScanDelegate())
devices = scanner.scan(10.0)

for dev in devices:
    print("Device {} ({}) - {} \n{}".format(dev.addr, dev.addrType, dev.rssi, dev.getScanData()))

My results are :

Discovered device c7:17:1d:43:39:03 Device c7:17:1d:43:39:03 (random) - -77 [(9, 'Complete Local Name', 'LEDBLE-1D433903'), (3, 'Complete 16b Services', 'f0ffe5ffe0ff'), (1, 'Flags', '06'), (25, 'Appearance', '4000')]

[biggestT]

Nice that it works for your's too @Betree , I created PR #8 now.

Running that code I got:

Discovered device 20:16:03:09:00:a8 Device 20:16:03:09:00:a8 (public) - -60 [(1, 'Flags', '05'), (3, 'Complete 16b Services', 'f0ffe5ffe0ff'), (9, 'Complete Local Name', 'LEDBLE-030900A8'), (25, 'Appearance', '0000')]

[Betree]

After few more tests I realized I was wrong : both protocols are not compatible. I merged your changes and added a --bulb-version (or -b) option to set the bulb version. If you're using the lib directly, you can set it with the second param when initializing the lib. If version is set to 9 your changes apply.

Of course it would be better to detect this automatically. Bluepy gives us the address type (public / random) but from what we've got I'm not sure about how we could detect the bulb version.

[StevenLooman]

I think the handle problems are solved with #20. The UUID appears to be the same for all bulbs/versions. The BT-library can get the handle from/via the UUID.

[Betree]

Indeed, there may still be some troubles with the address types in the future but I'll close this for now.