Hi all,
I have setup an ESP32 with ESPHOME generated binary in order to track bluetooth IDs near my home entrance. I chose the board type nodemcu-32s, and set the bluetooth tracker, as well as 3 other sensors (RCWL for movements, LDR for light, and DHT22 for temperature and humidity). It worked just once and then, nothing is detected anylonger after the first time. I have a few device around working on bluetooth, and I dont understand why the tracker is mute.
Here is the ESPHOME yaml:
esphome:
name: esp32multisensor
platform: ESP32
board: nodemcu-32s
ota:
debug:
logger:
level: debug
wifi:
ssid: "RFHA"
password: "XXXXXX"
manual_ip:
static_ip: 10.0.0.108
subnet: 255.255.255.0
gateway: 10.0.0.138
dns1: 8.8.8.8
dns2: 8.8.4.4
# Enable Home Assistant API
api:
reboot_timeout: 0s
time:
- platform: sntp
id: sntp_time
timezone: Europe/Zurich
# Bluetooth Tracker
esp32_ble_tracker:
scan_interval: 10s
id: BTE_HUB
# Example configuration entry
binary_sensor:
- platform: status
name: "multisensor Status"
# Hard sensors
- platform: gpio
pin: GPIO22
name: "RCWL Sensor"
device_class: motion
filters:
- delayed_on: 100ms
- delayed_off: 30ms
sensor:
- platform: dht
pin: GPIO23
temperature:
name: "Temperature"
humidity:
name: "Humidity"
update_interval: 90s
model: AM2302
- platform: adc
update_interval: 60s
pin: GPIO32
name: "Illuminance"
unit_of_measurement: lx
filters:
- lambda: |-
return 1400 - ( (x / 10000.0) * 14000000.0 );
``````````````````````````````````
Does anyone have a positive experience on the ESP32 as a BTE tracker? Did I make any obvious mistake in the yaml script?
Thanks in advance,
Felix
From what I understood from the docs this is the expected behaviour. You use the esp32_ble_tracker to scan for devices and then you use the ble_presence to detect if the device is there or away. Also note that the scan time is 300s (5 minutes).
Try it without the scan_interval. I am using it on my āMi_Flora Serverā and it works nicely without the scan_interval in there.
EDIT: it looks like 300s is the default scan_interval if nothing is specified so I guess for your application having it set to 10s is required, maybe you would even want it set lower
Thank you all for your involvementā¦
The intent pursued is that I clearly want to make a system capable to report to HA the list of BTE Mac addresses round the door. This is possible in pure coding (see https://youtu.be/KNoFdKgvskU) , I thought the ESPHOME enabled the same such as what we have with remote_receiver/dump_all function for RF signals. If not, it means maybe the ESPHOME isnāt the right tool for doing this.
@Clyra, totally right, the example in esphome site show that, following the listening command, ble_presence gives the status of the mac addresses in target.
But even this is not working for me, I dont get any binary sensor status backward that says āyour mac ID is thereā, hence I removed the code from the yaml, and was looking to get in the debug log the sniffed mac addresses aroundā¦ but nothing comes.
It might pay to pursue ESPhome. Here are a few lines from the logs of my ESP32 which is scanning for BLE devices:
[15:52:34][D][esp32_ble_tracker:470]: Found device 41:31:49:B2:1C:F4 RSSI=-90
[15:52:34][D][esp32_ble_tracker:491]: Address Type: RANDOM
[15:52:34][D][esp32_ble_tracker:470]: Found device 5D:14:B0:71:56:4B RSSI=-90
[15:52:34][D][esp32_ble_tracker:491]: Address Type: RANDOM
[15:52:36][D][esp32_ble_tracker:470]: Found device 73:AA:9F:9E:CF:9F RSSI=-91
[15:52:36][D][esp32_ble_tracker:491]: Address Type: RANDOM
[15:52:37][D][esp32_ble_tracker:470]: Found device 6D:E4:80:4D:CD:F4 RSSI=-84
[15:52:37][D][esp32_ble_tracker:491]: Address Type: RANDOM
[15:52:40][D][esp32_ble_tracker:470]: Found device 76:9D:28:5F:A6:0D RSSI=-71
[15:52:40][D][esp32_ble_tracker:491]: Address Type: RANDOM
[15:52:42][D][esp32_ble_tracker:470]: Found device 44:04:84:26:04:DA RSSI=-78
[15:52:42][D][esp32_ble_tracker:491]: Address Type: RANDOM
[15:52:43][D][esp32_ble_tracker:470]: Found device 70:E3:0A:55:66:32 RSSI=-71
[15:52:43][D][esp32_ble_tracker:491]: Address Type: RANDOM
[15:52:47][D][esp32_ble_tracker:470]: Found device 90:CD:B6:5A:63:AE RSSI=-94
[15:52:47][D][esp32_ble_tracker:491]: Address Type: PUBLIC
So you can see that it does pick them up. Since Iām not using it for detecting devices, only to receive data from Mi Flora plant sensors, I donāt do anything with the MAC address/device detection.
Thatās the closest from what I want to do, but based on a shell command line script. I think I will go this way, after investigating why my ESP32 doesnt provide the debug logs as Dave gets.
Thanks again for your help, Nick.
Felix
I use BLE keychain tags to detect presence, but my tool of choice is OpenMQTTGateway (OMG!). I think that 10s is a too small scan time. Try with a 30s or 1m scan time. Be aware that ESP32 has a design problem because it uses the same antena/radio (not sure about the details) to both BLE and wifi so it can do only one of those at a given time. It works but sometimes the results are not so good as my old esp8266 with external ble module.
The documentation said:
If you donāt see these messages, your device is unfortunately currently not supported.
I had the same problem fixed with platform: esp32, board:nodemcu-32s
MArco
As you wonāt show us your logs, how do you expect help?
If your esp32 with esp32_ble_tracker: isnāt doing ble scans your esp32 is broken, or your setup is wrong, or you arenāt reading the logs properly. PS 10s may be too frequent, as the scan takes a while.
And no, that thread was not the one I meant, but if I see it again I will post.
I think you are right Nick, thereās a problem with the ESP32 I am using. It is a DOIT V1 Devkits, and I dont get the esp_ble_tracker data. I turned it up and down, with different board type definitions, and data still doesnt come in the logs. Someone suggested me to hold the button ābootā pressed when starting the flash, I still have to try that.
Having to hold the boot button when starting the flash is only required if it wont flash at all. I had that issue the first time I flashed my ESP32 but never used it since on the same device (ie: to flash OTA). If you are getting a successful flash I donāt see that button fixing anything. Happy to be proven wrong though