Trigger fan on at low temp, trigger off at higher temp?


#1

Tricky scenario that I'm not sure if I can pull off. I have a fireplace fan that's hooked up to a zigbee outlet. I have a zigbee temp sensor mounted close enough to track when the fire is hot enough to turn on the blower and push out the heat. What I'd like to do:

Turn the fan on when the temp sensor reaches 90 degrees. (easy)

Problem: After the fire burns a few hours, the brick absorbs a lot of that heat and keeps the temp sensor reading high hours after the fire went out.

The fan should turn back off once the temp sensor drops down to 110 degrees (no idea if I can even do this)

I'm trying to compensate for all the stored heat in the brick with some sort of rule that only triggers it on when the brick is cold, and compensates for the stored heat in the brick.


#2

Could probably do it w/the WATO app...

1st trigger only acts when temperature is going UP.
2nd trigger only acts when temperature is going DOWN.

I've never used it for that exact purpose, but it does support rising and falling value triggers.


#3

This might be of some help:


#4

Clever. I hadn't seen that thread.

Still think using WATO would be much easier with its rising/falling trigger capability, of course I could be wrong since I haven't done it. :smile:

In the end - whatever gets it done is the right answer!!!


#5

Let us know if WATO works for you. That would be great!!


#6

I will definitely look into this. Thank you!


#7

Haha - of course someone beat me to it! Thank you for the link, I will check it out, too.


#8

So I was bored and looked at this... This is how I think I would do it in WATO. Seems to work on my virtual devices as expected. Two very simple WATO rules, about 30s of work.

The problem you could have with this is if the temperature reading is noisy, or goes up/down as it moves the fan could turn on/off at the boundaries (like when the fireplace is on). If you made the ON higher than the OFF, (like maybe ON @ 105 and OFF @ 90) it would always work as expected, though.

Turn switch ON @ 90F (rising):

Turn switch OFF @ 110F (falling):


#9

You could do this with 4 Triggers in Rule machine.
Trigger 1: >90 Turns the fan on and sets its own PB to false.
Trigger 2: <110 Turns the fan off and sets its own PB to False.
Trigger 3: >130 Sets PB True for Trigger #2
Trigger 4: <80 Sets PB True for Trigger #1

It would take one sequence up and down for the PBs to be set correctly, but I just did a quick test and it should work. Obviously you would have to adjust the temps for triggers 3 and 4 to suit your needs but you get the idea. It should be as close to the max temp you achieve as possible but not so close that it might miss it. And #4 could be room temp. This would prevent any "flutter" of the temp around the trigger temps causing a problem.


#10

This is how I do it.


#11

That's triggering at only one level. That isn't what the OP asked for.


#12

So the action for FALSE won't run when the temp drops below 50? What does that last box do? It's been too cold here to see if it works.


#13

Read the original post again. He want the fan to start at one temp and turn off at a different temp.


#14

I keep seeing this acronym used throughout this thread but I don't see any reference to what it stands for or where to find it... What is the WATO app? is it something built into HE or is it some community built add on?

-Jeremy


#15

WATO = When any Attribute Then this cmd Otherwise that cmd.

Kind of like making rules in RM, but you can specify any attribute (without making intermediate virtual devices, etc) and execute any command (without making custom commands).

It also has the ability to do math on inputs for the trigger, more than just >, <, =... Like the rising and falling triggers mentioned above.

I use RM for most of my things, but WATO scratches a couple of very specific itches for me that would be possible in RM - but with a lot more work/rules.


#16

Thanks, that's really cool.

Perhaps I could piggy back this thread for a somewhat similar use case I have:

I built a dog food scale using a SparkFun OpenScale and some off the shelf load cells attached to a wooden base I built. We have a dog food dispenser that allows the dogs to eat whenever they want: https://www.amazon.com/gp/product/B00IA5I97S/

I wrote a driver in Hubitat that uses telnet to access the weight (and temperature) of the food on the scale. Since it can hold 50 lbs of food, and we generally buy food in 40 lb bags: It makes sense to be notified to buy more food when it drops below about 15 lbs, and then get notified to add more food once it drops below 10 lbs.

Side note: Has anyone noticed there's no "weight" capability in the driver system? I guess no-one ever thought that someone would use a scale as part of a home automation system. :smiley: I had to just expose the weight as a generic attribute.

What I've been trying to figure out is the most elegant way to achieve:

1.) When weight falls below 15 lbs: Send a Pushover notification that it's time to buy more dog food.
2.) When the weight falls below 10 lbs: Send a pushover notification that it's time to re-fill the dog food dispenser.
3.) Don't re-send either notification until the weight on the scale goes above 20 lbs to "reset" the scale notifications.

The challenge is that the scales reported weight can "drift" a bit up and down even when the weight stays constant. This is very similar to a thermostat problem when you might set the fan to come on at 72 but you don't want it to shut off at 72.1. Likewise on the scale it could drop to 14.9 causing a Pushover notification and then 30 minutes later go back up to 15.2 then an hour later fall back to 14.9 again and fire off the pushover notification once again.

I know I could do this in Rule Machine with several rules and a bunch of private booleans, but I was curious if something like WATO might offer a simpler solution?

-Jeremy


#17

Would probably need RM, as there isn't really a good way of doing the set/reset on the alert in WATO right now.

Whereas in RM you could turn off the private boolean after triggered the 1st time, and not turn private boolean back on until > 20 lbs. It will just take more rules (3 I think?), but should be doable in RM.


#18

@Ryan780 I'm going to give your method a try first as I'd like to understand RM a bit more (I've only used it for simple lighting related things). If this doesn't work I'll try the WATO example.

Bear with me, but I don't entirely understand how the rules you gave as an example are working (a little confused by the PB's). I'm assuming the 4 triggers should be separate rules (not all 4 triggers in one rule). Let me know if I'm understanding this correctly:

Trigger 1 turns the fan on when my sensor hits 90 or above (bricks are cold, so this temp increase has to be from the radiant heat of a new, hot, fire). It also sets it's PB to false (I'm assuming that means this rule will not work again until something sets it to true which is when get back to room temp by trigger 4).

Trigger 2 turns the fan off when the temp is less than 110 and then disables the rule so the fan won't turn off again until the temp hits at least 130(easy to accomplish by a hot fire) by trigger 3.

What I don't understand is how rule 1 and 2 dont cancel each other out in this scenario. If the fire starts to get hot and hits 91 Trigger 1 turns the fan on, wouldn't trigger 2 immediately turn the fan off since its <110?


#19

They will the first time the temp goes up... But after that they won't. This is what happens:
At room temp, trigger 1 is PB true but trigger 2 if PB false. As temp goes above 90, the fan turns on and PB goes false for #1 and still false for #2. When the temp gets above
130 PB goes true for #2 but is still false for #1. When the temp gets below 110, the fan turns off and PB is false for 2 and still false for 1. Once it gets to room, #1 PB goes true again getting ready for the next fire.
Basically, until the temp gets on the other side of the trigger, the rules PB is false, preventing it from firing.


#20

@Ryan780 Ok, I think I get it now. I didn't think about the fact that Trigger 2 would be false since it's technically already triggered! Just looked in the logs and see that the PB is set to false right now.

Now to start a fire and test this out. Thank you!