the scanning screenshot looks fine. That means the esp32 is BLE scanning. You may get this on mqtt reconnect also
are using a username/password for mqtt, if no I would use one that will probably solve the issue easiest
Iâm using a password and username which I created in the UI in HA. It is configured in the Arduino sketch and in the MQTT integration configuration. Not in the Mosquitto broker add-on.
try using the primary username password from the âre-configure mqttâ option in the mqtt mosquitto broker integration. You also cant use TLS for this
How should I configure the username/password in Mosquitto addon? Can you give an example?
Since last night the sensor became unavailable only 3 times. So thereâs been an improvement.
Just a question? Did you configure an expire_after for the HA entities? If not: could it be possible to put that in the code myself? It defaults to zero, so if you didnât configure it, I could use it to prevent the state being offline for a few milliseconds by changing it to 3 seconds for example.
Iâve fooled around in your code and added pl_avail/pl_not_avail for all the contact related sensors and set pl_not_avail to âexpiredâ. Tested this and the sensors then only go unavailable when the payload is expired. Now Iâll write an automation thatâll send payload âexpiredâ when the ESP32 Linkquality (which I didnât configure the above for) goes unavailable for more than 5 seconds. Practically this does the trickâŚ
I would want to ask you though, if you are willing to change your code and build in something that has the same effect. Maybe with a user configurable boolean that you can turn on when you experience short disconnections/unavailable states. This all so it wonât be default and problems can still be found when someone sets everything up.
so the root cause here is MQTT somehow. I understand what you did and although that may fix your issue I donât think it should be added to the native code. good idea as a workaround though
what your change does is override the native online/offline payloads expected. Something else you can do is just comment out the line that declares the lastwill offline message, then instead of sending expired you can send the default âofflineâ without editing the HA pl_avail/pl_not_avail
comment this out
client.enableLastWillMessage(lastWill, "offline");
I do think I need to make a change to retain the offline lastwill message though, but thats a very minor issue. Iâm thinking it should be retained like this. This will account for an HA/MQTT reboot.
client.enableLastWillMessage(lastWill, "offline", true);
what your change does is override the native online/offline payloads expected. Something else you can do is just comment out the line that declares the lastwill offline message, then instead of sending expired you can send the default âofflineâ without editing the HA pl_avail/pl_not_avail
I know, thatâs exactly why I did this. I still want to keep track of the last will offline message, because if I comment that line out it would not send the last will offline message at all and I would not know about disconnections longer than 5 seconds.
Would there be a way to edit that âclient.enableLastWillMessageâ line so that it only executes if the last online lastwill payload was published longer than 5 seconds ago? Not for the native public code, but for me to use as a workaround instead of what I did now. That would be perfect and save me a lot of time whenever thereâs an update!
the lastwill message offline is sent by the broker. There might be an MQTT setting, but I am not aware of it
for you, minimal changes if u still want to see the MQTT disconnect lastwill message, then change that message to expire instead. Means you only need to change one line and the HA devices donât change. Manually send âofflineâ instead of âexpireâ
client.enableLastWillMessage(lastWill, "expire");
Smart thinking! This way I only have to change 1 line with updates, Iâll just switch the two payloads in my automation. Iâll let you know if I ever figure out why the payload is being sent.
Thanks for your help, keep up the good work and if thereâs anything I can do to help maintain the project: let me know!
1 Like
Hey all,
I find that sometimes the ESP drops off the network (is pingable, but wont show the config page) and its about as fast as when I was using the API 5-6 seconds, sometimes more.
Is anyone else having these type of issues?
Is there any logs ect I can look at?
Im pretty new to MQTT, so If Ive missed a post or something, please just direct me to it 
Thanks all
EDIT
So found the post that says that anything should be under -75
AC controls are a little over a 3.5m away from the ESP line of sight
Coffee Machine is 5m away line of site
Yet the computer thatâs 10m away though 2 walls is consistently better 
SwitchBot ESP32 MQTT version: v6.7
what version are u running? There were some issues with constant scanning needed for contact and motion sensor.
also it seems that cheaper power supplies can cause the esp32 to crash, I am still experimenting with that. Hard to tell, takes days to reproduce
with v6.9 the webserver will now restart everytime mqtt reconnects
Thanks mate
Im upgrade first and see how it goes.
When you say cheaper, as in the components are not providing smooth power?
ya. The esp32 is running BLE at max power, while also running wifi/mqtt and webserver. The developer of the NimBLE library mentioned similar comments. The BLE power can be reduced in the code, if it causes issues
if you only have curtain, bot, and/or meter that shouldnt be a problem though
update all the libraries before reflashing. The BLE lib was recently updated, not sure if there is an outstanding issue with thr BLE library atm
Ok cool, thank you.
The one part i struggle with every time is upgrading the actual vis studio side of things.
I seem to have to start from scratch every time, download the files from GitHub.
delete the existing files âSwitchBot-BLE2MQTT-ESP32 folderâ and then make a new project and rebuild the whole thing from scratch with just coping past the config that i saved in notepad
Is there an easier way? any instructions?
Thanks
yes you need to copy paste your settings from version to version. As long as I didnt add a new variable you can copy paste the variables names etc from your last file
This is my first esp/arduino project and making values configurable through a webpage wasnt really a design plan to avoid issues during development
you can use a program like âBeyond compareâ or âwinmergeâ to compare your last file against the latest version and easily copy your settings over that way
update all the libraries before reflashing.
Iâve never thought about that. Still the same ibraries since this project kicked off. Guess no better time then now.
These are the ones I see that are updatable. No BLE packages. Nevermind, I see it. Itâs the last one.
hey @duceduc funny you commented. It seems some BLE Nimble library issues recently came up and were dicussed in an espresense issue
I am trying out the latest NimBLE version now, but those issues probably affected this code also
sounds like issues started after 1.3.3. Might be fixed in 1.3.7?
Yeah ok, if thatâs what it is, thatâs what it is LOL I just wanted to really make sure there was no other way
I doubt anyone would be complaining about it mate, you have done such a great job in putting this together so we have local Switchbot.
Really thank you
I so much want espresense to work. The big hurdle is the esp32 doesnât have enough memory. Almost always crashes/ reboots.