the meters should auto update any time there is a change in temp or humidity, no matter what the settings are. But to get more frequent MQTT updates you can set these values
defaultMeterMQTTUpdateSecs = Any time the ESP32 is scanning and the device is found it will update every X seconds
static const int defaultMeterMQTTUpdateSecs = 600;
defaultMeterActiveScanSecs = The ESP32 will active scan for the meter. Meters support passive scanning though and active scannning uses more battery, so this is why the value is higher
static const int defaultMeterActiveScanSecs = 3600;
Good to know that it should update when the temp or humidity changes, I must have missed that in the doc.
Yes I’m on the 7.1 version. I looked at last night’s history and it didn’t update for 8 hours despite the temp changing, I think the ESP might be a bit too far as the link quality I’m getting now is -95 rssi.
I’ll try to add a closer one to the Meter and see how it goes.
I’m still getting the odd freeze using v7.1.
I’ve checked all the library versions installed and compared to the documentation, they are ok. The ESP32 version is also correct. It’s not happening as often as it did previously when I was using the wrong ESP32 version, but it is happening at least once a day.
hey @evanshaw sorry I am not having the same issues so I am not sure. Mine has been running v7.1 since the last update. No lock ups at all
What are all the device types you have? I have like 2-4 of each type
are you using a dedicated MQTT user/pass for the esp32? if no try creating one just for the esp32
also make sure you are using a good power supply
just as a note, what esp32 dev board do u have again?
if you leave the esp32 plugged into your pc you can turn on debugging to try and figure put why. You will want to use the arduino IDE 2 or platform io. The original arduino IDE can crash with too much serial monitor output
these are debug settings
static const bool printSerialOutputForDebugging = false; // Only set to true when you want to debug an issue from Arduino IDE. Lots of Serial output from scanning can crash the ESP32
static bool manualDebugStartESP32WithMQTT = false; // Only set to true when you want to debug an issue. ESP32 will boot in an OFF state when set to true. To start the ESP32 processing send any MQTT message to the topic ESPMQTTTopic/manualstart. This will make it easier to catch the last serial output of the ESP32 before crashing
Not sure about the debugging thing as all this is pretty new to me. v6.11 worked superbly for me with NimBLE 1.3.7, I’m suspecting that it’s still a NimBLE 1.4.0 problem in my case, Will 7.1 still work ok if I revert to NmBLE 1.3.7?
@evanshaw yes 1.3.7 will still work. the change I made was to not unsubscribe from BLE notification inside the notification method. I dont think 1.4.0 is the issue though as it works fine for me
Do u happen to have a diff brand esp32 to try with? someone else mentioned the “esp32s” giving them issues and they moved to a diff brand and it solved all the problems
these are the main ones I use
ESP-WROOM-32-U (with external antenna)
Hope you are well.
So I tried dropping to NimBLE 1.3.7, no change.
Then I tried experimenting with a different board type in the IDE, I went to what I think is quite generic “ESP32 Dev Module” again, no change, I was using “DOIT ESP32 DEVKIT V1” previously.
Not really sure which board type I should be using TBH as there is nothing in the list with WROOM in the description.
Anyway, I decided to upgrade back to NimBLE 1.4.0 and again no change. (I’ve kept it as ESP32 Dev Module for now)
Now for the weird part, after the failures I thought I’d switch on the debugging via the Arduino IDE, by setting the line you mentioned :-
And blimey, after setting up the Arduino Serial Monitor with that set, I think I’m seeing the Quantum Wave Affect, where when you monitor something, it does as expected. It’s not crashed since the serial monitor has been on.
P.S. The chip on the board itself says “ESP-WROOM-32 211-161007”
In that case, my only guess would be the power supply. If u have it plugged into a PC and it isnt crashing but while plugged into the usb charger it does
any slight power fluctuation could mess things up. Even if the power supply is working
If u have an old 1amp cheapo USB power supply I would suggest trying that instead of the fancy one you have
Hey, I feel a bit bad writing this, as the work done by @devWaves controlles my switchbot flawlesly for months now (big thank you!). But ever since I switched from the back-then wonky native HA switchbot integration to the mqtt bridge, it bothers me that the ESP32 used for it does nothing else. It’s located in my hifi rack, as there is the closest power source to the heating switch I stuck the SB to, so there would be tons of potential for further usecases with the unused pins (audio source switch, physical volume control for the ancient amp, …)
Now we have bluetooth proxy support in esphome, and I’m considering trying out to flash the same esp32 with esphome and to give the internal SB integration another try. It does still have the weird illogical way to provide controls (SwitchBot momentary mode, also entity missing?) though.
Anyone from within this thread who already tried to switch back and has a few days/weeks of experience with the setup?
I know, I could just leave the mqtt bridge as it is, and add yet another esp to the hifirack, but it kind of feels redundant.
Cheers!
I switched back when active bluetooth control using proxies became available. I’m back on this ESP32 solution however. The native integration worked for a day before becoming unavailable again. Even the one Switchbot device I never used the ESP32 bridge for as it always worked fine (humidity sensor) started to have connection issues.
Having said that, I think it may be fixed in the latest version. As my Humidity sensor has become stable again. So I may give it another try.
As I currently just to test have both integrations running I’ve tested on occasion if the native one keeps responding and it does. But not as smooth as the ESP32 bridge. For example if I close a curtain and then stop midway, the native version won’t show the open action and lists the curtain as ‘opening’ for a good half a minute or something. While with the ESP32 bridge I can just close, stop, open right away.
hey @Lakini. Don’t feel bad, use whatever solution you feel best suits your needs. The esphome bluetooth proxy stuff is really cool but I personally won’t be moving to it anytime soon if ever for multiple reasons
My code supports meshing esp32s for contact/motion/meters . Meshing esp32s provides lightning fast response time comparable to zigbee/zwave. My motion sensors and contacts sensors have basically zero delay
my mesh code handles the situations where duplicate data can be received where one esp32 receives the data faster than the other. Without that you could get a door that goes open, closed, open, closed when it was only opened,closed once in reality
3.Active scanning is turned on only when needed/desired in favor of passive scanning. This saves battery on switchbot devices. From my knowledge the esphome stuff has active scanning on all the time
My esp32 code only relies on MQTT and does not rely on other integrations that could receive breaking changes. If u have a working setup feel free to leave it that way
I am not sure if the switchbot integration handles when a switchbot devices is busy by reading the response the devices sends back. my code does. You can test this by putting a hold value on a bot, and during that hold time try to call the bot from the switchbot integration. The switchbot will accept the command but if busy will just return a busy response. My code will retry on busy
If you only have like one bot or curtain etc I can see how using an esp32 just for that can be “wasteful” but the code can accomodate using other sensors and the esp32s pins etc, it just isnt as straight forward as the esphome stuff. Just requires combining some arduino examples into the code. I provided some examples in the forum somewhere
but ya the esphome bluetooth proxy stuff is cool. I only wrote my code because the other options sucked at the time. If I had non switchbot BLE devices I would consider using it
Thanks for this! It sounds very promising, but for me, this is very unstable. It takes ages for the commands to go through, and my curtain bots keep becoming unavailable most of the time. The board is right next to the curtains, and my wifi strength is solid. Could it be because of the boards I am using? I’m using this board: https://www.amazon.nl/-/en/gp/product/B07Z83H831
Are there any recommended boards out there I can try with?
Yes, but I will probably be returning these. Good thing I bought from Amazon. I have in the mean time placed an order on Aliexpress for the recommended board (WROOM-32U). I will return all 3 AZ-Delivery boards once I get my Aliexpress order.
