ESS Control and VE.Bus System Control commands are not sticky

[thepaulcooper]

With ESS Control, when I set a new AC Power L1 Setpoint, it changes the value in my MultiPlus II GX momentarily but then reverts back to the original value. Similarly with the VE.Bus System Control, when I cause the node to change the Switch Position, it changes momentarily and then reverts back. Using nodes v1.4.1 and firmware v2.70-large-18. Is this issue because I'm using an older large image?

[mpvader]

Could be, but what ESS mode are you using? If its 1, or maybe also 2, then the GX will write to that parameter continuously

[thepaulcooper]

Many thanks @mpvader. I don't know about ESS mode numbers (where's this specified?) but I am using Optimized (with BatteryLife) and, for a short time, Optimized (without BatteryLife). I can see why the GX might be writing the AC Power L1 Setpoint continuously. But what about VE.Bus System Control | Switch Position? Can you explain why this isn't sticky?

[mpvader]

Hi, please see this document: https://www.victronenergy.com/live/ess:ess_mode_2_and_3

and with that you’ll have to piece the ends together yourself I’m afraid, or ask for help on community. From Victron side we don’t offer more detailed support on that.

wrt the on/off/charger-only switch: see Cerbo Gx manual for when that switch works and when it does not.

all the best! Matthijs

[thepaulcooper]

Thanks for the pointers to the documents. You're right, the ends do need to be pieced together. It would be nice if the documentation did that! I note that you have closed this issue. I still think there is a problem with the Node-Red node called VE.Bus System Control. When I control the switch position using the GX virtual interface:

...it works correctly. I can set it to charger-only which is what I'm looking to do using Node-Red. Unfortunately the VE.Bus System Control node doesn't behave the same way when sent a message with a payload of 1 (Charger Only) when the node is configured to control the Switch Position. I'm happy to continue this over in the community but I thought this was the place to report apparent issues. Many thanks for your help and patience.

[mpvader]

👍

@dirkjanfaber pls look into the vebus on/off control

[mark-cor]

Hi @thepaulcooper, could you maybe share your flow to provide some more insight?

I don't seem to have the issue that you are reporting, but do have a suspicion - do you maybe have a VE.Bus System node and a VE.Bus System Control node with the same parameter in the same sub-flow? (ie. VE.Bus System node used as an input to update Node-RED with any changes made via the Venus UI) If so, this can cause the behavior you have noted, unless you add some additional logic to temporarily block messages from the VE.Bus System node.

[thepaulcooper]

Thanks @mark-cor. I do have both the VE.Bus System and VE.Bus System Control nodes but one is output and the other is input so I don't see how they would clash. However, having tried the Switch Position control again this morning it has suddenly decided to start working! I can't explain this as it was not working a few days ago. Anyway, if you want to see my flow you can find it here: https://github.com/thepaulcooper/victron-openEVSE Many thanks for your help with this matter.

[mark-cor]

Hi @thepaulcooper, when you have both read & write in the same sub-flow you will find that they clash sometimes, but not always. This is because there is a small delay when you specify the state via Node-RED, and during that delay time it might receive the current (old) state (which it reads at a regular interval) and then overwrite the newly requested state. To avoid this you can add some extra logic to ignore receiving the current state for a short period of time after it is changed via Node-RED - something like this (with the ignore state stored as a context variable).

[thepaulcooper]

Hi @mark-cor, thanks for the explanation and the recommended extra logic. I've simplified it for you in the attached diagram. I think this will work just as well and doesn't require the use of a context variable.

.