Support for AC60

[bxm6306]

I have both a pre-production AC60 and a B80 expansion battery for it and would love to kick-start support for it. I've run bluetti-discovery --log on it and zipped up the log file and attached it. I've attached it - no personal data in it.
ac60-discovery.zip. Did I do it right?

[warhammerkid]

Yep, you did it right. The next steps for AC60 support are to use the bluetti-logger data to reverse engineer specific fields.

For most of our needs there are four different kinds of fields and the process for reverse engineering varies for each type:

• Numeric fields
• Boolean fields (on/off or yes/no)
• Enum fields (options or modes)
• String fields (like a device type or password)

For numeric fields like the battery percent or solar input, the process is to run the logger and write down the values you see on the screen, and the time when you saw those values. For rapidly changing values a range can be noted down. For slowly changing values it may be necessary to collect multiple logs at various values to make it easier to figure out where the field is. You can write down multiple field values at a given time so that you don't need to run the logger for as long.

For boolean and enum fields, the process is to run the logger and to change the field on the screen, noting down the value and the time when you changed it. You should wait at least a minute between changes, and for boolean fields it can help with identification to change the value several times.

I'm pretty sure I identified all the string fields but if there's a specific field you're looking for please let me know and I can help look for it.

---

A faster option is to use a bluetooth packet logger (like an ESP32 flashed with nRF connect app or the Android / iOS developer tools) instead of bluetti-logger, and to use a mobile device to connect directly to the AC60 over Bluetooth. I am not a lawyer so before you do this you should check that this is legal in the country you reside in. With this method you don't need to wait a whole minute after changing a settable field - simply note down the time when the value was changed and wait a few seconds before changing it again. This method usually helps speed up the search for sensor values as well, since the app only loads the data it needs for the specific screen you are on, narrowing down the range where that value could be located.

[bxm6306]

Thanks for the pointers! This is my first-ever github contribution and I wanted to give back to this project. I used a modified version of bluetti-logger with 10 sec intervals between polls, Beyond Compare and Notepad++ to discover around 37 new fields. The fields from other devices helped quite a bit and my approach eventually just became to brute-add a whole bunch of uint fields, then bool fields and check out any returned values and match them with values on the display and app.

Getting more battery pack fields extracted proved too challenging for me at the moment but the most useful AC60 fields are present in my PR.

[bxm6306]

@warhammerkid is anything else required to consider my PR?

[warhammerkid]

Sorry, been busy and wanted to look it over before I merged it. I had some feedback for you on your changes that I'd like you to address before I merge your changes (also feel free to reply there if you have any Git / Github questions - I'm happy to help).

Thank you so much for your work on this - this is a huge help!

[bxm6306]

@warhammerkid All good. I have a development question. How should I be setting up my dev code environment to run my branched Bluetti-MQTT code? If I just run python .\mqtt_client.py I get:
Traceback (most recent call last):
File "C:\Users\Windows\OneDrive\Documents\My Repos\bluetti_mqtt\mqtt_client.py", line 10, in
from bluetti_mqtt.bus import CommandMessage, EventBus, ParserMessage
ModuleNotFoundError: No module named 'bluetti_mqtt'

[bxm6306]

@warhammerkid I figured out the development environment (duct tape was used) and have corrected the style notices, renamed battery to pack fields based on your comments and added the writable address range. Awaiting your approval for the build test: https://github.com/warhammerkid/bluetti_mqtt/actions/runs/5231226011

[bxm6306]

I realized just now that most of the new fields aren't showing up as MQTT topics when running the bluetti-mqtt broker and see that I also need to define new data structures there.

[jasonralston1]

@warhammerkid @bxm6306 Did this work ever get pushed into production code? I am still only seeing limited fields for the AC60 at the moment and it would be great to get more support. I have an AC60 and am available to test any code.

[bxm6306]

@jasonralston1 It did not, I only got around to doing the non-MQTT legwork.

[jasonralston1]

@jasonralston1 It did not, I only got around to doing the non-MQTT legwork.

I think you are close. I incorporated your changes manually into the project at https://github.com/SSMCD/bluetti2mqtt (by just updating the AC60.py file) and so far its been working great. Via MQTT I am able to turn on/off the AC and DC inputs, monitor the power draw/output from the AC+DC ports, see the solar input and make changes that allow me to turn the battery SOS light on and off (gave my partner a fright when it went off haha), change the powerlifting mode and select the charging mode. The "Battery Pack" is the only thing erroring for me right now.

[jasonralston1]

@jasonralston1 It did not, I only got around to doing the non-MQTT legwork.

This is an example of what ive set up my dashboards to do from your python script changes

[bxm6306]

I found the main problem with the fields not getting sent out the MQTT pipe, I had forgotten to add the addresses to the polling_commands list in ac60.py - they were only listed for the logging_commands. Doh!

After fixing that I also re-adjusted several other field names and added new fields to mqtt_client.py. Changes have been tested successfully on my AC60, committed to my branch and are now awaiting workflow approval under PR #79 @warhammerkid