"is the public side of my driveway clear" device?

Didn’t read the whole thing, but would a sign of “Do not block emergency exit”, or something like that, hanging on the gate, work for you?

People might not care about your driveway, but maybe we reword a bit, and frame it as an “emergency exit”, then it would be enough to make some difference?

Because it is indeed a concern: when a fire or something happens, and then the fire engine or ambulance would want to come in, and then somebody’s car is blocking the entrance… these kinds of little delays could be live or death, right?

That is a really good point about firefighters / ambulances, etc.

In general, I’d say they could still get to my house without using the driveway. Perhaps driveway is not even the correct word for what I have? It’s not like some cool “private road” sort of driveway like I’ve seen in the US, where you actually drive up to somebody’s house. It is just a couple of meters. Sorry for the confusion, if driveway wasn’t the right term here.

This is what it looks like

(“My Street” isn’t private property; it’s the public road)

I can only guess (and hope!!) that, if there was a fire or other kind of emergency, they’d be able to reach the house just fine, even if some genius decides to park in front of the gate.

Would it be possible to just extend that white pattern painted in the road? If you’re in the Northern hemisphere, days are getting longer right now. You might find a quiet time early in the morning when you could finish the job before anyone noticed. Ask for forgiveness later.

And yes, that’s a driveway. It looks about the same size as mine. We don’t all live in mansions at the end of long driveways here in the US.

1 Like

I love the idea. But don’t dare to. I have reported people parking there often enough for the city to pick me as suspect number 1 if this happened.

Haha, sorry, I know. Didn’t mean it like that. I thought that there was perhaps another word for this kind of driveway (the word sounds so fancy to me, like, when I hear it, I think of these mansion-type driveways). The only times I drove / parked myself in such a driveway in the US, the person whose car / driveway it was always just called it “the spot”.

As we currently consider moving in the somewhat foreseeable future, I’ll use the ToF once they arrive, and block my own driveway until then. If the move will become a thing, I’ll try real hard to just not let me bother this until we’re gone. If we stay, I’ll definitely keep the line-extension idea in mind. Perhaps I need to be at city hall in person some day and some unknown third party will take care of that while I am there, so it couldn’t have been me… who knows :wink:

Good luck whichever way things go! It’s been fun working out solutions, anyway.

It’s funny how different words can have different connotations, even if they mean the same thing. Nobody at my “boat club” would consider calling it a “yacht club.” It’s true that a yacht is just any privately-owned boat, but for some reason it sounds too “fancy” for us.

I’m sure driveway has the same connotation somewhere. But where I live it’s just any place you can drive off the street to park to access your house.

1 Like

I received the VL53L0X recently and tried a test ESPHome.

Below is the code and how a wired things, plus a (bad) photo.

At first, I had only connect VL53L0x1 and everything worked (without id, address, and enable_pin). According to the docs, I needed to add address and enable_pin when using more than one of those sensors, which I did.

VL53L0x2 will always time out:

[08:48:44][I][app:029]: Running through setup()...
[08:48:44][I][i2c.arduino:183]: Performing I2C bus recovery
[08:48:44][D][vl53l0x:034]: 'VL53L0x1' - setup BEGIN
[08:48:44][D][vl53l0x:258]: 'VL53L0x1' - setup END
[08:48:44][D][vl53l0x:034]: 'VL53L0x2' - setup BEGIN
[08:48:44][E][vl53l0x:092]: 'VL53L0x2' - setup timeout
[08:48:44][E][component:113]: Component vl53l0x.sensor was marked as failed.

In Home Assistant, it looks like this

Since I ordered 4 of these, anyway, I just replaced the original one that I here refer to as VL53L0x2 with a new sensor as to assure that the sensor itself wasn’t damaged or I badly soldered it. But this error occurs with the new sensor as well as the old.

As you can see in the code below, I have timeout: 200us and update_interval: 500ms; I thought this might be too quick to handle, but even with update_interval: 30s and completely removing timeout, only the first sensor will work.

I have always run into issues with GPIOs on ESP32 and ESP8266, so I changed VL02 XSHUT to GPIO 23, GPIO 21 and GPIO 34, just to test random other GPIOs (in case that GPIO 17 was perhaps a special PIN that simply wouldn’t work with this) - but that didn’t change anything.

I’d like / need to connect all four sensors to this board ideally. Of course, I could use multiple ESPs, but I believe this should all work with one board, right?

What do you think causes this error / timeout here?


(bb is breadboard; I used the +- on one side for 5V and GND, and the one on the other side for SDA and SCL; those +- panes are not physically connected, so they cannot short each others)

SOURCE PIN DEST. PIN
ESP32
ESP32 V5 5V bb
ESP32 GND GND bb
ESP32 21 i²c bb SDA
ESP32 22 i²c bb SCL
VL53L0x1
VL01 VIN 5V bb
VL01 GND GND bb
VL01 SCL bb SCL
VL01 SDA bb SDA
VL01 XSHUT ESP32 19
VL53L0x2
VL02 VIN 5V bb
VL02 GND GND bb
VL02 SCL bb SCL
VL02 SDA bb SDA
VL02 XSHUT ESP32 17
substitutions:
# Angleichen
  api_reboot_timeout: 2min
  esp_board: nodemcu-32s
  esp_frame: arduino
  esphome_friendly: "Test/ESP32/Einfahrtstor"
  esphome_name: "einfahrtstor"
  loglevel: DEBUG # NONE / ERROR / WARN / INFO / DEBUG (Default) / VERBOSE / VERY_VERBOSE
  pw_accesspoint: "verysecure"
  pw_encryption_key: "muchsafe"
  wifi_address: 10.0.20.157
  #wifi_address: "${esphome_name}.${wifi_domain}"
  #wifi_domain: "van"
  wifi_power: NONE # NONE (ESP8266) / LIGHT (default ESP32) / HIGH
  wifi_reboot_timeout: 2min
# Secrets
  loc_elevation: !secret loc_elevation
  loc_latitude: !secret loc_latitude
  loc_longitude: !secret loc_longitude
  loc_radius: !secret loc_radius
  mqtt_broker: !secret mqtt_broker
  mqtt_password: !secret mqtt_password
  mqtt_port: !secret mqtt_port
  mqtt_username: !secret mqtt_username
  srv_internal: "true"
  srv_pass: !secret srv_pass
  srv_port: !secret srv_port
  srv_user: !secret srv_user
  wifi_backup_password: !secret wi_pass_1
  wifi_backup_ssid: !secret wi_ssid_1
  wifi_password: !secret wi_pass
  wifi_ssid: !secret wi_ssid
#--------------------------------------------------------------------#
#                              DEFAULTS                              #
#--------------------------------------------------------------------#
# ----------------------- entweder / oder ----------------------------
#
# esp8266:
#   board: $esp_board
esp32:
 board: $esp_board

bluetooth_proxy:
  active: true
esp32_ble_tracker:
# --------------------------------------------------------------------
esphome:
  name: $esphome_name
  friendly_name: $esphome_friendly


logger:
  level: $loglevel

api:
  encryption:
    key: $pw_encryption_key
  reboot_timeout: $api_reboot_timeout

ota:
  password: $pw_ota

wifi:
  networks:
    - ssid: $wifi_ssid
      password: $wifi_password
    - ssid: $wifi_backup_ssid
      password: $wifi_backup_password
  reboot_timeout: $wifi_reboot_timeout
  use_address: $wifi_address
  ap:
    password: $pw_accesspoint
    ssid: "${esphome_name} Hotspot"
captive_portal:

web_server:
  port: $srv_port
  auth:
    username: $srv_user
    password: $srv_pass
  include_internal: $srv_internal
  version: 2
#--------------------------------------------------------------------#
switch:
  - platform: restart
    name: "${esphome_friendly} Restart (Normal)"
  - platform: safe_mode
    name: "${esphome_friendly} Restart (Safe Mode)"
# -------------------------------------------------------------------
sensor:
  - platform: vl53l0x
    name: "VL53L0x1"
    id: distance1
    address: 0x41
    enable_pin: 19
    long_range: true
    timeout: 200us
    update_interval: 500ms
    unit_of_measurement: "m"
  - platform: vl53l0x
    name: "VL53L0x2"
    id: distance2
    address: 0x42
    enable_pin: 17
    long_range: true
    timeout: 200us
    update_interval: 500ms
    unit_of_measurement: "m"

i2c:
  sda: 21
  scl: 22
  scan: true
  id: myi2c

Interesting thread…

Multiple i2c devices need different addresses. This from Arduino Code | Adafruit VL53L0X Time of Flight Micro-LIDAR Distance Sensor Breakout | Adafruit Learning System

“The VL53L0X has a default I2C address of 0x29!

You can change it, but only in software. That means you have to wire the SHUTDOWN pin and hold all but one sensor in reset while you reconfigure one sensor at a time”

Good luck.

Read further down the same link.

l# Connecting Multiple Sensors

I2C only allows one address-per-device so you have to make sure each I2C device has a unique address. The default address for the VL53L0X is 0x29but you can change this in software.

To set the new address you can do it one of two ways. During initialization, instead of calling lox.begin(), call lox.begin(0x30) to set the address to 0x30. Or you can, later, call lox.setAddress(0x30) at any time.

The good news is its easy to change, the annoying part is each other sensor has to be in shutdown. You can shutdown each sensor by wiring up to the XSHUT pin to a microcontroller pin. Then perform something like this pseudo-code:

  1. Reset all sensors by setting all of their XSHUT pins low for delay(10), then set all XSHUT high to bring out of reset
  2. Keep sensor #1 awake by keeping XSHUT pin high
  3. Put all other sensors into shutdown by pulling XSHUT pins low
  4. Initialize sensor #1 with lox.begin(new_i2c_address) Pick any number but 0x29 and it must be under 0x7F. Going with 0x30 to 0x3F is probably OK.
  5. Keep sensor #1 awake, and now bring sensor #2 out of reset by setting its XSHUT pin high.
  6. Initialize sensor #2 with lox.begin(new_i2c_address) Pick any number but 0x29 and whatever you set the first sensor to
  7. Repeat for each sensor, turning each one on, setting a unique address.

Note you must do this every time you turn on the power, the addresses are not permanent!“

Thank you @steve_jo

Do you know how to do this in ESPHome, though? There it only states

Muliple VL53L0X sensors on same i2c bus

Example configuration entry

sensor:

  • platform: vl53l0x
    name: “distance1”
    id: distance1
    address: 0x41
    enable_pin: GPIO16
    timeout: 200us
    update_interval: 500ms
    unit_of_measurement: “m”

  • platform: vl53l0x
    name: “distance2”
    id: distance2
    address: 0x42
    enable_pin: GPIO17
    timeout: 200us
    update_interval: 500ms
    unit_of_measurement: “m”

and

address (Optional, int): Manually specify the i2c address of the sensor. Defaults to 0x29. If an address other the 0x29 is specified, the sensor will be dynamically re-addressed at startup. A dynamic re-address of sensor requires the enable_pin configuration variable to be assigned. If more then one VL53L0X sensor is used on the same i2c bus, a unique address must be specified per sensor.

I assumed that, when you use enable_pin, ESPHome would take care of changing the address on its own. Is this incorrect? Or is this a wiring issue, and if I were to change the wiring, this would actually work?

You need to change the address on the actual sensor itself

How does this work when

Note you must do this every time you turn on the power, the addresses are not permanent!“

Let’s say I change the address on the sensor via the example code on an arduino; then I disconnect it (thus powering it off) and connect it to ESPHome… when I power the ESPHome, wont the changed non-permanent address change right back to the original value?

The esp doc you quoted certainly makes it sound like it handles the addresses.

I don’t know about esp but it would make it easier to confirm wiring if both your tof devices were the same way up. Then I would be double checking that the xshut wires are connected to the pins you think they are on the esp device.

Maybe post your sensor.YAML for the vl053 devices?

1 Like

Sure. I had it in my earlier posting as well, but a bit hidden (all the way at the bottom).

This is the relevant part

sensor:
  - platform: vl53l0x
    name: "VL53L0x1"
    id: distance1
    address: 0x41
    enable_pin: 19
    long_range: true
    timeout: 200us
    update_interval: 500ms
    unit_of_measurement: "m"
  - platform: vl53l0x
    name: "VL53L0x2"
    id: distance2
    address: 0x42
    enable_pin: 17
    long_range: true
    timeout: 200us
    update_interval: 500ms
    unit_of_measurement: "m"

i2c:
  sda: 21
  scl: 22
  scan: true
  id: myi2c

I understand it this way: default is 0x29; each sensor that gets an enable_pin automatically gets assigned the address specified for it. And this must have worked for VL530x1, because it does display the correct value (or so I hope; at least it shows different values when moving the sensor closer/further). So it must have either been assigned address 0x41, or it must have ignored address: 0x41 and still communicated with it via 0x29 (which is a possibility, but I really doubt it).

So then the second sensor should work just the same, as it is configured identically to the first, only changing address and enable_pin.

Last resort would be using an arduino for the TOF sensors that communicates the read values to the ESPHome device, which then forwards them to Home Assistant. However, while it’s been on my list to learn how to do this (arduino to esphome) for a while, I’d like to avoid it for this project, if possible.

Update

Now I re-wired it, sorry, the photo is still bad. Wires make it hard to see the connections…

The output I get is now this

[11:31:22][I][app:029]: Running through setup()...
[11:31:22][I][i2c.arduino:183]: Performing I2C bus recovery
[11:31:22][D][vl53l0x:034]: 'VL53L0x1' - setup BEGIN
[11:31:23][D][vl53l0x:258]: 'VL53L0x1' - setup END
[11:31:23][D][vl53l0x:034]: 'VL53L0x2' - setup BEGIN
[11:31:23][D][vl53l0x:258]: 'VL53L0x2' - setup END
[11:31:23][C][esp32_ble:027]: Setting up BLE...
ERROR Serial port closed!

So the device seems to set up the second sensors without error this time (before, it broke after trying to set it up, see output from previous post); now the setup works, but as soon as BLE starts, it closes the serial port so I cannot debug any further.

Both sensors are visibile in Home Assistant now. However, #1 keeps toggling between some value and unknown, #2 is at around 1.6m (which ought to be right, guessing the distance between my desk and ceiling). The first sensor jumps between unknown and 0.27 - 0.28m, which cannot be right as they both point at the ceiling.

I switched to my active USB hub for powering the device (perhaps the PCs USB port was too weak), but now I don’t have serial debugging any longer. Also, without changing any wiring except the USB connection, now it won’t connect via wifi, so I cannot debug at all. This is weird!

I have now

  • used a USB power supply from mains instead of my PCs USB
  • changed the relevant lines to the code below
  • removed Bluetooth and Bluetooth Proxy from ESPHome

The sensors “work”, however, as you can see in the attached video, the measurements are inconsistent. 1.53 meters is the value I assume to be correct when the breadboard is on my desk and measures distance to the ceiling. However, only sensor 1 measures this. Sensor 2 stays at unknown most of the time. When I move my hand / sheet of paper above the sensors, I get these lower readings.

Demo Video (imgur)

However, while sensor 1 keeps updating frequently, sensor 2 hardly does at all.

I have moved one of the sensors once more so that they are not right next to each other; I thought, perhaps they interfere with each other. But the video above was taken after doing so, so now they should not be interfering…

Is there anything else I can do? I had different update_interval values (less than a second, 1s, 5s), but that didn’t make a difference.

sensor:
  - platform: vl53l0x
    name: "VL53L0x1"
    id: distance1
    address: 0x41
    enable_pin: 19
    long_range: true
    timeout: 1000us
    update_interval: 1s
    unit_of_measurement: "m"
  - platform: vl53l0x
    name: "VL53L0x2"
    id: distance2
    address: 0x42
    enable_pin: 17
    long_range: true
    timeout: 1000us
    update_interval: 1s
    unit_of_measurement: "m"

How frustrating!
However it’s ‘working’ sometimes so probably not software. I have no experience of ESP 32 but my understanding is it is a 3.3v device. What voltage are you powering the ToF sensors with 3.3v or 5v?

If 3.3v then presumably from the regulator on the esp board - can it supply enough power (no idea about the specs of it or the sensors)?

If 5v then maybe could be a level issue between 5v and 3.3v? It’s just a guess. But if you are using 5v then trying 3.3v power to the sensors is easy.

Did you test each of the sensor individually (without the “complexity” of having multiple sensors on one bus)? When you have them report differently then it looks like you got defect/inaccurate sensors. :put_litter_in_its_place:

It’s some time I played with the vl53l0x’s, but I remember when the function of having more than one on a bus in esphome (in the beginning the esphome component only supported 1 ToF at a time) I tested it out and it worked a treat with two of the same breakout boards you have.
The only “weird” (or new) thing was this xshut - but it was exactly like in the docs and worked right away without (manually) changing the i2c addresses of the vl53l0x’s. :arrows_counterclockwise:

Also I got like 4 breakout boards and when I tested them their measurements were all in par. :thinking:

You shouldn’t need to do this. Hopefully you get it working without having to mess around too much but if you did need to get the ESP to set the addresses on each power-up, you could just create a small automation in the ESP using the on_boot: trigger and then performing the address setting using the enable pins etc.

is it picking up the wires in front of the sensor?

This may help. From Pololu:
“Under favorable conditions, such as low ambient light with a high-reflectivity target, the sensor can report distances up to 2m, or with the VL53L1X, 4m.”

I use one vl53l10x to detect if I forgot to set out my trash bin. 2M is “iffy”, but 1M or less is quite reliable.