It might not be obvious why this is important unless you factor in ongoing troubles with DESS not (yet) being the one size fits all ESS solution it is more or less marketed as. There are currently quite a few community members trying to use Node-RED to make DESS ‘behave’ as ‘required’ but none of that is (yet) very well structured, let alone managed as a shared community effort.
Having this tool (A) to better show and share flows and possibly some involvement of you yourself to help centralize those efforts would be quite valuable for the further development and improvement of DESS.
Would Victron be willing to consider making DESS a separate ‘top level’ category all by itself, instead of ‘just another’ topic under Node-RED? I think that would be a good start.
Thanks, my suggestion isn’t so much about this forums structure itself as it is to find ways to improve upon the ongoing collaboration between forum members as a community as well as between the community and victron itself.
Currently everything is scattered all over the place between here, old forum, github and probably other places such as the Node-RED forums and repositories as well.
Having DESS defined as a category by itself is just one way of trying to create more structure and support towards such collaboration and as such not critical by itself. But all things considered it could be a relatively simple change with a high payoff if it could kickstart better visibility and focus on said collaborative effort to improve DESS.
Some separation is helpful, as a rule we don’t want nodered content mixed in other sections, much like content for the modifications category. When everything intermingles it can make searching more challenging.
DESS was put into its own sub-category as many users have no interest in the feature and did not want the volume of posts we saw at launch cluttering timelines. Those that were invested in the tech needed a dedicated area for it.
As I understand it, Victron’s node red variant of DESS was discontinued, so DESS topics in the mod/nodered space are very much around modifying or customising the default behaviour for different use cases.
IMO that probably still belongs in that section, while feed back or discussion on the current issues, limitations etc belongs in the DESS space.
Anyway, structure is for Guy to decide what serves the greater good.
It’s great the work you’re doing, the enthusiasm and desire to help. No community thrives without the dedication of its members, so thanks and keep it up.
This makes me a little nervous. As far as I understand it is a) not true and b) we depend on Node-RED DESS to achieve even a modicum of functionality to make DESS Trade behave.
What is true is that plans to phase out Node-RED DESS were announced with the added warning no effort will be made to implement 15 minute scheduling for Node-RED DESS. The rationale is well understood and also announced intentions to port over all Node-RED DESS functionality to VRM DESS and to be available via VRM API. In theory this should provide a reasonable path to migrate away from Node-RED DESS indeed.
But here is where things started to get skewed.
Despite multiple requests to enable, implement or otherwise make available an alternative for the option to pre-set a specific target SOC at a specific time for the (cloud based) scheduling system (as currently done by setting b_goal_SOC and b_goal_hour for Node-RED DESS), nothing has been done to actually do so.
Even worse there seems to be no awareness that the VRM-API route is not (yet) offering full functional compatibility with the Node-RED DESS implementation.
Combine that with the fact that scheduled SOC targets do not work in combination with VRM DESS we saw no other option than to create a hybrid DESS system first and foremost to bridge the time until either the b_goal_xxx gets ported over. Or of course scheduled targets are getting enabled.
The ‘getting a little nervous’ that I started with is because time is running out quickly. Here in NL tibber was supposed to switch to 15 minute scheduling last month June already. Those plans have been delayed a couple of months but once they do make that switch, DESS Trade will become useless again because Node-RED DESS won’t be able to work with that. And thus null and void our intermediate hybrid solution.
That’s an interesting observation and a double edged sword in and by itself: I think it shows both the high level of interest in DESS offering real value added functionality to the Victron platform, as well as growing frustration with the limitations of the current implementation and lack of visibility of the roadmap for future developments and improvements.
I guess my position in this is reasonably clear: I’d rather see Victron try to do with DESS what it already did with VenusOS, open source the whole toolchain from the multiplus’s assistants to the cloud based master schedulers and focus on supporting the community to collaborate better in more structured and efficient ways.
The fact of the matter seems to be that the customer base will (always?) be able to try to get more use cases work based on their perception of what DESS is and should be able to do, than Victron’s dev team is able to design and implement in a resource constraint reality of a real (and primarily hardware focussed) tech business.
