Mal ein kurzes Fazit von der PV-Überschussladung: Echt super, mit dem Regler!

Ich verwende folgende Parameter:

• Istwert: aktuelle Netzleistung (- = Einspeisung, + = Bezug)
• Sollwert: 0,1 kW Netzeinspeisung (= -0,1 kW), wobei ich den verschieben kann, z.B. auf +3,0 kW, um auf jeden Fall zu laden (dann halt nicht PV-Überschuss)
• Kp=0,1, Tn=10s, Tv=0s (bisher nur PI-Regler)
• sup: 0,2 kW: damit werden Schwankungen im Haus (hier ne Lampe an, da startet der Kühlschrank) gut weggefiltert, ebenso wird damit die Situation verhindert, dass der Regler die Wallbox als Sprungantwort ständig zwischen 2 Stromstärken hin- und herschaltet (z.B. 7A - 8A -7A, die Wallbox goE HomeFix arbeitet nur mit ganzen Ampere)
• min: die Wallbox startet bei 230V, 6A (= ca.1,4 kW), d.h. mein min ist fix auf 1.3 kW eingestellt => der Regler braucht nicht die gesamte Totzone von 0 bis 1.4 kW hochreglen, bis die Ladung freigegeben wird
• max: berechne ich dynamisch aus verfügbarer PV-Leistung minus 0,5 kW Grundlast plus Sollwert Netzbezug. Wenn eine Wolke drüber zieht und die PV-Leistung einbricht, muss der Regler nicht erst runterregeln, sondern reduziert die Ladeleistung sehr schnell. Ich nutze daher Kp, nicht Xp, weil die Veränderung von max keinen Einfluss auf y haben darf (außer y > neues max).
• hold: setze ich auf true, wenn die Anzahl der Phasen (1 nach 3, 3 nach 1) aufgrund der angeforderten Ladeleistung umgeschaltet wird. Die Wallbox pausiert hier kurz den Ladevorgang, was dazu führt, dass die vorherige Ladeleistung schlagartig ins Netz gegeben wird und der Regler mit einem Sprung antworten würde, was dazu führt, dass die Phasen ständig hin- und herschalten und gar nicht mehr geladen wird (durch die Ladepause bei der Phasenumschaltung). hold setze ich wieder auf false, wenn die Phasenumschaltung abgeschlossen ist und die Wallbox mit der neuen Anzahl Phasen weiterlädt

Ich muss mal sehen, ob ich noch eine Tv ermittle und in wie weit Kp, Tn und sup noch weiter optimiert werden können. Bisher bin ich aber schon sehr zufrieden!

@oxident da hast du im Prinzip einen P-Regler gebaut mit Kp = 0,6, sup = 100 und Zykluszeit 1 Sekunde. Die Eigenschaft eines P-Reglers ist, dass es bei einer bleibenden Regelabweichung bleibt, diese wird erst durch einen I-Anteil abgebaut. Ist eine Nachstellzeit Tn parametriert, bekommst du einen PI-Regler, parametrierst du noch eine Vorhaltezeit Tv, bekommst du einen PID-Regler, der noch schneller reagiert, als ein PI-Regler.
Wenn du dein System zu gleichmäßigen Schwingungen bringen kannst, kannst du z.B. über Ziegler-Nichols oder Chien, Hrones und Reswick Kp, Tn und Tv ermitteln, siehe: https://de.wikipedia.org/wiki/Faustformelverfahren_(Automatisierungstechnik)
Du musst dabei aber immer bedenken, dass dein System die durch den Regler ausgegebenen Änderungen der Stellgröße = bei dir die Ansteuerung der Lade- und Entladeleistung des Akkus dauerhaft verkraften muss. Es nützt dir ja nichts, wenn du die Nulleinspeisung mit optimalen Reglerparametern hinbekommst, aber nach einem halben Jahr die Elektronik oder der ganze Akku kaputt ist, weil die Bauteile mechanisch/elektronisch nicht für eine stetige Regelung ausgelegt und geeignet sind.

Hallo zusammen, ich habe viel mit dem Thema herumexperimentiert und bin jetzt zu einer für mich schönen Lösung gekommen, die ich hier zur Verfügung stellen möchte.

Ich habe ioBroker in einer virtuellen Maschine im VM Ware Player laufen: Ubuntu 20.04.01 Server. Motioneye läuft in einer zweiten VM, auch Ubuntu 20.04.01 Server. Die motioneye Installation hat zu 100% nach Anleitung funktioniert:
https://github.com/ccrisan/motioneye/wiki/(Install-On-Ubuntu-(20.04-or-Newer)
In beiden VMs ist der selbe shared folder aktiviert:

sudo nano /etc/fstab

Am Ende ergänzen:

.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults,allow_other 0 0

Damit steht in beiden VMs (iobroker und motioneye) der Ordner /mnt/hgfs/rack_HDD zur Verfügung. Der Name ist im Player natürlich frei wählbar.

Ich habe beide VMs mit statischen IP-Adressen versehen: iobroker: endet mit .50, motioneye mit .52

Im ioBroker muss in der Web-Adapter-Instanz (bei mir web.0) noch "Eingebautes 'Simple-API'" aktiviert werden. Wenn der Port nicht 8082 ist, muss das in den curl-Anweisungen in motioneye entsprechend geändert werden. Die Vorgehensweise unten bezieht sich auf 8082.

Konfiguration von motioneye:
mit putty einloggen

sudo nano /etc/motioneye/motioneye.conf

Wir wollen mit iobroker neben dem motioneye webinterface auch auf motion zugreifen, daher den Zugriff nicht auf localhost beschränken (motion_control_localhost false):

# whether motion HTTP control interface listens on
# localhost or on all interfaces
motion_control_localhost false

Noch kurz den Control-Port überprüfen:

motion_control_port 7999

Ich habe bei mir über die Web-Konfiguration der IP-Kamera folgende Werte eingestellt: 1280x720, 15 fps. Damit kriege ich einen ausreichend flüssigen Stream und die CPU-Last der VM (host: i5 3. Generation) liegt bei <20%.

Jetzt kann die Konfiguration von motioneye im Browser geöffnet werden, ich gebe hier noch Werte an, die bei mir ganz gut funktionieren:
<IP-Adresse Motioneye>:8765
ggf. Benutzer wechseln - admin (ohne PW)

• Preferences: die beiden Dimmer habe ich auf 100% gestellt, die Grenzen habe ich ja in der Kamera konfiguriert
• Video Device:
  Camera Name: ist wohl selbsterklärend, z.B. Garten
  Camera Device: bei einer IP-Kamera kommt hier der Link zum Stream rein, z.B. rtsp://... bzw. der Wert aus der Erst-Konfiguration ist eingetragen.
  Video Resolution und Framerate: so wie in der Kamera eingestellt, bei mir also 1280x720, 15 fps
• File Storage:
  Root Directory: hier kommt jetzt der gemeinsam genutzte Ordner rein, z.B. /mnt/hgfs/rack_HDD/motioneye
  Run A Command: ON
  Command: curl <IP-Adresse von iobroker>:8082/set/javascript.0.motioneye.getLastPic?value=%f
  Damit übergeben wir den Namen des letzten gespeicherten Bildes (z.B. bei Bewegung) an ioBroker.
• Text Overlay:
  Left Text: Camera Name
  Right Text: Custom Text: %Y-%m-%d\n%T-%q
  Mit -%q wird der Frame mit angezeigt, d.h. bei 15 fps sieht man in einer Sekunde, wie von 0 bis 14 hochgezählt wird. Damit erkennt man die aktuelle Stream-Geschwindigkeit gut.
  Text Scale: 3, damit kann man bei der Auflösung von 1280x720 die Schrift gut lesen
• Video Streaming:
  Streaming Frame Rate: 15 (entspricht der Einstellung der IP-Kamera)
  Streaming Quality: 100% (je nach Bedarf kann man auch mit weniger zufrieden sein)
  Motion Optimization: ON Damit wird der Stream ohne erkannte Bewegung auf 1 fps reduziert und hochgefahren, wenn Bewegung erkannt wird. Den Effekt sieht man durch -%q dann auch im Bild rechts unten.
  Streaming URL: Die Adresse kommt in vis z.B. in das Widget "basic -Image": Quelle. Damit hat man dann in der vis-Runtime den Live-Stream
• Still Images:
  Image File Name: %Y-%m-%d/%H-%M-%S_%q
  Durch %q wird vermieden, dass, sollten mehrere Bilder in einer Sekunde aufgenommen werden, Bilder überschrieben werden. %q hängt die Frame-Nummer an.
  Capture Mode: Motion Triggered (One Picture)
  Damit wird nur der Frame mit der meisten Bewegung (Anzahl geänderte Pixel) bei erkannter Bewegung (Event) gespeichert und nicht jedes einzelne Bild, was zu einer Bilder-Flut führt.
• Movies: habe ich deaktiviert
• Motion Detection:
  Frame Change Threshold: 0.4%
  Das sind knapp über 3.500 Pixel. die sich ändern müssen, um Bewegung zu erkennen. Habe ich durch (viel) probieren ermittelt und passt bei mir ganz gut
  Maximum Change Threshold: 50.000
  Damit wird bei mir vermieden, dass Bewegung erkannt wird, wenn z.B. nachts die Scheinwerfer eines Autos Licht in den überwachten Bereich werfen. In Kombination mit Light Switch Detection. Wenn sich die Kamera ziemlich dicht an sich bewegenden Objekten befindet, z.B. direkt über einer Tür, kann 50.000 viel zu niedrig sein. Gilt auch für Light Switch Detection weiter unten. Die Zahl der bewegten Pixel wird weiter unten auch angezeigt, damit bekommt man ein gutes Gefühl für sinnvolle Werte.
  Auto Threshold Tuning: off
  "On" hat bei mir zu viele Fehlauslösungen provoziert
  Auto Noise Detection: off
  "On" hat bei mir zu viele Fehlauslösungen provoziert
  Noise Level: 12%
  Wirkt vor allem nachts/ bei schwarz-weiß Bild der Kamera. Ich habe den Wert durch probieren ermittelt, um Fehlauslösungen zu vermeiden, aber Bewegung trotzdem zu erkennen.
  Light Switch Detection: 10%
  Der Wert darf nicht zu niedrig sein, eher >10%, Weil sonst echte Bewegung mit entsprechend vielen Pixeln als "Licht" interpretiert und nicht gemeldet wird. Wirkt vor allem, wenn die Kamera sich nachts bei Dunkelheit empfindlich einstellt und dann bei Lichteinfall das ganz Bild "weiß" wird, bis sich die Kamera an die neuen Lichtverhältnisse angepasst hat, was ja innerhalb weniger Sekunden der Fall ist.
  Show Frame Changes: ON
  Damit wird rechts oben im Bild die Anzahl der geänderten Pixel angezeigt und das bewegte Motiv wird rot umrandet.
• Motion Notification:
  Run A Command: ON
  Command: curl <IP-Adresse von iobroker>:8082/set/javascript.0.motioneye.getEventStart?value=true
  Damit übergeben wir erkannte Bewegung an ioBroker
  Run An End Command: ON
  Command: curl <IP-Adresse von iobroker>:8082/set/javascript.0.motioneye.getEventStop?value=true
  Damit übergeben wir beendete Bewegung an ioBroker

Jetzt können wir uns an die Blockly-Skripte machen:

1. Telegram
   Zuerst müssen die Datenpunkte angelegt werden (übernimmt Blockly):
   javascript.0.motioneye.getLastPic
   javascript.0.motioneye.takeSnapshot
   Dann die Logik:

• Foto unabhängig von Bewegung auslösen (z.B. über Telegram oder ein anderes Objekt):
  exec Befehl: muss in der Javascript-Instanz aktiviert sein: Erlaube das Kommando "exec"
  curl <IP-Adresse von motioneye>:7999/1/action/snapshot
  7999 ist der motion_control_port, den wir ganz oben aus der motioneye.conf geholt haben.
  1 ist die Kamera-ID. Bei mehreren Kameras ist hier die entsprechende ID anzugeben. Dann müssen ggf. auch mehrere Skripte mit unterschiedlichen (nummerierten) Datenpunkten
  javascript.0.motioneye.getLastPic
  javascript.0.motioneye.takeSnapshot
  angelegt werden.
• aktuellestes Foto an Telegram senden (ausgelöst durch Bewegung oder Telegram bzw. anderes Objekt):
  Bildname wird durch curl <IP-Adresse von iobroker>:8082/set/javascript.0.motioneye.getLastPic?value=%f (angegeben in der Motioneye-Konfiguration unter "File Storage" - s.o.) an ioBroker übergeben.
  

2. Aktion bei erkannter Bewegung auslösen, z.B. Licht schalten (=Bewegungsmelder)
   Zuerst müssen die Datenpunkte angelegt werden (übernimmt Blockly):
   javascript.0.motioneye.getEventStart
   javascript.0.motioneye.getEventStop
   Auch hier gilt: Bei mehr als einer Kamera ggf. mehrere Skripte mit nummerierten Datenpunkten anlegen.
   Dann die Logik:
   "Bewegung_erkannt_durch_Kamera_EINGANG" ist aus meinem Datenpunkt-Haushalt, bei euch ist das ein entsprechend anderes Objekt.
   
   Um ein Bild mit Telegram auszulösen noch ein text2command anlegen:
   Regel: Schalte irgendetwas an oder aus
   Name: Foto
   
   text2command muss in der Telegram-Adapter-Instanz aktiviert sein (=> NACHRICHTEN).

Wenn man jetzt also "Foto" an seinen Bot schickt, wird ein Foto ausgelöst und geschickt.

Das war er soweit auch schon. In der Anleitung steckt ein Haufen Arbeit, also nicht einfach hier rauskopieren und weiterverteilen - danke!

@wal Noch kein Ausreißer die letzten 20 Minuten!!!!! Ich gehe jetzt nochmal auf den S7 Adapter ohne deine Änderung zurück und schaue, wie lange es dauert, bis der erste Wert daneben liegt.
Edit: die ersten Ausreißer sind angekommen, ich gehe jetzt wieder auf deine Modifikation...

Ich bin gerne bereit, mit Euch Eure Regler-Ideen zu diskutieren und Euch bei der Umsetzung zu unterstützen. Themen sind beispielsweise:

• PV-Überschussladen = Netzeinspeisung auf 0 regeln (Auto, Batterie, Heizstab - für Schäden durch Kabelbrand oder Ähnliches kann ich natürlich keine Haftung übernehmen )
• Temperaturregelung (z.B. beim Holzkohlegrill oder Smoker, indem Ventilatoren geschaltet werden - für Schäden durch Verpuffung oder Ähnliches kann ich natürlich keine Haftung übernehmen )
  ...

Wichtig dabei ist natürlich, dass die Systeme, die vom ioBroker einen Sollwert bekommen, über eine entsprechende Schutzeinrichtung verfügen und kein Schaden verursacht werden kann. Beispiel: Die Wallbox erkennt, dass das Auto nicht weiter geladen werden kann und beendet die Ladung, egal, was über die API für Vorgaben kommen.

@martinschm ja, gerne. Habe den Post zufällig gesehen, habe keine Email oder so bekommen, dass ich mit @ in einem Post angesprochen wurde (habe meine Einstellung jetzt geändert).

Ich habe mich ja intensiv mit dem PID-Adapter beschäftigt, da könnte ich bei Interesse was dazu erzählen - mit Begrenzungsregler etc... Bekomme in Kombination mit einem ESP32 da jetzt auch ein Lüftungsproblem in den Griff.

@mcm57 sagte in Test neuer Adapter pid (pid-Regler) V0.0.1-alpha.x:

OK, das kann / werd ich ändern. Durch diff=0 sollte dann auch der I Anteil gleich bleiben. Der Differenziereranteil kann sich noch ändern, da ja diff[t-1] ggf ungleich 0 war.

das wäre Klasse, weil sonst kann der Istwert ja langsam weglaufen und die Regelabweichung wird immer größer, ohne dass der Regler eingreift. Deswegen ist if (set - act) < sup) then assume diff=0 das Mittel der Wahl.

Ich benutze Admin 6.4.3 mit dunklem Farbthema, aber bei deinem Screenshot oben ist C-1 auch rot, nur sehr schwer erkennbar, durch den weißen Hintergrund,

@mcm57 sagte in Test neuer Adapter pid (pid-Regler) V0.0.1-alpha.x:

Orange bleibt da der Adapter in dem Zustand ja nicht läuft ist das meiner Ansicht nach OK.

Der Adapter läuft ja, nur der Regler ist mit run = false angehalten. Habe mal einen 2. Regler in der Konfig hinzugefügt. Der eine ist grün, der andere Orange => auf eine Blick erkennbar, welcher Regler arbeitet und welcher pausiert => OK.
Die Frage ist dann, ob er auch Orange wird, wenn man = true, weil da passiert ja auch erstmal nix mehr - im Gegensatz zu sup, da ist diff = 0 ja nur temporär und wenn (set - act) > sup geht es ja automatisch weiter, während run und man ja umgeschaltet werden müssen.

@wal Ich habe den node-snap7 issue mal geschlossen und im iobroker.S7 issue einen Aufruf zum Mittesten gestartet. Ich glaube aber nicht, dass da viel zurückkommt. Bei mir läuft das Ganze mit sämtlichen Test-Skripten parallel zum Produktivbetrieb stabil über die letzten Tage. Sobald du den Mut zum Pull hast, würde ich auch den iobroker.S7 issue auf Github schließen.

@hf_spsler Es hat sich im Laufe der Zeit herausgestellt, dass das alle Zahlen-Werte (=nicht-Bool) betrifft: Byte, Wort, Doppelwort - ob Integer, Doppelinteger oder Real. Es gibt aktuell einen Workaround, der funktioniert, in dem in einem Java-Script unter Umgehung des Adapters die Werte in die S7 geschrieben werden. Mir ist auch daran gelegen, dass das richtig funktioniert, aber die Anwender, die den S7-Adapter brauchen und Javascript beherrschen und Lust haben, das zu debuggen, ist sehr überschaubar gewesen in den letzten 5 Jahren ;-(. Der eine oder andere ist auf node-red umgestiegen, da gibt es auch eine S7 Kopplung, das kommt für mich aber nicht in Frage. Wegen Workaround schau mal hier:
https://forum.iobroker.net/post/1109064
Ich hoffe auch, dass @Wal die Lust nicht verliert und dass ihm/ uns demnächst der Durchbruch gelingt!

Coral ist bestellt, kostet jetzt schon 75 € in DE - Frigate kann kommen...

Leider muss ich für den 15.05. schon wieder absagen, weil ich einen nicht verschiebbaren Termin in Erlangen bekommen habe. Gibt es schon eine Idee für einen Juni-Termin?

@cephalopod also geht der Regler auch auf 100%?

@cephalopod hast du schon weiter probiert? Mich würde ein Zwischenstand interessieren...

@cephalopod sagte in Test Adapter pid (pid-Regler) V1.0.x:

Nein, der Regler ist nicht am Anschlag, sondern bei maximal 83%.

Das ist schon mal gut. Willst du mal ein Screenshot von den Regler-Objekten (cfg bis para) posten?

Bei -70 Watt sollte der Regler den out.y eigentlich allmählich auf 100% schieben. Gehe mal auf kp von 0.1 -> zum probieren.
Warum kp = 0.1? Wenn die Annahme stimmt, dass durch die Einheit % => W ein kp von 0.2 bei einer Änderung von 1 W bei der Einspeisung direkt 1 W beim Steller verändert, reagiert der P-Anteil 1:1. Wenn das Verhalten durch ein kleineres kp weniger aggressiv ist, wird das helfen, die Regelabweichung wegzubekommen, der Regler ist dann aber etwas langsamer.

Vielleicht wäre es auch hilfreich eine Kurvendarstellung mit in.act, in.set und out.y zu erstellen. Nicht, dass bei der Übergabe vom Skript an den Regler was schief läuft.

Du kannst zum debuggen ja auch mal einen Netzbezug parametrieren, z.B. +400 W, +800 W etc. und mit den Sollwerten rumspielen. Dann siehst du, wie der Regler reagiert und den Sollwert anfährt. Bei 800 W Soll, 200 W Grundlast sollte der Regler dann ja auf 100% gehen, Wenn du dann einen Föhn dazunimmst sollte der Regler den Heizstab ziemlich schnell auf 0% bringen.

Dein Skript musst du dann natürlich anpassen, dass der Regler aktiv ist.

@cephalopod schau auch nochmal in dein Blockly-Script: du übergibst an den Dimmer einen gerundeten Wert von out.y. Nicht dass die Regelabweichung (zum Teil) daher kommt?!

Edit: habe gerade bei dir gelesen, dass der Shelly nur ganzzahlige Werte nimmt, du also runden musst. 1% Genauigkeit sollte ja langen... Vergiss den Beitrag hier einfach...

@cephalopod Anhand von kp und Tn sollte der Regler die Abweichung ausregeln (Edit: was nicht bedeutet, dass das schon die optimalen Werte sind). Das gelingt natürlich nur, wenn sich out.y zwischen para.min und para.max bewegt. Wenn der Regler am Anschlag ist, kann natürlich nichts mehr nachgeregelt werden. para.sup ist 0, nehme ich an.
Du solltest mal out.y mit aufzeichnen und in den Kurven mit anzeigen.
Für mich sieht das so aus, als wenn dein Heizstab nur ca. 400-450 W verbraucht, deine PV-Anlage aber 500-550 W liefert und dann kommt es zur Einspeisung von 70-80 W (Einspeisung = negatives Vorzeichen denke ich mal). Auf der anderen Seite bleibt die Einspeisung konstant, auch wenn die PV-Leistung zurück geht...
Egal wie, wenn out.y = 100 (%) ist und damit 10 V (max. Leistung) an den Steller gehen, liegt die Abweichung am Stellglied, nicht am Regler. Dann müsstest du mal die Signalkette vom Shelly über den Thyristorsteller an den Heizstab überprüfen.

@cephalopod sagte in Test Adapter pid (pid-Regler) V1.0.x:

Wann macht der Integrale Anteil Sinn?
Was empfiehst du?

Es ist ist auf jeden Fall sinnvoll, eine Nachstellzeit Tn zu parametrieren, fange mal mit 20 an. Ohne hättest du einen reinen P-Regler, da bleibt eine Regelabweichung (Nulleinspeisung wird wahrscheinlich nicht erreicht). Und dann könnte man sich auch den Regler sparen, und das einfach über Addition/ Subtraktion in Blockly realisieren, also als Kennlinie, z.B. Wenn Einspeisung = 500 W, dann Steller auf 500 W, Wenn Einspeisung = 0 W, dann 0 W. Eine Vorhaltezeit Tv dagegen ist nur bei sehr schnellen Regelkreisen sinnvoll. Kann aber bei dir zutreffend sein, je nachdem wie schnell Verbraucher außer dem Heizstab rein- und rausgehen: Staubsauger, Föhn, Backofen etc. Da kommt es immer zu einem Stromkauf aus dem Netz, weil der Regler muss ja eine Abweichung feststellen, um zu reagieren. Je schneller und besser er parametriert ist, umso geringer ist dann der Zukauf.

@cephalopod ich arbeite mit kp, nicht mit xp, das ist wohl Geschmackssache. xp berücksichtigt den Messbereich (min/max), kp ist nur die Verstärkung bei der Sprungantwort. Da ich min/max z.T. dynamisch beschreibe (über einen zweiten Regler, der zu Begrenzung dient - Details dazu, wenn dich das interessiert), kommt für mich nur kp in Frage, da sich bei xp und Veränderung von min/max das Reglerverhalten verändert.
Heißt also, wenn kp=1 und sich der Istwert um 1 ändert, springt der Stellwert auch um 1. Hier sollte man auf die Einheiten achten (abgebildet durch para.min und para.max). Wenn dein Istwert Watt ist und dein Stellwert auch Watt, kann ein kp von 1 sinnvoll sein: es kommt ein W mehr vom Dach => der Heizstab kann sofort 1 W mehr verbraten. Wenn die Leistung in % (0-100) an den Heizstab übergeben wird, kann ein kp von z.B. 0,2 sinnvoll sein, weil 1% = 5 W.
Siehe ggf. auch https://forum.iobroker.net/topic/75038/anwendung-von-pid-adapter-mit-blockly/9?_=1741182921548
Wenn es dir gelingt, den Regelkreis zum Schwingen zu bringen (Ziegler-Nichols), kannst du PID-Parameter zur Einstellung des Reglers ermitteln. Dazu brauchst du Geduld und eine gleichmäßige Sonneneinstrahlung, sonst ändert sich ja die Regelstrecke. Und dann wäre natürlich noch zu überlegen, wie gut die Elektronik mit optimierten Regelparametern umgehen kann, d.h. wie gut würde sie ständige Leistungsänderungen vertragen. Dazu kann im Regler aber ja para.sup parametriert werden => das würde ich auf jeden Fall empfehlen.

Ich bin leider auch nicht dabei - das stinkt mir - ich habe gestern einen Termin in Erlangen bekommen und komme am Donnerstag abends erst zurück. Meine Themen sollen aber im Backlog bleiben und ich will unbedingt wieder dabei sein!

@haus-automatisierung