I believe they should all be mostly the same. Some esp32 have external antenna port. mine doesn’t. the one you listed uses the
cp2104 which is the legit one and not the knockoff
Bluetooth uses 2.4ghz just like many other things. there can be alot of interference on 2.4ghz
my esp32 is plugged in behind my fridge, the metal back of the fridge makes the signal worse, but my highest rssi is -73 and it works fine
with rssi signal strength a value closer to 0 means better signal
try with the esp32 right next to the bot and see what rssi you get, if possible try in another room
if your esp32 or bot is close to your router, or an Rpi using usb3, or zigbee or something using 2.4ghz, you could be getting a bad signal from interference with other stuff
Nice work on version 2.1 and Thank you @HardcoreWR - Auto discovery surely makes life easier.
I’ve been playing with 2.1 on one esp32 before moving others to this version. On this one I have 3 bots and a meter attached, after a HA reboot the meter does not refresh thus it stays ‘unavailable’.
Is this a known issue or is there a tweak needed?
I have tried autoRescan ON and OFF, still no joy.
Lucky for me power to this esp32 is on a smart plug so I can toggle power if away from home and it comes back to life.
Sorry…Also, is it possible to have the ‘mqtt_clientname’ added to the wed ui? having multiple esp’s and working out ip addresses can be a little confusing.
hmm something I can only test if I fake a meter. I can probably try something though to simulate. might have to ask @HardcoreWR or others who have the meter
with scanAfterControl true, once a MAC address is detected as a meter, it should always update at least every 30 sec, unless you override it in botScanTime list
when the esp32 reboots it would resend the HA MQTT discovery messages, that would be the only difference I think
Yes, the metre does update every 30 secs once alive (I did add to botScanTime just in case).
weirdly, after a HA restart the metre doesn’t appear again… well, for me it doesn’t.
It was a mixture of stuff.
By accident it was missing the retain flag for meter config so on a HA restart all the meter entities became unavailable.
Bot entities became unknown because the config was retained but the state topics (for all the devices) were not.
I also changed the lastwill message to lowercase ‘offline’ and added a publish of ‘online’ at boot.
Changed the discovery config to use this as the availability topic which means all related entities will become unavailable if the ESP is down.
I read the request about the mqtt_clientname to be added to the web UI and that got me thinking (also because I’m running into this myself now as well).
To keep things more clean in MQTT maybe we can use the following structure for the topics; [ESPMQTTTopic]/[esp_hostname]/curtain
I don’t think this is too much work to add since variables are used anyway.
ya I was thinking something similar. Let me know what u get to changing and we’ll release the fixes in a v2.2. I might be busy over the next couple days
Changed lastwill to lowercase offline and publish online on boot
Added lastwill topic as availability_topic for MQTT configuration
Added hostname to web interface
Changed root web interface to also show the upload page
Modified the upload page a little bit, showing a table (from the login page) and a fancy progressbar for the upload
Added the esp hostname in the main ESPMQTTTopic
Retain state and mqtt config messages
I’ve moved ESP32 next to the bot. I am getting -55 to -60. It was working fine. Then I’ve rebooted my NUC with home assistant. Then it stopped working. The status is Unknown.
I’ve tried to restart mosquito addon many times, then removed the bot from devices. After that MQTT discovery finds the device correctly but the status is still unknown. I know that the bot is working because I have a spare rpi4 and with switchbot integration and inbuilt bluetooth, it’s working good.
I just want to move to ESP32 because I am switching HA from rpi4 to NUC.
I am trying with v2.2. It seems to work now :-). Tried many reboots. It is taking sometime (2 to 3 minutes after reboot) before it’s fully operational. I will continue to test it and keep you informed.
Updated to v2.2.
I have a problem with the LastWill integration. If I sent a open/close command to the curtains the LastWill goes from online to offline. All items related to SwitchBot becomes unavailable and the SwitchBot items can’t be controlled anymore.
My workaround for now is changing offline to online in the .ino script.
I’m running just 1 esp32 for only 2 curtains.
Tested today if I could get the offline status again after changing back online to offline again in the ino file=>I couldn’t get it to offline, so it seems okay for now.
