I changed the ‘from’ value to a date before I had the charge point installed, and it correctly returns a total of about 200 charge sessions. Problem is, it only returns details for the last 50 of them 
so I don’t think this will work
@wout some work done by @siumba might give the answer… if only shell would document their systems.
internally there’s a request to url https://ui-chargepoints.shellrecharge.com/api/facade/v1/user-sessions/charge-points with a body of…
{
"chargePointSerials":["{{#payload.chargePointSerials}}{{.}}{{/payload.chargePointSerials}}"],
"endDateTime": "{{payload.end}}",
"offset": "0",
"sortField": "startDateTime",
"sortOrder": "desc",
"startDateTime": "{{payload.start}}",
"userId": "{{payload.id}}"
}
the offset bit might be relevant here? i’ll add something to make that changeable, and maybe setting offset: 50 will give the next block of 50 results with another request…? let me have a fiddle.
So I figured out what I was doing wrong with your flow before, so I got everything working via MQTT (getting and sending info). I don’t really understand why you want to trigger the flow via a button in Home Assistant, but that’s something else to discuss.
@wout What I did in the NodeJS app to get the total usage is to determine the firstConnection. FirstConnection is variable that gets the installation date of your home charger. This installation date is like the very first point that data can be generated. I do a select of all sessions since that firstConnection date and therefore I get the “total usage”.
I’m also updating my NodeJS app with the new Shell Recharge URL’s, then I can actually break down the URL for retrieving totalUsage ;).
1 Like
Would you be able to share your config?
I’ll share my config as soon as it’s completely done :).
The request for the total usage is located here: https://account.shellrecharge.com/user/SOMEGUID/dashboard/chargevisual.json?pointId=&chargeCardRfid=&type=point&from=1462744800000&to=1654639199999&_=1654628493218
This gives me a JSON with the following structure:
{
“chartTotal”: {
“totalkWh”: “15.409,8”,
“totalkgCO2”: “12.828,659”,
“totalTime”: 27103395,
“totalSessions”: 570
},
“chart”: [
{
“date”: “09-11-2019”,
“sessions”: 16,
“kwh”: 75.31
},
{
“date”: “09-12-2019”,
“sessions”: 46,
“kwh”: 687.9099999999999
},
{
“date”: “09-01-2020”,
“sessions”: 41,
“kwh”: 1091.5
}
]
}
I’ll see if I can update the flow with this logic myself. The Shell Recharge node is pretty complicated but I’m getting there.
I’ve already made some adjustments and I want this flow to trigger each 15 mins by itself and just post it’s payload to the MQTT topic:
The function behind the “info” request makes sure that the “to” date is filled with the current timestamp. The response part is being split up in “assets” and “energy”, publishing the payloads to their respective topics:
excellent.
@siumba i did some code for the endpoint https://account.shellrecharge.com/user/SOMEGUID/… already but i found it unreliable (not sure what the issue is, it needs some work). it’s in the subflow you have already but it’s deactivated. call with…
{
"action": "energy",
"from": 1651014000000,
"to": 1653605999999
}
keep trying, it’ll eventually work. i’ve also added some experimental code to allow something like below for @wout
{
"action": "info",
"from": 1651014000000,
"to": 1653605999999,
"offset": 50
}
Version is here with everything activated and available.
Where did you disable the energy part in the original one?
I’ve stopped getting any charge info with the new flow. Am getting a new error though "“Unexpected token F in JSON at position 0”
that’s probably the first letter of the error message ‘forbidden’. will probably work if you send a ‘flush’ payload then try again. will have a look.
there’s a node marked ‘guard’ near the beginning of the flow which will need to be edited to
(ready|^token|aftertoken|setup|vehicles|start|stop|reset|info|^poll|nopoll|flush|^refresh|norefresh|energy)
I’m also trying to figure out why the “energy” call doesn’t work consistently, but I didn’t find a solution yet. Is there an easy way to be able to debug your subflow template? If I copy all nodes into a new flow I’m not sure how to trigger it yet, that way I could set up some debugging. I also saw that your call for “energy” differs a little from “info” regarding the specific “change nodes”, where you check the token again, where you don’t do that in “info”.
When the “energy” path errors out I can call the “info” path and most of the time it works, sometimes it needs a second call on “energy” but it does work in the end.
This would be exactly what I’m looking for. Although I’d skip MQTT and directly update a sensor through the websocket integration. Should be able to get that sorted myself when you get the flow working.
i tend to wire a debug node after the node i’m interested in debugging inside the subflow then triggering it from an outside flow with an info/enegry/token/start inject node. the whole sub flow’s not really sorted for managing unexpected responses from shell and that needs tightening up (node-red’s not particularly good for collaborating, though, is it?!)
the only consistent thing i’ve found is that getting anything out of account.shellrecharge.com will be inconsistent and unreliable. i think it will have something to do with JSESSIONID-- if you examine the http exchange using something like charles it seems to change all the time.
not done anything, sorry @Wout. my setup’s working in a way that suits for the moment. how did you get on with the changes posted above?
No very well. The offset works of the individual session data, but it still ouputs a max of 50 sessions. So there’s no way to add up the energy numbers. The ‘energy’ action doesn’t generate any debug output for me.
there’ll be some nodered magic that could combine all the energy use information into one array/data structure… happy to have a look if you send it over
Anyone who found a way to integrate NewMotion without NodeRed?
I appreciate the offer, but it seems like a fragile solution that’s very dependent of what they’re doing on their side. I’m thinking of just using an induction based meter with clamps