Custom temperature threshold alarm?

[ct16k]

Hello,

Would it be possible to add global min and max temperature limits, which would set off the alarm and stop both relays when crossed?

I'm planning a custom temperature control solution for my aquaterrarium and having this fail-safe in case something goes awry (the chiller will be Peltier-based), would be perfection (for my use case this is actually the only feature missing from the original firmware, but I only noticed the fixed out-of-rage thresholds after placing the order :-S ).

Thank you and keep up the great work!

[matsstaff]

Hi!
It would be possible, but I'm afraid that there is not enough code space left to add such a feature. And also, this is not a desired feature for fermentation control.
However, if there are implemented features that you don't need (like profiles and such), then I think that it would be best to make a 'new' custom firmware for your needs, based off STC-1000+.
I'd like to help, but I have seriously a limited amount of time to spare, and my priorities are of course to maintain and develop this firmware first.
The source is open, so you are welcome to make modifications yourself. If you can't, well, you'd need to make a pretty compelling case for me to take the time to rewrite this into a new firmware (like showing me that there are more ppl who would want this, and would go through with upgrading their controller).
Cheers!

[andrhamm]

I could see this being valuable for fermentation... if the compressor of your fridge malfunctioned, or maybe your fridge is on a different breaker and it gets tripped or something, it would be desirable to be alerted before the fermentation is ruined.

[matsstaff]

That is a good point. But also, this is not as easy as it sounds. First off, there is no more space in EEPROM for additional configuration options. Secondly, what rule(s) would you use to trip the alarm? It is not as easy as 'if temperature is less than setpoint - x or greater than setpoint + x', what if you are running a profile? Then setpoint can 'jump' and the above condition be true, even if there really isn't a problem.

I'm not against adding this feature, on the contrary, I think it could serve a purpose. But in order to do so, I think we need to define an acceptable definition of when an error has occurred.

The first issue, that there no more EEPROM space left, could be handled by appending to the SA parameter that I recently added. It does a similar thing but in reverse. It sounds the alarm when setpoint has been reached (for alerting when it is time to pitch yeast).
As this feature would not be usable in conjunction with that, I'm thinking SA=2 could enable this feature instead.
The second issue will not be so easy... There needs to be a non-complicated way, that also works with profiles, to determine if an error condition occurs or this feature will not be usable.

[andrhamm]

what rule(s) would you use to trip the alarm?

Sorry, I only visited this project because I ordered an STC-1000 so I haven't actually attempted the mod yet. The ideal implementation, imho, would be to have this setting be a part of the profile but defaulted to something sane. If the temp is more than 10º +/- (as an extreme example) it would definitely mean something is wrong. Customizing this as part of the profile, or as a global setting at the very least, would be important because I could see some people maybe having much stricter requirements.

A complication I could see (based on how tight the memory restrictions / logic space available) would be that you probably don't need to be alerted while the initial cool-down is happening. As in, when I put my 70º wort into the ferm chamber and I'm using a lager profile, if my chamber takes 3 hours to drop the wort temp to the 50º setpoint, will there be an alarm during that time? That would be annoying. Maybe there could be a rule where during the first setpoint there won't be alarms? Or maybe the alarm threshold only becomes active once the first setpoint is reached initially, or after a static number of hours (4?) in case something is messed up right from the start.

Bear with me, I don't know the limits of the system, just trying to contribute to the discussion of this feature since I see it being mentioned a lot on homebrew forums like HBT.

Thoughts?

[andrhamm]

what if you are running a profile? Then setpoint can 'jump' and the above condition be true, even if there really isn't a problem

Oh I just now understood what you meant by this... So basically the ramping/jumping would have to be taken into account in more than just the case of the initial ramp as I previously thought. That definitely complicates things.. Maybe it can refrain from sounding the alarm if there is a trend towards the expected setpoint. So if it was ramping down from 70º to 50º, maybe the last 5 reads of the temp would be kept in memory and if there was a downward trend (ex: 70.. 68.. 67.. 65.. 63..) it would hold off on the alarm.

[ct16k]

Hello again,

When I originally submitted this request, for me it was literally [just] a safety concern - if my TEC fails and heat starts leaking through to the cold side I don't want my aquarium turned into a giant soup, or worse, become a possible fire hazard. So for my part, just some general, configurable min/max temp to trigger the alarm is enough. So for example, if the whole current profile has an expected max temp of 70º, the alarm could be configured to trigger at 75-80º to stop both relays. Same for lower limit.

[ This seems like a simple enough thing to do, but it's been quite a while since I worked with PICs, and I'm still waiting for a second unit to toy around with, but once it gets here I'm definitely trying my hand at this. :) ]

[matsstaff]

Ok, so after some consideration, I have come to the conclusion that the user definable alarm could be useful. And not wanting to complicate things, I have settled on repurposing the SA parameter, to be a value the user selects how much from the setpoint the temperature is allowed to deviate before the alarm sounds (also I allow for negative settings which would mean how much the temperature must deviate from setpoint unless the alarm should sound, this will be useful in the 'tell me when wort is at pitch temp' scenario). It will be up the user to make sure the correct setting is specified, based on how soon the warning should come vs. not giving false warnings if running profiles.
I think this is simplest, but still useful and 'understandable' to the user.
I will not however disengage the outputs if the alarm goes off, as that would with all probability not be the desired behaviour in most cases for fermentation.