Laststeuerung und Überschussladen in Mehrfamilienhaus m- 22 Parteien, 8 Ladestationen

[hansh]

Nachdem wir einen 90kW PV Anlage in Betrieb genommen habe und sehr große Stromüberschüsse produzieren, wollen wir natürlich unsere Autos möglichst nur mit Solarstrom laden.
Der Netzbetreiber bestand darauf den gesamten Solarstrom direkt per neu gelegter Leitung an seinen Verteiler auf der Straße einzuspeisen. Die Berechnung des Eigenverbrauchs und Netzbezugs erfolgt rein mathematisch auf Basis der Smart-Meter Viertelstunden Verbrauchs-Intervalle durch den Netzbetreiber.
Neben der 8 Ladestationen in der Tiefgarage, betreiben wir noch eine 30 kW Peak Stromverbrauch Wärmepumpe.

Nun zur Projektidee:
Die aktuelle PV Produktion können wir sehr einfach über unsere Kostal WR per http API auslesen
Die Go-e Ladestationen können wir ebenfalls sehr gut per http auslesen und steuern
Den aktuellen Stromverbrauch der 22 Haushalte + Allgemeinstrom und Wärmepumpe wird schon schwieriger. Ob wir zur Messung der Gesamtverbrauchs im Wandlerschrank oder am Übergang zur den Verteilschienen Messzangen anbringen können wir noch mit dem Netzbetreiber geklärt.
Alternativ könnten wir den Verbrauch der Wärmepumpe per Stromzähler messen, den aktuelle Ladestrom der Auto haben wir ja auch und die 22 Haushalte könnten wir per Lastprofil H0 schätzen. Die knapp 40.000 Datensätze (Datum-Uhrzeit + Verbrauch in kWh normiert auf 1000 kWh Jahresverbrauch) habe im CSV Format als Durchschnittswerte 2023 pro Viertelstunde des Jahres bereits runtergeladen. Der Allgemeinstromverbrauch während des Tages ist vernachlässigbar.

Als Lösung hätten wir aufgrund der einfacheren Wartung und Programmierung gerne einen Loxone Server. Unser Problem ist dabei die Schätzung der Haushaltsverbräuche über das Lastprofil H0.

Die einzige Lösung die uns eingefallen ist, wäre die folgende:
Programm Baustein mit kleinem endlos Pico-C Programm, welches aus eine stark komprimierte Datei mit Satzlänge 12 Byte, (ca. 480 kB Dateigröße) alle 15 min den nächsten Datensatz liest und über Analogausgang des Bausteins den errechneten Schätzverbrauch ausgibt. Wir gehen davon aus, dass in Falle eines Neustarts des Servers, der aktuelle Dateipointer der geöffneten Datei verloren ist und wir daher die Remanenz nicht nutzen können. Bei Neustart würden wir die Datei neu öffnen und wieder zum zum aktuellen Zeitpunkt sequenziell vorlesen (worst case 400.000 reads a 12 Byte) und dann wieder den aktuellen Hausverbrauch ausgeben.
.
Hat schon jemand im Forum einen Pico-C Baustein mit Datenzugriff geschrieben?
Gab es dabei Probleme z.B. Stabilität, Memory Leaks, Abbrüche etc. da ja Dauerläufer?
Wohin könnte man den die 480kB große Datei auf der SD Karte legen und kann man mit RSH oder FTP auf das Dateiensystem der Loxone schreiben?
Gibt es Probleme mit der Gesamtstabilität des Systems, wenn wir max. 400.000 reads im Pico-C am Stück machen, ich habe in der Pico-C Beschreibung kein Wait() oder ähnliches gefunden und bin nicht sicher, ob die anderen Bausteine während der etwas längeren read Schleife noch CPU bekommen?

Alternativ können wir das Projekt natürlich auch auf einem Loxberry mit Docker und Node-Red umsetzen, aber sicherlich mit deutlich mehr Wartungs- und Umsetzungsaufwand.
Wenn so ein Programmbaustein stabil läuft wäre das sicherlich die einfachere Lösung, da wir dann einige vorhandenen Bausteine der Loxone nutzen könnten.

Eine andere Idee war die Speicherung der H0 Daten in einer Google Firebase, aber wir sehen keine Möglichkeit direkt aus der Loxone einen Firebase Aufruf ohne Loxberry zu machen (Google Security, Client API etc.).
Unsere Daten sind ja nicht geheim, kennt vielleicht jemand eine andere möglichst freie Cloud DB, wo man einfach per Http aus der Loxone eine Key/Value Pair Datei lesen kann?

Freue mich auf die geballte Erfahrung des Forums

[AlexAn]

Wenn ich das richtig verstehe hast du:
ein Kabel für die Produktion: Leistung Einspeisung und Überschussenergie per Kostal API oder Zählerauslesung
ein Kabel für alle Verbraucher inkl. WP, Wallboxen Wohneinheiten

Im wesentlichen wie bei einem Haushalt mit einem A+A-Zähler
Wobei du nur die Leistung der 2 Zähler saldieren musst für deinen Energiemanager.
Ist halt die Frage ob du beim Bezugskabel eine eigene Summenwandlermessung machen kannst/darfst oder ob du alle Messungen erfassen musst für die Saldierung.


Für die Wallboxen gibt es bereits den zentralen Baustein: Neu: Wallbox Manager - Loxone Explained | 2023 [4K] (youtube.com)
go-e Gemini - LoxWiki - LoxWiki (atlassian.net) per Modbus TCP

WP mehrstufig?
Warmwasserbereitung ebenfalls mit der WP des Heizsystems?

Für was Pico-C - Abrechnung der 1/4h Werte?
Entweder gleich alle Wohnungen per EVU Zähler auslesen oder Modbus RTU Zähler setzen falls alle Messungen benötigt werden.
Wird das eine Energiegemeinschaft?

[hansh]

Alles korrekt. Da wir in Österreich sind und der Betreiber der Anlage eine Eigentümergemeinschaft ist, heißt diese Form von Energiegemeinschaft Mieterstrom Modell nach WEG. Einziger Unterschied zur Energiegemeinschaft ist, dass man auf die Gründung einer juristischen Person verzichten kann.
Wegen der Bausteine für Wallbox und Energiebilanz würde ich ja gerne Loxone nehmen. Ich bin allerdings nicht besonders optimistisch was die Messung des Strombezugs angeht. Ich fürchte der Netzbetreiber erlaubt keine fremden Messzangen im Wandlerschrank und erlaubt auch keinen Zugriff auf die 24 Smartmeter der Verbraucher.
Daher wird es wohl auf die Verbrauchsschätzung über H0 Lastprofil und damit auf das Lesen der 40,000 Zeilen Datei hinauslaufen. Habe aber keine Erfahrung mit Pico-C.
WP ist mehrstufig IDM Twin Terra mit Brunnen als Wärmequelle ca. 90 kW Heizleistung + Warmwasser.

[AlexAn]

Was machst du mit einer Verbrauchsschätzung?
Falls du 24 Smartmeter auslesen möchtest dann muss dir jeder Betreiber die Daten zur Verfügung stellen.

Bei der Anlage wirst du vermutlich Gruppentrenner benötigen. Würde den Netzbetreiber fragen ob du diese erfassen kannst. Im wesentlichen wirst du nur die Summenleistung/Energie benötigen.

Wenn ich das richtig verstanden habe möchtest du nur den virtuellen Überschuss verwenden für den Energiemanager.

[hansh]

Genau, die Daten vom Netzbetreiber kommen zu spät. Wir müssten schon realtime direkt per API auf die 24 Zähler zugreifen. Geht oder lässt uns der Netzbetreiber aber nicht. Daher die Schätzung des aktuellen Wohnungsverbrauchs über Standard Lastprofil H0.

[AlexAn]

Na da hast du eine große Range von einer Schätzung bis Realtime!

Realtime bei 24Messungen und Saldierung alleine ist nicht realistisch und hat eine gewisse Fehlerrate
Ein Summenlastprofil ist da schon eine Schätzeisen.

Falls kein dauerhafter Wandler möglich ist würde ich versuchen einen Beobachtungszeitraum auszuhandeln damit du selber ein Lastprofil hast.
Diese Leistung kannst du in einer simplen Schaltuhr analog innerhalb einer Woche abbilden - ganz ohne Pico-C

[hansh]

Die Daten der 24 Zähler bekomme ich monatlich in Viertelstunden-Intervallen. Die Schaltuhr wäre als Notfall Option machbar. ich könnte zunächst die H0 Standard Lastprofildaten und später bei Verfügbarkeit die Echtdaten auf Stundenbasis Mitteln und danach um den Jahreszeiteneinfluss zu berücksichtigen könnte ich für jeden Monat eine Schaltuhr definieren und die Tageswerte (Mo-So) pro Monat wieder Mitteln. Dann hätte ich 12 gefüllte Schaltuhren an denen ein Wert am Ausgang anliegt, der sich stündlich ändert. Aus den 12 Bausteinen auf Basis der aktuellen Monat den richtigen Wert zu selektieren wird irgendwie auch gehen. Ich würde mal spontan sagen Statusbaustein.
Klingt zwar nach sehr viel Mitteln, aber das H0 Lastprofil hat zwar einen Verbrauchswert für jede Viertelstunden-Intervall des Jahres, aber der ist auch nur ein Mittelwert aller Haushalte ohne Elektroheizung und -warmwasseraufbereitung, die über einen Smart-Meter verfügen normiert auf einen Jahresverbrauch von 1.000 kWh. Je mehr Echtdaten wir hätten, um so mehr würden die bessere Datenqualität das doppelte Mitteln ausgleichen. Geschätzt ist halt nicht gemessen.
Danke schon mal für diese Lösung, dass die Schaltuhr auch einen Analogausgang hat, darauf wäre ich nie gekommen.

[Tico]

Another option for a database system in Loxone is to use the Status Block for tabular data. In the attached picture, the I1 input is the 'Month'. The I2 input is 'Minutes past Midnight'.




In this application, Status-text contains the value for an Irradiance sensor that measures Watts/m². The State value contains the value for total solar production in kW. The data is representative of the 1st day of the month. For any given month, there are about 90 entries across the day at 10 minute intervals. This makes the Status Block about 1100 lines deep.

In your application, you would only need H0 load profile in either of the Status-text or State value column at 15 minute intervals.

I then duplicate the Status Block using copy/paste. One Status block receives the current month as input (I1); the copied Status block receives the current month +1 (I1)



I then interpolate between the current Month and Month+1 to get a linear value based on the current day. The inputs below include the current day (I3) and how many days in the month (I4). Your application would only need one of the formulas below for a single metric H0.



The benefit of the method is only one Status Block needs to be populated with high-fidelity data. And you get a Time-of-Day output with a granularity of your choosing. Across the year, this provides for about 34000 virtualised datapoints at 10 minute intervals in my application.

I'm guessing the network operator won't allow access to the household meters due privacy requirements for individuals? Is there scope for a hard-wired electrical integration via Modbus RTU that can consolidate the meters into a de-identified 'Total Consumption'?

[hansh]

Thanks Tico, would also work. i did not know that you can make so many entries into a Status Baustein.
Do you or anybody else know how many rows you can enter into the Status Baustein?

[Tico]

I haven't tested to failure...getting to +1100 entries was painful enough. I would assume if you do 15 minute intervals for the whole-of-day, for the 1st day of each month, you will have 1152 entries (interpolated across the month gives you ~35000 datapoints). I have 10 minute intervals during solar production hours.

It isn't clear to me whether the H0 profile contains data for individual meters or the whole site? If it is individual meters, then you have the option of 2 households for each Status block (Status text and State value). 11 Status blocks to cover the site in higher granularity. And somewhat of a headache in data entry...

I was initially sceptical that a database approach would work. But given there's so many households, the 'averaged' data might actually be a fairly accurate method to work with.

[Tico]

Another alternative would be to use the two Status block columns for 'Weekday' and 'Weekend' profiles. The representative '1st day of the month' needs to account for these large differences in power use.

[hansh]

Tico, the H0 Load Profile contains the average data of all private households in Germany without electric heating and warm water making. To account for different household sizes and energy usage pattern, the calculations are normalized to an annual consumption of 1.000 kWh. So if you want to estimate the usage of an household for a specific 15 min interval, you take the value of this interval in H0 load profile multiplied by the annual usage of this household divided by 1.000.
I have the annual usages of each household in the building so I can do the math.
It is not a problem to further reduce the profile to about 1.000 entries e.g. I do only need values during daylight. I will try to look into the Loxone config file, if I can identify the structure of the Status Baustein. I would rather write a python script than to enter 1.000 entries via GUI by hand. I will start with a new config file an a add only the Status Baustein with a few entries and have a look into the file. Loxone must be able to easily read and interpret this file as well. In Node Red this is very simple to do, as all Nodes can be exported as JSON files.
Tx for everyone for the help.

[Tico]

Thanks for the clarification on the H0 Load Profile. Another project here delves into the back-end of the Loxone operating system -

https://github.com/mr-manuel/Loxone_LoxStatEdit

There may be some parallels with extracting and modifying data for the Status Block. I believe mr-manuel maintains that project.

[Tico]

And another link to Python utlities that can extract and view the Config file in an editor. eg. loadMiniserverConfigurationFile.py - Load the current configuration from the Miniserver and uncompress it, so it can be opened with a text editor. Also describes the load order of configurations.

https://github.com/sarnau/Inside-The-Loxone-Miniserver?tab=readme-ov-file

[hansh]

Very helpful Tx