Venus OS V3.55 and lower accept negativ day to disable scheduled charge
V3.60~74 returns “invalid enum value”, enable (7-everyday) is working, .
Used this to force charging in generator is switched on.
Is there an alternative to deactivate schedule charge?
additional info:
in V3.55 enum of “victron-output-ess”-node "Schedule x:day was not checked and negative numbers where accepted ,V3.60~74..~80 do not accept any more.
All flows using this node for de-activating scheduled charging will not work anymore.
In my flows I will use customcontrol-“/Settings/CGwacs/BatteryLife/Schedule/Charge/0/Day” instead.
But the help should be corrected
“A negative value means that the schedule has been de-activated.” is not correct for V3.60~80.
or
the enums in the node template should also cover the neg numbers.
Good find. I’ll see if I can add that to the next release, containing some more cosmetic fixes.
1 Like
On the latest v3.60 beta you are able to write a -1 to the enum, meaning disabled. Note that you will need to remove the node and re-add it in order to make that work (under the hood the node stores its valid values and that doesn’t get updated with firmware updates).
Works perfect in ~84! Many thanks, great job!!
One little remark from my side: you can remove the remarks
“A negative value means that the schedule has been de-activated”
because only -1 is de-activating the timer, in past every neg number could be used.
Greetings from Austria!
One little remark from my side: you can remove the remarks
Yes, you are right. Thanks for spotting that.
The ‘ESS node, Venus settings, Schedule 1: Day’
outputs
‘-8 (undefined)’
Is this correct behavior for that value to be negative (of the actual value: ‘Weekdays’)?
The system, under the hood, works lik this: all negative numbers are allowed to disable a schedule. The gui just makes the current value negative.
That isn’t ideal on the node-red side of things, as I define all possible values in the service.json file and prefer to somewhat limit the size of that file. Hence the fact that I only define -1 there.
So at can indeed happen that a schedule that has been disabled by the gui can output -8 (undefined). Not ideal, but right now that is what it is.
For the next updates for the node-red-contrib-victron package I am planning on making some adjustments to the way things get defined in the services.json file and better cope with this.
I did not (manually) set any schedule (yet), just trying to figure out how DESS populates/stacks/rotates those schedules.
I did however just set the system to ‘Keep batteries charged’ right before reading these schedule values. I assume that is why it outputs the negative of 8.
I am trying to find a more suitable way to temporarily force charging than switching the ESS state (to keep batteries charged) as shown in the flow here: Phasing out the Node-RED Dynamic ESS implementation - #8 by UpCycleElectric
Questions:
- Can I do the same as you say gui does: read schedule 1: day and write the negative thereof to schedule 1: day and setting target SoC sufficiently high?
- How do I reverse/end force charging, simply reverse day to a positive value again and write current SoC to target SoC?
- Is there a better solution that ‘messes’ less with DESS normal operation? A more suitable setting that I missed?
- What (and when) triggers DESS to update the schedules (back to regular operation) after manual/automated intervention to force charging?
Bit diverting from the original topic, but Dynamic ESS uses its own schedule slots (under com.victronenergy.settings / /Settings/DynamicESS/Schedule/).
Thanks, digging deeper I into the rabbit hole I came to the same conclusion.
So far I have identified an ESS, a VRM DESS and a Node-RED DESS schedule to consider, seems quite complicated for simply wanting to override standard VRM DESS Trade to force it to charge on demand when prices are low. But I’ll get there (and on that note will move on from hijacking this topic).
Just two addition al remarks to make:
- Both the VRM DESS and Node-RED DESS use the same scheduling mechanism.
- The current Node-RED DESS implementation is being phased out in favour of a (new) VRM-API node call. I hope to finish that within the next 2 weeks.
Understood, it turned out to be much easier to learn how to work with the Node-RED version, primarily due to its implementation being a lot more accessible (even with the core scheduler being run in victrons cloud). Once over the initial hurdle of grasping the basics of DESS inner workings on Node-RED, the move over to VRM DESS isn’t as daunting anymore.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.