Well, import of an example resulted in selection of the original VRM-API Node. Changing it to the alpha node removed the 2nd output option somehow. Just adding the alpha node does not show that extra output option either. Any ideas?
…Deleted image to hide siteID…
See 1st picture 
Oh, had to delete that picture for showing site ID but yes I had installation stats ánd Dynamic ESS selected. The issue is real. I guess maybe you had a clean install of the alpha node ? Not on top of a full active flow with several VRM-API calls running? It was also strange that importing the example flow from the alpha, auto selected the non alpha VRM-API node, that must be related. Possibly version no conflict (as in the alpha has same version no)
I’m not to happy to try and reset Node-RED again, had to manually reconnect each and every virtual devices node for half a dozen virtual devices.
I also had to replace the node with the alpha one, but other that that it just works:
Try reinstalling the node and/or restarting (not resetting..) node-red.
Uh:
[quote=“Jan, post:23, topic:47229, username:UpCycleElectric”]
I’m not to happy to try and reset Node-RED again, had to manually reconnect each and every virtual devices node for half a dozen virtual devices.
[/quote
]
Anyway, looks like it that second connector simply outputs the the price schedule in P only, no price formula applied, is that correct? I can reconstruct that by adapting the function node I was working with here:
The second one uses the price, based on the configured formula.
See victron-vrm-api/src/nodes/vrm-api.js at f3b9f560007b676a87d2037e69ba01ca1debd78e · dirkjanfaber/victron-vrm-api · GitHub
and victron-vrm-api/src/utils/price-schedule-transformer.js at main · dirkjanfaber/victron-vrm-api · GitHub, which does that transformation.
Nothing too fancy indeed, but saves the need for an extra function node and probably more efficient.
And this can be extended upon of course.
I simply assumed you would have used, or reverse calculated, P to prevent the question buy or sell price. And a bit of wishful thinking I guess, as it is much easier to work with P itself. Anyway,mI got stuck on the alpha version not being selected by the example flows. And the 2nd example seemed empty but I didn’t investigate further
A second noderedreset deleting virtual devices from the vmr device list before reloading the backup flow made life a lot easier.
Also tested the alpha first, as snowwie already mentioned, you still have to replace the vrm-api node in the 1st example, but now it did indeed have a second output. I looked around a bit, seems to work as expected now. I see a bit more choice in preselecting parts of the full scheduler object, that’s not bad. But to be honest, by the time you get to know the scheduler object, not really needed either. Or am I overlooking something there? Anyway, as far as I can see vrm-api_alpha is the unbroken one, that’s great news, thanks!
UPDATE: @dfaber Please check the screenshots below before release…!
Then last but not least, is this a good time to mention upgrading the venusOS scheduled SoC precision to float? And the port of b_goal_soc & b_goal_hour to vrm-api, or is it too soon for that still? It won’t go away and I think you guys severely underestimate the magic that can be worked with a pre-scheduler (as in: input to the scheduler) targetSoC@future-timeslot setpoint, it would impresively simplify the life of my Node-RED SoC Monkey, why not give him that banana to hunt for? 
Is this correct:
Duration is 900 alright but why limit the schedulers output to only 48 timeslots and trunc SoC to INT like the venusOS Scheduled SoC timeslots, you should go the other way around really. What is the rational to throw away precision at this stage already? This way you are locking in at the API level, a roadblock against any future SoC precision upgrade at the venusOS schedule execution level. That can’t be right. I can see utility in providing the structure this way but that is the easy part. The hard part is rounding up or down to the correct INT SoC which depends on the direction of the energy flow, to or from the grid. Something like this:
Last night I (quickly) tried your price analysis example but didn’t get it to work yet (some errors in functions and didn’t have time to really read into it). Nevertheless, the functions seem a bit overcomplicated for my needs - in VRM-API 0.3.1 this works:
I have set a multiples-timer that fetches the price every 15min (or if force-injected) and from there I can send current price information to all my other flows and devices to make logical choices. How would I approach this with the newest api version, as there are only half of the values available and [95][1] no longer exists?
The reason I need this to work on 0.3.6 is that Cerbo draws it’s power from the battery and the raspi with 0.3.1 is directly in mains 
Will be a total mess in the logic when power goes out
See also here @dfaber V3.70 beta - DESS related - #51 by UpCycleElectric
That is already being worked on and will be added in one of the next beta’s.. Don’t want to go too much into technical details, but once a certain dbus path is defined as an integer, it isn’t possible to alter that to float. Which means adding an new path and adjusting all the software to look and write to the new path.
There are “only” 48 slots available on the dbus, which I’d say is more than need to be filled.. Each schedule contains 15 minutes, so it schedules ahead for 12 hours. Not sure about your system, but during 12 hours most other systems tend to wander of the forecasted route. Which is why VRM updates the planned route every 15 minute. The Node-RED example flow limits it to just 8 hours.
We added that many for the VRM scheduler to allow for both expected maintenance and unexpected downtime of the scheduler or the users internet connection.
@sarka9000 You are now trying to get the value from the schedule. You should take it from the stats, where [95][1] can be taken from.
Yes I was expecting there to be low level implications needing to be resolved.
Update: reading is an art in itself, you already said next beta, never mind the following remark (will leave it for posterity): If I may do a suggestion: if (and only if) the v3.70 beta is nearing the end, I could see a rational to shift this to v3.80 beta.
Not trying to shoot myself in the foot here, as (one of) the biggest advocate (s) of this change, but putting this at the front instead of at the end of a beta test period might be the wiser option here.
I didn’t catch at first that this output had a structure targeting the VenusOS (dbus) schedule records.
Anyway, if you guys keep it up this way, I’ll soon run out of DESS pet peeves to nag you about, only the b_goal_SoC/hour pre-scheduler target left. I’ll have to return to boat page development then (independent battery select for boat page leading the list).
I’m confused. I have no such option in my vrm-api node which I have taken from the palette myself, see below:
However, when I try your price analysis example, the option shows up but with only 24h mode:
Should I see also a non-deprecated version?
Ah, I though you where mentioning the alpha version that was linked to in this thread.
The latest beta carries a somewhat broken version. I’ll tag a new release shortly (based on that alpha) and try to get that in the next beta asap.
Ah, that makes sense. So many versions, so little time 
VRM-API 0.3.7 in todays beta v3.70~54
Same as 0.3.6 alpha1?
Any specific do’s and don’t on how to update, remove the alpha first for instance?
And is it safe to assume that the VRM-API secondary output for installation stats DESS will change from INT to float together with the upcoming d-bus schedules SoC INT to float implementation?
Just saying, this is how a a well behaved DESS Trade System looks like under a 15 minute pricing regime:
Yes, it is identical to the alpha version, which is safe to remove now.
