I declared a switch inside my code, and it does create the component for me, but after changing the state its not being preserved. What can I do to store the state in my_bool_id so that the changed state is preserved?
globals:
- id: my_bool_id
type: bool
restore_value: True
switch:
- platform: template
id: threshold_active
name: 'My boolean'
What do you mean by this?
When the device is power cycled?
Use the switch restore_mode options.
switch:
- platform: template
id: threshold_active
name: 'My boolean'
restore_mode: RESTORE_DEFAULT_OFF
See: Switch Component — ESPHome for other modes.
This saving of this state depends on what type of ESP board you have. There are other options you have to set if you do not have an ESP32.
Also why are you doing this?
Please give a lot more information in future.
Add this to your switch:
on_turn_on:
then:
- lambda: |-
id(my_bool_id) = x;
on_turn_off:
then:
- lambda: |-
id(my_bool_id) = x;
not tested…
This component is mainly a humidity monitor. It already has sensors for temperature, humidity, etc. I’m going to have a few of these in the house.
I want for the user to be able to set a relative humidity threshold (mHT), like 55% so if/when the RH sensor value crosses the threshold a RH-threshold-breached event is thrown somewhere, that is in HomeAssistant or the component’s universe.
This mHT value could be stored in HA, as an input_number, but I’d like to have the component provide its own variables and handle its functions as much as possible and makes sense. Having just said HomeAssistant will provide fhe UI for adjusting mHT (lol?)
So the component is chugging along. Someone takes a shower causing the RH to soar past the mHT value. The component does something to let the big shots know the RH is above mHT and they might want to do something about it. So they open a window and fhe RH drops like a rock dropping below the threshold mHT. The component doesn’t do wiindows so the best it’s willing to do is to does almost the same thing it did for RH going above mHT, with the distinction it lets fbe big shots know the RH is going down below mHT. BTW the component will also have an on/off switch on the componentt called mActive. If it’s off, the component won’t do anything but report the weather sensor values. If on, events, messages, etc. go through to where they can be caught and handled by fhe big shots, HA, or something else.
If the component didn’t have the ability to send messages, throw events, etc. we could have written an automation in HA with the appropriate triggers. But since the component is monitoring the RH with respect to mHT we decided that when the RH crosses mHT that the component will not only send a message, it’s going to run an automation on HT. So when we setup the component we will provide the entity_id of HA automation that should run when RH goes above mHT and the entity_id for the automation which handles the “drops below mHT”. In our example, it might be id_RH_rising and id_RH_falling.
You could use this to store mHT
It will appear in Home Assistant where it can be set.
Then for your threshold tripped sensor compare the humidity reading to the template number using this in ESPHome:
This will also appear in home assistant where you can use it to trigger automations.
Alternatively, for the simplest implementation, just use the humidity reading directly in a home assistant numeric state trigger with an input_number helper.
So this would be the closest to having the component device determeine when the goes-above and goes-below events are triggered, and on the HA side you can create automations monitoring each?
If I wanted to start a fan directly from the component and not an HA automation then a User defined action would work, but that would require hard wiring the device name into the component? (Yeah, it’s got to be hard wired somewhere)
Do you mean create an input_number helper, and use that in a automation’s trigger?
Yes.
automation:
triggers:
- trigger: numeric_state
entity_id: sensor.humidity
above: input_number.humidity_high
below: input_number.humidity_low
Is this solely for your personal use, or is this supposed to be something that is generally useful?
I have two scenarios where I use relative humidity to make a decision to do something.
Neither of those scenarios would work so well with your proposal. For the bath fan, I use 70% as the turn on value as it is highly unlikely the humidity will be that high with the shower not running. However, turning off the fan at 69% would not be sufficient. I have set 50% as the low point. But, there are times that achieving 50% is impossible, so I also have a 30min of the humidity staying essentially the same as a second case to turn off the fan.
For the dehumidifier, a single set point is the reason my previous dehumidifiers had a short life. When the humidity rises, the dehumidifier turns on. Typically the humidity drops like a rock in the area around the dehumidifier and the dehumidifier stops. Now all the moisture it has collected gets reabsorbed (fan doesn’t turn off) and the humidity quickly rises above the set point. The cycle repeats until the weather changes.
I now use the 60min average AND have a minimum on time and when that is done remove power from the dehumidifier to stop the fan. This lets the water drain (mostly) before the next cycle starts (an hour or more) later.
If you see value in your component that is great.
I created this automation before I had sensors everywhere. I did think about using a difference, but the current model of 70% right above the shower (at the fan) works incredibly well. The (BT) sensors I now have that are in the same room don’t respond nearly as clearly. There is a general tracking of the sensors, but the relative humidity reading changes quite a bit with temperature so the signal is not so clear that way.
I first started with there needing to be a sudden increase in temperature and humidity, but that was not as quick to respond and didn’t really have a better rejection ratio.
I’m just messing around with arduinos right now for fun.
I already have automations that can control the bath fan. What I currently do is look for sudden humidity spikes, either up or down. By creating a couple of binary_sensors with the trend integration.
- platform: trend
sensors:
bathroom_humidity_rising:
entity_id: sensor.mba_humidity
friendly_name: Bathroom Humidity Rising
sample_duration: 600
min_gradient: 0.0165
max_samples: 600
device_class: moisture
bathroom_humidity_falling:
entity_id: sensor.mba_humidity
friendly_name: Bathroom Humidity Falling
sample_duration: 600
min_gradient: -0.0165
max_samples: 600
device_class: moisture
I’m sure I could create the same kind of sensor on the component, but to keep it simple I’m going to use mHT as a poor man’s trend sensor but this might work well for you. So if bathroom_humidity_rising (and possibly other conditions) goes from false to true, turn on the fan. Now bathroom_humidity_falling might not work for you, because you might not get a sudden spike downward, even with the fan on. What I did was simply put a timer on the fan for 30 minutes. When the fan turns on, I automatically saved the current temp/humudity/time “initial” values… So after 30 minutes I compare the current humidity to the initial. If they are close, the fan turns off. Otherwise I might let it run a bit more. I’m always tinkering with it. Make sure you add an input_boolean active so that nothing happens when it is false. This is useful when the SO is taking a bath and that turns on the fan which is a wee bit annoying.
Hey Google, I’m taking a bath!
Which makes active false and bathtime can continue. An hour later and active is set to true and the humidity monitor can continue. And since he knows that Rubber Ducky just met Mr. Bubble he looks at the sensors history to see how long the fan should run for.
Speaking of dehumidifiers, I love my Midea Cube 50. It’s lasted five years and showing no signs of breaking. I got mine from Costco but it’s not on their website at the moment. Sam’s has the best price right now. This thing did as well as a $2,000 Santa Fe Compact Dehu and it’s alive. I can’t vouch for the “uphill” pump, mainly because I never used it except to see it work (it does). If I could marry an appliance I’d mary the Bosch dishwasher but this Midea is my mistress.
What device are you using to measure temp/rh/rp and where are you putting it? I use BME280 and they are fast as well as reliable. I wasn’t sure where I would put the sensor on my first arduino, so I used copper wires to connect it to the board, which gave me the advantage of pointing the sensor where I wanted it. Like a pet rock.
I use an sht-15 that I bought more than a decade ago (well before the BME280 existed as a twinkle in some designer’s eye). It is connected to a SonOff TH16 and both are in the bath fan.
The other BT sensors I have in the same room (at about 1.2m height) also work, but not as well.
So, yeah, having the sensor just above the shower head works really well. Even with that, I notice when the fan doesn’t start right away (and wonder if something is wrong). But, I have it on a 30s update, so I usually only have to wait a min at most to see the light that says the fan is on.
