SDI-12 Logger through HomeAssistant

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)?

Hi @sar1 , any progress on your esp-sdi project? I’m also very interested in the direction you are going.

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

Any idea?

You guys ever find a fix for this? I’m having the same issue where the serial.sensor is not updating after the initial measurement on reboot.

Hey @gargamel any chance you’d be willing to share the scripts you used to get this data and get it into a Maria DB?

I’m still having this problem. I couldn’t solve it.

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

1 Like

What is the address of the sensor?

Thank you for pointing this out, I will add to the OP that changing the address to non-0 is recommended.

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…

Sin título

… 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?

I hope somebody can helpme.

Thanks in advance

Hey Macario

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

        c_ec_s1:
        friendly_name: Calculated EC Sensor 1
        unit_of_measurement: "dS/m"
        value_template: >
        {{ (((80.3) - (0.37) * ((states('sensor.temperature_s1')|float) - 20)) * ((states('sensor.electric_conductivity_s1')|float) / 1000) / 
             ((((2.887e-9 * (states('sensor.vwc_s1')|float ** 3)) -
             (2.080e-5 * (states('sensor.vwc_s1')|float ** 2)) +
             (5.276e-2 * (states('sensor.vwc_s1')|float)) - 43.39) *
             ((2.887e-9 * (states('sensor.vwc_s1')|float ** 3)) -
             (2.080e-5 * (states('sensor.vwc_s1')|float ** 2)) +
             (5.276e-2 * (states('sensor.vwc_s1')|float)) - 43.39)) - 3.125)) | round (3) }}

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.

2 Likes

This is great!!
Actually, I have installed it in mineral soil, so I will study your code, and I will try to adapt to my soil.
Thanks a lot!!!

Thanks for sharing this templated formula, I will have a spin with this and include it in my OP if you don’t mind :wink:

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

/media/soilsensors.csv:

2022-12-27T05:49:51.159981+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T05:50:51.148419+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T05:51:51.138495+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T05:52:51.149646+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T05:53:51.143309+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T05:54:51.136300+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T05:55:51.138448+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T05:56:51.148438+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T05:57:51.141328+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T05:58:51.151250+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T05:59:51.145800+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T06:00:51.144077+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T06:01:51.138745+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T06:02:51.140168+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T06:03:51.138467+00:00 1; 33.2; 24.8; 346; 2.394;
2022-12-27T06:04:51.137762+00:00 1; 33.2; 24.8; 346; 2.394;

Can you post your configuration.yaml and automations.yaml files?

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:

2022-12-28T14:45:01.151296+00:00 1; 34.4; 25.6; 424; 2.746;
2022-12-28T15:00:01.158892+00:00 1; 34.4; 25.6; 424; 2.746;
2022-12-28T15:15:01.152012+00:00 1; 34.4; 25.6; 424; 2.746;
2022-12-28T15:30:01.149769+00:00 1; 34.4; 25.6; 424; 2.746;
2022-12-28T15:45:01.151561+00:00 1; 34.4; 25.6; 424; 2.746;

The real problem is here:

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).

Maybe @Potterstraat and @jiangduo2013 solved this in the past.

I think I found something on this matter in the official Teros 12 Integrator Guide (at page 11):

DDI SERIAL COMMUNICATION

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).