NodeRed: flow "overrules" remote control settings, how can i fix this?

[habi]

Hi, i’m new in the forum, first post, i hope i am doing things right

i have a full victron offgrid system and - with the help of one reddit victron user - made my first programming flow with node-red. a very simple flow to control the relay 1 of the cerbo gx (to switch on and off my water heater depending on Battery SoC).

the flow is working as intended and the hardware (switch, relay) as well! but i am still complete noob with node-red.

i encountered one issue that i would like to solve:

in the venus os settings (remote control or vrm) there is the option to manually turn on (close) / off (open) the relay.

i thought it would make sense to be able to manually turn it off/open it (for example for maintainance or remote decisions), BUT the node-red flow “overrules” the manual setting! after 5 secs there will be a new value forwarded by the flow and it will close the relay again, although i just opened it manually in the settings.

i could set the nodes to “only send changes”, which would give me an unpredictable amount of more time, but this seems to be “unsafe”.

when i think about it, either way, no matter if the flow tells “off” and i manually want to switch it on, or the flow says “on” and i manually want to switch it off, there will always be a conflict between the activated flow and the manual switch.

how could i solve this? how could i either deactivate the running flow to have control over the manual switch, or implement the switch into the flow? the point would be to be able to control this WITHOUT having to go to the computer and connect to node-red on the cerbo and stop the flow…

could i add something like an on/off-switch for the node-red flow, that appears in the settings or in vrm?

thanks for your ideas!

[Xabi]

@habi

after 5 secs there will be a new value forwarded by the flow and it will close the relay again, although i just opened it manually in the settings.

Hello,
Try to tick the checkbox only changes in the Victron input node …

Xavier

[vcleto (Valdson)]

@habi

could i add something like an on/off-switch for the node-red flow, that appears in the settings or in vrm?

I think you need the same feature I asked about in another post. See the answer I got there:

Control button on the console to be read by a Node Red flow

V3.60 beta versions had a node called a “Virtual Switch” which added a switch pane to the console and could be used to control actions in a Node Red flow. I tested it and it worked most of the time but had a few problems which were not solved in time so it did not make the final release. The Virtual Switch node should return in V3.70 beta testing soon. Create your flow but for the moment using an inject node that has a 0 or 1 output and swap that to a virtual switch when they come back.

[UpCycleElectric (Jan)]

I’d like to add that you need to get your ‘logic rules’ well defined first, regardless of the implementation. With relays being controllable from multiple sources, the key question is what ‘signal’ is ‘master’ and when.
Once that is clear, you create a flow to reflect the ‘required’ relay status first, and use that to ‘lock’ the relay in that state by monitoring any changes (a) and resetting it to the required state immediately.
In some cases this can still leave a side effect to be solved: fast unintended on/off cycling (under 5 seconds) , that to my best knowledge can only be solved reliably by a hardware ‘delay’ timer relay set to a bit more than the regular 5 seconds (1 message per 5 seconds) that most Victron nodes use.

(a) By monitoring the changes you can also ‘catch’ desired state changes, for instance if you want a manual ‘open’ in the app to be a hard ‘off’ or only ‘off’ under certain circumstances or time conditions. Feed that to the decision logic to change the required ‘state’.

PS I recommend the boolean ultimate set of nodes to do logic operations in node-red , it includes boolean logic (with delay timer), basic math, flow interrupts and much more. A basic control flow connects the relay input node to an interrupt node to a boolean decision node and then back to the relay control node. That way you can interrupt the 5msg/s flow ánd control the state of the relay with the smallest possibly feedback loop (do not tick the ‘only changes’ box as you want that as a ‘heartbeat’ msg to trigger your logic-control that then in it’s turn controls the feedback loop by interrupt and a forced state signal)

PPS, I’d add at least one 1 second delay node in the feedback loop to prevent a possible runaway (race) condition that can instantly make your Cerbo lock up. Speaking from experience.

[Ernst (Ernst Lemm)]

I experience also unexpected behaviour of relais.

See:

How to determen what controlls the relais in Cerbo

For temperature control I use Node-RED and a temperature sensor. I configure the relais to "Manual’. With the for relais dedicated Node I can control only relais number #2. Every day there is a charge and a discharge cycle to earn on hourly electricity prices. The dayly cycle leads to fan-cooling during those times. However, in the log I see relais #2 switching unsuspectingly on. [image] Two periods, the right ones, are perfectly ok. The few times on the left is on moments the temperature …

[JFischer (Jeremy Fischer)]

@How to determen what controlls the relais in Cerbo

the for relais dedicated Node I can control only relais number #2. Every day there is a charge and a discharge cycle to earn on hourly electricity prices. The dayly cycle leads to fan-cooling during those times. However, in the log I see relai

Hello! Interesting Challenge. Unfortunately, the behaviour you describe is how node red works: it controls de devices according to some input and some logic you program.
As I see, you have two options (until Virtual Switch comes out)…
1 - Use some inject nodes to override the output via Node-Red as sugeste by @Valdson (this implies that you will have to open the node-red page every time you want to override the output).
2 - If you have a relay that is not being used:

• Configure both relays as manual.
• Let Relay 1 be the automatic one (the one controlled by node-red).
• Let relay 2 be the manual override.
• On the Node logic, use the Relay 2 status to override the output given by the logic that controls the Relay 1 (Something as “if relay 2 is on, then turn on relay 1, and if it is off, consider the output of your logic”).
  In that way, you could use the remote console to turn on and off the relays, but you will be using both relays for only one purpose.

[UpCycleElectric (Jan)]

@JFischer

On the Node logic, use the Relay 2 status to override the output given by the logic that controls the Relay 1 (Something as “if relay 2 is on, then turn on relay 1, and if it is off, consider the output of your logic”).
In that way, you could use the remote console to turn on and off the relays, but you will be using both relays for only one purpose.

Smart . Virtual switches are now back in beta in case there are no surplus relays available. (Could also be an unused BMV relay by the way)

[Ernst (Ernst Lemm)]

Hello Jeremy,
Thank you for looking at my topic and suggest a solution.

I think I understand your reply. Controlling a relais with two sources always need some logic, like witch source is dominant. However, I want to fully control a relay with Node-RED. The most simple flow would be messaging a 1 to the node controlling a relais. This most simple flow will not set relais #1 in my system. That I do not understand. Relais #1 will switch controlling it via VRM. The hardware seems to be ok.

Controlling Relay#2 with a Node-RED flow seems to work. However, occasionally I see the relais switching at unexpected moments, like something additional is controlling the relais.

[thomasinaz (Derrick Thomas)]

Something to keep in mind…the GX relays are not latching relays. If there is a system reset/reboot etc. the relay will return to a default state.

[Ernst (Ernst Lemm)]

Default relais status at boot must be defined. I could not find this in the documentation, but it is something easy to test and can be assumed.

However, my node flow is a series of: a trigger, every 10 seconds, calculation when switch on, and the node controlling the relais.

Interesting is the (faulty?) situation when context data "flow.Fan_State’ is 0 and the relais switches on.

Some more context info, the scripts: