the problem with multiple presses is that I noticed that if u press it fast, the switchbot contact sensor doesnt always notice each individual push, so the counter could be off. Thats why I left it as one push. It didnt seem like it was reliable enough
but if u give a small delay between pushes it could work
one of the reasons I publish the count as well as the PUSHED state, so if people want to use the count they can. Glad u have a use for it if u find it reliable enough
Thatās true. But the buttoncount sensor is always showing the correct value after you stop pressing the button for a sec or so. You can try that yourself. With the above automation I think the minimum interval is about a split second, but if I could write a template that compares the before state and after state of buttoncount and calculates how many steps it took in the 1-15 cycle, there wouldnāt be a minimum interval. You would only have to configure the amount of seconds you need to perform your desired consecutive presses in and add a little delay to catch the last Switchbot advertised value of buttoncount. Then compare that to either
This is me thinking out loud though.
thats what I am saying. I tested that. clicking 5 times real fast, only 4 were registered sometimes. I planned on supporting multiple presses but found that during testing so didnt bother. It all depends how fast u click
I am use to switches with scene multiple presses now
Well, I can only imagine how many things you must have tested when making this whole project. So no worries, Iām just sharing user experience and ideas on functionality.
Could it be an idea to use something similar to the SendBackupMotionContact for this case? Or make use of the counter domain for the count sensors?
ya Iāll see if something can go in the next release. Ive got it mostly figured out in my head, just wasnt a personal use case for me and didnt seem 100% reliable when I initially looked at it
in/out zero count fix and EXITED/ENTERED fix applied to v6.9. Thanks
v6.9 now updates the assumedstate right away with a STATEON/STATEOFF. This will fix an issue if the esp32 happened to lose power before the next scan or control
The clean install didnāt helpā¦
Last night Iāve removed all (if I did it right) retained messages through MQTT Explorer, restarted the Mosquitto addon afterwards. Still having the unavailable states popping up every now and then.
Here are the logs from Mosquitto addon:
1644800861: āāā Username/password checking enabled.
1644800861: āāā TLS-PSK checking enabled.
1644800861: āāā Extended authentication not enabled.
1644800861: Opening ipv4 listen socket on port 1883.
1644800861: Opening ipv6 listen socket on port 1883.
1644800861: Opening websockets listen socket on port 1884.
1644800861: Warning: Mosquitto should not be run as root/administrator.
1644800861: mosquitto version 1.6.12 running
1644800861: New connection from 127.0.0.1 on port 1883.
1644800861: Socket error on client <unknown>, disconnecting.
1644800861: New connection from 192.168.2.24 on port 1883.
{"result": "ok", "data": {}}1644800861: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644800862: New connection from 172.30.32.1 on port 1883.
[02:07:42] INFO: Successfully send discovery information to Home Assistant.
[02:07:42] INFO: Successfully send service information to the Supervisor.
1644800862: New client connected from 172.30.32.1 as 2pyIfrI8LgHzD5rt3upqvR (p2, c1, k60, u'esp32switchbot').
1644800941: Socket error on client 2pyIfrI8LgHzD5rt3upqvR, disconnecting.
1644800963: New connection from 172.30.32.1 on port 1883.
1644800963: New client connected from 172.30.32.1 as 6dpNR4nUlm4p0xwn4cU6yJ (p2, c1, k60, u'esp32switchbot').
1644801432: Client ESP32SwitchBot disconnected due to protocol error.
1644801432: New connection from 192.168.2.24 on port 1883.
{"result": "ok", "data": {}}1644801432: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644801664: New connection from 192.168.2.31 on port 1883.
1644801664: New client connected from 192.168.2.31 as mqtt-explorer-2d92a234 (p2, c1, k60, u'esp32switchbot').
1644802041: Client mqtt-explorer-2d92a234 disconnected.
1644802662: Saving in-memory database to /data/mosquitto.db.
1644804463: Saving in-memory database to /data/mosquitto.db.
1644805603: Socket error on client ESP32SwitchBot, disconnecting.
1644805603: New connection from 192.168.2.24 on port 1883.
{"result": "ok", "data": {}}1644805603: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644805813: Client ESP32SwitchBot disconnected due to protocol error.
1644805813: New connection from 192.168.2.24 on port 1883.
1644805813: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644806264: Saving in-memory database to /data/mosquitto.db.
1644808065: Saving in-memory database to /data/mosquitto.db.
1644809866: Saving in-memory database to /data/mosquitto.db.
1644810255: Client ESP32SwitchBot disconnected due to protocol error.
1644810255: New connection from 192.168.2.24 on port 1883.
{"result": "ok", "data": {}}1644810255: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644811667: Saving in-memory database to /data/mosquitto.db.
1644812446: Socket error on client ESP32SwitchBot, disconnecting.
1644812446: New connection from 192.168.2.24 on port 1883.
{"result": "ok", "data": {}}1644812446: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644812626: Client ESP32SwitchBot disconnected due to protocol error.
1644812626: New connection from 192.168.2.24 on port 1883.
1644812626: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644813468: Saving in-memory database to /data/mosquitto.db.
1644814097: Socket error on client ESP32SwitchBot, disconnecting.
1644814097: New connection from 192.168.2.24 on port 1883.
{"result": "ok", "data": {}}1644814097: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644814126: Socket error on client ESP32SwitchBot, disconnecting.
1644814127: New connection from 192.168.2.24 on port 1883.
1644814127: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644814156: Client ESP32SwitchBot disconnected due to protocol error.
1644814157: New connection from 192.168.2.24 on port 1883.
1644814157: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644815269: Saving in-memory database to /data/mosquitto.db.
1644816887: Client ESP32SwitchBot disconnected due to protocol error.
1644816888: New connection from 192.168.2.24 on port 1883.
{"result": "ok", "data": {}}1644816888: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644817070: Saving in-memory database to /data/mosquitto.db.
1644818871: Saving in-memory database to /data/mosquitto.db.
1644820672: Saving in-memory database to /data/mosquitto.db.
1644820849: Invalid QoS in PUBLISH from ESP32SwitchBot, disconnecting.
1644820849: Socket error on client ESP32SwitchBot, disconnecting.
1644820849: New connection from 192.168.2.24 on port 1883.
{"result": "ok", "data": {}}1644820849: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644820939: Invalid QoS in PUBLISH from ESP32SwitchBot, disconnecting.
1644820939: Socket error on client ESP32SwitchBot, disconnecting.
1644820939: New connection from 192.168.2.24 on port 1883.
1644820939: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644822259: Socket error on client ESP32SwitchBot, disconnecting.
1644822260: New connection from 192.168.2.24 on port 1883.
{"result": "ok", "data": {}}1644822260: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644822473: Saving in-memory database to /data/mosquitto.db.
1644823881: Socket error on client ESP32SwitchBot, disconnecting.
1644823881: New connection from 192.168.2.24 on port 1883.
{"result": "ok", "data": {}}1644823881: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644824274: Saving in-memory database to /data/mosquitto.db.
1644824390: Socket error on client ESP32SwitchBot, disconnecting.
1644824390: New connection from 192.168.2.24 on port 1883.
{"result": "ok", "data": {}}1644824390: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644824723: Client ESP32SwitchBot disconnected due to protocol error.
1644824723: New connection from 192.168.2.24 on port 1883.
{"result": "ok", "data": {}}1644824723: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644824724: Client ESP32SwitchBot disconnected due to protocol error.
1644824730: New connection from 192.168.2.24 on port 1883.
1644824730: New client connected from 192.168.2.24 as ESP32SwitchBot (p2, c1, k300, u'esp32switchbot').
1644826075: Saving in-memory database to /data/mosquitto.db.
1644827876: Saving in-memory database to /data/mosquitto.db.
1644829677: Saving in-memory database to /data/mosquitto.db.
1644831478: Saving in-memory database to /data/mosquitto.db.
1644833279: Saving in-memory database to /data/mosquitto.db.
1644835080: Saving in-memory database to /data/mosquitto.db.
1644836881: Saving in-memory database to /data/mosquitto.db.
1644838682: Saving in-memory database to /data/mosquitto.db.
1644840483: Saving in-memory database to /data/mosquitto.db.
1644842284: Saving in-memory database to /data/mosquitto.db.
1644844085: Saving in-memory database to /data/mosquitto.db.
1644845886: Saving in-memory database to /data/mosquitto.db.
Here is the history from HA:
Turned off
3:40:04 PM - 1 hour ago
Became unavailable
3:40:04 PM - 1 hour ago
Turned off
8:45:30 AM - 8 hours ago
Became unavailable
8:45:24 AM - 8 hours ago
Turned off
8:45:24 AM - 8 hours ago
Became unavailable
8:45:23 AM - 8 hours ago
Turned off
8:39:51 AM - 8 hours ago
Became unavailable
8:39:50 AM - 8 hours ago
Turned off
8:31:21 AM - 9 hours ago
Became unavailable
8:31:21 AM - 9 hours ago
Turned off
8:04:20 AM - 9 hours ago
Became unavailable
8:04:19 AM - 9 hours ago
Turned off
7:42:19 AM - 9 hours ago
Became unavailable
7:42:19 AM - 9 hours ago
Turned off
7:40:49 AM - 9 hours ago
Became unavailable
7:40:49 AM - 9 hours ago
Turned off
6:34:48 AM - 11 hours ago
Became unavailable
6:34:47 AM - 11 hours ago
Turned off
5:49:17 AM - 11 hours ago
Became unavailable
5:49:16 AM - 11 hours ago
Turned off
5:48:47 AM - 11 hours ago
Became unavailable
5:48:46 AM - 11 hours ago
Turned off
5:48:18 AM - 11 hours ago
Became unavailable
5:48:17 AM - 11 hours ago
Turned off
5:23:46 AM - 12 hours ago
Became unavailable
5:23:46 AM - 12 hours ago
Turned off
5:20:46 AM - 12 hours ago
Became unavailable
5:20:46 AM - 12 hours ago
Turned off
4:44:15 AM - 12 hours ago
Became unavailable
4:44:15 AM - 12 hours ago
Turned off
3:30:13 AM - 14 hours ago
Became unavailable
3:30:13 AM - 14 hours ago
Turned off
3:26:43 AM - 14 hours ago
Became unavailable
3:26:43 AM - 14 hours ago
Turned off
2:17:12 AM - 15 hours ago
Became unavailable
2:17:12 AM - 15 hours ago
Turned off
2:07:42 AM - 15 hours ago
Became unavailable
2:07:34 AM - 15 hours ago
Turned off
1:54:54 AM - 15 hours ago
Became unavailable
1:54:44 AM - 15 hours ago
Turned off
1:26:13 AM - 16 hours ago
Turned on
1:26:13 AM - 16 hours ago
Turned off
12:48:23 AM - 16 hours ago
Became unavailable
12:48:13 AM - 16 hours ago
Turned off
12:28:39 AM - 17 hours ago
Became unavailable
12:28:32 AM - 17 hours ago
In the screenshot below, thereās one retained message that I canāt deleteā¦ If I click the X or send a blank message with retain flag to the topic, nothing happens. Also, whatās up with the topic retainedmessages/count under %SYS/broker?
What I did notice last night in the lastwill topic, there were online payloads at a regular interval, but when the state goed unavailable thereās 3 payloads at the same timestamp, in the following order: online - offline - online. Then it goes back to 1 payload per timestamp.
By now Iām really stuck here and donāt know what to do to make this work. I hope you know the solution! Could the last will message of the MQTT integration be a problem in this case?
Thank you too for the quick thinking! Keep up the good work!
the online state is sent every 30 secs if the esp32 is connected to MQTT. The offline state message is triggered and sent by the MQTT broker when it believes the client has disconnected using the MQTT lastwill functionality
I cant explained why u see them all with the same timestamp though
What kind of power supply are you using? I am starting to notice that certain cheap USB power supplies can affect how the esp32 draws power for scanning and running the webserver at the same time. The esp32 is working hard with BLE and wifi running at the same time
Are you noticing a ābootā mqtt message. This would mean the esp32 crashed, if not then it is something with MQTT
you should only need to delete mqtt retained messages from /homeassistant and /switchbot. I dont think retained messages is the issue though
Are you using a mesh wifi network? Ive heard some people having issues with mesh. I have a mesh network, works for me. My 2.4ghz ssid is also seperate from my 5ghz ssid
Installing a test MQTT on another non HA system might work, but obviously not a solution
Where would I be able to find the ābootā mqtt message?
The power supply should be fine, itās a normal micro USB v2.0 cable attached to a Samsung Power Plug (5v at 1.0A)
Could it be possible to let the broker only send the offline state when the disconnection has been longer than x seconds? This would be a work around and not a solution for the underlying problem, so just for my personal case. Because to be honest I donāt really care much about the few millisecond disconnections, I just donāt want the device to report unavailable all the time because it floods the logs/history and makes me have to exclude the unavailable state from any automation triggers.
Just received a lastwill offline payload at 17:45. The topic ESP32Switchbot/status didnāt report boot before, only āscanningā directly afterwards
boot is right on the main MQTT topic. You will see it as soon as you plug the esp32 in (or when it reboots/crashes)
ESP32 will respond with MQTT on ESPMQTTTopic with ESP32 status
- <ESPMQTTTopic>
example payloads:
{status":"idle"}
{status":"scanning"}
{status":"boot"}
{status":"controlling"}
{status":"getsettings"}
ya so the esp32 isnāt crashing if you arenāt seeing ābootā
from googleā¦
āLast will is only published by the MQTT broker if the the keep alive timeout expires, and the last will is not sent if your device reconnects within the timeout windowā
in the code I have the keep alive set to 60 sec
client.setKeepAlive(60);
The thing is that the timeout can never be expired, because when there is an offline payload published, there has been an online payload less than 1 sec and one 30 secs before.
ya it is not really making sense to me sorry. I am not getting the disconnects.
when the esp32 reconnects it will send a new online message, also the āonlineā messages are retained, so they may appear as resent when MQTT reconnects. The āofflineā is not retained
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
