[13:44:33][D][sensor:104]: 'Waterproof Distance Sensor': Sending state 1.19278 m with 2 decimals of accuracy
[13:44:38][D][ultrasonic.sensor:040]: 'Waterproof Distance Sensor' - Got distance: 1.193 m
[13:44:38][D][sensor:104]: 'Waterproof Distance Sensor': Sending state 1.19278 m with 2 decimals of accuracy
[13:44:43][D][ultrasonic.sensor:040]: 'Waterproof Distance Sensor' - Got distance: 1.182 m
[13:44:43][D][sensor:104]: 'Waterproof Distance Sensor': Sending state 1.18232 m with 2 decimals of accuracy
[13:44:48][D][ultrasonic.sensor:036]: 'Waterproof Distance Sensor' - Distance measurement timed out!
[13:44:48][D][sensor:104]: 'Waterproof Distance Sensor': Sending state nan m with 2 decimals of accuracy
I get a lot of “Distance measurement timed out” nan (not a number) values but I suspect this is ok as the unit sends a lot of pulses in Mode 0. Correct? Applying a filter to average values might help.
A bigger issue is that when an object is close to the side of the sensor (not over it) the reading drops back to minimum of ~24cm therefore can’t work inside a 2 inch pipe at this point.
I’m thinking these issues could be due to the default rate of pulse in Mode 0 (every 100ms) and so I thought to try mode 2 which would send a pulse on demand. I did try this, but nothing come back…
3. Can’t get Mode 2 to work:
Code: (snippet)
[12:28:46][V][jsn_sr04t.sensor:014]: Request read out from sensor
[12:28:49][V][jsn_sr04t.sensor:014]: Request read out from sensor
[12:28:52][V][jsn_sr04t.sensor:014]: Request read out from sensor
I can see the ESP32/ESPHOME sending the request but nothing back. Same GPIO HW layout. Mode 2 jumper is bridged.
Other documentation reports that a voltage divider is recommended to limit voltage of GPIO pins to 3.3v but every reference I find (youtube videos) have not done this.
Any assistance to get this work for my use case (water level measurement in a 2inch PVC pipe) would be appreciated.
I’d add that even with the sensor pointed slightly up with nothing in its direct line of sight as per image, it only reports ~0.25m! This is what I mean by it detects something to the side. Like the detection ‘beam’ is too wide. Do I have a faulty sensor?
I’ve now got it to work in mode 2 however distances reported are not consistent and are all over the shop with many invalid data logs. I’m not even moving it at this point.
[16:05:35][D][sensor:104]: 'Distance': Sending state 0.25100 m with 1 decimals of accuracy
[16:05:55][D][sensor:104]: 'Uptime Sensor': Sending state 183.09000 s with 0 decimals of accuracy
[16:05:56][W][jsn_sr04t.sensor:051]: Invalid data read from sensor: FF.00.F6.F5
…and when I just bump it…lots of errors.
[16:13:05][D][sensor:104]: 'Distance': Sending state 0.25500 m with 1 decimals of accuracy
[16:13:08][D][sensor:104]: 'Distance': Sending state 0.25500 m with 1 decimals of accuracy
[16:13:11][W][jsn_sr04t.sensor:051]: Invalid data read from sensor: FF.00.FA.F9
[16:13:14][D][sensor:104]: 'Distance': Sending state 0.25500 m with 1 decimals of accuracy
[16:13:17][D][sensor:104]: 'Distance': Sending state 0.25500 m with 1 decimals of accuracy
[16:13:20][D][sensor:104]: 'Distance': Sending state 0.25500 m with 1 decimals of accuracy
[16:13:23][W][jsn_sr04t.sensor:051]: Invalid data read from sensor: FF.00.FA.F9
[16:13:26][W][jsn_sr04t.sensor:051]: Invalid data read from sensor: FF.00.FA.F9
[16:13:29][W][jsn_sr04t.sensor:051]: Invalid data read from sensor: FF.00.FA.F9
[16:13:32][D][sensor:104]: 'Distance': Sending state 0.25500 m with 1 decimals of accuracy
[16:13:35][D][sensor:104]: 'Distance': Sending state 1.54200 m with 1 decimals of accuracy
[16:13:38][D][sensor:104]: 'Distance': Sending state 1.52000 m with 1 decimals of accuracy
[16:13:41][D][sensor:104]: 'Distance': Sending state 1.51600 m with 1 decimals of accuracy
[16:13:44][W][jsn_sr04t.sensor:051]: Invalid data read from sensor: FF.00.E1.E0
[16:13:47][W][jsn_sr04t.sensor:051]: Invalid data read from sensor: FF.00.F6.F5
[16:13:50][W][jsn_sr04t.sensor:051]: Invalid data read from sensor: FF.00.F5.F4
[16:13:53][D][sensor:104]: 'Distance': Sending state 1.53500 m with 1 decimals of accuracy
I’ve also applied the voltage divider without any noticeable difference in behaviour.
Sounds like a great project - great notes and sorry you are having trouble with the module - hopefully we can get to the bottom of the issue!
Would it be possible to get a longer log of the outputs?
A missed measurement here and there is normal for any real-world sensor.
I note that one of the YAML files from this video provides some extra filtering, have you had a chance to experiment with it?
Are you able to test with multiple materials? The tape measures used in the videos ought to reflect the audio off them without returning to the sensor, whereas the wood surface will cause some reflections back leading to false, shorter measurements.
For an ESPHome deployment Mode 0 would be the least complexity. The MCU is still in full control of sending the trigger to the module, no automatic measurements should be made (can be verified through the onboard LED).
I’ve attached the log of responses from overnight. I’d suggest the 1.5m measurements are correct as I had it pointing at my ceiling all this time and it has not moved since then.
Please note this is in Mode 2. ESPHOME log output for JSN-SR04T probe.zip (26.4 KB)
The config:
As for filtering, I’ve not tried this yet and this can be next.
Regarding testing multiple materials for the issue of the sensor reporting minimum values as it is approached from the side, the materials used to date are, wood, PVC, flesh (my finger/hand), metal tape measure, cardboard, …
I believe it would be ok to receive the odd spurious value and using filtering/averaging of the many samples can probably result in addressing this. Trying this next.
However, my biggest concern is not being able to measure down a 2inch PVC pipe to the water level. I had intended to mount the sensor in a PVC end cap such as this image…
…however this immediately results in the sensors reporting the minimum 0.25m and/or many errors
[W][jsn_sr04t.sensor:051]: Invalid data read from sensor: FF.00.F2.F1
If the unit needs to be mounted above the pipe to work so be it but I don’t infer that can work at this point.
I appreciate your continued support.
A thought, would a lidar sensor be more directional to produce a better result down a pipe?
Interesting that the tape-measure and PVC reported back those values.
The guide you linked above does make some good arguments for using that method. Do you have some pipe on hand you could do some experiments with?
With mode2 extra ‘smarts’ in the sensor will prevent any extra processing we might be able to do (e.g. looking for the median computed of each edge in the output).
My intuition is telling me that there ought to be a good setup or combination of logic to solve this.
A lidar’s reflection also just as variable off of water, if you added a float to solve that, or use a submerged pressure sensor.
May I ask why you are using the pipe instead of reading directly off the surface of the water?
Liam
Thanks Liam,
Regarding distance measurements with ANY material close (within ~10cm from flush) which always results in a reading of ~25cm, as such I can’t seem to do anything like these images…
…hence my conclusion there must be something wrong with it. ¯_(ツ)_/¯
I do have a 50cm pipe to hand but it’s not working so far. Granted my setup for this needs improving as I’d focussed on ANY consistent distance measurement to date.
I infer you want to revert to Mode 0. Sure, I’ll do that.
As for alternative approaches or sensors, the water being measured is in a Wilson industrial hot water system of about 2m in height. The unit is enclosed, and the top of hot water tank is not accessible. The water temperature is ~90-100 degrees Celsius. The submerged pressure sensors on Core’s website were not rated for this and would not have survived. Hence an approach of using a “sight glass” method.
Having now reverted to Mode 0 and with the sensor held stable about 1m (or so) off the floor by a helping hands…and after adjusting then leaving alone…the sensor consistently reports 24cm which is incorrect.
ESPHOME log output for JSN-SR04T probe mode 0.zip (6.3 KB)
Note if I tilt the sensor slightly further away from the table then it starts to report a much better distance number, i.e. the ~1m but I contend the tilt in the image should not result in a minimum reading. Hence a faulty sensor.
Looking at lidar sensors like TF-Luna Lidar Sensor (8m range) | Buy in Australia | WS-24893 | Core Electronics seem applicable for what I want to do. It has a Field-of-View of 2 degrees.
I have to conclude the ultrasonic sensor I am using has a field of view nearing ~160+ degrees. Assuming this is not a fault condition.
Mark,
I’ve been running a similar (generic,but with a remote Ultrasonic Head) sensor for some time. Unfortunately the battery needs replacing so I cannot give you an example of my readings.
However, I found that the SR04T has a ‘dead zone’ of about 24cm and is severely affected by anything in that zone.
These sensors a very similar to the parking sensors on a car and if you have a car with them you’ll notice that they are triggered by things that are not directly behind the car and even the road if you are approaching a slope.
Somewhere I found a diagram that showed the cone shape of the signal (I seem t recall a 15degree shape) and you could construct a cone from cardboard to test the size/shape of it, but I simply have mounted my sensor in a 25mm conduit fitting in the top of the tank where the Ultrasonic pulses are not confined to a pipe.
There is also a cone on JSN-SR04T Cone by Bolukan - Thingiverse that may help keep the ‘stray’ reflections away if you can adapt it.
So upon implementing the TF Luna Lidar for ESPHOME, I have success! I can consistently receive valid distance measurements down a length of 2inch pipe.
The challenge was that Esphome does not natively support the TF Luna so I had to develop my own external component which took some time. Vibe coding FTW!
Glad to hear the project is up and running! Sounds like it was a bit of a mission to get the components to place nicely with each other. Feel free to drop a link to the code if you’ve got it on GitHub, would love to take a look.
