Unable to connect to MOVE

[beanian]

When I execute hcitool lescan I can see the MOVE2 which i'm assuming is my MOVE device. (I have noticed it is not CSRMESH like others have seen)

Executing the cli results in the following error:

Any ideas?

[Swiftnesses]

I guess this is because you're using the new firmware? Bluetooth standard. Has anyone has success accessing the blinds with this new firmware?

[beanian]

That could be it. I wasn't aware there was a difference in bluetongue protocols depending on firmware. Have you a source of or more information on this? I have only took delivery of the unit this week.

[nkaminski]

I do not have a MOVE unit, however I am aware of some previous issues related to MOVE connectivity that were thought to be a result of the MOVE unit enforcing a random source address. Can you try temporarily replacing addrType=btle.ADDR_TYPE_PUBLIC with addrType=btle.ADDR_TYPE_RANDOM on line 13 of csrmesh/gatt.py and see if it resolves this?

[beanian]

Thanks for your help, I tried that and i'm getting this message now

[+] Connecting to device C1:43:18:00:00:01
[+] Writing 0x81fb8d008041e17a696a1b80e0c3f446afe3ff to BTLE handle 0x21
[-] A communication error has occured: Error from Bluetooth stack (comerr)
[+] BTLE disconnected
[+] Communication complete
[-] Operation failed

[klimbot]

I've just updated one of my old MOVE devices that used to work using this library and it is no longer working. It appears the firmware update breaks compatibility with this library somehow.

[nkaminski]

Can you make sure that the move is the only BT device connected and post a packet capture / HCI snoop log resulting from sending one or more commands to the device using the official app?

Make sure that the CSRmesh network PIN used is not a PIN you use for other things, and that you don't have any other Bluetooth devices active so you don't expose potentially private data in doing such however.

On February 26, 2018 6:40:00 PM CST, klimbot notifications@github.com wrote:

I've just updated one of my old MOVE devices that used to work using this library and it is no longer working. It appears the firmware update breaks compatibility with this library somehow.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/25#issuecomment-368703935

-- Sent from my Android device with K-9 Mail.

[beanian]

@nkaminski I have attached my snoop log. I followed the following procedure

1. Enabled snoop log
2. connected to MOVE device
3. Issued a blind up command
4. issued a blind down command

My move mac address is c1:43:18:00:00:01 Hopefully this makes sense to you btsnoop_hci.log

[nkaminski]

I will take a look at it this weekend. Also, what is the 4 digit network PIN you used when you created this log? FYI if you want to see the contents of the log file, open it in Wireshark.

On March 2, 2018 8:01:25 AM CST, beanian notifications@github.com wrote:

@nkaminski I have attached my snoop log. I followed the following procedure

1. Enabled snoop log
2. connected to MOVE device
3. Issued a blind up command
4. issued a blind down command

Hopefully this makes sense to you btsnoop_hci.log

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/25#issuecomment-369928173

-- Sent from my Android device with K-9 Mail.

[beanian]

@nkaminski the network key is 8888. Yeah I was looking at it in wireshark to see if I could make sense of it but I'm not familiar enough with bluetooth protocols to understand what is going on!

[beanian]

@nkaminski Did you get a chance to look at this?

[nkaminski]

I had gotten sidetracked with a few other priorities. Will look at this tonight.

• Nash

On March 12, 2018 9:39:30 AM CDT, beanian notifications@github.com wrote:

@nkaminski Did you get a chance to look at this?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/25#issuecomment-372332395

-- Sent from my Android device with K-9 Mail.

[nkaminski]

OK so this still looks like CSRMesh traffic, which is good. Possibly the format of the payload is what has changed. Going to revise my decryption tool slightly to make it easier for all (including myself) to analyze and see what has changed.

[lisaele]

Any progress on this? I'm having the same issue since updating the firmware and it would be much appreciated if you could find a solution. :)

[nkaminski]

I should be able to look into this more this weekend.

[Swiftnesses]

@nkaminski any luck?

[nkaminski]

@Swiftnesses Yes, one of the issues is that the 2 BTLE handles that the data is sent to has changed. Can you test with the move-experimental branch and let me know if you still see this issue?

If you do still see this issue, I have finished building my analysis tool, csrmesh-util, that can encrypt and decrypt raw data so that we can investigate further.

• Nash

On May 11, 2018 4:30:07 PM CDT, Swiftnesses notifications@github.com wrote:

@nkaminski any luck?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/25#issuecomment-388490750

-- Sent from my Android device with K-9 Mail.

[Swiftnesses]

@nkaminski Just fired up the RP I used to test this some time ago... Trying to remember the commands :)

Have the commands changed with your new exp. branch release?

[Swiftnesses]

@nkaminski

Seem to be hitting an error upon install:

https://pastebin.com/CYeXwkwF

[Swiftnesses]

Seems I needed to run: sudo apt-get install libglib2.0-dev

[Swiftnesses]

Tried issuing this command:

sudo ./bin/csrmesh-cli move --pin 263056 --dest EE:16:B0:00:00:04 --position 120

I get:

[+] Connecting to device EE:16:B0:00:00:04 [-] A connection error has occured: Failed to connect to peripheral EE:16:B0:00:00:04, addr type: public [-] Connection to mesh failed [-] Operation failed

[nkaminski]

Interesting, so it isn't even connecting to the device. I've made another experimental change to the move-experimental branch where random source addresses, as opposed to a fixed, public address are used. Some BTLE stacks only accept one type of address or the other. Can you retest?

On May 13, 2018 4:18:47 AM CDT, Swiftnesses notifications@github.com wrote:

Tried issuing this command:

sudo ./bin/csrmesh-cli move --pin 263056 --dest EE:16:B0:00:00:04 --position 120

I get:

[+] Connecting to device EE:16:B0:00:00:04 [-] A connection error has occured: Failed to connect to peripheral EE:16:B0:00:00:04, addr type: public [-] Connection to mesh failed [-] Operation failed

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/25#issuecomment-388612848

-- Sent from my Android device with K-9 Mail.

[Swiftnesses]

@nkaminski I can just make the changes to the file on my pi, right? No need to rebuild etc?

[nkaminski]

Yes, but make sure you edit the correct copy of the file if you have installed it system-wide or virtualenv-wide.

On May 14, 2018 8:36:14 AM CDT, Swiftnesses notifications@github.com wrote:

@nkaminski I can just make the changes to the file on my pi, right? No need to rebuild etc?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/25#issuecomment-388818740

-- Sent from my Android device with K-9 Mail.

[nkaminski]

@Swiftnesses Also, I would recommend using a 4 digit PIN since my library will not handle PINs with a length other than 4 correctly at the moment.

This will be easy to implement if you can provide a Bluetooth packet capture of the resulting traffic when a PIN longer than 4 digits is used however.

On May 14, 2018 8:36:14 AM CDT, Swiftnesses notifications@github.com wrote:

@nkaminski I can just make the changes to the file on my pi, right? No need to rebuild etc?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/25#issuecomment-388818740

-- Sent from my Android device with K-9 Mail.

[Swiftnesses]

Same error as before, with the exception that the error message now states 'random'

[Swiftnesses]

The new app generates 6 digit pins, I'll override it however and re-add some devices to test!

[Swiftnesses]

@nkaminski created a new 'place' with a 4 digit pin and re-added the devices. Tried with the both experimental versions (with and without random). Sadly, no luck :(

[Swiftnesses]

@beanian I'm not great with debugging (no wireshark), can you perhaps help us too?

[Swiftnesses]

My dreams of integrating these into my home automation schedule are slipping away, perhaps it's time to look for an alternative 😢

[lisaele]

Did you kill the app on your phone before sending the commands?

[nkaminski]

@Swiftnesses If you would like to try taking a packet capture for me to analyze:

Ensure any other paired Bluetooth devices are off/disconnected to avoid exposing any potentially private data.

Enable the Android developer options by clicking 10 times on the build number under settings>about

Kill/force stop the teptron move app

Enable the checkbox in settings > developer options for "Bluetooth HCI snoop logging"

Open the teptron app and perform a few known actions, recording specifically what you do.

Disable/uncheck the "Bluetooth HCI snoop logging" option.

Copy the btsnoop.log file from the device using the Android file transfer application available from Google and attach to this issue, along with the PIN that was used when interacting with the devices.

On May 15, 2018 7:47:41 AM CDT, Swiftnesses notifications@github.com wrote:

My dreams of integrating these into my home automation schedule are slipping away, perhaps it's time to look for an alternative 😢

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/25#issuecomment-389153924

-- Sent from my Android device with K-9 Mail.

[nkaminski]

@Swiftnesses Also since this looks like a connection issue and not a protocol level issue, at least at the moment, can you try connecting to the device manually:

Make sure the teptron app is completely stopped (or turn off Bluetooth on the phone temporarily).

On the pi run: bluetoothctl

Then at the prompt, run:

power on scan on

list-attributes connect All of such steps should succeed without returning errors. On May 15, 2018 7:49:10 AM CDT, lisaele wrote: >Did you kill the app on your phone before sending the commands? > >-- >You are receiving this because you were mentioned. >Reply to this email directly or view it on GitHub: >https://github.com/nkaminski/csrmesh/issues/25#issuecomment-389154337 -- Sent from my Android device with K-9 Mail.

[Maatss]

Thought I could pitch in with a couple of tests.

I have the latest experimental version of csrmesh installed.

Config 1. (Success?) MOVE-unit MAC-ADDRESS: C1:43:18:00:00:01 PIN: 4321 ADDR_TYPE_RANDOM HANDLE: 0x001C

Results in: Yet the MOVE-unit doesn't move at all.

Config 2. (unsuccessful) MOVE-unit MAC-ADDRESS: C1:43:18:00:00:01 PIN: 4321 ADDR_TYPE_PUBLIC HANDLE: 0x001C

Results in: This indicates that 'ADDR_TYPE_RANDOM' is needed.

Config 3. (unsuccessful) MOVE-unit MAC-ADDRESS: C1:43:18:00:00:01 PIN: 4321 ADDR_TYPE_RANDOM HANDLE: 0x0021

Results in: Perhaps an unnecessary test, but it shows that the new handle (0x001C) is correct.

And here are also two bluetooth snoop logs

Snoop 1. What I did: Pin: 123456

1. Start the app
2. Select ‘place1’ inside ‘MOVE TEPTRON’-app
3. Wind all the way down (completely closed)
4. Wind all the way up (completely open)
5. Wind half way down (somewhere in the middle)
6. Close down app btsnoop_hci_place1_pin123456.log

Snoop 2. What I did: Pin: 123456

1. Start the app
2. Select ‘place2’ inside ‘MOVE TEPTRON’-app
3. Wind all the way down (completely closed)
4. Wind all the way up (completely open)
5. Wind half way down (somewhere in the middle)
6. Close down app btsnoop_hci_place2_pin123456.log

Note: Be sure to ‘disconnect’ from MOVE2 if you have tried the bluetoothctl stuff metioned earlier, csrmesh-cli failed in all cases until I did just so. Also, as has been said previously as well, be sure your phone isn’t connected to the MOVE (turn off Bluetooth and terminate MOVE-app)

[Maatss]

Any news?

[nkaminski]

Will look into this later this week.

On June 17, 2018 10:31:02 AM CDT, Maatss notifications@github.com wrote:

Any news?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/25#issuecomment-397886589

-- Sent from my Android device with K-9 Mail.

[Maatss]

Any progress?

[DjangoEdwards]

Any Progress? Would love top integrate my moves in my smart home.

[Swiftnesses]

Me too 👍

[nkaminski]

Yeah I haven't turned attention to this for a while. I will try to take a look at it this week.

On September 10, 2018 1:14:31 PM CDT, Swiftnesses notifications@github.com wrote:

Me too 👍

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/25#issuecomment-420009122

-- Sent from my Android device with K-9 Mail.

[Swiftnesses]

Praying, this would be huge for me...

[nkaminski]

Have not lost sight of this.

On October 4, 2018 6:12:18 AM CDT, Swiftnesses notifications@github.com wrote:

Praying, this would be huge for me...

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/25#issuecomment-426980080

-- Sent from my Android device with K-9 Mail.

[veaceslavc]

This is my only hope, MOVEZ is dead looks like.

[nkaminski]

OK, so I have finished building a sort of CSRMesh device emulator (which I will commit after a little code cleanup) and have the following results from replaying @beanian 's packet captures into such:

~/Code/csrmesh ‹move-experimental*› » python read_pcap.py --pin 123456 --capturejson test_packets.json | grep decpayload decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'01807322ffffff00d2' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0180732200ffff00d3' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'018073227cffff00d4' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff'

~/Code/csrmesh ‹move-experimental*› » python read_pcap.py --pin 123456 --capturejson test_packets_place2.json | grep decpayload decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'01807322ffffff00c9' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0180732200ffff00ca' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0000734564b40004ff' decpayload: b'0180732289ffff00cb' decpayload: b'0180732289ffff00cb'

Therefore, since this further supports the theory of a protocol level change, I plan to modify the csrmesh-cli tool to be able to packetize and send arbitrary binary payloads so that we may replay each unique type of packet to determine the effect of such. Also when you work these devices from the app, do you tell the device to go to an absolute position or to you just provide relative movement commands (up, down, stop)?

[klimbot]

I haven't really used the latest version much but I'm pretty sure it goes to an absolute position during normal use. In case it matters, but during device config you set the absolute position limits and then you command the device to different positions within those limits when using the device via the app.

It's possible to free drive it in a given direction but not during normal operation.

[Maatss]

@nkaminski ~/Code/csrmesh ‹move-experimental*› » python read_pcap.py --pin 123456 --capturejson test_packets.json | grep decpayload

decpayload: b'0000734564b40004ff' decpayload: b'01807322ffffff00d2' decpayload: b'0000734564b40004ff' ... decpayload: b'0000734564b40004ff' decpayload: b'0180732200ffff00d3' decpayload: b'0000734564b40004ff' ... decpayload: b'0000734564b40004ff' decpayload: b'018073227cffff00d4'

~/Code/csrmesh ‹move-experimental*› » python read_pcap.py --pin 123456 --capturejson test_packets_place2.json | grep decpayload

decpayload: b'0000734564b40004ff' decpayload: b'01807322ffffff00c9' decpayload: b'0000734564b40004ff' ... decpayload: b'0000734564b40004ff' decpayload: b'0180732200ffff00ca' decpayload: b'0000734564b40004ff' ... decpayload: b'0000734564b40004ff' decpayload: b'0180732289ffff00cb'

---

Within the app the different positions can be set between a value of 0-255, where 0 is fully open and 255 fully closed. While examining the unique payloads one could see that only two bytes seem to change, the first is the position byte, and the last byte is some sort of counter?

decpayload: b'01807322ffffff00d2' // ff = 255 (Fully closed) decpayload: b'0180732200ffff00d3' // 00 = 0 (Fully open) decpayload: b'018073227cffff00d4' // 7C = 124 (About half way down)

decpayload: b'01807322ffffff00c9' // ff = 255 (Fully closed) decpayload: b'0180732200ffff00ca' // 00 = 0 (Fully open) decpayload: b'0180732289ffff00cb' // 89 = 137 (About half way down)

[nkaminski]

The other unknown is how the device ID/address is encoded. Would someone on this thread who has more than one physical MOVE device be able to share a packet capture containing an interaction with more than one physical device?

Given this, we should have an accurate enough description of the revised protocol for a confident attempt at implementation of such :)

On October 7, 2018 1:10:36 AM CDT, Maatss notifications@github.com wrote:

@nkaminski> ~/Code/csrmesh ‹move-experimental*› » python read_pcap.py --pin 123456 --capturejson test_packets.json | grep decpayload>

decpayload: b'0000734564b40004ff'> decpayload: b'01807322ffffff00d2'> decpayload: b'0000734564b40004ff'> ...> decpayload: b'0000734564b40004ff'> decpayload: b'0180732200ffff00d3'> decpayload: b'0000734564b40004ff'> ...> decpayload: b'0000734564b40004ff'> decpayload: b'018073227cffff00d4'>

~/Code/csrmesh ‹move-experimental*› » python read_pcap.py --pin 123456 --capturejson test_packets_place2.json | grep decpayload>

decpayload: b'0000734564b40004ff'> decpayload: b'01807322ffffff00c9'> decpayload: b'0000734564b40004ff'> ...> decpayload: b'0000734564b40004ff'> decpayload: b'0180732200ffff00ca'> decpayload: b'0000734564b40004ff'> ...> decpayload: b'0000734564b40004ff'> decpayload: b'0180732289ffff00cb'>

---> Within the app the different positions can be set between a value of 0-255, where 0 is fully open and 255 fully closed. While examining the unique payloads one could see that only two bytes seem to change, the first is the position byte, and the last byte is some sort of counter?>

decpayload: b'01807322ffffff00d2' // ff = 255 (Fully closed)> decpayload: b'0180732200ffff00d3' // 00 = 0 (Fully open)> decpayload: b'018073227cffff00d4' // 7C = 124 (About half way down)>

decpayload: b'01807322ffffff00c9' // ff = 255 (Fully closed)> decpayload: b'0180732200ffff00ca' // 00 = 0 (Fully open)> decpayload: b'0180732289ffff00cb' // 89 = 137 (About half way down)

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/25#issuecomment-427628761

-- Sent from my Android device with K-9 Mail.

[andrasj]

I tried to generate a logfile as requested, hopefully it has any value. What I did:

• I registered 2 Move devices into the official app (network pin: 1234)
• I struggled to get a hci-snooplog (seems to be a little more difficult in android 8.x) (after enabling log, toggle BT)
• Rebooted device
• started Move-App (and wait to connected state)
• Open device1
• Close device1
• Open device2
• Close device2
• generated debug-report & extracted the hci-snooplog (see attachment) It's possible I first did the close, then the open, but same order for both devices. To me, it's not clear what is the open/close button. Pressing at the outer right position (curtain closed icon) make the Move turn, and when it finishes, the slider is positioned next to the 'curtain open icon'. Anyway, if communication is reliable, I could try to integrate it in HA and use an app of choice...

Hope this logfile is sufficient.

hci_snoop_Move2Devices.zip

Edit: I'm not that used to python, but I cannot find the read_pcap.py file. Did you already push it?

[Swiftnesses]

Hey guys, any progress on this following the above logs?

[nkaminski]

Looking into it, however one oddity that I've noticed is that @andrasj 's capture uses a 4 digit PIN. Can you confirm that you are using the new firmware on your move devices?

I thought from previous comments that the new firmware used a 6 digit PIN. Since I don't have any move devices can you also confirm what the correct constraint on the PIN for the new firmware is?

With new firmware can the PIN only be exactly 4 or exactly 6 digits or can it be within some larger range of M to N digits? If so, what are M and N?

[Swiftnesses]

Thanks for looking into this :)

I'll need to check, I thought it needed 4 digits, let me check once I'm home, unless @andrasj can confirm first!