patrickcollins12 / esphome-fan-controller

ESPHome Fan Controller
431 stars 49 forks source link

Problems using Dallas sensor #14

Open jazzmonger opened 1 year ago

jazzmonger commented 1 year ago

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.

03BDA0B4-7BF5-4066-91BD-4801E9695485

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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: Screenshot from 2023-02-09 15-57-49

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 commented 1 year ago

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 commented 1 year ago

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 C43012AA-933B-4745-B567-CAB1F6986E2D

jazzmonger commented 1 year ago

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

image

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:

image 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 commented 1 year ago

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 commented 1 year ago

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. 91776A80-52E6-48AF-8622-61464B0F17BA

This is before deployment 974A3F29-455B-4AFA-94E9-3D09267216DD

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.

D124DF14-7A92-465A-9A08-093DE992AB46

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 😳