devWaves / SwitchBot-MQTT-BLE-ESP32

Allows for multiple SwitchBot bots and curtains to be controlled via MQTT sent to ESP32. ESP32 will send BLE commands to switchbots and return MQTT responses to the broker. Also supports Temperature, Motion, Contact sensors
MIT License
531 stars 66 forks source link

Support for ESP DEVKIT V1 (generic from ali express) #86

Closed Jacksonbm1 closed 1 year ago

Jacksonbm1 commented 1 year ago

I have one of these: https://www.aliexpress.com/item/3256801743620798.html?spm=a2g0o.order_list.0.0.120a1802llozYz (the DEVKIT V1), which I thought was a DIOT, but I'm not certain anymore. It's been flashing as the DIOT just fine, but who knows. Anyway, I've flashed it and it's discovering the bot, but it won't discover the commands like my wrover will.

Here's a screenshot from MQTT explorer with only relevant parts (note how the bottom is missing (set = ):

Screen Shot 2022-07-18 at 11 21 02 PM

They are the both connecting to the same device (but even when I only had the bottom one on, it didn't work.

Here's my config (expires in a month, but I can always repaste if needed): https://pastebin.com/7TbCT4FJ

Logs from serial monitor (with debug on): https://pastebin.com/jviG7Mtc

Without debug, it basically is just:

2:58:30.327 -> lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)
22:58:30.664 -> lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)
22:58:31.991 -> lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)
22:58:33.069 -> lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)
22:58:34.727 -> lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)
22:58:35.021 -> lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)
22:58:36.353 -> lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)

So I'm thinking that this is an issue with something going wrong with the model maybe? But I'm too new to microcontrollers to know. Any thoughts? Ways I can help you debug?

devWaves commented 1 year ago

it all looks good from here. you can see a "REQUESTSETTINGS" command was sent and success so I think youve compile and uploaded correctly. "REQUESTSETTINGS" is also a command sent to the bot to get firmware, holdsecs values. It just doesn't make the bot move. The rssi of -83 isnt great but it did at least work once

what seems to be the issue is with MQTT broker somewhere. if you sent a command, no matter what it should show in the 'set' topic. Even with the esp32 unplugged as this is done by the MQTT broker

you can try using a separate MQTT username and password for the 2nd esp32, but it probably won't fix things as the issue is with MQTT receiving the set command, not the esp32

as a note though you can use the same value static const std::string mqtt_main_topic = "switchbot"; // MQTT main topic for both esp32s. This is the main topic that can be shared with all esp32s. only the host needs to be different

scetu commented 1 year ago

Hmmm, having same generic ESP-32 38Pin and just finished setting everything up, and it's working, but there is really big delay between commands sent from ESP to Switchbot Curtain, and having same log as @Jacksonbm1 21:27:35.377 -> lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)

basically this start to spam serial port once command is sent

devWaves commented 1 year ago

@scetu those logs are normal and sent from the NimBLE library. No way to turn them off from what I can tell. They aren't sent from my code directly

what is the rssi linkquality value for the curtain device. This value shows the BLE signal quality. How close is the esp32 to the curtain? the closer the better

scetu commented 1 year ago

@devWaves ESP is 3-4 meters from curtains, without obstacles image image

devWaves commented 1 year ago

@scetu you might have a dud esp32. -88 is not a good signal. You want something at least in the -70s

You are sure the esp32 you have doesn't need an external antenna plugged into it?

scetu commented 1 year ago

@devWaves ok, I will investigate it more tommorow, or will try to move it further. Thanks for suggestion, I will let you know, I've sent command from HA and curtains did not respond at all but I will check it tommorow and this was in log

Logger: homeassistant.components.mqtt.discovery
Source: components/mqtt/discovery.py:107
Integration: MQTT (documentation, issues)
First occurred: 12:37:46 AM (12 occurrences)
Last logged: 12:37:48 AM

Received message on illegal discovery topic 'homeassistant/sensor/Závěsy_-_Levá_strana/linkquality/config'
Received message on illegal discovery topic 'homeassistant/sensor/Závěsy_-_Levá_strana/illuminance/config'
Received message on illegal discovery topic 'homeassistant/sensor/Závěsy_-_Levá_strana/position/config'
Received message on illegal discovery topic 'homeassistant/binary_sensor/Závěsy_-_Pravá_strana/calibrated/config'
Received message on illegal discovery topic 'homeassistant/binary_sensor/Závěsy_-_Levá_strana/calibrated/config'
devWaves commented 1 year ago

@scetu spaces in the names are replaced with _ and you have a space before and after the - . HA might also might not like the special characters. These would be from HA, not the esp32

not sure what HA doesn't like but I would suggest a name like Zavesy_Leva_strana if you are having issues

scetu commented 1 year ago

@devWaves ok after playing a bit, deleting and renaming device, it works more responsively - there is sometimes delay 2-3 secs, but it works and no errors in logs and all commands are executed in queue.

Thanks for your great work!

Jacksonbm1 commented 1 year ago

Huh, really weird, it works now fine after plugging back in. Didn't change anything to my knowledge.

Jacksonbm1 commented 1 year ago

Nvm. It doesn't work. What ends up happening is I have two esp32s. The first works, but the second (the one with the code here) doesn't seem to actually work. The weird thing is that it's information shows up in mqtt explorer, but it seems like it's trying to send the command through the wrong esp. When you say:

"you can try using a separate MQTT username and password for the 2nd esp32, but it probably won't fix things as the issue is with MQTT receiving the set command, not the esp32"

Isn't this the password for my broker (set up through HA)? Why would it be different? Maybe that'll solve.

devWaves commented 1 year ago

@Jacksonbm1 if you ever loaded multiple esp32s with the same devices that could mess things up. If you aren't using MQTT for other things the easiest things to do is delete everything under the homeassistant and switchbot MQTT topics using MQTT Explorer (with the esp32s unplugged), then plug them back in. This will start things from scratch It is possible you have a device incorrectly associated to the wrong esp32 topic

You can create different username/passwords for MQTT HA by simply creating a new user in HA. Use those credentials

devWaves commented 1 year ago

@scetu the delay of 2-3 secs is caused by poor signal. A signal of something like -50rssi will have no delay (or close to it)

Jacksonbm1 commented 1 year ago

Ok I will try that. Little scared to do that bc it might nuke my setup, but I will give it a go

devWaves commented 1 year ago

Ok I will try that. Little scared to do that bc it might nuke my setup, but I will give it a go

if you are using mqtt for other stuff then dont delete the entire homeassistant topic as it will delete other HA mqtt devices. you can individually delete those related to switchbot devices in that case. This is the same as deleting MQTT devices in HA but can be done all at once from MQTT explorer

deleting the switchbot topic should not affect your devices in HA. They will repopulate once the esp32s are turned on

Jacksonbm1 commented 1 year ago

Yeah I've been doing that. I got it all working (I did, unfortunately reflash the wrong esp32, but that's fine, I'm 99% of the way to getting that one back online to what it's original purpose was). The great thing is, I got the bots working. Two were trying to connect to the same device and I think that was causing problems! I think it's now fixed, though! Thank you for your help! Also, semi-possible that one of them had a bad bluetooth receiver (I shelved it because I thought it was causing the issues, but I'm thinking it actually wasn't)