Tasmota support for Sonoff TH Elite + WTS01 Waterproof Temperature Sensor

[atownsend247]

Quick general question surrounding the Sonoff TH Elite and the WTS01 (Successor to the DS18B20), has anyone managed to get this working with Tasmota yet? I think the answer is likely no, but I'll be following up with a tear down of the new sensor shortly.

I've tried using the various sensor configurations when configuring the Tasmota module including the DS18x20, but to no avail.

Following on from a discussion started on discord, starting this thread with the of idea of getting it working by the end, I'll try my best to diagnose it and resolve it myself but might need some pointers on direction and best approach etc.

Thanks in advance.

[sfromis]

For context, the question of supporting WTS01 was also raised here, without getting to a conclusion. #15856 (comment)

And on Discord, where it got to effectively being an enhancement suggestion.
https://discord.com/channels/479389167382691863/790185752855052288/1143850375108112384

[atownsend247]

So finally had a few minutes to dig into this more, I've dismantled one of the WTS01 probes, There is indeed 3 cables going from the black bulge to the actual probe, digging into the bulge, there is a small circuit board with three in and out cables.

On the board itself are a few resistors/capacitors and a tiny IC can barely make out the laser etched markings but I think its the following
8R03A1 on the first line followed by L53CN1

[sfromis]

Yeah exactly as expected, some tiny MCU in there. Does not matter what MCU it is, as what happens is up to the firmware it is programmed with.

[atownsend247]

So what would be some next steps for me, have basic soldering equipment (no oscilloscope though), would it be hooking it up to a basic esp device and try and get it to read data out into the serial console?

[sfromis]

It is very probably not a UART serial protocol. My guess would be that it might be supportable in a similar way as the Sonoff MS01 soil humidity sensor (and other probes from them), but with some variation in detection and calculation.
This is coded in https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xsns_sensor/xsns_06_dht_v7.ino

If this speculation is correct (I have no firm basis), playing around with how the driver handles the Sonoff one-wire protocol might be a way forward.

[arendst]

What you could have done is running this script:

#!/bin/bash

CPUFREQ=(80 160)
DHTDELAYHIGH=(300 350 400 450 500 550 600 650 700 750)
DHTDELAYLOW=(20 30 40 50 60 70)

for freq in ${CPUFREQ[@]}; do
  echo "CpuFrequency $freq"
  curl "http://192.168.2.163/cm?cmnd=CpuFrequency%20$freq"
  sleep 1
  for high in ${DHTDELAYHIGH[@]}; do
    for low in ${DHTDELAYLOW[@]}; do
      echo "CpuFrequency $freq - DhtDelay $high,$low" | tee -a "DhtDelay.log"
      curl "http://192.168.2.163/cm?cmnd=DhtDelay%20$high%2C$low"
      sleep 12
      curl -s http://192.168.2.163/cs?c2=0 | tail -n 30 | grep -A 900 "DhtDelay1\":\[$high,$low" | tee -a "DhtDelay.log"
    done
  done
done

to find if there is a setting resulting in valid data.

In the past I ran this with below excerpt:

CpuFrequency 80 - DhtDelay 350,60
11:49:25.886 MQT: stat/thr316d/RESULT = {"DhtDelay1":[350,60]}
11:49:26.960 DHT: Pin25 timeout waiting for pulse 0
11:49:30.933 DHT: Pin25 timeout waiting for pulse 0
11:49:34.954 DHT: Pin25 timeout waiting for pulse 0}1
CpuFrequency 80 - DhtDelay 350,70
11:49:38.413 MQT: stat/thr316d/RESULT = {"DhtDelay1":[350,70]}
11:49:38.937 DHT: Pin25 timeout waiting for pulse 0
11:49:42.959 DHT: Pin25 timeout waiting for pulse 0
11:49:46.930 DHT: Pin25 timeout waiting for pulse 0}1
CpuFrequency 80 - DhtDelay 400,20
11:49:50.992 MQT: stat/thr316d/RESULT = {"DhtDelay1":[400,20]}}1
CpuFrequency 80 - DhtDelay 400,30
11:50:03.485 MQT: stat/thr316d/RESULT = {"DhtDelay1":[400,30]}}1
CpuFrequency 80 - DhtDelay 400,40
11:50:15.921 MQT: stat/thr316d/RESULT = {"DhtDelay1":[400,40]}}1
CpuFrequency 80 - DhtDelay 400,50
11:50:28.342 MQT: stat/thr316d/RESULT = {"DhtDelay1":[400,50]}}1
CpuFrequency 80 - DhtDelay 400,60
11:50:40.817 MQT: stat/thr316d/RESULT = {"DhtDelay1":[400,60]}}1
CpuFrequency 80 - DhtDelay 400,70
11:50:53.327 MQT: stat/thr316d/RESULT = {"DhtDelay1":[400,70]}}1
CpuFrequency 80 - DhtDelay 450,20
11:51:05.758 MQT: stat/thr316d/RESULT = {"DhtDelay1":[450,20]}}1
CpuFrequency 80 - DhtDelay 450,30
11:51:18.281 MQT: stat/thr316d/RESULT = {"DhtDelay1":[450,30]}}1
CpuFrequency 80 - DhtDelay 450,40
11:51:30.822 MQT: stat/thr316d/RESULT = {"DhtDelay1":[450,40]}}1
CpuFrequency 80 - DhtDelay 450,50
11:51:43.287 MQT: stat/thr316d/RESULT = {"DhtDelay1":[450,50]}}1
CpuFrequency 80 - DhtDelay 450,60
11:51:55.874 MQT: stat/thr316d/RESULT = {"DhtDelay1":[450,60]}}1
CpuFrequency 80 - DhtDelay 450,70
11:52:08.291 MQT: stat/thr316d/RESULT = {"DhtDelay1":[450,70]}}1
CpuFrequency 80 - DhtDelay 500,20
11:52:20.832 MQT: stat/thr316d/RESULT = {"DhtDelay1":[500,20]}
11:52:22.958 DHT: Pin25 timeout waiting for pulse 0
11:52:26.928 DHT: Pin25 timeout waiting for pulse 0
11:52:30.956 DHT: Pin25 timeout waiting for pulse 0}1
CpuFrequency 80 - DhtDelay 500,30
11:52:33.295 MQT: stat/thr316d/RESULT = {"DhtDelay1":[500,30]}
11:52:34.952 DHT: Pin25 timeout waiting for pulse 0
11:52:38.967 DHT: Pin25 timeout waiting for pulse 0
11:52:42.940 DHT: Pin25 timeout waiting for pulse 0}1

Resulting in a stable output using command DhtDelay 450,20

[atownsend247]

So I tweaked the script a bit which is included below and I've attached the DhtDelay.log for convenience.

#!/bin/bash

CPUFREQ=(80 160)
DHTDELAYHIGH=(300 350 400 450 500 550 600 650 700 750 800 850 900 950 1000)
DHTDELAYLOW=(20 30 40 50 60 70 80 90)
IP_ADDRESS="192.168.68.134"

for freq in ${CPUFREQ[@]}; do
  echo "CpuFrequency $freq"
  echo "http://${IP_ADDRESS}/cm?cmnd=CpuFrequency%20$freq"
  curl "http://${IP_ADDRESS}/cm?cmnd=CpuFrequency%20$freq"
  sleep 1
  for high in ${DHTDELAYHIGH[@]}; do
    for low in ${DHTDELAYLOW[@]}; do
      echo ""
      echo ""
      echo ""
      echo "New Run:"

      echo "CpuFrequency $freq - DhtDelay $high,$low" | tee -a "DhtDelay.log"
      echo "http://${IP_ADDRESS}/cm?cmnd=DhtDelay%20$high%2C$low"
      curl "http://${IP_ADDRESS}/cm?cmnd=DhtDelay%20$high%2C$low"
      sleep 12
      curl -s "http://${IP_ADDRESS}/cs?c2=0" | tail -n 30 | grep -A 900 "DhtDelay1\":\[$high,$low" | grep -v "RSL: STATE" | tee -a "DhtDelay.log"
    done
  done
done

DhtDelay.log

As mentioned on discord and as you was predicted if you connect the sensor straight through without the bulge in the cable, it works just like any other DS18B20 sensor. But doesn't work out of the box :)

[arendst]

Well at least that kept you busy for almost an hour ;-) Pity it didn't work.

[Littlesloths]

Not sure what is the outcome? Is WTS01 working now or do I need to cut out the "Bulge"?
Found some link that worked, but I don't understand what they did...
https://www.letscontrolit.com/forum/viewtopic.php?t=9846

[wayner9]

As a related question - I just bought a TH Elite20 with what is labelled as the DS18B20 Waterproof temperature cable. I want to connect a much longer "regular" water DS18B20 cable. What is the pinout from a regular DS18B20 into the RJ9 port?

[sfromis]

https://templates.blakadder.com/sonoff_THR320D.html

[wayner9]

Excellent, thank you. With Tasmota is it possible to control the dry contact relay independently from the main switch on this device? In eWeLink it only shows one switch to toggle on and off, presumably it toggles the dry contact the same as the main power switch.

Too bad the RJ9 connector isn't connected into the main ESP chip. It would have been nice to be able to flash to Tasmota just using an RJ9 cable.

One more question - is this the right place to be asking questions regarding Tasmota? Or is there another forum or place? It seems like their was a sub-reddit but that appears to have been turned private, presumably due to the reddit changes earlier this year.

[sfromis]

In addition to this Github project (where the Discussions tab is fine for questions), Tasmota also has a Discord server, well-suited for quick questions/answers. Other places not part of the project exist too, but may have "more varied" activity.

And yes, the lower-voltage dry relay appears separately in Tasmota, just like the primary relay with mains power. You'll have to do extra setup if you want then to act in unison.

[wayner9]

Thank you very much for all your help!

[fkroepfl]

Is there any news on whether this request will be implemented and, if so, approximately when this will be the case?

Background: Should I wait and see or look for an alternative solution 😉

[cidoafranio]

I still couldn't read the temperature of the sensor, I only got this result:
FWSW OB38ONE2UART THSENSOR OB38R08A1 v1.0.0

Has anyone managed to read the sensor using the ESP32?

[sfromis]

That image does not show more than there's a MCU in there (looks like you opened the bulge of a WTS01). The issue is what protocol is being used from that MCU to the relay device. For Tasmota to support WTS01, someone will have to work out the details of the communication; an attempt some time ago saw no success.

Simplest current solution is to cut out the bulge and connect the probe directly, to "convert" it from being a WTS01 to instead being DS18B20.

[cidoafranio]

I was able to read the temperature, I need to find a way to filter these results.

(HEX): 0 (DEC): 0
(HEX): 86 (DEC): 134
(HEX): 55 (DEC): 85
(HEX): 1 (DEC): 1
(HEX): 1 (DEC): 1
(HEX): 4 (DEC): 4
(HEX): 1 (DEC): 1
(HEX): 11 (DEC): 17
(HEX): 19 (DEC): 25 <---- degrees Celsius

(HEX): 0 (DEC): 0
(HEX): 86 (DEC): 134
(HEX): 55 (DEC): 85
(HEX): 1 (DEC): 1
(HEX): 1 (DEC): 1
(HEX): 4 (DEC): 4
(HEX): 1 (DEC): 1
(HEX): 11 (DEC): 17
(HEX): 1C (DEC): 28 <---- degrees Celsius

(HEX): 57 (DEC): 87
(HEX): E0 (DEC): 224
(HEX): 55 (DEC): 85
(HEX): 1 (DEC): 1
(HEX): 1 (DEC): 1
(HEX): 4 (DEC): 4
(HEX): 1 (DEC): 1
(HEX): 11 (DEC): 17
(HEX): 1C (DEC): 28 <---- degrees Celsius

(HEX): 5D (DEC): 93
(HEX): E6 (DEC): 230
(HEX): 55 (DEC): 85
(HEX): 1 (DEC): 1
(HEX): 1 (DEC): 1
(HEX): 4 (DEC): 4
(HEX): 1 (DEC): 1
(HEX): 11 (DEC): 17
(HEX): 1D (DEC): 29 <---- degrees Celsius

[sfromis]

Hmmm.... A temperature would usually have at least one decimal. Images of Sonoff TH16 does show temperature that way with WTS01.

[Littlesloths]

is it possible that the firts two bytes are related to the temperature decimals?

[cidoafranio]

This was the maximum it can read from the wts01 sensor so far.
https://github.com/cidoafranio/wts01-sonoff-TH.git

[HectorDRR]

Hi;
Would it be possible to pass your code to read the sensor to Berry language to use directly in the Tasmotized device?
I used an old SonOff TH to control my solar water hot system but suddenly, sensor input fails and now is fixed at 85º.
I've bought a TH Origin 16 to find that after tasmotize it, I don't have access to the T sensor.
With the information you get, only the degrees without decimals, it's ok for me until it can be developed inside Tasmota firmware.
I think if I could get your reads from my sensor through Berry, we could get the information needed to discover how to interpret the rest of information to get the decimals, because my system has a good gradient to test.
But I'm new to berry and to use sensors, but I have some experience working with Python.
I've seen in Berry yo can access GPIOs setting up this as Input in the configuration of Tasmota, and it gives commands to access this GPIO, but I don't known how I can read the information you get of the sensor.
Thanks.

[Littlesloths]

to re-engineer a bit more I guess we need a slow temperature trend over e.g. 10°C with slower than 1 °C/min to see whether the data makes sense as decimal digits...
@cidoafranio, so you think it is possible to provide such a trend?

[cidoafranio]

I did several tests and so far I haven't gotten anything promising, but as soon as I get something I'll share it here.

[HectorDRR]

Hi;
I've made test with the Berry console and get several readings from the sensor. Only have problems to decode the decimal part.

A fixed part of 0x550101040111 and then a byte for the degrees in Celsius, and another two bytes that change
My readings are like this:

bytes('5501010401111851D6')
bytes('5501010401111851D6')
bytes('5501010401111851D6')
bytes('550101040111184BD0')
bytes('550101040111184BD0')
bytes('550101040111184BD0')
bytes('550101040111184BD0')
bytes('5501010401111844C9')
bytes('5501010401111844C9')
bytes('550101040111184BD0')
bytes('550101040111184BD0')

I've played with the last two bytes in several ways, Assuming are a integer, for example in 4BD0, 4B * 256 + D0 / 65536 but the readings show a gap that don't cover totally from 0,0 to 0,9.

I've put another DS18B20 beside the WTS01 and its readings from the SonOFF TH are consistent with the readings from the WTS01 in the degrees.

From the Berry console I use the next code to test:

# Define the GPIO and speed
Sensor = serial(25, -1, 9600)
header = bytes('550101040111')
# After it, I iterate several times this code
entrada = Sensor.read()
print(entrada.size()/9)   #print number of reading
for f:0..(entrada.size()/9-1)
  if entrada[f*9..f*9+5] == header
     print(entrada[f*9+6],entrada[f*9+7]/256.0)
  else
     # In case the reading is not aligned with the header print all readings
     print(entrada[(f*9)..((f+1)*9)-1])
  end
end

[HectorDRR]

Well, after analyse the readings better, the last byte seems a parity check because only change when the another 2 bytes before change. And the byte after the degrees only goes from 0-100 so it seems that show directly the centesimal part of a degree.
With this code:

entrada = Sensor.read()
print(entrada.size()/9)
for f:0..(entrada.size()/9-1)
  if entrada[f*9..f*9+5] == qq
     print(entrada[f*9+6] + entrada[f*9+7]/100.0)
  else
     print(entrada[(f*9)..((f+1)*9)-1])
  end
end

I think the readings are consistent.
Now, I'll try to implement a driver from the Berry console to try to display the value in the web page and in the JSON of telemetry.

[sfromis]

Did you also try with a setup where the temperature varies in a predictable way?

Your bytes above only looks like ambient with slight variations in what the sensor produces.

And if the decoding is reliably working, it would be a candidate for being integrated in Tasmota.

[HectorDRR]

I put both sensors, one beside the other, and get them in my hand to test how they rise its temperatures several degrees above and after that, they go down their readings. And the results in both cases were similar, only some decimals of difference between both.
Some times, the result is not aligned, the header is not at the first bytes read, so I have to implement in the code the alignment of the data before to process it.

[HectorDRR]

Well. I've created this driver in the Berry console that seems is working correctly.
When you issue a status 10 command it answer correctly. It was my main objective to get all the rest of my system, running in node-red, keep working.
I'll let it working several days to test if all is working correctly. I've saved it as autoexec.be and put in the filesystem of the SonOff and I've tested that at restart, it is loaded and get working.
I hope it will be useful for others.
In the configuration, I only put the GPIO 25 as input to be able to manage from the berry console.

#- Lectura de sensor WTS01 desde SonOff TH Origin/Elite
Héctor D. Rguez.

- Ver 0.4, 20240610: Arreglamos la parte de mostrar la información en la página web. Subimos un autoexec.be que lo único que hace es cargar el módulo con un load("WTS01.be") y también cargamos el WTS01.ve de manera que lo separamos del autoexec.
- Ver 0.3, 20240610: Generamos una clase par poder instalar como un driver y que genere el JSON con la información para responder a un status 10
- Ver 0.1, 20240609: Aprendemos como configurar el GPIO 25 como puerto serie para leer los datos que manda el sensor y empezar a descodificarlos
-#

# Inicializamos comunicación serie a través del GPIO 25 sin puerto de envío ya que el sensor no necesita que se le envía nada para el enviar información
class WTS01
    var Sensor
    var Temperatura
    var cabecera
    var ultima

    def init()
        self.Sensor = serial(25, -1, 9600)
        self.cabecera = bytes('550101040111')
        self.ultima = 10
    end
    
    def Leo_Temp()
        # Alineamos la información recibida si la cabecera no es correcta
        # Calculamos el número de lecturas (9 bytes cada lectura)
        # Nos quedamos con los últimos 18 bytes para asegurarnos de coger la última lectura
        var entrada = self.Sensor.read()
        # En caso de que buffer esté vacío, para que no de error, devolvemos 10º
        if entrada.size() < 9 
            return self.ultima
        end
        # Para debug print(entrada.size(), entrada.size() / 9, entrada[0..8])
        entrada = entrada[-18..]
        # En caso de no estar los datos alineados, buscamos la cabecera y realineamos
        if entrada[0..6] != self.cabecera
            for f:0..9
              if entrada[f..f + 1] == bytes('5501')
                 entrada = entrada[f..]
              end
            end
        end
        # Descartamos la cabecera y devolvemos los grados (7º byte) más las centésimas de grado (8º byte)
        self.ultima = entrada[6] + (entrada[7] / 100.0)
        return self.ultima
    end
    
    def every_second()
        # Leemos información
        return self.Leo_Temp()
    end
    
    def web_sensor()
        tasmota.web_send('Temperatura: ' + str(self.Leo_Temp()) + 'º')
    end
    
    def json_append()
        tasmota.response_append(',"WTS01":{"Temperature":' + str(self.Leo_Temp()) + '}')
    end
end
MiWTS01 = WTS01()
tasmota.add_driver(MiWTS01)

[sfromis]

Great. For such a driver to be well-integrated with Tasmota, two things are relevant to add.

First, as you alluded to, the web_send_decimal call should have the format for the value being shown on the Tasmota front page, something like:
tasmota.web_send_decimal(format('{s}WTS01 Temperature{m}%s{e}', self.Leo_Temp()))

Second, adhering to the Tasmota settings for TempRes, TempOffset and SetOption8 (C/F) is good for general usage. Here's an example of a relatively short driver doing that:
https://github.com/TomsTek/tasmota-berry-TMP117-driver/blob/main/tmp117.be

[sfromis]

Oops, saw one thing. I'd recommend that your every_second() store the result in an instance variable, as it does not work returning anything from that function, and then use the instance variable in both web_sensor and json_append, instead of executing the polling code two times more. You already have that instance variable, without using it, Temperatura

[HectorDRR]

Thanks for your advice!

Now the visual result, and the performance, is more professional ;)

#- Lectura de sensor WTS01 desde SonOff TH Origin/Elite
Héctor D. Rguez.

- Ver 0.5, 20240610: Siguiendo consejos de sfromis, tomo de ejemplo el código del driver del TMP117 
    (https://github.com/TomsTek/tasmota-berry-TMP117-driver/blob/main/tmp117.be) para formatear mejor la salida y solo hacer una lectura en el 
    every_second y usar una variable de instancia en el resto.
- Ver 0.4, 20240610: Arreglamos la parte de mostrar la información en la página web. Subimos un autoexec.be que lo único que hace es cargar el 
    módulo con un load("WTS01.be") y también cargamos el WTS01.ve de manera que lo separamos del autoexec.
- Ver 0.3, 20240610: Generamos una clase par poder instalar como un driver y que genere el JSON con la información para responder a un status 10
- Ver 0.1, 20240609: Aprendemos como configurar el GPIO 25 como puerto serie para leer los datos que manda el sensor y empezar a descodificarlos
-#

# Inicializamos comunicación serie a través del GPIO 25 sin puerto de envío ya que el sensor no necesita que se le envía nada para el enviar información

class WTS01: Driver
    static sensor_name = "WTS01"
    static temp_label = "Temperature"
    static cabecera = bytes('550101040111')    # cabecera del mensaje del sensor
    var tempres         # number of decimals from Tasmota settings
    var tempoffset      # temperature offset config, from Tasmota settings
    var temp_format     # function to convert temperature to formatted string
    var Sensor
    var temperature

    def init()
        self.Sensor = serial(25, -1, 9600)
        self.temperature = 10
        print(self.sensor_name.." sensor detectado")
        self.tempres    = 2
        self.tempoffset = 0
        self.create_formatter()
        tasmota.add_rule("TempRes",    /value -> self.create_formatter(value))
        tasmota.add_rule("TempOffset", /value -> self.create_formatter(nil,value))
        tasmota.add_rule("SetOption8", /value -> self.create_formatter())
        tasmota.cmd("Backlog TempRes; TempOffset")
    end
    
    def create_formatter(tempres,tempoffset)
        if tempres    != nil self.tempres    = tempres    end
        if tempoffset != nil self.tempoffset = tempoffset end
        var fahrenheit = tasmota.get_option(8) == 1
        print(self.sensor_name, "TempRes:"..self.tempres, "TempOffset:"..self.tempoffset, "Fahrenheit:"..fahrenheit)
        var tempmask = "%." .. self.tempres .. "f"
        self.temp_format =
            def (temperature, display)
                import string
                return string.format(
                  tempmask .. (display ? " °" .. (fahrenheit ? "F" : "C") : ""),
                  (fahrenheit ? temperature * 1.8 + 32 : temperature) + self.tempoffset)
            end
    end

    def Leo_Temp()
        # Alineamos la información recibida si la cabecera no es correcta
        # Calculamos el número de lecturas (9 bytes cada lectura)
        var entrada = self.Sensor.read()
        # En caso de que buffer esté vacío, para que no de error, devolvemos la última lectura
        if entrada.size() < 9 
            return self.temperature
        end
        # Para debug print(entrada.size(), entrada.size() / 9, entrada[0..8])
        # Nos quedamos con los últimos 18 bytes para asegurarnos de coger la última lectura
        entrada = entrada[-18..]
        # En caso de no estar los datos alineados, buscamos la cabecera y realineamos
        if entrada[0..6] != self.cabecera
            for f:0..9
              if entrada[f..f + 1] == bytes('5501')
                 entrada = entrada[f..]
              end
            end
        end
        # Descartamos la cabecera y devolvemos los grados (7º byte) más las centésimas de grado (8º byte)
        self.temperature = entrada[6] + (entrada[7] / 100.0)
        return self.temperature
    end
    
    def every_second()
        # Leemos información
        self.Leo_Temp()
    end
    
    def web_sensor()
        import string
        var temp_format = self.temp_format
        var msg = string.format("{s}%s %s{m}%s{e}",
            self.sensor_name, self.temp_label, temp_format(self.temperature, true))
        tasmota.web_send_decimal(msg)
    end
    
    def json_append()
        import string
        var temp_format = self.temp_format
        var msg = string.format(',"%s":{"%s":%s}',
            self.sensor_name, self.temp_label, temp_format(self.temperature, false))
        tasmota.response_append(msg)
    end
end
MiWTS01 = WTS01()
tasmota.add_driver(MiWTS01)

[arendst]

Great job done 👍

Now I have to learn both berry AND spanish .....

EDIT: Played with the above code and it works just fine. I see no need to hardcode it in Tasmota. Great example of berry extending Tasmota.

[HectorDRR]

Ok, I'll translate it to English, only have it in Spanish while I was developing ;)

There is any repository where to upload the file to be available to other people?

Or have you thought about, like autoconfig, to put any way to let the people select drivers in .be to be added in a easy way to the firmware?

I've based part of my work, thanks to sfromis, in the work of @TomsTek with the TMP117 driver, so I think there are several driver similar to these that it would be a good idea to have it centralised.

[Jason2866]

@HectorDRR Via Autoconfig would imho the best way to provide. Users don't have to do anything to get it working. You can see how it can be achieved from the Autoconfig of the m5stack core2 https://github.com/tasmota/autoconf/tree/main/raw/esp32/M5Stack_Core2

[HectorDRR]

Thanks for your information. That seems to be just what I was looking for.
I'll have to see with more time how to do it correctly and what files to put in the folder.
I've seen that there is a preinit.be apart from the autoexec.be and I don't know if the driver of the WTS01 is better to put in one or another or it doesn't matter.

[sfromis]

It could be based on the existing https://github.com/tasmota/autoconf/tree/main/raw/esp32/Sonoff_THR316D_with_DS18x20 and adding preinit.be (like the other setup) to load your code, and have the code file included. In general, it is preferable to have such drivers as separate files, instead of directly put into boot files like preinit.be or autoexec.be.

Of course, also adjusting init.bat to set the fitting template, and remove the DS18B20-specific gpio command from there. However, this would then have to be repeated per Sonoff device having that connector, to support WTS01.

Some drivers also reside here https://github.com/arendst/Tasmota/tree/development/tasmota/berry/drivers including the driver for the AXP192 used in the M%Stack autoconf mentioned.

[arendst]

Just for your information with latest dev branch it is now possible to configure only SerBr Rx or SerBr Tx for Serialbridge. With setting command SerialDelimiter 254 the below result will be shown:

12:40:53.094 MQT: tele/thr316d/RESULT = {"SSerialReceived":"550101040111161FA2"}
12:40:54.167 MQT: tele/thr316d/RESULT = {"SSerialReceived":"550101040111161FA2"}
12:40:55.249 MQT: tele/thr316d/RESULT = {"SSerialReceived":"550101040111161FA2"}
12:40:56.320 MQT: tele/thr316d/RESULT = {"SSerialReceived":"550101040111161FA2"}
12:40:57.395 MQT: tele/thr316d/RESULT = {"SSerialReceived":"550101040111161FA2"}
12:40:58.472 MQT: tele/thr316d/RESULT = {"SSerialReceived":"550101040111161FA2"}
12:40:59.550 MQT: tele/thr316d/RESULT = {"SSerialReceived":"550101040111161FA2"}

This resembles your output of your initial berry code ;-)

[cidoafranio]

The code is in fact working normally based on the temperature and tests here on the bench, thank you very much for not having to cut the original wts01 cable anymore.

[HectorDRR]

Thanks to you, that made the first steps to get information from the sensor, and it was the base of all the work I made after that, with the help of @sfromis to get a correct display of the data and to @Jason2866 for the information about Autoconfig to put it in a easy way to users can access to it to configure it.
It has been funny to develop this driver and learn a bit of Berry while I was recovering from a appendectomy... ;)
I hope to end with a few of changes to make it more tolerant to fails before to make the autoconfig.

[arendst]

I don't want to spoil the berry party but since v14.1.0.2 there is a hardcoded solution too:

• Configure GPIO25 as SerBr Rx
• Execute command SSerialMode 3 once

and presto

[HectorDRR]

This is the problem of having good people pending of this project. They are too fast to answer and implement changes that your work has little life... 😅
It was fun while it lasted.
Thanks for your work.

[arendst]

Oh, I didn't mean to offend you.

We both learned something out of it and I'm looking forward to your next berry driver ;-)

[HectorDRR]

No, please, I'm not offended in any way. Maybe my English is not so good to communicate my feelings in a proper way.

It's a pleasure see how fast you work to adapt new features to the firmware.

It was my main goal, that the support of the sensor was implemented in a new firmware release, so it's good news to know that now the work is in progress and it would be soon available to more people in a easy way.

Thanks again for this marvellous firmware and the work to maintain and improve it.

[xkalib3r]

Thank you so much for your work on this! I just got one of these device today and this has been a lifesaver :-)

I know I may be jumping the gun a little here, but is there yet a way to get the humidity readings as well?

[sfromis]

No, with WTS01 there is no "the" humidity, as that sensor is only for temperature. The sensor is waterproof, so it would be bad if humidity could penetrate the metal tube.

[xkalib3r]

Makes total sense! Thanks! Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: sfromis ***@***.***> Sent: Wednesday, June 12, 2024 11:37:31 PM To: arendst/Tasmota ***@***.***> Cc: Dane Walker ***@***.***>; Comment ***@***.***> Subject: Re: [arendst/Tasmota] Tasmota support for Sonoff TH Elite + WTS01 Waterproof Temperature Sensor (Discussion #19373) No, with WTS01 there is no "the" humidity, as that sensor is only for temperature. The sensor is waterproof, so it would be bad if humidity could penetrate the metal tube. — Reply to this email directly, view it on GitHub<#19373 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AZBWSIYFYXSFGUDLQAQTLNLZHC5RXAVCNFSM6AAAAAA34TCZ3GVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TONJWGYZTA>. You are receiving this because you commented.Message ID: ***@***.***>

[wayner9]

Has anyone successfully attached multiple DS18B20 sensors to one of these units. I tried to attach some and best case scenario is that they work for a few days and then stop working. I wanted to attach three of these to a TH Elite to read the temperatures in and around my hot tub. I made my own pigtail RJ9 connector and then connected the DS18B20s to this. At times it would work and I could see all of the temps, but then the sensors would disappear from Tasmota. It seemed super-finicky.

I was also never sure if I needed a 4.7k Ohm resistor or not, but I tried it both ways and still didn't get it to work consistently.

When I use the DS18B20 probe that I bought from Sonoff it works. But that probe is very short, about a half metre, and I want multiple probes.

[croc1234]

Thank you for the good work on adding the WTS01 sensor in v14.1.0.2. Now i am trying to use this sensor in tasmota rules. What would be the WTS01 equivalent for the following rule?

Rule1
ON DS18B20#Temperature<24 DO Power1 ON ENDON

Because the following rule does not work:

Rule1
ON WTS01#Temperature<24 DO Power1 ON ENDON

[sfromis]

To see what you have to work with, read the console to see what sensors appear in the JSON payloads at TelePeriod. When you have something there, you can have rules (or Berry code) acting on that. And do make sure to also have your rule set enabled.

[croc1234]

What i see in the console is: 17:26:27.907 MQT: tele/tasmota_BAAAB8/SENSOR = {"Time":"2024-07-05T17:26:27","WTS01":{"Temperature":50.9},"TempUnit":"C"}

So my assumption was that this should work:

Rule1
ON WTS01#Temperature<24 DO Power1 ON ENDON

Rule1 ON

But the rule does not trigger when the temperature reaches the set point. Probably i misconfigured something?