OK, I had no idea those existed. I think something else the world needs is a website where you can just input an URL describing some project (e.g. your github URL) and your home address and it would return the easiest/fastest/cheapest way to buy it. If nobody has done that, I might build that one day myself, because that would make such questions like the one I am asking go away.
Same with the external antenna. I probably don’t care which one I buy, as long as it is better than an onboard one.
Choices are nice, but not when the overhead of making a choice is so high.
For example, the quindor esp32 guys could just add an option for buying an external antenna to go with it.
Regarding cases, there don’t appear to be any available to buy. You need to look on https://www.thingiverse.com or https://www.prusaprinters.org (etc) and find a model that you can 3D print. If you don’t have a 3D printer, there are places you can pay to have something 3D printed.
Thanks a lot, I was able to find those in my country too. In a way it’s just a matter of knowing the right term to search for. It would also be useful to add such terms to your GitHub page for other people.
Now, all I need to do is figure out an external antenna to use and then I can order. What I ideally would need is just someone that has a test setup with 3 concrete walls showing what, if any, signals still come through for various antennas. Ideally, there would probably be two antennas on your device (ignoring for a minute whether or not that might lead to interference (in theory with the right electronics there won’t be)). One for sending/receiving data to/from a not so directional antenna (for communication with the SwitchBots) and one very directional antenna for communicating to “the mothership” through 3 walls.
By the way Olimex as different esp32 based boards with external antennas. The esp32 gateway has also an enclosure.
I have this one (EA) with the enclosure, it has a very good range. You can also easily switch to another antenna thanks to the rp-sma female connector.
They have also POE models.
Note also that this is a way to support open source hardware manufacturers.
What’s a good product to power those usb-c ESP32s?
There are fast chargers, but they cost 3 times as much as the ESP32 and on top of that they are a theft target, because everyone needs those. The location where I will be using these will be fairly public.
One would expect a product to exist that is as cheap as an USB2.0 adapter, but just charges slower. OTOH, perhaps I just shouldn’t care.
I think you can use technically anything that supplies 5v at least 1a (probably 500ma) over usb. you do not need fast chargers and in some cases may actually cause more issues
I have used usb phone chargers (really old and new), power bar usb, PC usb port etc. I use a usb-a to usb-c cable
something I have been experimenting (still unsure) when I was debugging the last issue, I noticed it was crashing less when I used my PC usb port over one of the cheaper usb chargers I have. It is possible that some usb chargers dont play well with the BLE scanning at max power for a long time. In that case reducing the BLE scan power “might” help.
if you are only using bots and curtains you shouldnt have that issue because it doesnt constant scan, only when contact/motion are included
so basically you wont really know if the usb charger works well until you try it for an extended period of a couple days etc
you can also power the esp32 through the GPIO pins if you dont want to use usb
I have released a v6.8 to address some issues with constant scanning required for contact and motion sensors
If you were on v6.7 and only using curtain and bot and you didn’t have issues, no real reason to update
I have also added a donate buy me coffee link to my github page. I started this project for personal use and decided to share and add new features during this pandemic we are still in. My wife and I are now expecting a child and we are very excited. If you would like to support my work… and my kid, that would be awesome
@devWaves Congratulations!! As a new farther I can honestly say it’s an absolutely fantastic period in my life! Hope all will keep going well. And in the words of Anderson Cooper: “Don’t Blink”
First of all thanks for all the work on this project. I have been using it in combination with a contact sensor for about a week now and everything is running fine. The only problem I run in to is the sensor frequently disconnecting from the client, the intervals are not regular so can’t really find out what is the problem.
I’m running v6.8 and already tried your suggestion of chancing the ReconnectionAtttemptDelay to 10000ms, you’ve mentioned on another forum. Now I see that the unavailable state lasts 10 seconds almost every time, so I think the problem is somewhere else.
Any idea what might be causing the log message “Client disconnected due to protocol error” on my Mosquitto addon? I believe this is causing the esp32 to lose connection and wait 10 seconds before attempting to reconnect.
It doensn’t really bring any use case problems, so only having a way of not publishing the unavailable state but instead keeping the old state for x time, would solve all problems for me.
Hey so it sounds like an MQTT broker issue. Not sure what though
It would not be the sensor losing connection with the esp32, it would be the esp32 losing connection with your MQTT broker. There is never actually a “connection” made between the esp32 and the contact or motion sensors, just reading broadcasted data. The availabilty lastwill state of each device is the esp32 connection to mqtt broker state
what is the rssi linkquality value of the esp32 device in HA? that would be the WIFI signal. The rssi on the switchbot devices is the BLE signal.
So if rssi of esp32 is bad, MQTT/WIFI might disconnect. if rssi of devices is bad, they may not be able to read the latest broadcasted BLE messages
It is usually best to place the esp32 as close to the switchbot device you want best reliabilty and fastest response time. WIFI spreads better then the BLE signal. But in your case it may be the wifi is bad?
I can only really suggest trying with a fresh MQTT broker and see if the issue remains
The state of contact and motion are retained MQTT messages so you can always get the last state if it was published properly
Thanks for the quick response. Both RSSI values are around -55 which is quite good I believe. The esp32 is less than one meter away from Switchbot and about 2,5 meters away from router. That shouldn’t be the problem.
I agree that it seems like the problem is on the broker side, because of the log message ‘protocol error’ and the fact that changing the ReconnectionAttemptDelay value doesn’t fix the problem, only prolonging the ‘unavailable’ state.
I’ll try the fresh broker install as soon as I get home. Is it correct that I would only have to do the following steps?
Delete MQTT integration
Uninstall Mosquitto addon
Restart HA
install Mosquitto addon
Restart HA
Look for auto discovery of MQTT in integrations
Also, should I change back the ReconnectionAttemptDelay to 10ms before I do the above? Since that didn’t fix the problem…
yes your steps sound right. If you arent using mqtt for much else, might be good to delete all retained messages with a tool like mqtt explorer, but I think a fresh install does that also
your rssi of -55 is really good, so not the problem
By the way, I didn’t mean sensors having a connection with the esp32. I meant to say that it remains unclear if the connection between the broker and esp32 is lost due to problems on the esp32 side, or the broker.
I’ve been fooling around in the beginning because first setup I’ve put the mac of the contact sensor as a motion sensor. Changed it afterwards, rebooted and everything was working correctly. I’ve also made a mistake by putting my esp32 HA user credentials in the Mosquitto config page under ‘logins’, which I removed when I found out it was not meant to be there.
I’ve also found a bug in the code which I chabged. There was a payload of ‘ENTERING’ or ‘EXITING’ being sent when the incount/outcount changed, while the referring IN/OUT sensors were listening for a payload_on of ENTERED and EXITED. This caused those referring sensors to never report state=on and the logs to mention an unknown payload. I’ve matched those in my Arduino sketch which solved that problem. Maybe you can include that in your next release?
