batpred
batpred copied to clipboard
Publish a JSON version of the plan
This is based on the publish_html_plan method, but it makes a plan_json entity with only the data.
The bit I haven't done yet is the split slots (is that where there's a charge and a discharge in the same time slot?)
Example JSON output:
{
"plan_starts": "2024-07-07 11:45",
"last_updated": "11:45:00",
"version": "v8.2.4",
"config": {
"best_soc_min": 0,
"best_soc_max": 0,
"best_soc_keep": 0.5,
"carbon_metric": 0,
"metric_self_sufficiency": 0,
"metric_battery_value_scaling": 1
},
"slots": [
### Then lots of entries which look something like this:
{
"soc": {
"percent": 67,
"percent_end": 62,
"percent_end_window": 62,
"percent_max": 67,
"percent_min": 62,
"percent_max_window": 67,
"percent_min_window": 62,
"change": -0.69
},
"state": {},
"pv": {
"forecast": 0
},
"load": {
"forecast": 0.65
},
"rate": {
"start": "Sun 23:00",
"import": {
"value": 16.59,
"adjust_type": "copy"
},
"export": {
"value": 0,
"adjust_type": null
}
},
"cost": {
"start": 72.269,
"change": 0,
"currency": [
"£",
"p"
]
},
"car": {
"charging_kwh": 0
},
"iboost": {},
"carbon": {},
"span": "not in_span"
}
### (end of the "lots of entries" object) ###
]
Things I think could be improved:
- Some indication of the split slot thing
- The
adjust_type, I'm not sure of the logic around that - I just copied the
spanlogic (which is used for the HTML rendering, I'm not sure if it has relevance here)
Things I think could be improved:
Some indication of the split slot thing
The
adjust_type, I'm not sure of the logic around thatI just copied the
spanlogic (which is used for the HTML rendering, I'm not sure if it has relevance here)
That's brilliant @magicmonkey , very much follows the sort of idea I had for the structured JSON output.
A few suggestions:
- currency could be pulled into the header rather than repeating per cost
- I think the span logic is useful to include, because if the aim is to be able to create the html output from the json then it makes the transformation easier if it at least knows about the spans. I'd suggest the transform of json to the html is a desirable aim so the html plan could eventually be retired rather than having two things in Predbat that do much the same
- Did wonder about including some indication of the h/m/l values that predbat assigns to some entities (eg high PV, low load), but this probably isn't best practice and is better done in the json rendering
- Change the PV and Load structures to be nested json, containing PV and PV10 for example - also allows for further expansion
- Wonder if the SOC should be made a sub node under state, so for example: state: { mode: Idle soc-start: 80 soc-end: 85 } { mode: Charge soc-start: 85 soc-end: 90 limit: 100 }
Would give a way to handle split modes and also the ability to link the limit to the individual modes whereas at the moment the limit is only for one, so if in a 30 minute slot predbat is both charging and discharging, the limit is a bit meaningless
- A number of new soc fields I don't know what they mean !
Thanks @gcoan , I've implemented some of those suggestions:
currencyis moved into the top-levelconfigstructure and removed from eachslotsentry- Added PV10 and load10 - I'm unsure if these should be inside a top-level
forecast, or if the top level should bepvandloadlike it is now - I've made the
spanentries more explicit - Personally I don't think the h/m/l should be there, these are purely "display" logic, but I can add these back in if it would make things simpler
socis moved understate
I still haven't dug into the splits logic, but I'll have a look at that when I get a chance.
Also, I missed the actual "publish the entity" bit earlier, I've added that back in now. Oops!
Updated example of a slot:
"state": {
"soc": {
"percent": 61,
"percent_end": 61,
"percent_end_window": 61,
"percent_max": 61,
"percent_min": 61,
"percent_max_window": 61,
"percent_min_window": 61,
"change": 0.01
},
"mode": "Freeze charge",
"limit": 61
},
"pv": {
"forecast": 0.02,
"forecast10": 0.02
},
"load": {
"forecast": 0.2,
"forecast10": 0.22
},
"rate": {
"start": "Mon 05:30",
"import": {
"value": 15.54,
"adjust_type": null,
"charge": true
},
"export": {
"value": 0,
"adjust_type": "copy"
}
},
"cost": {
"start": 159.493,
"change": 2.93
},
"car": {
"charging_kwh": 0
},
"iboost": {},
"carbon": {},
"span": "not in_span"
}
Great idea :)
BTW: The span thing is just to merge multiple rows of the same (e.g. charge or discharge) together for visual purposes. Maybe the JSON can just ignore that?
Maybe the JSON can just ignore that?
Agreed, I think I've removed that logic now.
Excellent, thanks @magicmonkey be interested to see what @pacemaker82 makes of using this in the Predbat table card
Agree about not including the HML, these are really display thresholds so shouldn't be in the JSON.
How does the state structure now look with multiple Predbat activities in the same slot?
How does the state structure now look with multiple Predbat activities in the same slot?
I haven't figured that bit out yet (hence the PR still being draft); in the HTML version, the logic is based on the soc_sym variable which is removed from the JSON version so I think I (or anyone) need to get enough of the logic back in order to represent the split slots.
... also I don't (yet!) have an export tariff so I'll have to fake the data somehow to get it into a state to test it ...
... also I don't (yet!) have an export tariff so I'll have to fake the data somehow to get it into a state to test it ...
Just put a rates_export in apps.yaml https://springfall2008.github.io/batpred/energy-rates/#rate-bands-to-manually-configure-energy-rates
e.g.
rates_export:
- rate: 15
or
rates_export:
- start: "00:00:00"
end: "07:00:00"
rate: 5
- start: "07:00:00"
end: "00:00:00"
rate: 25
If you want something more interesting to look at
Just a quick note - I've not had a chance yet to look at the last remaining bit of this (the split slots), but I still intend to do that soon (maybe this week), apologies for the radio-silence!
I've attempted to replicate the "split" logic, although I'm failing to trigger any splits even with various export rate values. As a result, I've not made the JSON represent the split, only the mode label. If I can make a split, then I'll make it into a richer structure.
How did you get on with this, does it do what you want and should I merge the change?
Just wondering if it should go into an attribute under plan_html rather than creating a new entity?
I've fiddled with various config settings, but I can't get predbat to decide to export at all. I'm trying to avoid this turning into a support thread, so I'll keep playing with settings, there must be something I've set which makes it not want to export...
I've finally found the setting I was missing! I can now cause the split logic - I'll have a go at confirming the JSON structure. I have no opinion about it being an attribute under plan_html, I'll switch it over to that.
I've rebased the branch onto main, squashed the commits, and tested a split slot; it looks like this:
{
"state": {
"mode": "Charge - Discharge",
"soc": {
"percent": 69,
"percent_end": 53,
"percent_max": 69,
"percent_min": 53,
"change": -2.09
},
"limit": 4,
"split": true
},
"pv": {
"forecast": 0,
"forecast10": 0
},
"load": {
"forecast": 0.3,
"forecast10": 0.33
},
"rate": {
"start": "Sun 04:30",
"import": {
"value": 11.55,
"adjust_type": null,
"charge": true
},
"export": {
"value": 15,
"adjust_type": null,
"discharge": true
}
},
"cost": {
"start": 125.878,
"change": -25.83
},
"car": {
"charging_kwh": 0
}
}
are we planning to merge this in at some point?
Now done in a different way in the latest release