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
ya sure, i’ll add the client name, main topic etc
1 Like
Cool. Cheers.
For now I could just create a automation on a restart to toggle plug (probably after 5mins or so). Love a workaround!!
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.
I need to treat you to a coffee or beer! 
I have not experienced this behavior but I will take a look into this.
Edit: I managed to replicate this issue and fix it. Need to do some extra testing but will probably push my changes later today and submit a PR.
ok cool. ya looks like just need to set retain = true on the initial mqtt discovery message
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
Just submitted a PR.
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
2 Likes
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.
switchbotone Battery Unknown
switchbotone Linkquality 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.
Thanks
v2.2 released. Main fix for HA after reboot
there was a bug in v2.1 after HA rebooted
try v2.2
Awesome!
I’m away for a few days, will give it a try when I get back. 
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.
Thanks again for your great work.
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.
Please Advice?
if lastwill is being sent as offline there is a problem. lastwill means the MQTT broker hasn’t heard from the esp32 in 60 secs
how many esp32 are running? each one needs a unique host name. if multiple esp32 are trying tk use the same name you will get connecting issues
I do see a bug though that if it disconnects, it is not sending online again after. I will fix that shortly
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.
Thanks!
I noticed this morning that my curtains were unavailable. It turned out that in the middle of the night there might’ve been a small network glitch that caused the esp to be disconnected to the broker for at least 60sec.
It was still updating the curtain topics every 10min (I happened to have MQTT Explorer open so could see the history) but the lastwill topic changed to offline and didn’t go back to online (which is expected because we only set it at boot).
I will submit a patch that will send online to the lastwill topic every now and then.
Edit: PR Submitted with this fix
v2.3 released should fix the lastwill online/offline
lastwill offline is only sent by the MQTT broker once it hasn’t heard back from the ESP32 for 60 secs. The esp32 will send lastwill online every 30 sec (when connected) and everytime the connection is reestablished