search

mariolukas / Bluetti_ESP32_Bridge

Bluetti Power Station ESP32 Bluetooth to MQTT Bridge
GNU General Public License v3.0
88 stars 29 forks source link

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

Open SvHeGithub opened 1 year ago

SvHeGithub commented 1 year ago

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

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 commented 1 year ago

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

SvHeGithub commented 1 year ago

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

mariolukas commented 1 year ago

Merged with #51

SvHeGithub commented 1 year ago

Hi @AlexBurghardt,

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

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

2. 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();    <----

}

3. 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 commented 1 year ago

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

SvHeGithub commented 1 year ago

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 commented 1 year ago

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

AlexBurghardt commented 1 year ago

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 commented 1 year ago

I would have to see your code for further support.

SvHeGithub commented 1 year ago

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

SvHeGithub commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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?

DPs_iobroker

log_iobroker

AlexBurghardt commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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: IMG_20230310_221305

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 commented 1 year ago

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

AlexBurghardt commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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. :smile: