Wir wechseln das Forum am 14.11.24 auf die Forensoftware Discourse. Zwischen Montag Abend und Dienstag Nachmittag wird das Forum deaktiviert. Danach sind wir hoffentlich mit neuem Forum inkl. der vorhandenen Beiträge wieder am Start! Hier zum Forenbeitrag!
Bei mir sieht das für die influxdb so aus:
Danke. Ich werds mir mal nochmal anschaun.
Klingt eigentlich einfach. Wenn mir nur nicht immer was dazwischen käm...
Gehn die direkt an die Brennersteuerung? Hab den Schaltplan nicht mehr so ganz im Kopf...
Der Wirkschaltplan der Sicherheitskette sieht bei mir etwa so aus
Die Heizungsregelung ist hier mit einem Relais vertretet (hier Shelly)
Woher kommen denn die Signale Brenner ein und Brenner Störung? Wo greifst du diese ab?
Brenner ein wird nur als Sensor in den Shelly geführt, richtig?
Wie wird denn die Störungsleitung verarbeitet?
Wird eine Brennerstörung nicht direkt vom Feuerungsautomat verarbeitet?
"Brenner EIN" am Shelly kommt über die Sicherheitskette, Augangspunkt ist T1, es ist elementar für die nachfolgenden blockierenden Einrichtungen. (Klappe ...).
Nur wenn 230VAC an T2 ankommen wird der Brenner aktiv.
Brenner Störung S3 liegt am Brennerstecker DIN 4791 als Ausgang an. (wird also vom Gasfeuerungsautomaten generiert)
Störung wird nur visualisiert, auch die originale Viessmann-Regelung hat diesen nicht verwertet.
B4 ist übrigens für den Betriebsstundenzälhler gedacht. Damit lässt sich die Einschaltzeit erfassen.
@jay die HUE Leutmittel ziehen etwa 5W, auch ausgeschaltet. So hat es der Shelly in Lichtschalter gemessen. Dazu die Hue Zentrale, die Homematic Zentrale, etc.
Und ja, mir reicht eine PV Auswertung. So kann ich planen, was am Netz bleibt und was auf die Insel geht.
10x 130Wp + 4x 210Wp -> 4x MPPT 100/20 + 2x HM300 + BlueSmart IP22 24/16 -> 2x 24V 100 Ah LFP -> Multiplus C 24/2000
einfach ALLE Daten die auch in der Sqlite stehn auch in die Innodb (oder Maria
keine Datenbank kann zu einer anderen "pushen".
man muss über export/CSV/import etc gehen, zumindest habe ich noch keinen Weg SQlite->influx gefunden
beim Schreiben kann man zwei Schreib-Blöcke erstellen, der eine nach SQL, der andere nach influxDB
MariaDB und sqlite sind kompatiblel, das könnte mit einem query gehen, kommt aber auf deine Struktur an
Hast du dann den mit den 2 GB Ram laufen? Wie ist da die Speicherauslastung?
1.2 GB / 2 GB
Adoons sind Timescale, Cloudflare, Samba, Google Backup, insgesamt 18 Stück, davon die Hälfte aber nicht wirklich wichtig.
Ich benutze einen alten Odroid-C2, für mich ausreichend, vor 5 Jahren war der für IOBroker damals grenzwertig, damals lief HA,
(was jetzt HA Core genannt wird) auf nen Raspberry Zero.
..,-
Korrektur, vor Im November vor 6 Jahren hatte ich IOBroker mal ausprobiert
..,-
Was haltet ihr von folgendem Experiment?
1. IR-Lesekopf am Zähler / MQTT@ RasPI / HA@VM / Wifi Delock 11827 Steckdosen Schalter (o.ä.)
2. gleiches, aber ioBroker statt HA
Dabei ioBroker & HA als docker container beide in eigenen VMs, testweise am PC mit 16GB Ram und 4 Kernen also keine echte HW Limitierung.
Danach das gleiche auf 2 FUTRO S920. Containerisierung, damit ich diese einfach inkl. Konfig auf die FUTROs clonen kann.
- Kann ein einschaltender Verbraucher wie Gefrierschrank nach 5Sec erkannt werden?
Ist das Ergebnis vorhersehbar?
OOM, das alles in 16MB reinzuknautschen ist ambitioniert, unter 512MB würde ich da nicht anfangen.
..,-
@hsteffan Im Prinzip ja. Das kommt aber darauf an wie du das erkennen willst.
Über den Verbrauch im Zähler oder über eigene Steckdose für den Gefrierschrank?
Bei der Steckdose müsstest du die so konfigurieren das die maximal 5 sekündlich aktualisierte Werte schickt oder minimale Änderung entsprechend.
Beim Stromzähler müsstest du vergleichen um wieviel der Verbrauch angestiegen ist, d.h. wenn dein Gefrierschrank 150W verbraucht, das alter Wert x, neuer Wert x+ ca. 150 ist.
Wobei da auch alles mögliche andere mit einem ähnlichen Verbrauch die Erkennung stören könnte.
Bei mir hängen Kühlschrank, Gefrierschrank, Wasserkocher jeweils an einer eigenen ZigBee Steckdose. Spülmaschine aktuell noch nicht.
@petrel: ich will nicht an jeden möglichen Verbraucher eine wlan / Zigbee Steckdose hängen müssen um den Gesamtverbrauch zu ermitteln und davon abgeleitet bestimmte Reaktionen zu erzwingen. Daher "Sensor" ganz vorne am Stromzähler. Das Anlaufen des Gefrierschranks ist nur ein Beispiel, aber ein treffendes, da für Nacheinspeisung genau diese Art von Verbraucher erfasst werden sollten. Wenn man so eine allgemeine Steuerungsplattform bauen würde, ist die bedarfsgesteuerte Nachteinspeisung nur eine von vielen Möglichkeiten - die Abregelung der Heizung bei Starkem PV Ertrag natürlich eine andere. Dine generelle Anforderung ist aber eine gewisse Reaktionsschnelligkeit über die ganze Kette von Systemen und daher der Test.
Für die Nachteinspeisung reicht die ja der sekündliche Wert vom Stromzähler egal was den Strom verbraucht. Abhängig davon dann bei positivem Wert von Zähler Einspeisung um den Betrag erhöhen, bei negativen um den Betrag verringern.
Der Wirkschaltplan der Sicherheitskette sieht bei mir etwa so aus
Aus Interesse: Was ist ein Wirkschaltplan?
Hallo, was haltet ihr von folgendem Aufbauplan um Verbrauchsschwankungen zu erfassen und nachgelagerte Reaktionen zu triggern (in Stichworten):
1. HW:
3xFutro S920 Active nodes (8GB SATA-SSD, 4GB RAM)
3xVMs auf VMwareplayer auf Server als passive Backup und Failover Nodes (ähnlich ausgestattet)
2. OS und Laufzeitumgebung:
6x AntiX (knapp 2GB Minimalausstattung, 3GB mit allem Notwendigen, u.a. Docker.io)
Backup und sync der passiven Nodes (VMs) über docker export / docker import & ggf. rsync der Volumes mit persistenten Daten
3. SW/Anwendungen auf den 3 aktiven / passiven Nodes:
a. TTL-Kopf/VZ -> USB -> HA container
b. dito -> IOBroker container
c. Influx & Grafana / mehrere container, zum Visualisieren
Bemerkungen:
- Openhab scheint nicht mehr angesagt zu sein, lassen wir mal
- glusterfs für einfachen Datenaustausch in dieser Architektur (nur 1 /shared Verzeichnis), Ansible zum einfachen Konfigurieren.
- 3c. via github.com/bcremer/docker-telegraf-influx-grafana-stack, 3a. & 3b. je native docker container der communities