I’ve noticed, using LYWSD03MMC BLE sensors with custom PVVX 4.2 firmware, that OMQTTG (with adaptivescan active) at first retrieves all the sensor infos seemingly in passive mode… but after a while (say, a couple of minutes, a new, additional property gets retrieved: “Name”.
This happens because every now and then adaptive mode switches to active connection to retrieve this data?
Do not use ESP32xxx - it cannot work with BLE at normal speed and drains the batteries of all BLE devices when connected!
and in fact I’ve noticed quite a steep battery drop on all my sensors, possibly after the 1.4.0 update (previously, I was using "activescan":false btw)
Well observed. Most devices only send their name property when being scanned actively. With intervalacts being the interval when active scanning is activated, this will be the interval in which you see the name, while any passive scans, possibly in between, won’t show it.
Because of the higher battery drainage of actively scanned devices we introduced adaptive scanning and separate intervalacts (active scanning) to interval (passive scanning) to allow for setting a lower frequency for active scanning for devices which require it for unique identification or getting all properties.
thanks for your reply @DigiH .
I’ve updated my original post explaining the reason behind my question, ie that the ESP32 issue that pvvx found may be the culprit (along with adaptive scanning) behind my recent battery drains.
LYWSD03MMCs do not require active scanning, neither for their identification nor to get all properties. So depending on what other devices you have in your set-up, and how frequently you’d want to get information of any devices which do require active scanning, you could always set intervalacts to a much higher value, like only doing active scanning very 5-10 minutes.
I also assume that with their documentation change they mean any new ESP32xxx model which have Bluetooth 5.0. With your postings about your Seeeduino Xiao C3 I take it that could be an issue for your recent battery drains - according to the above quote!?!
Possibly going back to a previous plain model ESP32 and observing the difference could be interesting.
After the first C3 ‘failures’, since my sensors are in a remote location and often the C3 would hang instead of rebooting, I soon switched back to a ‘vanilla’ ESP32, as documented briefly here
According to pvvx research (who is using lab equipment to test the sensor consumption) there’s an issue in the ESP32 family that prevents low power communication, and so actively connecting even infrequently will cause an abnormal load on the battery,
That’s not a great issue of course (I can just disable adaptive scanning) but I think it’s something to consider given that there’s the risk of adaptive scanning (in its default config) to drain the sensors.
Of course I’ll do more research and keep you updated
Hi @DigiH .
I’ve read your recent updates on ble.md, and this passage is a little obscure to me:
Setting Adaptive scanning to false will automatically put the gateway to continuous active scanning if no additional manual changes have already been applied
What are the additional manual changes needed to disable active scanning? In userconfig.h there’s no ActiveBLEScan to define anymore (since 1.4.0?) and timeBetweenActive is defined as an unsigned long, so maximum value is slightly less than 50 days…
I mean, my objective is to turn off active scan completely (to consume the least amount of battery possible on the sensors) and listen only for broadcasts… is there a ‘proper’ way to accomplish that?
additional manual changes are possible to set an extended interval for active scanning, but switching it off completely is not implemented since 1.4.0.
…is then setting AttemptBLEConnect=false enough then to prevent connecting?
I see adaptive scanning causes much less activity on the serial output of OMQTTGW, but again, since 1.4.0 the battery drain has increased on all of my LYWSD03MMCs…
Yes it is. Also visible as bleconnect in the BTtoMQYY status.
Which firmware are you using on your LYWSD03MMCs, PVVX, correct? And you have set intervalacts to a very high interval. So OMG gets your LYWSD03MMC PVVX properties by purely passive scanning (apart from the odd active scan every 50 days or so).
With purely passive scanning OMG should not even affect the batteries of your LYWSD03MMCs at all, as it solely passively picks up the advertising broadcasts. Therefore the increased battery drain you are seeing must be have some other reason.
Some recent PVVX firmware update?
Any other BLE gateways running, possibly in your neighbourhood, with frequent active scanning or even very frequent connection attempts?
Maybe I don’t get it right but… active scanning with AttemptBLEConnect=false can still be considered ‘active’ then? As far as I understand, this should effectively disable active scanning, no?
Which firmware are you using on your LYWSD03MMCs, PVVX, correct?
Yes, 4.2 to be correct.
Some recent PVVX firmware update?
A possibility, but I’m seeing the same behaviour even with non-updated (3.9) devices.
Any other BLE gateways running, possibly in your neighbourhood, with frequent active scanning or even very frequent connection attempts?
This is a very clever idea, actually.
I doubt it since the sensors are in a remote location in the woods, but I cannot rule it out, I must conduct some additional test to be sure this is not the case.
No, I think you are confusing active scanning and connecting to a device.
• Connection
If a devbice has been discovered either by active or passive scanning a connection request is sent to the device. If the device accepts the connection request, a connection is established, and data can be exchanged, usually by reading one or more service/characteristic for certain properties, or by writing to a service/characteristic. This can also be done by the OpenMQTTGateway READ/WRITE commands.
• Active Scanning
This involves a OpenMQTTGateway sending out a scan request packet to nearby devices. The devices which receive this request packet will then respond with an advertisement packet containing information. Often times with more information than with just a passive scan, e.g. usually the additional name of a device. There is no connection involved in active scanning though.
• Passive scanning
With this Open MQTTGateway only listens to advertisement packets sent out by nearby devices in regular intervals, often every second or even more frequently. This does not involve sending any scan request packets to the devices, nor connecting.
So with you using the last - passive scanning - option with your LYWSD03MMCs, and having set AttemptBLEConnect=false and intervalacts to 50 days, OpenMQTTGateway only passively listens to the braodcasts which your LYWSD03MMCs send out anyway; even if you would disconnect your OpenMQTTGateway completely, and which any other BLE scanning device or software could freely received in your vicinity, not being able to really affect the LYWSD03MMCs battery in any way.
• Did you change any of the settings of the PVVX firmware with the last upload?
• Which broadcast format have you defined, as there are several to chose from? Preferable the PVVX native format.
• Not having any PVVX devices myself, is there any setting to define how often the LYWSD03MMCs send our their advertising broadcast?
Not knowing where these woods are and what your weather is like there at the moment. Could it just be a spell of cold weather which usually is not very healthy for batteries?
Thanks for your reply @DigiH , it was very informative and indeed, I was confusing active scan with connection.
I think I’m right tho about active scanning actually increasing battery consumption, as the BLE devices will need to respond to active scan requests, right?
And, the best option (battery-life wise) should then be to set active scanning to happen as seldom as possibile, and denying BLE connection.
I did not change any setting, firmware wise (apart from lowering advertising broadcast frequency from every 2500ms to every 5000ms). And I’m using ATC format since it is 14 byte long instead of 16bytes for the PVVX format (which has greater precision for the reading, but increases air time for the BLE advertising by about 15%)
Of course I’m accounting for temperature in the battery calculation, and thankfully here in south of europe we’re near 20°C on average, and that should be near optimal for the batteries.
Yes, a bit more than passive scanning, which doesn’t affect the device battery at all, but not as much as a connections do.
So with you reducing active scanning to once every 50 days and having turned off connecting, and only using passive scanning the remaining time, the extensive battery drain you are seeing must have some other cause.
