Forum wide moderators
Can you add the following to your HassController config, restart, and post the contents of the dump file created (named <controllerid>-fan_kitchen_seashell_hood_ventilation_fan.json). Thank you!
config:
# other stuff
dump_entity:
"fan_kitchen_seashell_hood_ventilation_fan": true
Nothing more to add. I see we have hvac_blower, but, anyway, maybe a native fan on the same assumptions of the fan from HASS could be reasonable.
I have a couple of them. ie, this is from ESPHome via HASS.
x_hass.domain="fan"
x_hass.entity_id="fan.kitchen_seashell_hood_ventilation_fan"
x_hass.floor_id=null
x_hass.services=["fan","esphome"]
x_hass.source="esphome"
x_hass.state="off"
x_hass_attr.friendly_name="Seashell Hood Ventilation Fan"
x_hass_attr.percentage=50
x_hass_attr.percentage_step=25
x_hass_attr.preset_mode=""
x_hass_attr.preset_modes=[]
x_hass_attr.supported_features=49
Thanks.
done. I'll test, but your logic makes sense, of course.
anyway, part of the problem with complex rules is that I have a huge system and sometimes it's very, very difficult for me to find the right rule after a while. what could help me is a way to see all the rules a device is used into (triggers, constraints, actions, variables), and an advanced search, maybe,
one can dream 
Thanks, make sense. I realized from a backup that I had previously solar into the triggers. So I don’t know, maybe I was tired. Thanks for your help, I’ll try to rework this and create two rules!
I'm not sure how I can help here. Your assessment seems correct. Like the other recent post, the displayed states here show the triggers going true substantially before the constraints did, so the constraints prevented the rule from SETting.
That seems like a logic issue. You need different approach, and I can't really gauge how you want this to work, and what the system limitations and risks are. That's knowledge only you can possess, at least not without a much lengthier explanation/q&a about what all this is meant to do, what you want it to do, etc.
I can, however, throw out some things based on assumptions (and because they are assumptions, they may be completely useless to your problem and not make any sense)... assuming two key goals: you don't want to start A/C unless solar power is high, and once A/C is running you want to keep it that way, at least for a while. You could move the solar power condition to triggers and latch it. To make sure A/C is stopped if solar drops too low, add a trigger condition requiring solar > whatever minimum, so you basically have solar >= ACthreshold (latched) AND solar > ACminimum in the triggers. If solar momentarily drops below threshold, the latch keeps the A/C running, but when it drops below minimum, that condition going false resets the latch (and presumably allows the A/C to turn off). Additionally, you could add a delay reset on the A/C, to enforce a minimum runtime. This is often recommended to avoid cycling compressors too often, but also helps make sure that the money you spent on the startup inrush gets some useful life. Be careful here, though, because you now introduce the possibility that the A/C could run when the solar is below minimum (held on by the time delay).
I will also repeat advice I've given previously... sometimes it is easier and, in fact, necessary to separate "turn on" and "turn off" logic into separate rules. I know there's a big temptation to use the SET and RESET reactions of a single rule, but it can make the triggers and constraints excessively complex to support. For example, I have a dehumidifier in my garage (where I live, my tools would rust every summer otherwise). Three garage doors, temperature, humidity, standby generator operation, and other large loads in the space are all considerations for both stop and start, but with varying logic. One aspect perhaps similar to your rule here, is that the dehumidifier isn't stopped when the garage door opens for a short period (e.g. a car pulls in or out of the garage), because of the wear on the compressor starting it, and brief periods of door open don't significantly drag on dehumidification, but long periods definitely do. I have one rule with just the start conditions, and those conditions include (a) the dehumidifier hasn't been running for at least ten minutes (prevent short cycling; it doesn't have smart controls), (b) the doors are all closed, (c) the humidity has been above threshold for 30 minutes (via a "sustained for" option on that condition). If those are met, the unit is started (via the SET reaction). In the rule with stop conditions that turns the unit off, the triggers are (a) dehumidifier has been on for at least five minutes, and (b) the start rule isn't SET (i.e. the conditions that call for it to be on are no longer met), also sustained for at least five minutes. SET reactions only; no RESET reactions. While the basic logic isn't complicated, it would be very difficult to get the independent timing of the two (on and off) processes to work in a single rule. By the way, I have a separate rule to detect if doors are open; I don't look at each individual entity in every rule, because...
More general advice to the community: many (most?) posts lately have had huge monolithic rules posted. I don't recommend it. I don't do this to myself, and I wrote the darned thing. I make liberal use of the Rule State condition and separate out chunks of logic into small, easy to define, easy to debug, easy to test condition-only (no reaction) rules that are tested by other (action-oriented) rules. Modular design. Using the overrides on the UI makes it easier to test, because you can SET and RESET your input rules at will and in any order. When devices fail or change, there are then a lot fewer rules to update. I always start with this approach on anything new. If I later find it's overkill for the task, I can always import the input (condition-only) rules into the action rule and get rid of them.
Again, just some thoughts/rambling without deeper knowledge of the task...
I have this rule that stopped working recently, I think with the latest update:
As you can see, all is true, but the rule stays reset. Resetting the rule does the work and the A/C starts. I think it's because the trigger window is true, while a specific constraint (power_solar >= 1800) is not true when the triggers are true. But I don't want to put this into triggers, since I want the A/C to stay ON after it started, even if we have rain or similar, because of the inertia to start it. Any hint is appreciated here @toggledbits. Thanks.
In the first image, the triggers show true as of 9:42:09. The constraints show true 10 seconds later. That's a not pass. The constraints have to be true at the instant the triggers are also true (or before), or the rule does not SET. If the constraints become true later, that doesn't matter, the rule does not SET.
Your third image shows the same. Triggers true at 10:31:53, but constraints didn't go true until 10:32:12 (19 seconds later).
From the docs:
This is now available in build 26242. The config has changed slightly, so review the final documentation for correct usage and examples.
A couple of things here...
Even restarting Reactor doesn't do what this button does.
