Alerts for grill reaching target temperature, and probe reaching target temperature

[stephenpapierski]

Is your feature request related to a problem? Please describe.
My phone is on silent and I always miss the Traeger app alerts. I'd love to be able to trigger my Google Home's to verbally alert me when the grill/probe reach their target temps.

Describe the solution you'd like

1. A binary_sensor that says if the grill has reached its target temperature
2. A binary_sensor that says if the probe has reached its target temperature
3. Logic for sensors
   • Sensor would reset to False whenever a new target temp is set
   • Sensor would become True when actual temp >= target temp

Describe alternatives you've considered
I've considered implementing a template sensor outside of the integration, but feel other people might find it useful as well.

Additional context
I'm willing to look at implementing the code for this, I just wanted to toss out the idea first to get some feedback and see if others think it would generally be useful. Or if you have already figured out an easier way to achieve this with the existing code.

Additionally, I think the logic presented above would add better functionality than the Traeger app itself. There are times when I smoke at 225 for a while, then I bump up the temp to 500 to sear. The Traeger app only sends one notification when the grill first gets to 225. When I up the temp to 500, it never tells me when it gets there because it's already "preheated".

[stephenpapierski]

Alternatively (and I think this would be much easier to implement), we could use the hvac_action to describe this. This is different from the hvac_mode in that it describes the current action versus the general mode.

We could return HVAC_MODE_HEATING when igniting/preheating, but then return HVAC_MODE_IDLE when the grill is actually at temp. HVAC_MODE_COOLING, and HVAC_MODE_OFF would follow the existing logic for hvac_mode. In this case, you could simply set a trigger for if the hvac_action ever goes to HVAC_MODE_IDLE to know when the grill or probe reach their target temperature.

Grill Climate Logic

• HVAC_MODE_HEAT = Trying to increase actual temp to target temp
• HVAC_MODE_IDLE = Holding actual temp at target temp
• HVAC_MODE_COOL = COOL_DOWN
• HVAC_MODE_OFF = IDLE/SLEEPING/OFFLINE

Probe Climate Logic

• HVAC_MODE_HEAT = Probe connected, actual temp < target temp
• HVAC_MODE_IDLE = Probe connected, actual temp >= target temp
• HVAC_MODE_OFF = Probe disconnected

[stephenpapierski]

Sorry to spam this thread, I just keep coming up with different ways to tackle this and I'm not sure which is best. Are custom state attributes on the climate entity an option too? Or are you limited to the defined attributes of the climate entity? I can't seem to find an answer to that in the developer docs. If that's an option, a well named custom state attribute may be more self explanatory than the solution proposed above.

[njobrien1006]

Custom Attr do seem to be allowed within a climate class. See climate.py for reference.

Each option suggested does seem to be of possibility. In the end, my vote would be for *sensor class as it is an independent entity and easier to work with from Node-Red/Automations standpoint. With the custom Attrs....I've had issues getting the triggers to shine through for Automations ETC (by design or my lack of knowledge, idk).

I do currently use Node-Red for elapsed timer and probe target detection. Then Traeger sends me a push noti of preheat achieved.

Additional suggestion for the preheat binary_sensor would be a sensor that goes from preheat/at-temp/undertemp/overtemp/reduce-heat as I have push alerts for under/over via Node-Red.

Happy to help, collaborate or validate if you need.

[cgc007]

We could return HVAC_MODE_HEATING when igniting/preheating, but then return HVAC_MODE_IDLE when the grill is actually at temp. HVAC_MODE_COOLING, and HVAC_MODE_OFF would follow the existing logic for hvac_mode. In this case, you could simply set a trigger for if the hvac_action ever goes to HVAC_MODE_IDLE to know when the grill or probe reach their target temperature.

While the main thrust of your original idea is already implemented for me, yesterday I suffered a grease fire because I failed to clean out the traps like I should have before cooking 20lbs of chicken.

Your quoted idea of utilizing the hvac_mode to signal what was the intended behavior would allow me to use that for an emergency announcement throughout the house and my devices to warn of thermal run away so I can investigate.

This request may require it to be a different issue, but I think the idea is sound. Why the Traeger app doesn't have this built in I have no idea. Yesterday my target temp was 325F and the grill probe was reading 440 when I got out to combat the grease fire. =(

[njobrien1006]

Probe Climate Logic

• HVAC_MODE_HEAT = Probe connected, actual temp < target temp

• HVAC_MODE_IDLE = Probe connected, actual temp >= target temp

• HVAC_MODE_OFF = Probe disconnected

One additional thing on the probe actual temp >= target temp. If I remember correctly, Traeger reverts the target temp back to 0 once the temp is achieved.

[stephenpapierski]

I like the idea of a sensor that returns multiple state values based on different scenarios. I think this allows me to set triggers for when I reach my target temp as well as giving the option of triggering for excessive heat in a grease fire scenario. Here would be my proposed states and what I think they should mean. Thoughts?

State	Description
heating	Trying to get temp up to new target temperature
cooling	Trying to get temp down to new target temperature
at_temp	Temp has reached target temp and is holding temp at ±20°F of target temp
over_temp	Was at_temp, but now temp is >20°F above target temp
under_temp	Was at_temp, but now temp is >20°F below target temp
idle	Not in igniting, preheat, cooking modes

[stephenpapierski]

One additional thing on the probe actual temp >= target temp. If I remember correctly, Traeger reverts the target temp back to 0 once the temp is achieved.

Yeah, I think you're right. I'm going to start with the heating state first, but I'll keep this in mind when I get to the probe state.

[njobrien1006]

For the state, it looks good. Maybe add pre-heat to match Traeger app till 160F?

For the probe there are 2 mqtt json entries that may already deliver what the intent is:

• [ probe_alarm_fired ]
• [ acc : alarm_fired ]

I wouldn't say the probe needs all the other things the base climate entity needs. So for me, hookup:

• [ probe_alarm_fired ]
• [ acc : alarm_fired ]
  to sensor for testing and see if that delivers desired results.

[stephenpapierski]

For the state, it looks good. Maybe add pre-heat to match Traeger app till 160F?

I like that. I went ahead and made it 165°F since that's the min_temp. Below is the full table of what I've tried to implement. Now to get something on the grill and verify that it does what I expect.

State	Description
preheating	Igniting/preheating and under min_temp (165°F)
heating	Trying to get temp up to new target temperature
cooling	Trying to get temp down to new target temperature
at_temp	Temp has reached target temp and is holding temp at ±20°F of target temp
over_temp	Was at_temp, but now temp is >20°F above target temp
under_temp	Was at_temp, but now temp is >20°F below target temp
idle	Not in igniting, preheat, cooking modes

How do we feel about these states for the probe state sensor?

State	Description
set	Probe target is set
close	Probe temp is within 5°F of target temp
at_temp	Probe alarm has fired
idle	Probe target not set

[njobrien1006]

For the probe state sensor that is a good starting point. Differentiating at_temp and idle may be interesting.

[stephenpapierski]

I'll have to monitor while cooking, but are you thinking the probe_alarm_fired is only going to report that in one message, then return to 0?

[njobrien1006]

No, I misinterpreted what you were thinking. I thought you were going to try and use set_probe & actual_probe to create those four states. When I worked with alarm_fired the first time, I believe it maintained until a new setpoint was put in or the grill power is cycled (but was 6months ago).

[stephenpapierski]

My hope was that it would behave in the way you described. Below is my (untested) logic for the state. I'm using the alarm for at_temp and just using the target and actual values to determine close or set

    def state(self):
        if self.grill_state is None:
            return "idle"

        target_temp = self.grill_state["probe_set"]
        probe_temp = self.grill_state["probe"]
        alarm = self.grill_state["probe_alarm_fired"]

        if alarm:
            return "at_temp"
        elif target_temp != 0:
            close_temp = 3 if self.grill_units == TEMP_CELSIUS else 5
            if probe_temp + close_temp >= target_temp:
                return "close"
            else:
                return "set"
        else:
            return "idle"

[njobrien1006]

Probe_Alarm_Fired and Cook_Timer_Complete seems to only go through for a single MQTT message and then resets to zero.

The nested Alarm_Fired in the probe acc seems to be a duplicate of the other one. Seems to maybe be a prep thing if they had more than one probe (acc).

So, for your code it'll need a latch for alarm and un-latch if the probe is disconnected or the setpoint is changed.

[stephenpapierski]

Noted. Made an update to latch probe_alarm_fired and I'll do some testing tonight.

Funny that you mention it. Looks like the new Timberline has 2 probe connections. In favor of supporting that going forward, it may make sense to include some of the similar logic from climate.py that actually sets up probes based on the nested entities instead of looking at the top level entities.

[stephenpapierski]

I've added the sensors here and done a little bit of testing. Any feedback or help testing would be appreciated. Is it still expected that everything lints with Black? When I passed in the custom_components directory, there were a lot of changes that were unrelated to the code I changed.

[njobrien1006]

I don't think I understand the question:

lints with Black?

lines? There are some lines that show up as improperly nested. But has always been like that.

I did a pull and tested with your feature(s). I left one error in the commit comments and another state for consideration.

[stephenpapierski]

Per the contribution guidelines...

3. Make sure your code lints (using black).

Use black to make sure the code follows the style.

When I run black on the code, it changes a lot.

[stephenpapierski]

I responded to your comments in line. I fixed the one variable reference and added the "fell_out" state (please correct my thinking if my stated assumptions are not correct). I'll put that through one more cook of testing and submit a pull request if everything works as expected.

[njobrien1006]

Per the contribution guidelines...

3. Make sure your code lints (using black).

Use black to make sure the code follows the style.

When I run black on the code, it changes a lot.

I'll take the blame on that. I didn't have Black installed and was using the standard autopep8. I'll fix the leftover formatting in a PR I have open.

The added coding/fixes looks good to me.