There is always esphome-configs.io
The site has a new URL https://www.esphome-devices.com/
Yes, very much agreed! Its the only reason I had decided to give these DIY sensors a shot. ESPHome has and will make so many things much easier to integrate into HA.
Did not even know esphome-configs.io existed. Will definitely look into adding this info there. Thanks again for the help. I have seen you around, and I am sure your previous posts have definitely help me out as well!
There are far more knowledgeable people than me on here, but I do what I can
Well, adding to http://esphome-configs.io will take some reading up on exactly how to do it. So, Ill add my working configuration here:
VL53L0X with a D1 Mini
ESPHome YAML:
esphome:
name: Softener
platform: ESP8266
board: d1_mini
wifi:
ssid: "YourWifiSSID"
password: "YourWifiPassword"
manual_ip:
static_ip: 10.0.0.59
gateway: 10.0.0.1
subnet: 255.255.255.0
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Softener Fallback Hotspot"
password: "YourPassword"
captive_portal:
# Enable logging
logger:
# Enable Home Assistant API
api:
password: "YourPassword"
ota:
password: "YourPassword"
i2c:
sda: D2
scl: D1
scan: True
sensor:
- platform: vl53l0x
name: "Water Softener Salt"
update_interval: 10s
address: 0x29
unit_of_measurement: "Inches"
filters:
- multiply: 39.37
as nickrout pointed out, you must use D1 and D2 as those are the SCL and SDA pins (GPIO5 and GPIO4) on the D1 Mini. I did confirm that this works on the production ESPHome and no need to be using the dev version.
Yes this component was in esphome 14.0 release, which is fairly new.
So could we get HA to do what you see in the video in this post?
That would be awesome.
At this moment with current code, no. It’s just possibility which must be programmed “from scratch”(means it’s not just about “movement_direction: enable” option in ESPhome config file).
If the movement direction works though I think we could use the counter component …
This should get us to the next step and a couple automations later we could be there unless I’m misunderstanding something. (Quite possible)
Displaying the info in lovelace may take some more work… haven’t thought about that yet.
Hi.
I use a nodemcu & Arduino IDE to get values from 2 differents VL53L0X sensors with only one I²C Bus (using the Xshut pin and the “vl53l0x_dual” script example by Adafruit). It works great.
I tried to use ESPHome & its awesome integration in hassio to get those 2 sensors values, but was able to get only one value (sensor1), using this code :
sensor:
- platform: vl53l0x
name: "sensor1"
update_interval: 1s
address: 0x29
- platform: vl53l0x
name: "sensor2"
update_interval: 1s
address: 0x29
I understand that the 2nd sensor has to have its own adress.
Does anyone know how to set the address of the 2nd sensor using ESPHome ?
Thanks
Finally, I changed from ESP8266 to ESP32. ESP32 can have 2 I2C bus. With one VL53L0X on each bus, i now have both sensors available & working !
Hello, has anyone managed to get the VL53L1X working as a people counter?
Thanks
I haven’t gotten any hardware and I’m quite a novice at this stuff anyway, but this is promising:
https://community.st.com/s/question/0D50X0000A7VWoMSQW/is-vl53l1x-people-counting-source-code-available
Someone in this thread did it with a wemos D1 mini.
Not sure if this can be dropped into ESP Home, but someone who knows what they’re looking at would likely be able to adapt it.
IMO the implementation is faulty. I just connectd a sensor to an ESP32 Wroover using the default I2C pins which is working with all other I2C devices tested.
After configuring THIS sensor component I see the same result as jcbbas - a rapid endless loop blocking all other components like WIFI. I will check cabling but no matter how wrong cabling was (if it is) it should not hinder ESP32 to start.
Sorry but for me such component (I2C or VL53) is unacceptable and was not tested. It looks I will endup in writing custom drivers for almost every implementation by myself …
… wondering WHO has ever tested/accepted this component before ?
The other I2C device drivers (PCF8574,INA219,…) not able to communicate are well behaving.
while (reg(0x83).get() == 0x00)
yield();
Well done
I am testing a VL53L0x sensor which works well on a nodemcu. I would like to use two in automation. Counting people and controlling the light, but I don’t know how to start. Does anyone have experience with this sensor and code for ESP home?
I’ve got a VL5310x working on a Wemos D1 mini. It’s currently cohabiting with a bh1750 and a BME280 on the same i2c bus.
I compiled on the dev version of ESPHome.
Note that they each have their own address.
Thank you for your reply Peter. I do believe the implementation works if the device is attached and responding correctly but if it fails for any reason (address, cablelength, pullups) i guess the endless loop starts.
I would be interested what happens if you configure an address different from 0x29 ?
I am currently looking at the code to derive a custom driver - maybe i find the problem.
the setup function does not care about a failing communication:
void VL53L0XSensor::setup() {
#if (1)
uint8_t v;
if (!read_byte(0x89, &v)) {
this->mark_failed();
return;
}
reg(0x89) = v | 0x01;
#else
reg(0x89) |= 0x01;
#endif
…
Best regards, Tom
edit:
But as I need the sensor further away of the ESP32 controller I will attach the vl53l0x sensor to a STM8 (simulating 4-20mA with PWM) and attach this as 4-20mA sensor so i can run virtually any length two (maybe three) wire cable.
Do you have experience with this: what is the maximum length of the cable to the sensor that works reliably? Without STM8.
Hi Pepe !
So far i have only used i2c onboard but i think the maximum distance you can reach is mostly dependent on the clock rate (of course also environment, cable type, busvoltage, …). But you can use P82B96T as range extenders (~60ct / piece on Aliexpress) to achieve high bandwidth at long distances. I am also considering this as Plan B but don’t forget the supply voltage drop for the distant parts so maybe regulate the power there as 3.3V won’t reach very far.
IMO 1 to 2 meters won’t be a problem @400kHz anything further may require lowering bandwidth.