3 fanspeeds with 2 bathrooms - just need a logic inverter?

Hi,
I’m not very experienced with Advanced Flows and have been struggling for three days to find / create a logic inverter. I have experience with logics in general.

My fan control setup has three switching modes: low, medium, and high. I have two bathrooms with separate humidity sensors but a single central fan. The switch levels are as follows:

  • High: If either sensor exceeds 60%, the fan is set to high.
  • Low: If both sensors are below 50%, the fan is set to low.
  • Medium: This is where I’m stuck.

The issue arises with the medium setting. I thought I solved it by blocking the medium command when high is active, using an AND gate to block Medium whenever a sensor exceeds 60%. However, the high condition now TRUE and I need a FALSE on the medium AND-gate to get it blocked.

To properly block medium when Fan-high is selected, I need a logic inverter that outputs FALSE when the FAN-high condition is TRUE. Unfortunately, I can’t find a way to invert the signal in the logic, and my attempts with scripting have either resulted in errors or simply passed the signal without inversion.

Different subject is my attempt to add a variable to avoid double activation but this did not work for unknown reason. The output turned out to be false all the time.

Thanks for your feedback,

Bob

First of all (no pun intended), ALL blocks are to use after conditional cards, NOT after trigger cards.
Trigger cards NEVER trigger exactly at the same time: triggers are “pulse” signals, hence the name. They’re not “states”, as in, a trigger will stay active to be of use with an ALL block.

To create a state of two triggers, you can use a boolean variable, you could call it [kb_gb_+61] for instance for use with the ‘greater than 61%’ trigger.
The trick is to only set the variable when the other sensor’s humidity is already above 61%

Like:
When…
-sensor KB humidity becomes greater than 61%
And…
-sensor GB humidity is greater than 61%
Then…
-set logic variable [kb_gb_+61] to True (or Yes)

When…
-sensor GB humidity becomes greater than 61%
And…
-sensor KB humidity is greater than 61%
Then…
-set logic variable [kb_gb_+61] to True (or Yes)

When…
-logic variable [kb_gb_+61] has changed
And…
-logic variable [kb_gb_+61] state is Yes
Then…
-MQTT Client send ON to topic home/fan/high

Of course the [kb_gb_+61] variable should be set to False (or No) again, when the humidity became less than 60%

YW!
I wasn’t finished yet :grimacing::wink:, added some additional info to my post!

Ah yes, that sounds great.
I changed the logic and set a variable “Fan_State” at trigger. the Fan command would be executed by this variable.
I now decoupled the trigger from the commands: I will test if this works. Thanks for your suggestions, Recommendations always welcome.

1 Like

Two triggers before a ALL-card will never work.

Try this:

Great Wim, looks a lot better to do it in sequence. Peter already adviced certain do’s & dont’s. Thanks for the effort! Will test this in the coming days.

I think Wim responded to your edited flow, James; there’s still one ALL block right after trigger cards:

By the way:
The bottom part lacks triggers; you now try to start these flows with AND conditional cards:

Something has to be added to start those flows, like:
IF…
-logic variable [FanStatus] has changed

Now connect the output of this card to all 4 conditional cards’ inputs.

But,
you can carry on with Wim’s excellent example flow, I just try to show what went wrong with your flow

That’s great Peter, thanks for your tips. I connected Wims flow layout to my mqtt commands and it looks like all works fine. Whenever I grow into the Homey’s program techniques, I will tweak all to my convenience, but so far, I am very happy with tips from both of you. Keep it going!

1 Like

@James99 Great that everyone has helped you out with the flow itself however I have noticed mixed results with just switching me central fan ON/OFF regarding the relative humidity in my bathroom.
(I also Live in the Netherlands)
– And I’ve noticed in these winter seasons the humidity in your house might be relative low due to a lot of heating in house.
– then in the spring with weeks of rain and less heating the humidity in house might increase quite a bit and thus triggering your flow
– etc. etcccc

So at least in my case I’ve replaced the “dumb” light switch in the bathroom with a 6button variant where 2 buttons are used to set the central fan to high.
(as a bonus my lights in the bathroom are not allowed to switch off when fan is set to high since my motion sensor cannot see a person through the glass shower door (and previsously turned the lights off))

as an extra here is the humidity of my bathroom last year just to have a general idea (yea i know i quite high)

Hi Sebas, that in interesting… we need to find a conversion from outside temp/hum into inside to set the lower hum level. We may use a lower limit calculated by the following:
Hum (Hi) inside + Offset = 0,05 To^2 + 0,2 To + 0,5 Ho. This maybe close enough.
And dreaming about the perfect controller, (your) manual control is interesting too. I think an auto / manual mode would be beneficial. If someone interferes by pressing a button fanspeed 1,2 or 3 (at the dashboard in my case), the action would override the (hum based) auto control. I guess this must be limited by a timer, where the flow automitically falls back into auto-mode after, for example, 2 hours. We can add an auto mode button to force back to auto.
At the moment, I am not able to work with flows with ease but I will do some testing step by step to implement these two elements.

A that’s also a good idea ofcourse (I do have Aqara temp/hum T1 sensor outside) which im able to use something like that.

I noticed that when both humidity sensors are below 55, there is an MQTT command FanLow every time a sensor changes a litte bit. So I want to prevent that a command can be given when it is in the required state already. I added one block, which is the variable of the state of the fan (set in parallel with the MQTT commands) and whenever the Fan_State is NOT Fan_Low, the command should pass the AND gate. However, I found that the command, even FanState is Fan_High, the signal from the block seems not high and the signal does not pass. Could someone inform me why this setup does not work?

I don’t see the flaw instantly, to many ALL-cards and curly lines.

To keep things simple I suggest the following:

The fun part is that when the flow set the fanstate to LOW while the state is already LOW Homey doesn’t see the variable as being changed. So the When-Card ‘FanState is changed’ doesn’t trigger.

Maybe I found tw flaws?

Yes you’re right, I was copying arround. Thanks for your input, this is a diffferent approach I did not think of.
Actually, I moved the state-settings to the back to avoid timing problems. Now I will change it to your suggestion and come back with my findings.