Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems using Dallas sensor #14

Open
jazzmonger opened this issue Feb 8, 2023 · 9 comments
Open

Problems using Dallas sensor #14

jazzmonger opened this issue Feb 8, 2023 · 9 comments

Comments

@jazzmonger
Copy link

jazzmonger commented Feb 8, 2023

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
Copy link

DunklesKaltesNichts commented Feb 8, 2023

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
Copy link
Owner

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
Copy link
Author

jazzmonger commented Feb 9, 2023 via email

@jazzmonger
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

jazzmonger commented Feb 10, 2023

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

jazzmonger commented Feb 26, 2023

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 😳

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants