The configuration.yaml and automations.yaml file I shared in my starting post do not rely on Liudr’s python script, you might be able to get it to work with his script in Home Assistant, but I didn’t go that route.
The easiest way to get you setup working, is simply to copy the contents of configuration.yaml and automations.yaml and adjust a couple of parameters in those yaml files to make it match to your situation. The parameters to adjust are descried in my starting post as well.
For us to help you a bit better, it’s good to be specific about what is not working for you, if possible with a log output so we can understand what is going on. In your case, are you able to read the raw outputs in Home Assistant? If you go to Developer tools → States, and then scroll through your entities; under which entity is your raw output showing and how is it formatted (what does the entities state look like)?
hey man, unfortunately i havent made any more progress with this.
i have removed everything from the box and went back to the bench and still get the jibberish?, i have tripple checked all the wiring i have looked for stray solder balls or wire strands that could cause an issue and found nothing i even tried a brand new esp32 and still the same.
i have re-checked the acclima sensor using the terminal app on a phone and the sensor reports correctly no jibberish so i think the problem must be in the code, i can only pressume since i first tried this on the bench where everything worked correctly, something has changed on esp-homes side code wise which is causing the issues?.
since i only have very basic coding knowledge im not sure what else to try?.
the only reason i wanted to use an esp32 was because my sensor is in a different room to my pi4 so wanted to send the data wirelessly into home assistant, at this point im ready to admit defeat and just buy a long mini usb to usb a cable and use the method @Potterstraat uses in his first post.
I think I have the same problem with my Teros 12 sensor or config. At reboot the sensor make a new measurement. After that all the data seems to be cached from first measurement.
Looking at Events Log, the automation trigger after hass reboots and sensor reads fresh data:
Serial Sensor changed to 0+21.58+22.3+651
01:37:50
mm_sensor_0 switched off by automation Log all sensors triggered by time pattern
01:37:50
Sensor Address 0 changed to 0 triggered by state of Serial Sensor changed to 0
01:37:50
Serial Sensor changed to 0
01:37:50
Sensor Address 0 changed to 00013 triggered by state of Serial Sensor changed to 00013
01:37:50
Serial Sensor changed to 00013
01:37:50
mm_sensor_0 switched on triggered by automation Log all sensors triggered by time pattern
01:37:50
Log all sensors triggered by time pattern
01:37:50
After that the automations triggers but the sensor state dont change:
mm_sensor_0 switched off triggered by automation Log all sensors triggered by time pattern
01:38:50
mm_sensor_0 switched on triggered by automation Log all sensors triggered by time pattern
01:38:50
Log all sensors triggered by time pattern
01:38:50
I’m guessing it’s because you still have the sensor address set to 0. Per the SDI-12 implementation from the manual:
"Out of the factory, all METER sensors start with SDI-12 address 0 and print out the DDI Serial startup string during the power-up time. This can be interpreted by non-METER SDI-12 sensors as a pseudo-break condition followed by a random series of bits.
The TEROS 11/12 will omit the DDI Serial startup string (sensor identification) when the SDI-12 address is nonzero. Changing the address to a nonzero address is recommended for this reason."
See if this helps. You will have to adjust your configuration and automations yaml files to match the sensor number and measurement command
Hi!!
First of all, thanks a lot for this post. I can irrigate my trees acording the humidity, so now I can save a lot of water.
This works perfectly with humidity and temperature, but I have a question about CE.
I get this kind of data 1+2335.55+16.5+334
In the example in this post, the 4th data (CE) is 1, but I always get values too high (334 as my example, 4xx, even 5xx)
I tried to follow a formula in the page 18 of this document of METERGROUP…
… and my calculations give to me a value under 0
3,879 x 10^-4 x 334 - 0,6956 = -0,5660414
Is this result dS/m??
Do I have -0,5660414 dS/m?
Is it possible/correct to obtain a CE under 0?
Am I doing something wrong?
That formula is for calculating the VWC, the second value in the string of readings. The formula for calculating the EC is much more complicated. This took me like 2 or 3 weeks to figure out, but the following is what I put in my automations.yaml after the electric_conductivity_s1 entry
If relevant, this was the formula for the SOILLESS MEDIA as I am working with coco coir. Regardless, the formula you were trying to use was the wrong one which is probably why you’re getting weird values.
The 334 value that you’re getting from the sensor is correct, it’s just the raw value that hasn’t been applied to any calculations. My formula works for me, it gives me almost the same exact number as if I use the little bluetooth dongle and the Aroya phone app.
See if any of that gets you closer to what you need. I believe the equation from the manual that I followed was
σp = (εp * σ b) / (εb − εσb=0)
But I’m a little rusty on all of it. I just remember it was a lot of work to come up with this.
Hey matthew, thanks for the help. But the problem persists even after change the sensor address.
First measurement:
Serial Sensor changed to 1+15.45+24.8+346
01:37:50
mm_sensor_1 switched off by automation Log all sensors triggered by time pattern
01:37:50
Sensor Address 1 changed to 1 triggered by state of Serial Sensor changed to 1
01:37:50
Serial Sensor changed to 1
01:37:50
Sensor Address 1 changed to 10013 triggered by state of Serial Sensor changed to 10013
01:37:50
Serial Sensor changed to 10013
01:37:50
mm_sensor_1 switched on triggered by automation Log all sensors triggered by time pattern
01:37:50
Log all sensors triggered by time pattern
01:37:50
Next measurements (only trigger automation. Sensor state dont change):
mm_sensor_1 switched off triggered by automation Log all sensors triggered by time pattern
01:38:50
mm_sensor_1 switched on triggered by automation Log all sensors triggered by time pattern
01:38:50
Log all sensors triggered by time pattern
01:38:50
Only had a second to look at this but the first thing that popped out to me is that the recordings from your soilsensors.csv file are in one minute increments, but in your automations.yaml it’s only set to take a measurement once every 15 minutes.
I would comment out the minutes: ‘/15’ line and uncomment the seconds: ‘/50’ line and change the 50 to 30. It’s entirely possible you’re just not waiting long enough between recording intervals to look at your data.
Once you make that change you can click on Developer Options and restart your automations. That will begin making the faster recordings right away.
If that doesn’t work, I’d pull up Liudr’s python script and connect the sdi-12 connector to a computer and take manual measurements to make sure you’re not getting static measurements. I’m a bit pressed for time but if you need to go down that route I can help walk you through that when I get a little more free time.
But start with changing the recording interval, I’m very curious if that’s the root of what you’re experiencing.
The filenotify service is inside of “Log all sensors” automation. So they trigger every time automation triggers, the same automation that take measurements from sensor. Below a sample with 15 min readings:
First measurement after HASS reboots and automation “Log all sensors” triggers:
Serial Sensor changed to 1+15.45+24.8+346
03:35:00
mm_sensor_1 switched off by automation Log all sensors triggered by time pattern
03:35:00
Sensor Address 1 changed to 1 triggered by state of Serial Sensor changed to 1
03:35:00
Serial Sensor changed to 1
03:35:00
Sensor Address 1 changed to 10013 triggered by state of Serial Sensor changed to 10013
03:35:00
Serial Sensor changed to 10013
03:35:00
mm_sensor_1 switched on triggered by automation Log all sensors triggered by time pattern
03:35:00
Log all sensors triggered by time pattern
03:35:00
Next measurements when automation “Log all sensors” triggers:
mm_sensor_1 switched off triggered by automation Log all sensors triggered by time pattern
03:50:00
mm_sensor_1 switched on triggered by automation Log all sensors triggered by time pattern
03:50:00
Log all sensors triggered by time pattern
03:50:00
mm_sensor_1 switched off triggered by automation Log all sensors triggered by time pattern
04:05:00
mm_sensor_1 switched on triggered by automation Log all sensors triggered by time pattern
04:05:00
Log all sensors triggered by time pattern
04:05:00
mm_sensor_1 switched off triggered by automation Log all sensors triggered by time pattern
04:20:00
mm_sensor_1 switched on triggered by automation Log all sensors triggered by time pattern
04:20:00
Log all sensors triggered by time pattern
04:20:00
With Liudr’s python script or another reading method (MeterGroup ZSC, Tera Term, Terminal++, etc) all readings are fine. I think it’s a problem with HASS automation (maybe a lack of config or another detail).
DDI SERIAL TIMING
At power up, the sensor will pull the data line high within 100 ms to indicate that the sensor is taking a reading (Figure 6). When the reading is complete, the sensor begins sending the serial signal out the data line adhering to the format shown in Figure 7. Once the data is transmitted, the sensor goes into SDI-12 communication mode. To get another serial signal, the sensor must be power cycled.
I believe this explains the fact that the sensor just performs a new measurement only when HASS/HAOS is restarted.
I tried to perform some tests by turning the RPi USB power off and on where the SDI12 adapter is connected, but the HAOS terminal is a bit limited for that (no permissions/no sudo).