How to obtain client_id in laymans terms #3
Comments
|
@flinthamm did you ever get anywhere with this? I've done exactly the same as you - new to the BLE stuff, had limited output from wireshark that relates to the 0x11 stated in the readme 😂 |
|
Very frustratingly no, although mainly due to time as I rarely give up...unfortunately, this is one of those times, as I could not get any feedback or assistance. I'm resigned to waiting for our next shower upgrade that will be WiFi enabled, although no doubt that will be a long time. |
|
Adding my two pence worth I found a fork of this at https://github.com/dave01945/python-miramode. This includes the brute force loop that is mentioned in this repository, I'm just trying to get my head around it now! |
I hope you can, and can share back. I have two of these showers, I initially tried to get it working. However other priorities took over. I will come back to it at some point. |
|
I also have the mode bath - I'm used to code on a higher level than this so it's also pretty foreign to me. Perhaps GPT can help ;) |
|
Hi all, apologies, I missed the initial comment here! As my Mira shower and bath work well in Home assistant / Alexa with the current implementation since almost 4 years, I didn’t progress past this initial proof of concept to sort out the pairing process and add more features. |
|
Hey @alexpilotti thanks for the response. I think the majority of the people in this issue are just after some idiot proof steps to find the device ID/CRC - once I have something working, I'm pretty good at debugging |
|
Completely agree with @spamoom if you do have 5mins spare to put together a very quick how-to guide as detailed above it would be very much appreciated @alexpilotti! Thanks again for all your hard work with this! |
|
I finally managed to get it working with the help of dave01945
Split the value into hex pairs so they look the same as below: data = bytearray([ Now save the file and run the script. It should then generate a Client ID for you.
|
|
@kingal123 Thanks for the details explanation of the steps once you have the right capture. Can you share any more information about how you managed to get a capture containing the 0x0011 handle in the first place? I've captured the entirely process of starting and stopping each of the two outlets via my phone, and have lots of traffic on the Handle 0x0010 and Handle 0x0012 handles, but no packets with the 0x0011 handle. Did you make your Wireshark capture during normal usage, or do I need to record the packets exchanged during the pairing process? |
|
@robotfelix the WireShark capture needs to be performed while turning on / off the outlets, I’m surprised by the lack of 0x11 packets. The pairing process is a different story, would be good to have that sorted out eventually to avoid the need of WireShark in the first place :) |
|
Hello again all and I can almost say... "Happy New Year". I'll try and keep this short and appreciate this is not a technical support forum, especially for BLE sniffing but I'm hoping someone can quickly point out the obvious error I'm making, which is simply that I can't seem to receive any ATT protocol data, as was pictured in the WireSharkCapture.pdf posted by @kingal123. I'm using the Adafruit nRF51822 USB dongle on a Win10 Laptop with the latest WireShark v4.2 and Npcap v1.78, CP210x Universal Windows Driver v11.3.0, Python 3.12.1, pyserial 3.5. The nrf_sniffer_for_bluetooth_le_4.1.1.zip found on the Nordic Semiconductor has then been used to copy the relevant files into the global WirelShark plug-ins directory and from the same archive, the configuration profile files have been copied into the personal configuration folder. With the above setup completed, the system rebooted and the dongle plugged in, everything appears to be functioning correctly. A blue LED "CONN" flashes initially, the WireShark interfaces page loads. The "nRF Sniffer for Bluetooth LE Com5" interface is selected and on doing so, lots of "LE LL" protocol data starts flooding in, while a new amber LED (one of two mounted directly above one and other but not labelled, presumably TX/RX) starts flashing in addition to flashing blue "CONN" LED. When the Mira Mode bath filler is then selected from the device dropdown in WireShark (provided by the plugin config toolbar) a new red "MODE" LED flashes with the amber instead of the Blue LED. If I then select the Mira app on my phone that has been previously paired to the Mira Bath filler, immediately a connection is made in the app the LED's seem to stop flashing (or flash VERY occasionally), unless the Mira Mode device is unselected in favour of the "All advertising devices" or the app is disconnected. I've tried interacting with the Mira within the app, turning the bath filler valve on / off which all work but the data is never seen in WireShark. As this is the first time I've ever conducted BLE sniffing and as far as I'm aware, all instructions have been followed to the "T", I'm not sure where to look next? Google found a few people with similar issues in various Forums but the messages threads never concluded with any useful information. Hopefully others have had more luck than me but I thought it was worth posting here as hopefully something is obviously wrong, at least to the right trained set of eyes :) |
|
Perhaps I'm just being unlucky and need to persevere. See Adafruit Introduction FAQ |
Not that it helps, but I have had the same exact experience you describe above - not being able to record anything other than advertising packets with the Adafruit. I have now moved to inspecting the packets using the HCI Snoop Log on my android device.
I have not managed to find an 0x11 packet yet, though. |
|
Thanks @spafrost for confirming this, interesting :) Funny enough, I remember going down the exact road you describe too (well over a year ago, so can't remember the exact details) and I probably gave up too easy. Unfortunately, with the documented Adafruit process having not provided any useful data and having not seen any useful threads of people having or certainly resolving similar issues, it was time constraints that finally caused me to give up. I consigned myself to hoping more information would come to light in time, as and when further investigation could be done + hoping this thread might be one solution. |
|
Jumping on this thread as I see this issue is still active today. I'm looking to redo my bathroom and need some advice from owners. I'm looking at either the Mira Mode or the Activate, truth be told I prefer the activate which I think is now WiFi? Would this make things easier to get into home assistant? One thing that I can't work out for the mode that really puts me off is the temperature control. It looks like a mechanical dial with numbers but you can set a temperature in the app. If you set a temperature in the app, how does that reflect on the dial? Like when you change the dial does it ignore the set temp and jump to the dial temp (Thinking if app set and dial are far apart) or does it just offset the dial temp? Like the look of the digital display as I assume that follows the temp set in the app |
As it happens the Mira Mode I have been trying to integrate belongs to a friend, and I have the Mira Activate myself. As far as I know there has been no work into integrating it with via the WiFi connection - although it works as expected through Alexa/Google (something I strongly avoid). As it happens - I have also tried the same BLE methods against the Activate, as its app seems to prefer using BLE where it can for direct control - but it too does not behave as expected above - although it may work entirely differently to the Mode. |
|
I still haven't had any luck in getting this to work. I noticed there are some UUIDs in the python-miramode/miramode/__init__.py Lines 7 to 12 in eca2685 Sorry if it's a silly question, but do these need to be edited too for this module to work? I'm reasonably confident that the UUID of my Mira Mode is different, but the README only mentions finding the |
|
Hi @spamoom, @flinthamm @cook1emr @robotfelix @spafrost I have managed to get this working and created a step by step guide - hope this helps! TLDR: If you cannot see the ATT packets, add the nRF Sniffer for Bluetooth LE interface Toolbar and select your device! Mira Mode - How to obtain the device address and device and client ids.pdf @alexpilotti I am more than happy if you want to add these instructions to the readme to help future people benefit from your awesome module. @robotfelix no, you do not need to edit the variables in init.py, you only need to set the address, device_id and client_id. These are not in any of the files within the repo but are within the example that you use to call the miramode python module (this repo)
|
|
Well done this guide looks great Why dont you do a PR to add to the readme? That would be great |
That was my hope but I currently don’t currently have time to write it in markdown, save all the photos etc. I did it like this for a quick fix to help people. |
It is gratefully received |
|
@Ed62641 great work! If you’d like to send a PR for the readme it would be great. If not, if you would like to submit the PDF as is, for now even just a PR with the PDF placed in a “docs” directory within the repository would be great. Thanks!! |
I noticed this part of the comment only now sorry. I have two Mira mode devices, the UUID is consistent for both, this doesn’t mean that it might not be different on other devices, but I didn’t see any other user reporting issues on this. Hope it helps! |
|
Thanks for everyone's great work! I've actually been talking to Mira about this issue. I reviewed their app on the Play store (Not a great review :-/) and they reached out to see what my concerns were. I basically told them about how their app has delays through the pages and running bath preset #2 feels like a chore as I have to spend longer than I should in the app. They told me that they are considering opening up the API but they had concerns about safety etc. I threw them a curve ball and said that it could be made safer in Home Assistant etc as it would allow conditions to be met before a device turns on ie. Door sensor on shower doors making sure they're closed. In its current state, this can't be done I ended up having a Teams call with them last Friday where they wanted to know more about how people are using Home Assistant and what can be done, I think it really opened their eyes but they mentioned they've spent a lot of money developing their app and I think they're getting pressure from above about how it's working I did mention this method of control and they said that this should only work on the earlier models, the early models apparently could only connect to one device whereas the polling process is different on the new models and this approach may not work - This may be why we've been having issues. They said that the new models came out about 2 years ago, mine is 6 months old and it falls into this category, I tried for hours to get codes and got literally every code except the one I needed They said they would send me out 2 buttons to play with, my plan is to break into them and use an ESP relay type setup to trigger the button but we'll see how that pans out If you get a chance to review the app in the Play / App store, I would encourage you to mention opening the API and making it compatible with HA as they are listening I'll try this method of getting the code again as status would be a great thing to see Thanks everyone :) |
|
I really wanted to buy their product, but I ended up getting something else
due to these concerns about no API
And it isn't even for sale in my country, hence I would have had to import
it somehow... They are really missing an opportunity.
Maybe you could send them the link to this thread?
…On Mon, Sep 16, 2024, 11:49 Jinsin456 ***@***.***> wrote:
Thanks for everyone's great work!
I've actually been talking to Mira about this issue. I reviewed their app
on the Play store (Not a great review :-/) and they reached out to see what
my concerns were. I basically told them about how their app has delays
through the pages and running bath preset #2
<#2> feels like a
chore as I have to spend longer than I should in the app.
They told me that they are considering opening up the API but they had
concerns about safety etc. I threw them a curve ball and said that it could
be made safer in Home Assistant etc as it would allow conditions to be met
before a device turns on ie. Door sensor on shower doors making sure
they're closed. In its current state, this can't be done
I ended up having a Teams call with them last Friday where they wanted to
know more about how people are using Home Assistant and what can be done, I
think it really opened their eyes but they mentioned they've spent a lot of
money developing their app and I think they're getting pressure from above
about how it's working
I did mention this method of control and they said that this should only
work on the earlier models, the early models apparently could only connect
to one device whereas the polling process is different on the new models
and this approach may not work - This may be why we've been having issues.
They said that the new models came out about 2 years ago, mine is 6 months
old and it falls into this category, I tried for hours to get codes and got
literally every code except the one I needed
They said they would send me out 2 buttons to play with, my plan is to
break into them and use an ESP relay type setup to trigger the button but
we'll see how that pans out
If you get a chance to review the app in the Play / App store, I would
encourage you to mention opening the API and making it compatible with HA
as they are listening
I'll try this method of getting the code again as status would be a great
thing to see
Thanks everyone :)
—
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACOZ76YZJ6RSMST2WP7S4LZWZ5ORAVCNFSM5HX3KD4KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZVGIYTEOJUGE3A>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Have you tried the instructions I uploaded yesterday? It would be great to get some feedback? The bit where it suddenly started working for me was when I added the nRF Sniffer for Bluetooth LE interface Toolbar and selected my Mira device. After that the ATT packets were flooding in. It was then just a case of finding one with a value length of 20. |
I'll give them a try again but I think I set up everything ok because I was getting a lot of btatt packets but whatever one the initial tutorial said I needed , I couldn't find. I can't remember off the top of my head but if it needed 0x11 I was getting 0x10, 0x12, 0x13 but spent hours and never managed to get the right one I had more luck with another sniffer than the blue fruit but I sent that one back I'll probably have another go at the weekend, maybe start again and follow your guide as I think you got an 0x12 packet |
I tried to reach out to them about opening up the BLE API but it didn’t lead anywhere. I’m glad that now they are listening. I’d be happy to talk to them if you’d like to send an intro email. As far as security goes, if their plan was to implement a “security by obscurity” approach in making up a kind of CRC algorithm, that didn’t go far, as this repository proves (figuring that out was the hardest part of the work but not a blocker). Opening up the BLE API will not change anything security wise, while not opening it up will surely lead them to miss business opportunities (starting with the Home Assistant community). |
I ordered two of their devices (shower and bathtub) from the EU around 5 years ago (before brexit), so no import taxes at the time. FWIW they work seamlessly since then and I’m happily operating them via Home Assistant / Alexa since I wrote this code shortly afterwards. I would never use the phone app to do anything beside the initial setup. It really doesn’t compare with uttering “Alexa turn on the shower” when you wake up without having to look for your phone, the user experience is just not comparable. |
Yeah that makes a lot of sense. I'm about the limit of what I know how to do. If you're happy to share your email address I can pass it on to the people I spoke to |
|
Hey all. This probably isn't the best place, but.... I have a 2 button mira mode device, and have been doing some work on a 'better' iOS app due to my frustrations with the slowness of the official app (it's just for my own use at the moment). The CRC algorithm used is a standard CRC known under a few names: CRC-16/CCITT-FALSE, CRC-16/IBM-3740, CRC-16/AUTOSAR The clientId itself is generated in the client application, and passed to the device as part of the 'pairing' process with a device-specific single byte chosen by the device and sent back to the client (I call it the clientSlot). When subsequent requests are sent to the deivce, they include the clientSlot in the reuqest and are CRCd with the clietnId - this allows the device to verify that the request has come from a paired client. The pairing process itself uses a different identifier for creating CRC for the pairing request - I'm not publishing this at present as I don't know if it's hardcoded in the client application or discovered from Mira owned servers. Either way, this paring id can be easily brute forced from a sniffed pairing request in the same way that people have desribed brute forcing the clientId above. It really doesn't add much security. The rest of what I've discovered so far is in the README here: https://github.com/nhannam/shower-controller-documentation It's not 100% complete, but getting there. I hope it helps other people make better use of these devices. ...now I just need to find smart bath plug... |
|
Hi @nhannam, thanks so much for the work you are doing! I am definitely going to look into it and ideally finally implement the missing parts (clientId generation and reading the valve status in particular). The fact that the iOS app is not available in my local AppStore is very annoying as I have to switch to the UK one just for their app, so I’m really happy to hear that you are working on a new app. Please let me know if you find a smart bath plug, I’ve been thinking about that for a while! :) |
|
I also would love to see the stuff that @nhannam has implemented within this project. I think they could be the last pieces to finally turn this into a full custom component for home assistant. @alexpilotti I also have never found a automated plug. However I did come across this and intend to build it at some stage. https://youtu.be/PsWwSk9bz0I?si=0ZiOwNKmTofzHMik |
|
Would you guys be interested in moving this conversation to something like a Slack channel? Given the excellent protocol documentation effort made by @nhannam it would be good to have a place to brainstorm more efficiently and provide feedback. We can then update this GH issue when we have more results. On my end I will start testing the newly documented BLE commands and adding features to the Python client accordingly. I’ll need to look into the “pairing-specific id” to begin with. |
|
Happy to join a slack channel if someone wants to set one up. It'd be good to understand whether the pairing-specific id you find for your device is the same one I found for mine. I was wondering whether it could be something that the client picked up from info broadcast when the device is put into pairing mode, but I couldn't see anything that matched, so I'm assuming it's either hardcoded, or possibly derived/looked up outside of the bluetooth comms. I ran into something else interesting today that I hadn't noticed before. Pretty much all the commands that result in a 'SuccessOrFail' type response will fail if either outlet is running AND for 5 seconds after they've been stopped. This is probably why there's a few slow responses in the offial app. I never noticed before, but the buttons on the controller also have this kind of 5 second lockout, so looks to be a device limitation. I think the offical app may be being super-cautious about this 5 second delay - it's only really necessary if the outlets need to be stopped before doing something. The main things I can see in the official app that I haven't replicated yet are less frequently used things like:
|
|
It'd also be good to understand how the app works out how many / what type of outlets it has (they do various combinations of bath / shower / overhead shower). I'm guessing it's derived from the model number you can read. |
|
@nhannam I found a hardcoded client id replacement 54D2EE63 for command type 0xeb with either 24 or 1 payload lengths, can you please confirm if this is the one you are seeing as well? Interestingly, it seems to be used for a bunch of other commands as well (command type, payload length):
Except for 0x6b, 0xeb and 0x07, I didn't check what the others are for, although 0xf4 is apparently labelled as "Extended Reset Valve". |
|
That id doesn't match the one I'm using for pairing. If the same id is being used for all those commands, it may be that it's just a new clientId that was generated when pairing a new client app. I don't seem to have commands for 0xf4, 0x32 or 0x41 but the rest look familiar. the 0xeb with 24 byte payload length should be the pairing request although it wouldn't surprise me if it could also be used to change the client app name in the device too. |
Interesting, that id is hardcoded in the app, not generated. I will run some tests asap! |
On it! |
I created a Slack workspace: https://join.slack.com/t/homeassistant-w3w6687/shared_invite/zt-2uk8sisn4-P_utz_TnYHj5GnSCqKiyOg There’s a channel named “BLE-protocol”, see you there! |
|
Hi all, the long awaited pairing command is finally here! The project now includes a CLI (Linux only for now, looking at making it cross platform). Please look at the README for details, the basic pairing command is as follows:
|
Let me second the comment about @alexpilotti and outstanding work ;)
I stumbled upon your code when trying to create some automations for our newly installed Mira modes. Unfortunately with almost zero experience using BLE or Bluetooth in general, after a few hours research and trial and error, it seems I'm barely any further forward.
I've managed to find what seems to be some great tools, like the nRFConnect and Logger mobile apps and these have sniffed some useful information but I can't find any 0x11 characteristic info or know how I would go about decoding the client_id from the CRC data, if indeed I was able to obtain it?
The Adafruit BLE Sniffer v2 has also been problematic with Wireshark as it seems to lock up just when it appears your starting to get at the data needed.
Literally ANY pointers on how to get this information and decode it would be very gratefully received and no doubt use to others in the community? Thanks in advance for any help.
The text was updated successfully, but these errors were encountered: