I’m writing Strategy=1 (Self-consumption) to /Settings/DynamicEss/Schedule/0/Strategy via victron-output-dess node. The write succeeds (green status on the node), but the effective strategy on the system layer (/DynamicEss/Strategy) doesn’t change — it stays at 2 (Pro battery). VRM API also still returns the original value.
Is this expected behavior in Mode=1? Does Venus OS ignore writes to the settings layer when VRM Auto is active?
If yes — is there any supported way to override the active slot strategy from Node-RED without SSH, while keeping Mode=1?
Cerbo GX, Venus OS 3.80-14, DESS Mode=1 (VRM Auto), Green mode on, no SSH.
No, you can overwrite that and DESS will pick it up. Mind your System may eventually just not be working on Slot 0, you need to check the timestamp and duration to see which slot is active.
Earlier releases mostly went from 0 to 4 within an hour, later versions use 0,1 until the scheduler moves the active window to 0. (Not sure, when that changed, may be connected to hourly vs quarter prices as well)
Which version of venus are you on? Later versions also serve the system/DynamicEss/WindowSlot (iirc) path, where it outlines which slot of the schedule is currently active.
Should be working for either version. You just have to publish the number there (0, 1, 2 or 3), not the exact string, maybe that’s the issue?
Also make sure you select the “number” type from the dropdown in front of the value field in Nodered. If you send “1” as a string, settingsdevice will probably reject it.
No sure about the ‘supported’ part but it is definitely possible to completely take over the DESS execution schedule (the one that lives on the D-BUS) while running mode 1. I have that running for many months already. In a nutshell what I do is:
Subscribe to the same MQQT broker that pushes the new schedule to VenusOS (once per quarter hour under normal circumstances as Dognose also says)
As soon as that push arrives, immediately restore from prestored values any DESS key values that are (at the same moment) changed by the incoming schedule and ensure the currently active ‘window’ stays ‘locked’ to these pre-update schedule values. This buys time to process the schedule update.
Store the newly received schedule update and trigger a post-processor when the complete schedule has been received.
Post-process. Here you can apply any logic you want, I use multiple custom-strategies: hold, self-consume with MinimumSoc adaptation, full sell, full buy, boost sell, boost buy. The latter two based on time shifting the received schedule forward in time (minutes adjustable with custom slider in GUI v2), tricking the DESS execution engine into a ‘running behind’ state that ensures it will consistently run at full power, no matter whether it buys or sells. But only when already scheduled to buy or sell during the current window. This was my key objective for this flow, it completely removes the over/under selling/buying and back selling/buying artifacts when the predicted consumption/production deviate from actuals.
Compute a custom schedule table and write that to the D-BUS. At minimum for the first two ‘windows’ but in practice upto 12 hours ahead.
Release the hold ‘lock’ set in 1.
All these steps take less time than the 5 seconds update loop of the VenusOS DESS execution loop, resulting in a seemless control takeover with full retainment of mode1 functionality and, most important, all it’s safeguards unaffected. On top of that, the step 1 lock times out after 5 seconds to ensure standard DESS operation in case anything fails or hangs in the custom schedule processing.
Thanks for the detailed writeup — the lock mechanism during schedule processing is really elegant.
I’m solving a simpler variant: fixed purchase tariff, dynamic sell price — so the only goal is to neutralize Pro battery slots and keep Self-consumption behavior.
What I do:
Monitor /DynamicEss/WindowSlot (custom input node) to always know the active slot index
Poll every 5s, read active strategy from global context
If strategy != 1, write Strategy=1 to /Settings/DynamicEss/Schedule/{WindowSlot}/Strategy via victron-output-dess
Venus OS picks it up reliably — ReactiveStrategy=1 confirms writes to the settings layer are respected
MQTT is available on my setup but I didn’t think of using it this way — your approach of intercepting the VRM push directly is interesting and would give much cleaner timing than polling.
One open question: balancing slots. I can identify them by the combination Strategy=2 + Soc=98 + AllowGridFeedIn=false, and plan to pause polling when detected. But I haven’t been able to test this yet (next balancing expected ~April 28).
How do you handle balancing in your post-processor — do you pass those slots through unchanged, or do you have a separate detection mechanism?
Rebalancing: my batteries are Li-NCM and hardly need to balanced (think once a year). I do run another flow that provides a buy bias to counteract the build in sell to minimum SoC bias of the current DESS trade algorithm. This ensures the system hits 100% often enough to keep SoC perfectly aligned.
Under the hood, the code that executes the DESS schedule on VenusOS in mode1 subscribes to a special schedule push MQQT broker in Victron’s broker cloud. This is how the schedule updates arrive on your systems D-BUS and is fully independent from the optional MQQT broker on VenusOS that can re-publish (any) D-Bus values to other clients.
If you can help to convince Dognose that Victron really needs to port the b_goal_SoC / hour function from Node-RED DESS to VRM DESS, I will rethink making my control flow publicly available to this community. It took me almost a year to make it fully failsafe, especially the timing of the lock and release code was especially ‘interesting’, debugging race conditions on a millisecond scale, to achieve full takeover safely without unwanted state changes during the critical 5 seconds around the schedule update push, without the need to poll for after the update D-Bus changes. My code doesn’t poll anything, it actually front-runs the D-BUS schedule updates.
If I had to balance, I would implement a watchdog flow that monitors the SoC schedule and makes sure to pick one of the days that are scheduled to charge to 95% or higher, and force that to 100% for a a certain balancing time. Bypassing the ‘baked in’ balancing function altogether as it seems awfully unintelligent (to me). But even a single hour at 100% per week provides ample balancing time for my battery system, I never see a delta V over 5mV (in rest) between 30% and 100%, and only below 30% a little more, upto 25mV when nearing full empty. Li-NCM has distinct advantages, this being one of them.
I’m in favor and agree that it would be very beneficial. I don’t yet have the knowledge for such sophisticated modifications, but I’m also struggling with schedule updates. For a simple strategy change, it seems that using the currently active slot and overwriting the strategy within it works. The problem is that schedule updates are practically unpredictable…
I have Pylontech batteries, and balancing is a problem in itself there. If only one hour at 100% were enough. I agree that monitoring a planned SoC above about 95% is the way to go. I haven’t found where to get information about scheduled charging from VRM (DESS), apart from the icon in VRM. I’m considering creating a completely separate logic for scheduling balancing and bypassing the built-in function entirely. But with Pylontech’s passive balancing, it’s still complicated.
Hint: you will need to ssh into your venusOS only once to find the broker path and credentials of the schedule push broker, then use those with a standard MQQT node in Node-RED.
