Connectivity to HomeBrite A19 Household bulb does not work

[truedat101]

I've got an A19 Household bulb, which is definitely running the CSRMesh stack (maybe 1.3?)

Steps:

• I turn it on
• discover via linux host: sudo hcitool lescan
• I obtain my mac: E0:34:E4:06:DD:A2 Feit Bulb
• I run the command as a regular user: csrmesh-cli --pin 0000 --dest E0:34:E4:06:DD:A2 --level 0
• the command executes two gatttool commands, and then nothing happens

Some platform details: Linux 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

I've attached the BLE Gatt information I gathered from an android app:

[nkaminski]

We have the same bulb so this should be easy to troubleshoot :)

Bulbs that are to be controlled using this need to be configured as part of a network. I only have a single bulb at the moment, so if possible, put one bulb on a separate network with a separate PIN.

Be aware that BTLE only supports ONE connection at a time and the Feit app remains connected to the bulbs for several minutes in the background after you close it, at least on Android. This was a frustrating issue that I had during development of this.

Make sure you can connect to the bulb manually from the Linux computer using gatttool in interactive mode. i.e

run: gatttool -b -I and type "connect" at prompt

If you get errors such as "Socket error" or "Transport endpoint not connected", something else is connected to the bulb. Force stop the Feit app or temporarily turn off bluetooth on the phone running the app. I should really check the exit code of gatttool and report such errors on the console but I was a little too excited once I got the protocol implementation working and neglected to do so. Will add this in next release for sure.

You should then be able to use the csrmesh-cli utility as documented. Please let me know if you still have issues.

[truedat101]

I can definitely connect via the gatttool. No errors there. Just nothing happening with the csrmesh tool. Any other thoughts here on debugging the setup?

I have:

• iOS app setup a mesh network
• 2 bulbs

[truedat101]

Since these aren't color lights, I don't pass the red green blue values. That shouldn't matter, right?

Is there a particular version of gatttool needed?

[nkaminski]

You should only need to pass --level for white bulbs, and you should not need a specific version of gatttool. Anything packaged with bluez 5.x or newer should work.

[nkaminski]

Can you try with a single bulb network? I have not tested with more than one bulb in the network since I only have one bulb. There could be a "set destination" command that is needed with multi bulb networks.

[nkaminski]

In terms of gatttool, I'm using 5.23-2+rpi2 on a Raspberry Pi 3. Any bluez 5.x+ gatttool supports BTLE GATT and should work however.

[truedat101]

Interesting. So the app automatically groups the lightbulbs so that only a broadcast goes out to the group. I noticed the on-off triggered both bulbs. In any case, I could only detect a single bulb in the hcitool lescann. Once I shut off the other bulb, can't see anything.

Shut off the BLE on the iOS device, and I can see the one bulb. Then I run: csrmesh-cli --pin 0000 --dest E0:34:E4:06:DD:A2 --level 0

which executes the gatttool commands but no result or change.

[nkaminski]

What bluez version are you using? Also, do you have an Android device such that we can use the Bluetooth HCI snoop logging to determine with certainty if this is a packet creation or communication issue?

[truedat101]

Let me switch to my 'droid.

[nkaminski]

Capture an on and off command using the bluetooth HCI snoop logging. What is written to handles 0x0011 and 0x0014?

[truedat101]

Bluez version : 4.1.01.

Should I be building something newer?

[truedat101]

What are the commands for the hci snoop logging that you use?

[truedat101]

Ah, I see in the 'droid developer settings.

[nkaminski]

Pre 5.0 bluez is known for unstable BTLE support. That could be the issue.

• Force stop Feit app
• Go into Settings > Developer Options > and tick "enable bluetooth HCI snoop logging".
• Open feit app and switch on, wait several secs(makes it easier to ID packets), switch off.
• Untick snoop logging.
• Pull /sdcard/btsnoop_hci.log using adb
• open log in Wireshark

[nkaminski]

Going to test on my Acer C720 too running arch linux and bluez 5.40.

[truedat101]

Looks like that setting is missing from my Marshmellow 6.0 but it's still in the 5.x on my nexus.

[nkaminski]

On the nexus, go to settings > about and tap on the kernel version 10 times ;)

[truedat101]

Nexus is fine, it has the settings needed. Marshmellow device is missing the HCI snoop logging.

[nkaminski]

Reproduced issue on my C720, try changing char-write to char-write-req in gatt.py

[truedat101]

Hmm, ok, the nexus5 isn't finding anything (no mesh found). Trying this on an Nexus gen2 tablet.

[truedat101]

Is there a trick to factory reset the bulbs? None of my droids can find them after having paired with the iOS device. Even the iOS device has problems.

[nkaminski]

To reset: Turn the bulb on for 18 seconds then turn it back off for 1 second. Repeat the process 4 times.

[truedat101]

Does it blink if it worked (reset)? I'm having no luck with these android devices to connect.

[truedat101]

In any case, should I just modify the source as you'd specified above?

[nkaminski]

Yes, only works on my Pi with original source, both my Arch Linux chromebook and desktop PC require the change (and it still works on the Pi). The real app does a char-write-req as opposed to a char-write on closer inspection as well.

[truedat101]

ur running ArchLinux on the pi?

[nkaminski]

Raspbian jessie minimal on a Pi 3 and Arch Linux on an Acer C720 Chromebook. Changes pushed to repo too.

[truedat101]

So weird, on the two nexus devices the BLE doesn't want to work with this HomeBrite app. But fine on the Android 6.0 device.

[truedat101]

Cool, I'll pull those changes. If I can get this working on the desktop, will move to the router.

[nkaminski]

The Android app is extremely buggy, part of the motivation for writing this ;)

[truedat101]

Amen. I don't completely understand the obsession with making apps the single point of failure and the reason your product gets returned to the store.

[nkaminski]

Also when it failed earlier, did the gatttool commands take an unusually long time (>5 sec) to run? Running on my Acer C720, it would hang for close to a minute before continuing and the bulb not responding.

[truedat101]

Actually, no, only if the ble endpoint had become unavailable.

[nkaminski]

You should also get 2 lines of output stating "Characteristic value was written successfully" after making the change.

[truedat101]

I patched the one gatt.py line. I don't get a result other than the same as before.

[nkaminski]

Does it print "Characteristic value was written successfully"?

[truedat101]

I think I'm getting a cached bit of code here. Did you push to pip?

[nkaminski]

No, just github.

[nkaminski]

Pushing to pypi now.

[truedat101]

Sorry, I did a bad copy paste job. Retrying.

[truedat101]

Ok, so I can see it says the characteristics are written correctly. However, no luck on change of state with the bulb. Do I need a newer version of bluez? I can build that and use the latest.

[nkaminski]

Try a bluez version newer than 5.0. Both of my machines use bluez versions newer than 5.0.

[truedat101]

Ok, I'll do that.

[truedat101]

Building .... I have to remove my existing bluez package. Not sure how this will work.

[truedat101]

Hmm, that doesn't seem to help.I've got bluez 5.40 in there. Thoughts? I was hoping this was something I could bring up and verify easily, but seems like there are some nuances to deal with on each OS.

[nkaminski]

Confirm the firmware version that your bulb runs, mine is on the latest version, 0.16

Also the fact that you get the characteristic write confirmation leads me to believe that the data is being sent properly.

There is a possiblity that there is a subtle difference in the key derivation algo between iOS and Android.

Try setting up one on Android again if possible. Hard reset the bulb and clear the android app's data before starting and you should be able to get it working. The Android app's bugs prevent it from being able to join an existing network successfully.

[truedat101]

Not sure how I confirm that firmware version.

[truedat101]

I've switched to Android, but I'll try to double check that my factory reset works.

[truedat101]

Also, HomeBrite app version is 1.0.8.

Odd, I can't even get the app to connect to the bulb after trying the reset.

BTW is there any confirmation the reset works (a series of blinks or anything obvious)?

[truedat101]

Looks like even it says it can't cannot, after it gives up, DON'T reset the pin. It then lets you into the menu, and you can control the bulb. (Guess my reset didn't work).