Problems using Dallas sensor

[jazzmonger]

I have this controller working well on my Solar battery heater application. I use it with a Pwm dimmer to control the heating pads and I use a temp sensor from the battery BMS software that is exposed via a homeassistant sensor. It's all detailed in this Solar forum:

https://diysolarforum.com/threads/new-battery-heater-controller-home-assistant-and-esphome.53665/#post-685275

however, I have noticed that there are dropouts of that sensor when home assistant becomes unavailable for any reason which results in the battery either not being heated or being heated too much. So I am trying to add a local Dallas temp probe that I can sandwich between the batteries and have a self contained system running completely in ESPHome on one chip.

The problem is whenever the Pwm dimmer is ON (even at 1%), the Dallas temp sensor throws "Scratch pad checksum invalid!" errors and can't be read.

I'm no stranger to this approach in ESPHome or these sensors. I have several in use in my greenhouse and other areas. I've tried shielding the sensor wires, and even tried every available GPIO for the sensor and even watched the Dallas waveform on my scope when adjusting the pull-up resistor, all to no avail.

using a DHT type sensor isn't an option due to the way the batteries are mounted. It really needs to be a "probe" type sensor.

Any pointers or ideas to solve this are welcome!

[DunklesKaltesNichts]

sensor maybe broken?
the wiring is definitely ok?

these are the most common reasons for this problem in my case.

how long is the cable between esp and dalles? for longer distances 5V works better than 3.3

[patrickcollins12]

Here is where that error is being thrown: https://github.com/esphome/esphome/blob/dev/esphome/components/dallas/dallas_component.cpp#L242

Looks like you can set logging to "very verbose" and get a little more information.

I've not used this sensor, so I can't help further. You could also try asking in the ESPHome Discord #hardware channel?

[jazzmonger]

I just replaced the D1 Mini with an ESP32-S2 and the problem comp,Evelyn went away. I'm almost ready to deploy this heater!

…

On Feb 8, 2023, at 5:45 PM, Patrick Collins ***@***.***> wrote:  Here is where that error is being thrown: https://github.com/esphome/esphome/blob/dev/esphome/components/dallas/dallas_component.cpp#L242 Looks like you can set logging to "very verbose" and get a little more information. I've not used this sensor, so I can't help further. You could also try asking in the ESPHome Discord #hardware channel? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

-- This message may contain confidential and/or privileged information. If you are not the addressee or are not authorized to receive this for the  addressee, you must not use, copy, disclose, or take any action based on  this message or any information herein. If you have received this message  in error, please advise the sender immediately by reply email and delete  this message.

[jazzmonger]

Success!
I have the temp probe in front of a halogen light which is the approximation of the solar battery pad heaters. The PWM waveform out of the EWP32 absolutely SUCKS but this is a known problem w/ PWM and AC dimmers. There's a ton of flicker, but I don't really think that's going to affect something passive like a pad heater.

The adjustments I have are:
kd - 0
ki - 0
kp - 0.3

Here's the temp graph:

what's curious is that the actual avg temp rides below the set temp once it settles. Not that I think that will ultimately matter.

Thoughts?

[patrickcollins12]

Yes the offset is because you need to set ki to some small value, try 0.001. The purpose of ki is to eliminate an offset like that. See the instructions where I outline how ki works.

Also try setting up the deadband to eliminate that oscillation you're seeing.

I'm not aware of PWM being flaky. Have you tried setting the output samples to smooth the output?

What is that graphing component you're using?

[jazzmonger]

The Pwm issue was config related, it literally took me 4 hours to cycle through all the permutations to find the right method/mode/int config for the zero cross gpio. I landed here:

output:
  - platform: ac_dimmer
    id: dimmer
    gate_pin: GPIO18 
    zero_cross_pin: 
      number: GPIO39 
      mode: INPUT_PULLDOWN
    method: leading pulse
    init_with_half_cycle: true    

But now it's finally acting like a true dimmer. I'll give the offset a go. I read about the deadband, I'll implement that tomorrow.

I'm using Plotly for graphing, it really slick. A bit of a steep learning curve at first, and understanding the multiple Y axis', but worth the time investment. You can code filters in real time AND see the results as you type. Great for figuring out how to hard code them in ESPHome!
I built a wicked dashboard for my heavily modified pellet stove I flashed with ESPHome

[jazzmonger]

Im struggling to figure out why I cant get rid of this temp offset:

I've tried ki values all the way up to 50! no change. I got rid of all oscillations by using KD=20. No idea why. but without it all I get is this:

kd = +20
ki = 50
kp = 0.42

I suppose I can just adjust the thermostat 1.2 degrees higher than I want it, but it would be nice to know why...

[patrickcollins12]

That ki is far too large and will cause big oscillations.

Try turning off the kd temporarily.

Set ki to something small like ki: 0.0009

1/ki is the seconds it should attempt to correct an offset. So 0.03 will quickly adjust in 30seconds. 0.0009 will close a small temperature delta in 20 minutes. See a good description here https://blog.opticontrols.com/archives/344

Higher numbers like 0.03 will respond much quicker, but it also will cause a lot of noise and oscillation in the fan speed.

[jazzmonger]

Ok, iI deployed it into the real world. No matter what values I test with, I get about a 3.4 degree difference between Set temp and probe temp. It's fine I just set the climate set temp 4 degrees higher than I want it.

It's a Complex graph, but all the elements are there and it works as expected.

This is before deployment

And this is the actual bms sensor inside the battery, reported by the BMS. I deployed on 2/24 and raised the temp from 55F to 65F. Prior to 2/24, I had wide fluctuations both positive and negative depending on home assistant status (up/down) the Pi running the BMS, Wifi signal loss, etc, etc. Now everything is local within ESPHome and the PID controller.

you can see the on/off plug controlling the temp before 2/24.

I think I need to move the probe to inside one of the batteries. Right now it's sandwiched between the top and second one, so the reading location might not be perfect, but it's pretty good, so overall I'm happy with the result!

This all becomes ultra important in Dec/Jan ⛄️ when the temp drops into the teens and below zero F ❄️. LifePO4 batteries self destruct if you charge the when they are less than 32F. And that's $15,000 worth of batteries I'm now protecting with a $2.00 Chinese ESP32-S2 😳