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:
