Aanleveren data hoofdaansluiting via API

Je ziet dat Sessy  (net als bijv. laadpalen en andere energie-oplossingen) nu zelf data verzamelt van de hoofdaansluiting. Logisch dat deze optie geboden wordt voor een out-of-the-box werkend systeem. Echter je krijgt zo ook een wildgroei aan P1-meters/splitters en CT-klemmen. Qua architectuur zou het mooier zijn als er één centrale hub/proxy is waar alle energiedata gemanaged wordt en waar je de Sessy mee kunt integreren doordat die de actuele data van daaruit naar de Sessy stuurt.

Mij is niet helemaal duidelijk waar de regellogica van Sessy precies geïmplementeerd is, ik vermoed in de P1/CT-dongle, aangezien bij meerdere Sessy's de Sessy-dongles volgens mij niet onderling communiceren, maar de P1/CT-dongle de "regisseur" is die tussen de Sessy's wisselt en/of naar behoefte bijschakelt. 

Voor mensen die al een centrale plek hebben waar al hun energiedata van de hoofdaansluiting binnenkomt (of geen P1-meter hebben, of teveel P1-meters/splitters, of geen plek voor CT-klemmen), zou het mooi zijn als de P1- en/of CT-dongle de data van de hoofdaansluiting via een API zou kunnen ontvangen, mits de data op een andere manier al voorhanden is (in bijv. Homey, Home Assistant of vergelijkbaar systeem).

Als de dongle in deze configuratie staat, dan zou de data bijvoorbeeld 1 x per seconde verstuurd kunnen worden naar de dongle. Bij uitblijven (>10 s?) van data is het prima als het systeem naar een veilige stand (Idle?) gaat.
Data zou verstuurd kunnen worden via een HTTP-API (zoals de rest van de API's), of via MQTT (stuk lichter protocol en wat meer geschikt voor dit soort continue IOT-meetdata).

Op deze manier kan alle functionaliteit en regel-logica van Sessy gebruikt worden, zonder dat je plek moet vinden voor wéér een extra P1-device of CT-klem in je meterkast.

 

(ter inspiratie: Kijk eens naar de open source SmartEVSE-laadpaal, waar ook een dergelijke API in zit: https://github.com/dingo35/SmartEVSE-3.5/blob/master/docs/REST_API.md POST:currents L1/L2/L3 )