csrmesh
csrmesh copied to clipboard
nkaminski
MOVE unit does not work with any commands other than Set Position
Readme says that other MOVE commands should work but I'm unable to get anything other than Set Position to work. I have tried other write command such as Set Speed and Move Clockwise with no output on the MOVE unit. Gattool gives the response "Characteristic value was written successfully" but I see no clockwise movement or speed change.
I do not have a Teptron MOVE unit to test/debug this with. @t0mas is the only active contributor who does to my knowledge.
I also tried some other commands with no luck. But I guess the firmware in the device does not support many other commands. Also the GoToPosition command implemented in csrmesh-cli, does not match the 'UART' spec (it should include the speed as well).
I just wanted to point to the doc, and I see all links to 'dev-decs' are gone... anyone who still has the PDF offline?
https://web.archive.org/web/20160823145645/http://www.teptron.com/MOVE_UART_Commands_ver1.0.pdf I've tried to reach Teptron to ask for some simple documentation on how to have access to the device but their reply was not, IMHO, the best.
Tnx, could have thought about the webarchive (I only checked google cache). I've also sent an email twice with some questions/feedback, I didn't receive a reply.
Currently even the 'SetPosition' through this library is not 'robust' sometimes I need to send the BLE-packet multiple times (is this software issue? or could it be hardware?). (not really useful when integrating in automation system). I'm currently making adapters so I can mount the MOVE directly to the curtain rails and I really like the result. But if I can't find/get decent software/API, mayby I'lde better use different devices.
It's a pitty they don't let the community help, I guess it would be a win-win in this situation, certainly because they seem to not have enough manpower.
How far away are the move and your BLE transmitter?
I was thinking to have a look to other devices but I could not find anything else. I'm starting to think to do my own.
currently there I am using 3 devices for testing all in a range of ca 6m (without walls). The transmitter is an intel edison board powered by the USB-port of my mediacenter. (to have an always-on low power device with BLE). Maybe I should try with real PSU and/or regular pc separate BLE-dongle. Initially I though it had something to do with duplicate packet detection, but I changed some code to try avoid this, but it doesn't make a difference.
I just tried with my Raspberry Pi Zero W and I can see your same issue. I'm using blueZ v 5.23. It is unreliable at the moment.
opkg list-installed | grep bluez bluez5 - 5.37-r0 but I see gatttool comes from a bluez-5.24 folder
I also did some quick tests on another miniPC (zotac nano running openSuSE), using a CSR-BLE-USB dongle with bluez-5.41 and first impression is that it works reliably, need to test some more in the next days
It turned out, the openSuSE with CSR-dongle wasn't reliable either. I cannot explain why, but it seems to work a little better when I open gatttool in interactive mode, and send commands connect/char-write-req/char-write-req/char-write-req/char-write-req/disconnect in a send-expect style. however it is still not 100% reliable.
I'm also having similar reliability issues with my raspberry pi 3. I've written about how to integrate the bluetooth version of the move with openHAB, and I'm seeing issues when I haven't connected to the device in a while and I try to connect for the first time. I have a couple of units connected, and once I get either of the devices to respond for the first time both units move as commanded every time. The worst part is that I sometimes get the response "Characteristic value was written successfully" and the move device does nothing. It's almost like they need a wake-up packet or something.
I think that the best solution is to re-write the library using a bluetooth library that can capture errors. I recommend BluePy. It's on my own to-do list for the summer...
The behaviour you are seeing (characteristic values are written but the device does not respond) is also consistent with an invalid packet. One parameter of the protocol that is still unknown to an extent is what the true maximum range of the sequence/nonce number is. In my implementation, I assumed it to be the full range of the data type that stores such. I may advise testing with the range of the nonce value (computed in random_seq) limited to a smaller range such as 1 to 2^16-1 in case this assumption regarding the size was incorrect.
On April 18, 2017 9:11:37 AM CDT, Oren Lederman [email protected] wrote:
I think that the best solution is to re-write the library using a bluetooth library that can capture errors. I recommend BluePy. It's on my own to-do list for the summer...
-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/17#issuecomment-294857093
-- Sent from my Android device with K-9 Mail.
This weekend I spent some more time integrating the MOVE devices in my home automation. I made some code based on this python, which starts an interactive gatttool session to send the commands to multiple devices. (auto disconnect after some 'idle' seconds) The sequenceNb is currently initialized to some 'hash' (nb of seconds since begin of month, to avoid repeated binary equal packets), so I increment the sequence with 1 on every sent packet (even over multiple 'gatt-sessions'). Still I see the MOVE device doesn't respond sometimes. I also noticed that often only 1 device is 'ignoring' its packets while packets for another device always behave as expected. (need some more usage-days of usage to verify)
Anyway I don't think the range of the sequence is the problem, because next packets for antoher device (so with 'seqNr+1' are processed normally).
Another reason can be I'm having a totally different issue here. Where did you see the 'invalid packet'? maybe I can confirm...
How far are you with this? I can confirm this issue too. Have two units (more are still in packages). But sometimes only one works. The other one does nothing. When I try to move it by the app, then both of the units work. Thanks for your effort guys
@tomas is the only developer who I am aware has a Teptron Move unit. I can certainly try to help with protocol issues however I only have a series of Feit smart bulbs for testing at the moment. Will certainly look into it, and my other priority is migrating the packet sending routines away from gatttool since it is now deprecated and unmaintained upstream and could become a cause of issues, especially with newer versions of BlueZ.
On May 31, 2017 8:23:07 AM CDT, kajaba [email protected] wrote:
How far are you with this? I can confirm this issue too. Have two units (more are still in packages). But sometimes only one works. The other one does nothing. When I try to move it by the app, then both of the units work. Thanks for your effort guys
-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/17#issuecomment-305184937
-- Sent from my Android device with K-9 Mail.
I've had the issue where it doesn't always respond when using the Pi 3 bluetooth. After changing it to an older Pi 2 with a USB bluetooth dongle it has never happened again. So in my case it seems to be in the bluetooth hardware (or I may have been very unlucky in the sequence numbers, but that would be a very strange coincidence)
That's strange because I have raspi 2 with Bluetooth dongle and it doesn't work reliably
Could it be a reception issue? Because I noticed the Bluetooth range for a usb dongle in my case was much better than for the Pi 3 internal bluetooth chip. Possibly you have too much interference or distance as well?
Guys, how are you issuing over commands to the MOVE, for example set speed? Further, is it possible to retrieve info, such as the light level? Many thanks in advance.
Further, I've also noticed that some of my MOVES sometimes don't respond, very frustrating :(
it seems everybody is experiencing these issues. Even the 'set position' command is implemented differently than the specs they released (which are offline in the meantime). My guess is the firmware of the move itself is incomplete and has some bugs. Teptron promised to release a lot of new features and new communication in august with 'new, official' BLE-standards. This made me put my MOVE project on hold (and the fact I lack spare time due to other personal events). They are literally still 'in the box', waiting for valid firmware from teptron, hopefully they get the software working properly the 2nd time...
If I have some spare time again, I'll look into it further.
Thanks for the update, it's a great shame. The strange thing is the app based actions work 100% of the time for me...
It almost seems like mine are worse if they're left for some minutes between commands, almost like they're sleeping and miss the initial command.
Might be worth seeing if there is an actual or effective "no-op" or heartbeat command that you can send before the set position command to workaround this issue. Take a look at the traffic transacted by the official app and use the packet decryption functions in crypto.py to decrypt such.
Hi @nkaminski I've never ventured into the field of packet capture but really need this working so will grab my Android phone and experiment - I'll provide logs where I can in the hope you can assist...
I also noticed that only the 'initial' packets got lost. If I remember correctly it was also device specific, it could happen that when sending packet to B,A,B,A,B all packets to B worked fine, but A only responds after some more packets. I don't have any logs at hand now, but I do remember that when the official app started there was a really big amount of information exchanged between the devices and the app. But as I said before, I think lot's of features are missing in the initial firmware and therefor I decided to postpone further investigation until the new features are released in the offical app.
I asked teptron when we officially could expect all promised features in the android app. Here is their response:
For Android user we are going to publish an OTA (over the air) app in Oct/Nov. Through the OTA app you will be able to upgrade the firmware in your units. We will publish a step by step guide once the OTA app is released. For iOS users we will publish more information later this year regarding the OTA update.
So I'm hoping in a couple of months we can start looking for implementing new commands and reliable use of the Move device. (I expect new firmware will not be backward compatible with the current implementation in csrmesh - at least not the set-position command). Lets wait and see...
Not managed to upgrade the firmware in any of my units. Fails wth loss of connection at a maximum of 14%. Anyone else had any luck?
Now I wonder how we get access to them like we did before... I'd love to finally integrate them!
Did anyone successfully upgrade the MOVE firmware and test it with the reverse engineered CSRMesh BTLE protocol in this Github? I have 2 MOVE devices with old firmware. but it is not reliable since most of time the device does not move and I have to try the command every time. On other time when I send command to object id 0, only one device respond my command. I suspect that the problem is from the old MOVE firmware and it is no way to get the feedback status from MOVE device
I did connect to upgraded move unit. And issued commands successfuly
So I will sum up my attempts: When I run sudo hcitool lescan - I found a Mac address of my move unit (for ex. CC:BD:E0:11:01:E1)
then I run sudo gatttool -t random -b CC:BD:E0:11:01:E1 -I [LE]> connect and after connection I run: [LE]> char-write-req 0x0021 -n 85a83800809f218a7894dc738189952b4d84ff
please note that 85a83800809f218a7894dc738189952b4d84ff is computed by csrmesh-cli script. This "hash" is valid only short period of time so you must generate newer and newer (with correct position) I generate my hash by: csrmesh-cli move --pin 1985 --dest CC:BD:E0:11:01:E1 --objid 0 --position 0 csrmesh-cli move --pin 1985 --dest CC:BD:E0:11:01:E1 --objid 0 --position 255
but by using csrmesh-cli I cant move my move unit. only with gatttool in interactive mode
also very important is to use correct pin (I forgot how I configured it to 1985 :D )
Aaaaa, I figured it out, you need to use gatttool like this (with -t random parameneter). I think also csrmesh should be fixed to run gatttool with -t random
gatttool -t random -b CC:BD:E0:11:01:E1 --char-write-req -a 0x0021 -n fd79940080ad5065146e25297e7328b7e811ff
Are the units now more reliable, following the updated FW (I assumed they were now using bluetooth standards?). I gave up on my units as many didn't respond before... :(
Yes, I edited gatt.py and it works reliably. No errors.. I will continue testing
A couple of days ago I updated the FW of 1 of my devices. But I didn't investigate further because the offical app behaves even worse than the old one. Ccannot recalibrate open/close positions, when giving move command with the app, the curtain always goes down, only way to get it open again is with the buttons on the device itself. Also after sending a command the device, the device gets 'disconnected' in the app. Because this is totally unstable with the official software I think I'm not yet equiped for investigation 'custom control'. A collegue of mine had more success with the offical app.
Dear @kajaba, which part of gatt.py that you modified? I have checked the gatt.py no contain -t random as follow .... def gatt_write(dest, handle, data): strdata = hexlify(data).decode('ascii') p_handle = "0x" + format(handle, '04x') cmd = "gatttool -b %s --char-write-req -a %s -n %s" % (dest, p_handle, strdata) print("Running: " + cmd) os.system(cmd)
You would want to modify the line beginning with "cmd=" such that it reads: cmd="gatttool -t random -b %s --char-write-req -a %s -n %s" % (dest, p_handle, strdata)
On November 20, 2017 9:04:34 PM CST, Wayan Mustika [email protected] wrote:
Dear @kajaba, which part of gatt.py that you modified? I have checked the gatt.py no contain -t random as follow .... def gatt_write(dest, handle, data): strdata = hexlify(data).decode('ascii') p_handle = "0x" + format(handle, '04x') cmd = "gatttool -b %s --char-write-req -a %s -n %s" % (dest, p_handle, strdata) print("Running: " + cmd) os.system(cmd)
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nkaminski/csrmesh/issues/17#issuecomment-345902453
-- Sent from my Android device with K-9 Mail.
I have tried to modify the gatt.py by adding -t random. However, the device does not respond the command and the data transfer from external USB to device is quite long. I am not sure this happens only to the old firmware or not. I still keep the old firmware for testing purpose. Now I am waiting the arrival of another MOVE devices so I can test it with the new firmware. I will give the feedback with the new MOVE later in next few days.
This is the result of using -t random in gatt.py using the old firmware.
Running: gatttool -t random -b 43:c5:5b:04:00:06 --char-write-req -a 0x0021 -n 3e411d0080188cf9e0a2b6da8520c0c3b06cff connect error: Connection refused (111)
Does anyone try to test -t random using the old firmware?
I have tested some MOVE with the latest firmware using gatttol -t random. However, I am frustrated with the strange result as follows: ./bin/csrmesh-cli move --pin 291316 --dest C1:43:18:00:00:01 --objid 1 --position 0 Running: gatttool -t random -b C1:43:18:00:00:01 --char-write-req -a 0x0021 -n 1e55e30080903f7af66fda562081dc16af98ff Characteristic Write Request failed: Attribute can't be written Does anyone can help why it is not possible to write characteristic value?
In the new mobile app, the pin term has been changed to the network key which is allowed to input 6 digit. @kajaba, how do you know that your pin is 4 digit? Do you configure it in advance before adding the MOVE device? In conclusion, the new firmware have to use gatttool with -t random.
I spent hours and hours getting a move to work with the tutorials of Andrew https://andrew-klimovski.blogspot.nl/2017/03/home-automation-teptron-move-control.html
After resetting it for the 10th time (not just add, but actually hold the STOP button for 10 sec and THEN connect it, I managed to get a good scan including the mesh bluetooth device. However, trying to move the move, I get a positive response, yet nothing moves.
@wmustika The 4 digit PIN you will only get at first install of the app. If you lost it, remove the moves from the app, remove the app, re-install the app, run it and there you will be asked for a new PIN.
How did you guys update your MOVE firmware via iOS? The app doesn’t appear to have any functionality to do so for me.
Nope. This functionality is only on Android App. Borrow some android phone and make an upgrade
You can update it using virtual box and and android iso, worked perfectly for me on my Mac.
I’m interested in this project and how I can control my moves with homebridge.
Has anyone seen an improvement in communication since the update? I really want to get my units installed and give them another shot!
I can confirm that the speed-value defined as 0xFFFF in the movecontroller.py controls the speed. (Running on rpi3b+) First byte is for opening, and the other for closing.
The docs from Teptron says 0x00 will use default speed, but I can not reproduce that on my devices. Defining it as 0x0000 make the devices not move at all.
I can’t help feeling Teptron are not in a good place. Would advise people not to but these and wait for ikea to release HomeKit compatible blinds.
@tomwoodhams I agree they’re not in a good place but the IKEA ones aren’t the same. They’re all-in-one with the shades and I think the shades will only come in specific sizes. I was hoping they’d be like MOVE units.
Hello everybody? I got back to my move units and now I am able to controll them pretty well (sometimes the connection failes - may be the distance is the problem). What I used: python 3 (pluepy was not well compiled - must do make again) in gatt.py chage device = btle.Peripheral(mac, addrType=btle.ADDR_TYPE_PUBLIC) to device = btle.Peripheral(mac, addrType=btle.ADDR_TYPE_RANDOM) and my device works with command: ./csrmesh-cli move --pin 851985 --dest E6:FE:E4:34:82:7C --objid 0 --position 0 [+] Connecting to device: E6:FE:E4:34:82:7C [+] Writing 0xb9b83e0080c82296afda10cc7e7a93dcd41aff to BTLE handle 0x21 [+] BTLE disconnected [+] Communication complete [+] Operation succeeded
I am controlling just one right now - later will try controll more
Hello everybody? I got back to my move units and now I am able to controll them pretty well (sometimes the connection failes - may be the distance is the problem). What I used: python 3 (pluepy was not well compiled - must do make again) in gatt.py chage device = btle.Peripheral(mac, addrType=btle.ADDR_TYPE_PUBLIC) to device = btle.Peripheral(mac, addrType=btle.ADDR_TYPE_RANDOM) and my device works with command: ./csrmesh-cli move --pin 851985 --dest E6:FE:E4:34:82:7C --objid 0 --position 0 [+] Connecting to device: E6:FE:E4:34:82:7C [+] Writing 0xb9b83e0080c82296afda10cc7e7a93dcd41aff to BTLE handle 0x21 [+] BTLE disconnected [+] Communication complete [+] Operation succeeded
I am controlling just one right now - later will try controll more
Awesome, I was thinking about coming back to these too, was wondering how progress was going.
It's this with the original firmware or the latest firmware??
As soon as the latest (I think 2nd firmware update) was released I updated to to the latest firmware
Hallo,
For the latest firmware for the Teptron move units, which version/branch of the crsmesh software do I need? The master or the experimental branch? I read somewhere that the experimental branch was working, but the master branch seems more recent.
Gr. Remco
