-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to Control via MySmartBlinds Bridge? #4
Comments
@creedda The bridge is a dead-end, the code you referenced impersonates the app using your user credentials to push commands to the bridge via the cloud. Even the author of that codebase has said he will not move forward merging that into HA if this approach is feasible. This codebase directly accesses the blinds via BLE, it completely replaces the bridge hardware but requires no cloud connectivity and will work even if the internet goes down or mysmartblinds co goes out of business. |
Ok thanks. He did also make the suggestion that there might be a way to grab the keys off of the api vs trying to scan for them. I know that is what makes his approach more appealing to me, because I have not been able to get my keys using the search script or via an android phone. My thought was that it would just be great to have the option. Setting the library to try and connect locally first and only if the blind cannot be reached or is out of range try the API option. I know that as someone who wants to use this for homebridge and HomeAssistant local options are better but reliability is a close second. Just wanted to bring the option to your attention. I'll close this now. Thanks again for this library it is awesome! |
There is a way to scan for they key... Just brute force the first byte lol... Seriously, that's what the code in https://github.com/dnschneid/pysmartblinds/blob/master/examples/search.py does and it works :) |
So I have been trying that, I even increased the number of keyscan attempts up to 256 and just targeting one specific blind and it is still failing. I have my pi3 right next to the blind (since distance seemed to be a factor) and everything :) Not an expert with gatt or bluetooth packets so I've been going through the search.py and pysmartblinds.py code trying to understand how it works. Not sure if there are other levers I can pull outside of increasing the number of tries. |
Basically it does a hcitool lescan for everything called SmartBlind_DFU, then it hits those addresses going with a byte from 0 to 255 until the blind acks the correct key. If it takes more than a second for hcitool to see your blind, reception may be poor because of devices/wires in between. I would also check you can control via the app via Bluetooth (power off the bridge, app should be able to communicate directly via BT)... That'll make sure the blind isn't out of charge or something |
@creedda could you please file a separate issue, since pysmartblinds's search doesn't seem to be working for you? There is benefit to integrating the two for sure; people with large installs probably would be best served by one or more bridges to hit all their blinds. @ianlevesque, your thoughts? |
Looking through what the api provides this is what I can see so far: [Blind(name='Living Room',encoded_mac='gxxxxx7+',room_id='6xxxxxxx-0xxx-4xxx-axxx-2xxxxxxxxxx'), Blind(name='Big Window',encoded_mac='gxxxxx7+',room_id='6xxxxxxx-0xxx-4xxx-axxx-2xxxxxxxxxx'), Blind(name='Balcony Door',encoded_mac='rxxxxxxr',room_id='6xxxxxxx-0xxx-4xxx-axxx-2xxxxxxxxxx)] (Note: The position, rssi, and battery level are not 0 or -1 when the bridge is on and connected to the blinds) At the very least its a way to get the battery level which I don't think is offered as part of your library today, but again I think it should be in addition to, but not in place of the ble connection. Maybe for each blind in the config, the library attempts to connect and send the command via ble if the the blinds are out of range or cannot connect due to interference, the library could send the same command via the api to see if the bridge could reach it. Creates a sort of backup if the ble connection is not good. Your library also does stepping which the other library does not. (super useful) I just think a lot could be combined and learned from here. Thanks for putting this together. Been trying to get my hands on an android phone for a while now to do the sniffing and here you are providing me a way to do it with my pi :) Thanks! |
I think the cloud integration is useful mainly for grabbing the existing names, keys, and groups from the mobile app setup (though brute forcing the key is hilarious, I love IoT “security”). It seemed fairly robust, a vanilla (if proprietary) auth0 integration and then a pretty future proof GraphQL API for the config and control. From my personal usage the control was also very reliable - the primary reason I am unhappy with it is that cloud polling the current blind state is both slow (on the order of 15-25 seconds for a single poll) and not very reliable (blinds will report -1 presumably for bad reception decently often). I also am concerned that if polling was frequent they’d ban it, the usage pattern would be super different than their app or their Alexa integration, which only fall back to cloud as a last resort. I am completely fine with combining the code or approaches, ideally for my setup I’d use a hybrid of this project and mine. If it helps my stab at hass integration is on a gist https://gist.github.com/ianlevesque/f97e3a9bfafc72cffcb4cec5059444cc but I am not planning to try to merge that due to the polling limitations. |
The battery level is somewhere in those BLE packets; I just haven't looked very hard for it since I use the solar panel to keep them charged.
Yeah, and then default to the API approach to avoid lagginess. This seems reasonable.
Agreed, although unless I'm reading it wrong, I don't think your current code is requesting the key in its current form. Have you looked into decoding the MAC and key from the API output?
Yeah, I think I'd stick with the current method this library uses -- write-only and track the state locally (with the caveats as described in the README). I took this approach because it didn't seem like the phone app was able to read the current state either; I'm surprised the bridge does it -- unless it, too, is keeping local state.
Thanks! This one's here. |
I don't have the panel so this is useful. I suspect comparing the exact bridge values from the API to the BLE packets would make finding it easier.
Yes this is trivial. GraphQL just has you whitelist the fields you want so I left it out. The full response to the GetUserInfo query if you include all fields is:
I left the MAC & passkey in the clear so you can see if they make sense to you. If someone moves my blinds while they're in the neighborhood I'll wave.
That's a shame, I was hoping local BLE would be pollable (and more frequently). |
For completeness here's a query of blindsState (which is what exposes a valid battery reading):
|
Thanks! I'm guessing the encoded fields are just base64. I'll confirm against my own account. |
Well, maybe the position info is in the same place the battery info is. I'll start a new issue for figuring that stuff out. |
Yup, it's simply base-64 encoded. Filed ianlevesque/smartblinds-client#3 |
I've dumped a bunch of completely untested code into the sbc branch. |
Code doesn't load on >= 0.77 without my hatch patch in #7... after removing SERVICE_TO_METHOD, it dies with the following (tested on 0.85.1):
|
I replaced mac_address with encoded_mac and passkey with room_id since those don't seem to exist in the sbc definition of blind ... but then it failed with this, looks like it's trying to do bluetooth even though I've only provided the username / password to login.
|
I bumped smarblinds-client to v0.3 and retrying replacing passkey with encoded_passkey this time... made no difference still chokes loading with the same error. |
Looks like it's possible?
https://github.com/ianlevesque/smartblinds-client
Might want to see if you can get them to fork in some of their code. Always good to have options? Or maybe try one and fall back to the other?
The text was updated successfully, but these errors were encountered: