I’m just going to leave the mqtt explorer running for some time to see if we can get more information out of the logs…
read this…
configure your mqtt like this
Are you using a username password for mqtt? if not try with one
I’m running the supervised version in Hassio so how can I find the mosquitto.conf file?
it also does posts config at the same time
the offline payload in last will occurs at these timestamps too
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