Fan set to "on at max only"


 
Bryan, I am confused as to where we are at with this situation. You seem to indicate that you had experienced the issue but then retracted that and said you were mistaken. I know Todd and I are having the exact same issue, and I have verified the behavior multiple times with my HM. I flashed the snapshot linkmeter firmware without the "keep settings" option and still have the issue.
I am wondering if there is anything else I can do to help identify the possible cause of this issue, or at very least something more that I can do in attempt to get my HM back to working how it is supposed to? Do you think a "RESET" would provide a remedy that a firmware flash without keeping settings did not? Should I try a fresh build? I'm not particularly eager to go through the rebuild and setup of my HM additional times unless I have an expectation that it may actually remedy the issue.
 
Yeah I was wrong about being able to duplicate the issue. Can you copy paste the configuration url text from your config page here? I'm wondering if there's some part of the EEPROM config that's causing this behavior.
GPfcdPQ.png
 
Yeah I was wrong about being able to duplicate the issue. Can you copy paste the configuration url text from your config page here? I'm wondering if there's some part of the EEPROM config that's causing this behavior.

I clicked the Full Config URL and posted the data from that page, thought it was the same in a more readable format? At any rate, here it is.

al=-40,-200,-40,-175,-40,-200,-40,-200 &fn=0,10,70,210,16,100,50 &lb=30,255,13,10,12 &ld=100,30 &pc0=2.4723753e-04,2.3402251e-04,1.3879768e-07,5,3 &pc1=7.0798257e-04,2.1983532e-04,9.3692565e-08,10000,1 &pc2=7.0798257e-04,2.1983532e-04,9.3692565e-08,10000,1 &pc3=7.0798257e-04,2.1983532e-04,9.3692565e-08,10000,1 &pidd=13.30000019 &pidi=0.006 &pidp=3 &pn0=PIT &pn1=TWKS &pn2=TWKS &pn3=TWKS &po=0,0,0,0 &sp=250

If for some reason I need to provide it in a screen capture format just let me know.
 
Looking at the Fn entry (fan) I can make sense of all the numbers except the 16.

fn=0,10,70,210,16,100,50

Min,Max,SPDL,SPDH,?16?,StartupMax,OnAbove

Where does the 16 come from?
 
16 is the flags, like voltage vs pulse mode, invert, on/off only. I've tried entering all your settings into my device and we'll do a test tonight.

You can try resetting the HeaterMeter config completely (not the OpenWrt config) by going to System -> Startup and stopping "lucid". The website should stop working at this point. Then go to the HeaterMeter buttons and do the "Reset Config" there, wait 2 seconds then reboot the whole thing and see if it works.
 
Last edited:
OK, did the above mentioned reset procedure. I was surprised that my WiFi connection and custom home page settings remained afterward, though I am not complaining!

The good news is the damn thing is working properly now! YAHOO!

IDK what was going on but that fixed it, THANKS for your support Bryan.
 
On another note, I was just calibrating a RD3 for the first time since the new servo motion/rest behavior has been implemented and spotted something that may be confusing for a HM newbie, or someone used to the old behavior. After I made small changes in the SPD numbers to tweak the dampers 0% and 100% positions and hit SAVE I noticed the servo did not move to the new position (at least right away). I had to manually step the HM away from and back to the 0% and 100% value to see the new position(s). Would it be difficult to make the servo activate and move into position when settings are saved to make calibration easier?
 
Well I don't know what setting was stuck causing it to not use the after-startup-max, but it clearly is some cruft in EEPROM that isn't exposed in the config interface? This is the code that checks to take it from STARTUP mode to NORMAL. Maybe some interaction with lid mode?
Code:
if ((pitTemp >= _setPoint) &&
      (_lidOpenDuration - LidOpenResumeCountdown > LIDOPEN_MIN_AUTORESUME))

With the servo it would be a good idea to move it immediately if the config changes. I'm not sure how easy that is to implement. You just have to wait the up to 10 seconds for it to move if the move is small enough that it is held off though, you don't have to monkey with the manual output.
 
I think in tweaking the SPD settings the moves may be small enough to be ignored, I'm pretty sure I waited the 10 seconds for it to move but didn't actually count it off or anything. At any rate, not a big deal really, it was just a bit easier to calibrate the servo when it snapped into position right away when you hit save.
 
Well I don't know what setting was stuck causing it to not use the after-startup-max, but it clearly is some cruft in EEPROM that isn't exposed in the config interface? This is the code that checks to take it from STARTUP mode to NORMAL. Maybe some interaction with lid mode?
Code:
if ((pitTemp >= _setPoint) &&
      (_lidOpenDuration - LidOpenResumeCountdown > LIDOPEN_MIN_AUTORESUME))

Now that you mention Lid Mode maybe that had something to do with me having an issue with the update. I know I had lid mode set kinda odd to basically disable it for a high heat cook when I upgraded. I can't recall if I had set the timer really short, or had set the percentage really high though....

Speaking of lid mode, I find it a hindrance during high heat cooking, is there a proper way to disable it? If I set it to activate for 0 Seconds and save it comes back at 30 Seconds. If I set it to activate at 100% below the setpoint it seems to save, can't recall if this effectively eliminates lid mode detection or not? Come to think of it, that may be how I had it set when I did the upgrade... Do you think that would cause the issue I was having?

At any rate, it would be nice to have a way to turn off lid mode detection that isn't going to freak out the HM...
 
Yeah it won't hold off a change indefinitely, it can take up 10 to seconds to commit the change (unless there's no movement needed). I know that works because I specifically tested it, and then tested it again as I built my new RD3.

That said, the next snapshot should force a servo commit on the next update after changing the servo min/max (1s max).
 
more success

16 is the flags, like voltage vs pulse mode, invert, on/off only. I've tried entering all your settings into my device and we'll do a test tonight.

You can try resetting the HeaterMeter config completely (not the OpenWrt config) by going to System -> Startup and stopping "lucid". The website should stop working at this point. Then go to the HeaterMeter buttons and do the "Reset Config" there, wait 2 seconds then reboot the whole thing and see if it works.

I did this and things seem to be working for me as well. The process seemed to muck up the network connection for a bit but everything eventually came online. At first, the blower was up to it's old tricks (not recognizing the max blower speed) and was coming on at 100% whenever the damper was above the "on above" value. I was losing hope but then noticed that the blower was set to Voltage mode. I am running on a 4.1.4 board so the light bulb lit up and I changed to Pulse mode. Lo and behold, I think I have a house broken HM/blower/damper unit. The only other thing I need to fiddle with is the servo pulse width. Going from 100 to 50 percent on the HM seems to close the damper an awful lot (more than 50% in my mind).

Todd
 
update

I was messing around with my HM and calibrating the servo pulse range when I noticed that the blower was up to it's old "tricks" again. It was ignoring the max setting and coming on at whatever startup setting was entered. I went through a few cycles of "cooling" and "heating" (my wife just shook her head when she saw me with the pit probe under my tongue) but still couldn't get it to pay attention to the max setting. Then the aha! moment (or boy, what a dumba** moment depending on your pespective). It seems that the pit temp has to hold at or above the set point for a certain amount of time before it goes from the on startup loop to the min/max loop. During testing, I was ramping up over the set temp then immediately letting the temp fall back down. This is probably outlined somewhere else but thought I'd stick it at the end of this thread.

Todd
 
That's interesting for sure. It should only need 2 seconds above the temperature for it to switch from startup to normal.
 

 

Back
Top