kendallgoto / switchbota

Replaces the factory firmware on the SwitchBot Plug Mini via OTA, enabling the use of Tasmota without disassembling the unit.
GNU General Public License v3.0
105 stars 17 forks source link

Can't figure out how to build (goal of using as ESPHome BT proxy) #45

Closed ScottG489 closed 2 months ago

ScottG489 commented 11 months ago

More context below, but I'm trying to build the ESP-IDF binary, but there aren't any directions on how to do so.

I see that there's a makefile in the espressif dir, but there's not much in there and I'm not really sure how to get started doing this build.


So more context: I'm looking to use these plugs as dual purpose ESPHome BT Proxies.

I looked over a bunch of docs and was getting ready to start the OTA process when I came across this comment by one of the devs very familiar with the BT proxy feature: https://community.home-assistant.io/t/support-for-switchbot-plug-mini-w1901400-with-bluetooth-proxying/441893/26

It sounds like I would need to update the part.csv to match the partition table ESPHome uses as he also mentions here: https://community.home-assistant.io/t/support-for-switchbot-plug-mini-w1901400-with-bluetooth-proxying/441893/28

So I'm looking to update part.csv with the partition table he linked to, build the image, and then use that instead of the default one.

A side question is, if I did use this other partition scheme, would I break something earlier in the process before I eventually flash ESPHome?

Otherwise, thanks for this great project!

ScottG489 commented 11 months ago

After a little digging, it looks like this dir is used by a github action and I suspect the answer is in this command somewhere: https://github.com/espressif/esp-idf-ci-action/blob/v1/action.yml#L29

However, I'm still having issues running this. It looks like a build hasn't ran in a while either so I don't have any actions logs to go off of to help.


Ok got it working! This is the command I used (ran from the espressif dir):

docker run -t -e IDF_TARGET="esp32c3" -v "$PWD:/app/foo" \
  -w "/app/foo" espressif/idf:v4.4 \
  /bin/bash -c 'git config --global --add safe.directory "*" && idf.py build'

Which resulted in the file espressif/build/switchbota.bin which I believe I'd want to use in place of the default server/bin/app.bin?

So I think my only concern at this point is if you think it's fine to use this partition table in place of the default? Or will something break before I get the chance to flash ESPHome?

kendallgoto commented 10 months ago

hi @ScottG489 -- I'm not actively able to work on this project + am not totally familiar with the current state of things. However, do you have updates on what you tried here?

At a glance: I think you're confused on the point of the ESP-IDF binary in this project. The partition table is not designed to match tasmota's or ESPHome's for the app, it's designed to match the existing Switchbot one. That's because the ESP-IDF application serves as an update to the existing Switchbot program, then flashes an arbitrary partition table onto the hardware. That said, I would expect you wouldn't have to touch the ESP-IDF binary at all - it's just a generic write script (you can read https://github.com/kendallgoto/switchbota/blob/main/espressif/main/ota.c#L147C6-L201 - it literally is just downloading a new file and installing it). So, I would expect you can just switch the Tasmota full binary (partition table, bootloader, and app) with the ESPHome full binary (also partition table, bootloader, and app) and you'd be off to the races.

There's minimal documentation for how to build the espressif binary because there should be very little reason to ever modify it.

ScottG489 commented 10 months ago

Hey @kendallgoto. Thanks for taking the time to respond. It's been a few weeks and I'm a little hazy on where I was at with this, but it does sound like I was at least slightly mistaken from your explanation.

That's good to know that I could flash Tasmota or ESPHome directly using this. However, I think the problem would still remain that the partition table would be lacking for ESPHome to fully act as an ESPHome BT proxy. Not sure if you have any comment on this as to how that could be worked around?

Otherwise, I am following some work on a PR in ESPHome that would allow updating the partition table after ESPHome has been flashed OTA (currently this requires a serial connection which requires kinda massacring the plug).

kendallgoto commented 10 months ago

The partition table in the target application will be matched. The work in this repo is very similar to the PR you linked, in which the user-space code is able to update the bootloader / partition table. This application is executed on the Switchbot default partition table, but will write the partition table / bootloader of whatever application you tell it to (this is defined as the "payload" in https://github.com/kendallgoto/switchbota/blob/main/server/index.js#L83C1-L84C1 - it targets Tasmota by default).

Using Switchbota in this way is no different then flashing whatever binary you would install if you had direct access to the programming header on the plug. It flashes the entire image of the desired target application, including the full partition table.

ScottG489 commented 10 months ago

Interesting, I think I see. So it should be safe to just replace the server/bin/payload.bin file with a ESPHome binary?

Sorry, I had read about flashing Tasmota and then ESPHome from there, so I think that gave me the wrong impression of how things were working. Also from other inquiries, no one ever suggested just flashing ESPHome directly so I thought it wasn't possible. I also have very little experience with firmware flashing. Thanks again for your help.

kendallgoto commented 10 months ago

I wouldn't necessarily say it's "safe" since it hasn't been done (by me anyway) and isn't technically supported here. But yes, there's nothing tasmota specific about this project, and I would suspect you could switch the payload binary (and the matching MD5 hash provided by the web server!) and it would install the same as if you were connected directly over serial to the device.

Since it's untested, I would encourage you to be open to the possibility that you may have to crack open a unit if it fails.

ScottG489 commented 10 months ago

Ok thanks! Yeah I'm willing to take the risk that I'd have to crack it open (literally).

Out of curiosity, what would you say would be the biggest risk for something to go wrong when using an ESPHome bin instead of a Tasmota one?

kendallgoto commented 10 months ago

I don't know much about ESPHome to comment on that. I believe the device configuration is hard-coded into the compiled binary, so I would assume the biggest risk is if you misconfigure the binary before flashing, then you may end up with an output that is impossible to recover without opening it up. Mostly speculating though - Since Tasmota uses a fixed, multi-purpose binary that isn't device-specific, I have much higher confidence in its ability to install and run compared to something that is dynamically built. And even for that, I still used a plug with a programming fixture connected for testing + iteration (though, I've since programmed 50+ plugs without worrying about it).

I can test this sometime next week if I can find my debug plug - but again, since ESPHome is built dynamically, there's not much guarantee that the build I test & run will work well for anyone else.