Set much longer advertising intervals/turn off advertising altogether

[benho93]

I would like to use much higher advertising intervals, say every 10 minutes or 15 minutes.

Additionally, it would be quite handy if advertising could be turned off altogether for use cases where only temperature tracking to flash or the clock mode is desired.

Any way to make this possible?

[pvvx]

It is possible, but in a separate project ... The BLE standard does not support advertising intervals longer than 10 seconds. It will not be possible to connect to the device. Typical external BLE equipment performs poorly already at intervals of more than 2.5 seconds.

[benho93]

I'm only using the advertising mode, so I assume it would still work fine with longer advertising intervals?

Would resetting the device manually make it possible to connect to it again?

Any chance you could implement that?

[fanoush]

maybe it could be time related i.e. you could specify time of the day when advertising is on or off, then you could pull the data periodically e.g. once per hour/day when it is on.

[pvvx]

It makes no sense, since the consumption of the device in sleep mode is limited by the applied elements and has 5..6 μA for Xiaomi LYWSD03MMC B1.4, 6..7 μA for B1.6, ... When the interval is set to 10 sec and RF TX 0, the consumption does not exceed 10 μA. The price of the battery is negligible, and the work in this mode is more than a year. What's more, controllers like the ESP32 are very poor at accepting ad packets. Software they do not know how to continuously receive and have a lot of gaps in the reception of BLE packets.

[Janot106]

In my point of view, there is other points to take into consideration :

• database size on automation server side (but ok, it can also be solved on server side by skipping/averageing values)
• reduce smog for other bluetooth sensors or other protocols (zigbee...). Of course, this is valid for hundreds of sensors on each protocol or when we have poor reception from far sensors. It's possible.

Maybe Goldrush12 will have more things to say here.

But thanks for all the work ever done !

[pvvx]

In my point of view, there is other points to take into consideration :

• database size on automation server side (but ok, it can also be solved on server side by skipping/averageing values)

1. The impossibility of monitoring the health of the sensor or the discharge of the battery by the timeout of receiving packets.
2. Reduced guarantee of reception due to packet loss and complete non-reception due to incompatibility with BLE specifications for most BLE adapters on the market.

The block transmission option with short intervals between duplicated ADVs requires a continuous receive option from the BLE adapter. Those. the adapter should always work on only one channel for one or two sensors and not perform any other tasks. The standard BLE adapter does not have this feature. This can only be done using a specialized BLE sniffer.

• reduce smog for other bluetooth sensors or other protocols (zigbee...). Of course, this is valid for hundreds of sensors on each protocol or when we have poor reception from far sensors. It's possible.

The transmission time of a BLE advertising packet with a PDU of 27 bytes is 328 μs. This is 1 / 0.000328 = 3048 packets per second or up to 3 thousand devices with advertising intervals set at 1 second. With Zigbee, things are much worse, since the bit rate is very low.

or when we have poor reception from far sensors

Install a BLE repeater for $ 1.

[pvvx]

Periodic ads are not served in Home Assistant and other apps. Linux has just started to support the Bluetooth v5.0 standard released in 2016, but most top-level programs don't work with Bluetooth v5.0.

[Stephan3]

It is possible, but in a separate project ... The BLE standard does not support advertising intervals longer than 10 seconds. It will not be possible to connect to the device. Typical external BLE equipment performs poorly already at intervals of more than 2.5 seconds.

Hello @pvvx .

Found this using search function, as i am was after the same thing. Currently i use 12.5s advertising interval. Form temp and Humidity 30s+ would be still more than sufficent. I dont know if i understand the connection mechanics right. So if a longer advertising/messurement interval would result in longer battery life, why not? I transfer the data using few tasmota devices here and there to my iobroker. Works great. The devices with a button advertise much more often when button is pushed. So connection could still work.

If this has been answered elsewere, sorry to spam you here.

-- Stephan

[pvvx]

Currently i use 12.5s advertising interval.

The official BLE standard limits the advertising interval to 10 seconds. Recommended, according to the results of implementation - up to 1.6 seconds. The reasons are negligent software and installations in the Linux kernel (introduced sabotage from Intel specialists, plus an incorrectly selected algorithm for working in the driver - blocking the driver for the scanning period), old BT adapters, restrictions in recommendations from Apple contrary to Bluetooth SIG standards, ...

Currently, in some adapters, the embedded software is limited to a scan period of up to 10 seconds. It simply does not accept or does not connect, because a timeout of less than 10 seconds is built in and requires 2 receptions for this period.

The requirement of 2 advertising events is observed in Windows and Linux. In Android and according to standard algorithms, one is enough.

The devices with a button advertise much more often when button is pushed. So connection could still work.

Yes. All thermometers with a button and alternative firmware have the ability to enable the "Connect" function. This function shortens the advertising interval by 1..1.6 seconds so that you can connect. The operation time of the function after pressing the button is about 80 seconds.

[Stephan3]

Thanks for your answer. I thought "just make it 30 seconds and tasmota will catch it". Obviously that is not possible.

[pvvx]

Support for the BLE 5.0 standard will become possible when the BT drivers are completely rewritten in Linux. This cannot be done using an external API. The adapters themselves have nothing to do with it.