On AC200M commands AC and DC work, but states are not shown

[SvHeGithub]

Hi,
i used todays latest main and tried to get it running together with an iobroker as mqtt server.
The following works:

• Connection to iobroker as mqtt server
• Controlling AC and DC using the commands

What I do not see (and others seem to) are all the states like current power and i.e. total battery percent.
I added some debug code in parse_bluetooth_data() the only page 0x00 offset 0x0A length 7, page 0x00 offset 0x46 length 14 and page 0x0B offset 0xB9 length 14. All with some follow data, which not looked to deep into.
The listest data matches the values in bluetti_polling_command for the AC200M.

Thus is I wonder if I am doing something wrong or missing something, if the bluetti_polling_command needs to extended or if there is any other issue. As other person mention that AC200M is working at them I wonder what is the difference to my project (BLUETTI_TYPE AC200M i have defined in the config header).

Any help is welcome!

Regards,
SvHeGithub

[AlexBurghardt]

I will do a PR with extended dataset for AC200M ASAP. I guess this will help you.

[SvHeGithub]

Hi @AlexBurghardt
Sounds great. I will Test the PR as soon as i see it here (and i find the time).
Regards
SvHe

[mariolukas]

Merged with #51

[SvHeGithub]

Hi @AlexBurghardt,

i tested the new main, but still i have problem with my AC200M and i even have new once.

I still do not see any new states, just the once i had before.

I am now regularly running to
Error while publishTopic! 'device_type' can't be empty, reboot device)
Thus is reboots.
To avoid the reboot for now did the following:
//sometimes we get empty values / wrong vales - all the time device_type is empty
if (map_field_name(field_name) == "device_type" && value.length() < 3){

Serial.println(F("Error while publishTopic! 'device_type' can't be empty, (not) reboot device)"));
return;                <----
//ESP.restart();    <----

}

From parse_bluetooth_data the only time it trys to publish something is for the device_type.
No other valid bluetti_device_state is found in the if check.

I wounder what is the different from mine to your setup.
Any idea?
Using the mobile app (not in parallel), bluetooth is working fine.

Regards,
SvHe

[AlexBurghardt]

Is your configuration in config.h correct? Is really Device_AC200M.h being included?

[SvHeGithub]

Hi @AlexBurghardt
Yes i do (tested it with some compile errors in the file).
Any other idea? Can you post some of your serial Monitor Bluetooth data so i can compare it.
Regards
SvHe

[AlexBurghardt]

I can, but it will take some time. By tomorrow latest... tomorrow I could pull your code and test it here...

[AlexBurghardt]

Ok, this is an excerpt from my serial log:

21:36:58.209 -> We are now connected to the Bluetti BLE Server.
21:36:58.209 -> Write Request FF02 - Value: 0103 000a 007f 2428
21:36:58.209 -> Update Web events
21:36:58.209 ->
21:36:58.405 -> F01 - Write Response
21:36:58.405 -> 0103 fe41 4332 3030 4d00 0000 0000 0003
21:36:58.405 -> f9ab fc23 4602 0700 0000 0000 001d a300
21:36:58.405 -> 061c 7b00 068d 4700 0100 0000 0000 0000
21:36:58.405 -> 0000 0000 0000 0000 0000 0000 0000 0000
21:36:58.405 -> 0000 0000 0000 1500 0000 0000 0000 0000
21:36:58.405 -> 0000 0000 0000 0000 0000 0000 0000 0000
21:36:58.405 -> 0000 0000 0000 00c0 0000 0000 0000 0000
21:36:58.405 -> 0000 0000 0000 0000 0000 0000 0000 0000
21:36:58.405 -> 0000 0000 0000 0000 0000 0000 0000 0000
21:36:58.437 -> 0000 0000 0000 0000 0000 0000 0000 0000
21:36:58.437 -> 0000 0000 0000 0314 3800 0000 1500 2800
21:36:58.437 -> 0100 0114 3800 1500 0000 6401 2c16 bc02
21:36:58.437 -> 5801 4201 4201 4201 4201 4201 4201 4201
21:36:58.437 -> 4201 4201 4201 4201 4201 4201 4201 4201
21:36:58.437 -> 4200 4000 4000 3f00 0000 0000 0000 0000
21:36:58.437 -> 0000 0000 0000 0000 0000 0000
21:36:58.437 -> publish topic for field: device_type
21:36:58.437 -> publish topic for field: serial_number
21:36:58.469 -> publish topic for field: arm_version
21:36:58.469 -> publish topic for field: dsp_version
21:36:58.469 -> publish topic for field: dc_input_power
21:36:58.469 -> publish topic for field: ac_input_power
21:36:58.469 -> publish topic for field: ac_output_power
21:36:58.469 -> publish topic for field: dc_output_power
21:36:58.469 -> publish topic for field: power_generation
21:36:58.469 -> publish topic for field: total_battery_percent
21:36:58.469 -> publish topic for field: ac_output_on
21:36:58.501 -> publish topic for field: dc_output_on
21:36:58.501 -> publish topic for field: internal_ac_voltage
21:36:58.501 -> publish topic for field: internal_ac_frequency
21:36:58.501 -> publish topic for field: ac_input_voltage
21:36:58.501 -> publish topic for field: internal_dc_input_voltage
21:36:58.501 -> publish topic for field: pack_max_num
21:36:58.501 -> publish topic for field: internal_pack_voltage
21:36:58.501 -> publish topic for field: internal_cell01_voltage
21:36:58.533 -> publish topic for field: internal_cell02_voltage
21:36:58.533 -> publish topic for field: internal_cell03_voltage
21:36:58.533 -> publish topic for field: internal_cell04_voltage
21:36:58.533 -> publish topic for field: internal_cell05_voltage
21:36:58.533 -> publish topic for field: internal_cell06_voltage
21:36:58.533 -> publish topic for field: internal_cell07_voltage
21:36:58.533 -> publish topic for field: internal_cell08_voltage
21:36:58.565 -> publish topic for field: internal_cell09_voltage
21:36:58.565 -> publish topic for field: internal_cell10_voltage
21:36:58.565 -> publish topic for field: internal_cell11_voltage
21:36:58.565 -> publish topic for field: internal_cell12_voltage
21:36:58.565 -> publish topic for field: internal_cell13_voltage
21:36:58.565 -> publish topic for field: internal_cell14_voltage
21:36:58.565 -> publish topic for field: internal_cell15_voltage
21:36:58.565 -> publish topic for field: internal_cell16_voltage
21:36:58.598 -> F01 - Write Response
21:36:58.598 -> 0000 0000 00de b1
21:37:03.192 -> Write Request FF02 - Value: 0103 0bb9 003f d61b
21:37:03.225 -> Update Web events
21:37:03.225 ->
21:37:03.368 -> F01 - Write Response
21:37:03.401 -> 0103 7e00 0200 0000 0000 0000 0000 0000
21:37:03.401 -> 0000 0000 0000 0000 0000 0000 0000 0000
21:37:03.401 -> 0000 0000 0000 0000 0000 0000 0000 0000
21:37:03.401 -> 0000 0000 0000 0000 0000 0000 0000 0017
21:37:03.401 -> 0211 1526 3900 0000 0000 0000 0000 0000
21:37:03.401 -> 0000 0000 0000 0000 0000 0000 0000 0000
21:37:03.401 -> 0000 0000 0000 0000 0000 0000 0000 0000
21:37:03.401 -> 0000 0000 0000 0000 0000 0000 0300 0000
21:37:03.401 -> 007f
21:37:03.401 -> publish topic for field: auto_sleep_mode

Please note that the checksum of the page 0x00 response is invalid because I edited the serial field for privacy reasons.

[AlexBurghardt]

I would have to see your code for further support.

[SvHeGithub]

Hi @AlexBurghardt
here is my startup sequence.
I removed others doing and I am only polling the states.
I also added a Milli Info to know how much times passed as i do not have the time from my serial monitor.
What i see is that the response is to short, but i get several of them.
If you have any idea, that is welcome. ;-)

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13836
load:0x40080400,len:3608
entry 0x400805f0
Loading Values from EEPROM
*wm:AutoConnect
*wm:Connecting to SAVED AP: Home
*wm:connectTimeout not set, ESP waitForConnectResult...
*wm:AutoConnect: SUCCESS
*wm:STA IP Address: 192.168.0.227

IP address:
192.168.0.227
MDNS responder started
webserver BT/MQTT variable logging disabled...
HTTP server started
BLE Advertised Device found: Name: AC200Mxxxxxxxxxxxxxxxxx, Address: 00:15:83:92:6a:3f, appearance: 960, serviceUUID: 0000ff00-0000-1000-8000-00805f9b34fb, rssi: -80
Connecting to MQTT at: 192.168.0.127:1883
Connected to MQTT Server...
subscribe to topic: dc_output_on
subscribe to topic: ac_output_on
subscribe to topic: auto_sleep_mode
subscribe to topic: power_off
Forming a connection to 00:15:83:92:6a:3f

• Created client
• Connected to server
• Found our service
• Found our Write characteristic
• Found our Notifyite characteristic
  We are now connected to the Bluetti BLE Server.
  Milli: 3795
  Write Request FF02 - Value: 0103 000a 007f 2428
  Milli: 4001
  F01 - Write Response
  0103 fe41 4332 3030 4d00 0000 0000 0003
  f99a 05c9
  Milli: 4007
  F01 - Write Response
  fd02 0200 0000 0000 001d a300 061c 7b00
  068d 4600
  Milli: 4509
  F01 - Write Response
  0100 0000 0000 0000 0000 0000 0000 0000
  3900 0000
  Milli: 5011
  F01 - Write Response
  F01 - Write Response
  0000 00c0 0000 0000 0000 0000 0000 0000
  0000 0000
  Milli: 6514
  F01 - Write Response
  0000 0000 0100 e600 0000 0001 f400 0000
  0000 0000
  Milli: 6796
  Write Request FF02 - Value: 0103 000a 007f 2428
  Milli: 6796
  F01 - Write Response
  0000 0000 0000 0000 0000 0000 0000 0000
  2202 4200
  Milli: 7307
  F01 - Write Response
  a800 0000 0000 0314 bb00 0600 1700 2800
  0100 0114
  Milli: 7808
  F01 - Write Response
  bb00 1700 0000 6401 2c16 bc02 5801 4a01
  4a01 4a01
  Milli: 8309
  F01 - Write Response
  4a01 4a01 4a01 4a01 4a01 4a01 4a01 4a01
  4a01 4a01
  Milli: 8810
  F01 - Write Response
  4a01 4a01 4a00 4f00 4900 4f00 0000 0000
  0000 0000
  Milli: 9311
  F01 - Write Response
  0000 0000 0100 e600 0000 0000 0000 0000
  00a3 01
  Milli: 9837

[SvHeGithub]

Hi @AlexBurghardt,
i reduced the amout of data read at one command to a number that seems to fit to what i so far receive.
That works for me, so i receive the data i need (and not caring on the others).
You log helped me to understand it better, so thanks!!
@mariolukas I think we an document it somewhere that reducing the amount of byte that are read might help (in some setups).
Regards,
SvHe

[AlexBurghardt]

Hi @SvHeGithub,

Warhammerkid (who reverse engineered the BT protocol) mentioned this in his posts. Requesting larger portions increases the risk of getting corrupted responses. The Bluetti device is responding by sending small parts that have to be concatenated in the ESP32. It seems that this did not work for you.
There is the possibility to request several smaller portions which lowers the risk of getting corrupted pakets.

[viper4gh]

Hi,

the problem with the corrupted data seems to be right.
Since I updated the AC200M.h where more data have to be transmitted, I get more and more cryptic datapoints over time and errors in the iobroker log.
Is there anything we can do here?

[AlexBurghardt]

Hi @viper4gh,

I do not believe that this is related to the bluetooth connection. It seems as if there are corrupted/scrambled mqtt topics transmitted. Yes, definitely not an issue with BT connection, because the topic names come from <String map_field_name(enum field_names f_name){}> in MQTT.cpp.

If there was a BT issue, the topics name would be correct and the values only would be wrong.

When did you reset the ESP32 before this ocurred?
For how long time did it run properly before it showed this issue?
Maybe it is an issue of the mqtt adapter, are you running it as a broker?

Regards,
Alex

[viper4gh]

@AlexBurghardt
Thanks for the reply.
It is difficult to say, it was active several hours I think.
Because the ESP32 reboots automatically on connection problems, it is further difficult to answer.
I think it would help a lot if we could add the uptime (in seconds for example) and the publish error counter as publish topic to the MQTT Broker. Then I could log these values to Influx DB and could better answer this question.

I have the MQTT Broker Adapter for iobroker and it runs as Broker, yes.
Further the corrupted values began since the new values for the AC200M are in.
With the version 3 weeks ago I had not such values.
And it seems that the corrupted values are copies of other values, but not all. I had never such a corrupted value for total battery for example, really strange.

Would it help to test with the old AC200M.h file again?

Viper

[AlexBurghardt]

@viper4gh:

The mqtt adapter seems to be receiveing corrupted topic names. They appear along with the correct topics in the object tree.
I am not using the mqtt adapter as a boker. I use it as a client being connected to the mosquitto broker. So I am using a different setup. But anyway, it seems as if the mqtt adapter receives topics with scrambled names and values. What does your serial log read? The published topic names should appear there if <#define DEBUG 1> is set in config.h and the part

#ifdef DEBUG
Serial.println("publish topic for field: " + map_field_name(field_name));
#endif

exists in <void publishTopic(enum field_names field_name, String value){}> in MQTT.cpp

[viper4gh]

@AlexBurghardt
Ok, thanks.
Checking the Serial Output could be time consuming, because I don't know when the problem occurs.
But I will try.

[AlexBurghardt]

In the part

ESPBluettiSettings settings = get_esp32_bluetti_settings();
-> sprintf(publishTopicBuf, "bluetti/%s/state/%s", settings.bluetti_device_id, map_field_name(field_name).c_str() );
lastMQTTMessage = millis();
-> if (!client.publish(publishTopicBuf, value.c_str() )){
publishErrorCount++;
AddtoMsgView(String(lastMQTTMessage) + ": publish ERROR! " + map_field_name(field_name) + " -> " + value);
}
else{
AddtoMsgView(String(lastMQTTMessage) + ": " + map_field_name(field_name) + " -> " + value);
}

of <void publishTopic(enum field_names field_name, String value){}> in MQTT.cpp could happen something unexpected.

The first line marked with "->" assembles the topic name and it's path
The second line (marked with "->" publishes the topic along with it's value converted to string

You could print these strings to the serial console (temporaril)y for debugging.

Also: you are using a different board. Maybe there is an issue with it.

[viper4gh]

@AlexBurghardt
A little Update:
I added the serial output like you described and now testing the third day with it, because the recent 2 days the problem occurs not one single time. And the ESP32 was running around 8 hours each day.
For today, the third day, I thought about what is the difference. And the only difference which is not code related, is the position of the ESP32, because I had it connected to my PC for the serial connection.
Then I connected a longer USB cable and positioned the ESP32 there, where it is normally, next to the powerstation, because normally it is connected directly to it.
And after half an hour the problem occured.
First of all the serial output shows no scrambled publishTopicBuf or value, that means the scrumbling must happen later.

And then I thought about the WiFi signal, because I have an AP on the same floor and one AP a floor above.
I have to check it again, but I think the recent two days without the problem the ESP32 was always connected to the AP on the same floor, where the ESP32 shows a RSSI around -60 dbm.
But at the position next to the powerstation the ESP32 sometimes connecting to the AP a floor above, where the signal is worse. I don't know why it is connecting there, but it does it. And there the RSSI is around -85 dbm, which is a critical signal strength.

I will test a bit more.
I will add the RSSI to publishDeviceState, which could help to see if the problem only occurs on bad Wifi Signal.

[AlexBurghardt]

@viper4gh
If you are browsing the ESPs status webpage all the time: this could be a root cause!
After I extended the AC200M dataset and monitored the output using the status webpage I got TCP/IP/WIFI warnings written to the serial log and strange behaviour. The error messages disappeared once I closed the browser and left the webserver alone.

[viper4gh]

@AlexBurghardt
Unfortunately I had the problems today again, but without having the webpage open.
It runs around 2 hours without any problems and then there were publish errors all the time and scrambled data again. But all normal values were still updated correctly. The ESP32 was not resetting itself during this time, which means the publish error rate was maybe not high enough (I currently don't know what the auto restart conditions are) .
And the RSSI was around -65 dbm all the time, which means the WiFi signal quality cannot be a cause.
After a reset it works fine again the rest of the day.
The search goes on... 😐

Till 11:35 all ok:

Part of MQTT Log:

2023-03-10 11:35:43.652  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.ac_output_on" 
2023-03-10 11:35:43.653  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.auto_sleep_mode" 
2023-03-10 11:35:43.653  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.power_off" 
2023-03-10 11:37:43.658  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] connection closed: Error: Cannot parse topic 
2023-03-10 11:37:46.728  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] connected with secret *********666667_3799 
2023-03-10 11:37:46.739  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.dc_output_on" 
2023-03-10 11:37:46.744  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.ac_output_on" 
2023-03-10 11:37:46.750  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.auto_sleep_mode" 
2023-03-10 11:37:46.756  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.power_off" 
2023-03-10 11:38:46.778  - error: mqtt.0 (1787237) Client [Bluetti_ESP32] Cannot parse "bluetti/AC200M************/state/device_status": {"MQTTconnect0?9bluetti/AC200M 
2023-03-10 11:38:46.779  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] connection closed: Error: Cannot parse topic 
2023-03-10 11:38:46.850  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] connected with secret *********726847_294 
2023-03-10 11:38:46.858  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.dc_output_on" 
2023-03-10 11:38:46.863  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.ac_output_on" 
2023-03-10 11:38:46.868  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.auto_sleep_mode" 
2023-03-10 11:38:46.875  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.power_off" 
2023-03-10 11:39:46.948  - error: mqtt.0 (1787237) Client [Bluetti_ESP32] Cannot parse "bluetti/AC200M*************/state/device_status": {"MQTTconnecte0?9bluetti/AC200M 
2023-03-10 11:39:46.949  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] connection closed: Error: Cannot parse topic 
2023-03-10 11:39:52.693  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] connected with secret *********792689_1583 
2023-03-10 11:39:52.700  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.dc_output_on" 
2023-03-10 11:39:52.707  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.ac_output_on" 
2023-03-10 11:39:52.713  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.auto_sleep_mode" 
2023-03-10 11:39:52.714  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.power_off" 
2023-03-10 11:40:52.733  - error: mqtt.0 (1787237) Client [Bluetti_ESP32] Cannot parse "bluetti/AC200M*************/state/device_status": {"030bluetti/AC200M***********/st 
2023-03-10 11:40:52.805  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] Received pubrel for unknown message ID: 25903 
2023-03-10 11:40:52.805  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] Received puback for unknown message ID: 12848 
2023-03-10 11:40:52.805  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] connection closed: Error: Cannot parse topic 
2023-03-10 11:40:52.904  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] connected with secret *********852901_8692 
2023-03-10 11:40:52.912  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.dc_output_on" 
2023-03-10 11:40:52.917  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.ac_output_on" 
2023-03-10 11:40:52.923  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.auto_sleep_mode" 
2023-03-10 11:40:52.929  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.power_off" 
2023-03-10 11:41:53.004  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] Received pubrel for unknown message ID: 14897 
2023-03-10 11:41:53.004  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] connection closed: Error: Cannot parse topic 
2023-03-10 11:41:58.749  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] connected with secret *********918747_7431 
2023-03-10 11:41:58.759  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.dc_output_on" 
2023-03-10 11:41:58.764  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.ac_output_on" 
2023-03-10 11:41:58.769  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.auto_sleep_mode" 
2023-03-10 11:41:58.775  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.power_off" 
2023-03-10 11:42:58.863  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] Received pubrel for unknown message ID: 28261 
2023-03-10 11:42:58.864  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] connection closed: Error: Cannot parse topic 
2023-03-10 11:42:58.960  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] connected with secret *********978956_3529 
2023-03-10 11:42:58.968  - info: mqtt.0 (1787237) Client[Bluetti_ESP32] subscribes on "mqtt.0.bluetti.AC200M**************.command.dc_output_on"```

[viper4gh]

Is there a possibility to read the CPU Load and free RAM, that we can add these to the device state topic?

[AlexBurghardt]

@viper4gh:
I doubt that there is a built in function. There are some hints to implement such a function. Just do a google search regarding "cpu load" on ESP32. But I think it just will give you a "guess", It won't be precise at all.

[github-ccnt-nib]

Hi. I just come across this issue myself. Owner of the (second) AC200M and initially very happy about your development of the ESP32 bridge as it would be a much more power-saving solution than the previous RaspberryPi bridge (that actually was quite complete and working for me).
After some (minor) changes to the ESP32 code, I was able to compile and upload it to my ESP. After several rounds of trial-and-error (due to the EEPROM save which probably overrides the precompiled values (user/pass/id)), I was finally able to connect both to my broker (needs three tokens: user, pass, ID to be valid) and also the Bluetooth connection to the AC200M is established. I see datagrams and the (very basic) state info device_status (1, 1/0), device (IP, MAC, Uptime) and device_type (AC200M) on the foreseen topics, but nothing else.
I can use the command channels to switch AC and DC on and off, but there are actually NO proper state outputs arriving at the broker. I can see a pattern emerging: pData[1] of 0x00 three times, then pData[1] == 0x03 once, but no publish, then the error "Error while publishTopic! 'device_type' can't be empty, reboot device)" appears (the device_type variable is properly set once, but later is empty). I also bridged this error with a "return before reset" to keep the connection alive a bit longer.
Anyways, I can try to assist in developing this further, if you care to explain a bit about where to best look.

[bascht]

I'm stuck at the same point now. In case any one of you had any more success with the AC200M - I'm interested and could supply more debug logs if needed. I'm going back to https://github.com/SSMCD/bluetti2mqtt for the mean time, since that worked okay-ish as long as the AC200M is near my home assistant machine. 😄