Multiple programmable relay assistants and their logic for AC Out 2 control

DIY
, ,
1

I want to leave AC Out 2 on as normal when the grid is up but I want to override the normal behaviour of the system opening it when the grid is lost by closing the relay again 5 minutes after AC Input is lost unless the SOC is below 25%. If SOC subsequently drops below 25% I want the relay to open again too. Unfortunately the system controls the power supply for 17 people so I don’t really have the luxury of letting it reset repeatedly whilst I experiment with different assistants.

Researching the topic it is easy enough to find the few sphinx like pronouncements available on the issue - writing multiple assistants affecting one relay is common and order is critical, ON condition takes priority over OFF, multiple criteria in the ON (or OFF) list go by the OR principle, last assistant in the list wins, and (possibly) reversing logic might be helpful with the ON priority issue - but still there are various approaches that may or may not work depending on the finer details and I don’t wish to subject my tenants and their valued possessions to trying them all.

Once you write any assistant affecting a relay do you become completely responsible for the setting of that relay in all circumstances or are you only writing the changes to default behaviour that you want to see? If multiple conditions exist in one assistant does it become an AND or an OR situation within that assistant? If multiple assistants exist do subsequent ones completely override earlier ones and if that’s the case what can it possibly mean that ON conditions take priority when in any assistant there can only be an ON or an OFF - ie. the only way ON conditions can meaningfully take priority is in the case of multiple assistants? Under what conditions do things get re-evaluated - every time any condition in any assistant involving that relay is triggered all such assistants get triggered again in order or only those ones directly affected by changing conditions?

If multiple conditions within one assistant instance are combined as AND then it seems logical that I have one assistant to check SOC is high enough AND that AC Input has been unavailable for 5 minutes and then drive the relay on, whilst a second assistant can check if SOC is low AND AC Input has been unavailable for no time and leave it off instead. This does leave it undefined for some possibilities but if default behaviour kicks in anyway in those cases that’s fine.

If ON just takes priority no matter what else happens or in what sequence and there’s no way to AND anything then there would simply be no way to turn off on a low SOC because unavailability of AC for 5 minutes will win the argument by itself.

If there’s no way to AND but subsequent assistants can override an ON then do I switch it on if AC Input has been unavailable for 5 minutes and then off if SOC is low and execution order alone solves it? What happens if SOC changes subsequently though? And did I take over responsibility for even closing the relay when AC is present too?

The mind boggles at the varying interpretation possibilities here and community post after community post in the various different fora over the years reflects this confusion as different parties attempt to elucidate the logic by experimentation and deduction. Does anyone have the absolute answers though and can share them unequivocally?

2

Program the output to switch on and off based on the t sense input.
Wire it with two wires to a GX relay.

Use node red to do as you described driving the relay.

The assistant will always take some experimental work to find what is successful for your use case. There is no way around it. Just switch to a different method

The other way is to use the generator assistant to drive the ac2 out relay. Its a little less confusing that the other. However

This is the hard part of the logic there.

With node red even a free version of an AI can help you put something together. As long as you treat it like a coder who knows nothing about solar systems

3

Yes I was aware of the GX relay option…that will be my last resort for several reasons - I can also do the simple switch on after delay alone but then have to take full control of my smart switches instead of allowing central servers to handle most of that on predefined schedules…cleanest would be if someone can clarify this logic rather…

4

If you are heading in that direction then also using a smart switch for it is an option. Either a dry contact one or actually switching the load in question.

5

I appreciate the effort but this last is taking me further from what I’m asking, not closer, at least in part because I haven’t chosen to go into the details of why I want to do this to keep the question cleaner.

The generator assistant does look interesting when used in reverse (ie. opening the relay “starts” the generator)…are you able to clarify what would happen if I use it in combination with a programmable relay assistant? Generator start/stop could handle the low SOC and a programmable relay could handle the time delay but would the two play nice if I put the relay first and the generator second to potentially override it?

EDIT: it seems likely that this will just force the relay closed based on SOC and the time delay will never occur - and a delay is fundamental to the whole purpose of this for me.

6

It seems like the following overly-complex cover-a-lot-of-bases approach might work…are you willing to venture an opinion on it?

It makes the following assumptions - I should cover all possible routes including default behaviour just in case, that multiple conditions in one assistant are ANDed, that a later OFF can override an ON, and that any assistant is re-evaluated if and only if one or more of it’s conditions changes

  1. close the relay if AC input is present for 120 seconds
  2. open the relay if AC input is absent for 0 seconds
  3. close the relay if AC input is absent for 300 seconds and SOC is over 30%
  4. open the relay if AC input is absent for 300 seconds and SOC is below 25%

Edit: If I further change the order of these to be 2, 4, 1, 3 then I can remove the assumption that a later OFF can override an ON.