Bug in VRM-API DESS

Node-RED
,
1

Last night @snowwie and myself discovered an inconsistency in the DESS schedules provided by VRM-API:

When setting DESS parameters with (A) the VRM-API node, API type: Dynamic ESS, with b_goal SOC and b_goal hour set (not 0), the resulting msg.payload object provides a schedule consistent with the set b_goal SOC and b_goal hour values.

But, when reading the resulting schedule through (B) VRM-API, API type: Installations, Installation: Installation stats (from beginning day to +48 hours), the resulting msg.payload object provides a different schedule that ignores the b_goal values preset with (A) and subsequently targets minimum SOC at the end of the known pricing schedule.

This inconsistency can be reproduced by a test flow with the two (A) (B) VRM-API nodes with the “Store the response in the global context?” setting active, using injection node(s) to trigger (A) then (B), and comparing the resulting SOC schedules stored in the global context for the scheduled SOC at the b_goal hour: this will be the b_goal SOC for (A) but not for (B) with (B) showing a scheduled SOC at or near minimum SOC at the end of the known price schedule at midnight for a DESS Trade setup.

For more information see: Phasing out the Node-RED Dynamic ESS implementation - #50 by UpCycleElectric

Proposed solution: align the schedule output of (B) to that of (A) to retain the b_goal SOC at b_goal hour functionality.

Alternative solution: “enable/implement” the GUI(v2), Settings, System Setup, ESS: “Scheduled charge levels” to function in combination with “VRM DESS mode 1 (auto)”. Although the Scheduled charge levels” can already be “enabled”, they do not have any effect when DESS is active

Alternative workaround: update the VRM-API documentation for the VRM API node, API type: Installations, Installation: Installation stats, Get Dynamic ESS configuration, Modify Dynamic ESS configuration and Add Dynamic ESS configuration. Provide better insight in the working of these API calls in relation to the scheduler running in the VRM cloud, and the way these do or do not allow to implement / port the functionality currently provided by the b_goal SOC b_goal hour settings for the Node-RED DESS implementation mode 4.

Regression (to avoid) : incomplete / postponed port of this (critical) functionality as provided by the b_goal SOC b_goal hour settings until 15 minute price scheduling will leave current users with no solution at all.

Final request: please provide clarity on Victrons intentions for VRM DESS in light of above issue. The current state of affairs presents an unnecessary uncertainty on the awareness and the intentions of the dev team. This is not a new issue, it’s been known since the day that the phasing out of Node-RED DESS was announced, I’d much appreciate to see some response/discussion/movement on this topic before we get to a point where it will be a fait accompli that current solutions and workarounds simply stop working and all affected by it come crawling out of the woodworks with highly urgent operational problems.

2 Likes
2

Not a single response from Victron. That doesn’t bode well. Makes me wonder why I even bother to invest so much time in testing and reporting and trying to be helpful in general.
@dfaber @mpvader @nickdb
I don’t expect instant solutions but an acknowledgement of the stated bug (the inconsistency in scheduling outcomes within VRM-API calls) is not too much to ask is it?

3

With respect. As per our guidelines this is not an ask victrron site.
We are fortunate to have staff presence here but getting a response is not guaranteed. It is also holidays, many are on leave.
There is a broad base that everyone tries to keep happy, it is not just about individual requirements, no matter how passionate you are about it.
If you want formal responses follow the support process but please resist demanding attention by tagging staff; it will just end with moderation and we really want to avoid that. Thanks for understanding.

4

Really? No I do not understand why policing this forum is more important than acknowledging a good faith bug report. Moderate me if you feel you must.

5

I’d say that my response here was clear. Also, we are not phasing out the old system until the new version works as good, or better, than the previous one.

Bug reports for the VRM-API node can be posted here.

6

I am aware of that statement back then. But it was and still is not clear because there is no context provided whatsoever and therefore raises many more questions than it answers, here a few examples:

  • Why signal the future removal of functionality actively in use, proven to be valuable (to us)?
  • What will it be replaced with?
  • What are your criteria to evaluate the quality (fit for purpose) of a new version compared to the previous version?
  • What does ‘version’ relate to? DESS, API control of DESS, the scheduler system?

The above illustrates another, non-technical, problem: To all but a few select insiders, information on the future development of DESS is shielded from the actively involved user base. There is no publicly available roadmap, documentation is scattered, sometimes outdated or incomplete.

I guess my point is that I find it strangely ‘unfitting" that Victron is activity inviting its user base to participate in beta testing but at the same time refuses to provide a glance into ’ the kitchen’ of what it is ‘cooking’ for the future. Asking us to do field testing in the areas deemed important in the short time to (the sales team of?) Victron while at the same time telling us in so many words to ‘shut up and be happy with what you get’ and to ‘trust the team’ on areas I/we think are valuable and important in the not to distant future, is just not cutting it for me. Not to mention the not too subtle ad-hominem attacks (Dunning-Kruger) and threats of being cancelled (getting moderated). And I believe I do not stand alone in this matter. This is not a one way street, without community participation Victron would not have been able to get to where it is today.

I do appreciate the pointer to the correct place to post bug reports, thank you. Someday I will indeed create a GitHub account to report the above DESS problem as a bug there. But without an open dialog on the bigger issue I touch upon in this post, I hardly expect reporting a bug on GitHub will help any of us.

7

Hi Dirk-Jan, I only start using Victron since beginning this year and got the impression this community forum would be actively monitored by Victron staff.

Apparently I misunderstood. Therefore I’d like to have some clear ‘how to get support and post bugs and feature request’ beyond what the supplier I bought the Victron equipment from can offer. Things like the bug report Jan posted is not something a supplier can answer and i think it would be unfair to use suppliers as means to get such request to you.

You pointed us to a github page for a specific componenet, but what about other componennts or usage issues or feature request.

I guess the goal here is to get a clear and supportive interaction between Victron supprt/development and the community.

If this community forum is just for the end users to discuss thing amongst each other and we are just lucky some supprt staff is participating coincidently, then make this more clear so the end users can have som better ‘expectations’ around this.

8

The name of the forum is “Victron Community” not “Victron Support”.

Some topics are monitored by Victron staff and in some cases the moderator team will escalate critical topics directly to Victron.

9

@M_Lange
Indeed, but the “community” word is different in the views of many.
I’ve came with great hopes in this community, one of them being the fact that naturally - of course, in my opinion - the duty of the more knowledgeable is to teach/help the beginners to walk on their own feet.
In the end, it’s a community of enthusiast, right? Wrong!
Imagine the feeling when one of the staff/experts told me that they don’t have any such duty and need to do squat for any user.

So, @UpCycleElectric , soon I’ve realized that it’s more of a “get a free and quick feedback from the users for fixing our errors” place.
The same, in the beginning, I’ve tried to tag the persons that I’ve thought that are responsible, but soon I was put in my place, with the same line, “please resist demanding attention by tagging staff; it will just end with moderation”.
Which I was… Moderated…

So, good point @marcelmol , maybe some need to be clearly stated, “so the end users can have some better ‘expectations’ around this”.
But that will make more clearly the fact that it’s kinda “don’t call us”, we’ll call you when we need more “testing and reporting”.

For sure, I will get moderated somehow, like when I was trying to suggest to be more (beginner) user friendly and not behave like in one of the George Orwell novels… :wink:

Now I am just staying and trying to help if I can.
I’ve given up expecting help from Victron, because, without modesty, I am from the few that can reverse engineer my products, hardware and software.
And that, thanks to the attitude of some of the “experts” here that moderated me…
Thanks again for giving a kick in my b*t! It was a step forward. :zany_face:

10

Back to the technical side: The current VRM DESS implementation as-is does not work at all for a bare bones DESS Trade system because of the missing ability to provide the scheduler (at least one) intermediate target SOC before the end of the known price schedule. I have build and tested a plethora of custom flows to get around this problem and seen many other people struggle with the same problem. In a straightforward Trade only system the issue is clear as day, in more complicated systems with Solar and smaller batteries the problem get obfuscated but is still present. After months of monitoring and testing the conclusion is unavoidable: DESS Trade cannot be made to work autonomously (for a reasonable period of time) without the ability to instruct the scheduler when (what time of the day) it needs to target the highest charge level (of the timeframe of interest: those hours for which the actual hourly prices are known).

We can discuss forum policies, netique, business vs private interests for as long as we want, without acknowledging the technical issue at hand, nothing will get solved.

1 Like
11

I stand by my previous post.
I do not appreciate the suggestion that I demand attention. I do not randomly nor lightly ping Victron staff, so when I do you can safely assume I have serious concerns that made me believe not to have any no other options left.
And I already pointed out before how I think of the ‘fast shooting from the hip’ reflex to frame the messenger as stupid with a hint to possible cancellation to boot.

The path to a solution is simple: publicly acknowledge that VRM DESS Trade is broken as-is. Then and only then can we work towards an fitting long-term solution.