Hallo, welches System würdet ihr für eine selbst entwickelte Steuerung empfehlen? Mir ist bekannt, dass es fertige Steuerungen zu kaufen gibt, aber wir haben eine ungewöhnliche Installation, bei der eine individuelle Entwicklung vorteilhaft wäre. Neben der Steuerung einer Fußbodenheizung müsste ich die Kommunikation einer älteren Heizungssteuerung "belauschen" (RS485, teilweise bereits Reverse-Engineered), Sensoren für Temperatur und Helligkeit auswerten, mehrere Pumpen über Hutschienen-Schaltrelais steuern, eine Wetter-API einbinden sowie einen Webserver für die manuelle Steuerung und Kontrolle im LAN bereitstellen. WLAN und Bluetooth werden nicht benötigt bzw. es wäre gut, wenn man den Funk komplett abschalten kann. Später könnte ich mir noch vorstellen, das Auslösen von Bewegungsmeldern zu loggen und Aufnahmen von IP-Überwachungskameras aufzuzeichnen sowie per Web-Interface zu kontrollieren. Das wäre dann allerdings schon mehr als eine Heizungssteuerung. Angeblich soll die Bewegungserkennung bei Linux mit entsprechenden Programmen erheblich besser sein als eine bereits in der Kamera eingebaute Erkennung, die oft schon bei vorbeiziehenden Wolken Alarm auslöst. Falls zuverlässige Bewegungserkennung für mehrere Streams jedoch anstrengend für Einplatinencomputer sein sollte, kann ich mir auch vorstellen einen größeren Speicher zu verwenden und eine 72h-Zeitschleife mit reduzierten FPS aufzuzeichnen. Mit H.265 wird der Speicherbedarf hoffentlich kein großes Problem mehr sein. Ich dachte spontan an einen Raspberry, aber da scheinen viele Modelle momentan ausverkauft zu sein. Bei Reichelt gibt es noch wenige Raspberry Pi 2B v1.1, wobei das ein älteres Modell zu sein scheint. Auf meinen Rechnern nutze ich überwiegend Debian mit LAMP Stack und Python. Bei welchen Systemen lässt sich so etwas gut einrichten und darüber mit den IO Ports kommunizieren? Oder anders gefragt: welchen Einplatinencomputer mit welchem Betriebssystem würdet ihr bei meinen Anforderungen angesichts der momentanen Lieferschwierigkeiten wählen? Vielen Dank und herzliche Grüße, Karotte
:
Bearbeitet durch User
Raspi ist schon nicht schlecht (ein 3B macht bei mir auch Heizungssteuerung), aber den 2er würde ich nicht mehr nehmen, der ist schon wirklich zu alt. Den 4er gibts schon noch bei Amazon, aber günstig ist der da auch nicht (fast doppelt soviel wie bei der Einführung). Natürlich gibts auch andere Systeme, aber zum Raspi findet man schon noch am meisten Tricks, Howtos, Basteleien, etc. Der Bewegungsmelderkram sollte aber so oder so davon unabhängig sein.
Bei mir werkelt exakt zu diesem Zweck ein Olinuxino A10. Auf diesem steckt ein selbstentwickelter Aufsatz mit den Schnittstellen. - 2x RS232 - Onewire f. DS18B20 - Analogeingänge f. Drucksensor - Treiber-Ic f. Relais - Treiber f. meine Uhrenanlage
Habe dafür einen Raspberry 1B+ mit RS232 angeflanschtem AtMega328 im Einsatz. Die eigentliche Arbeit macht der AtMega und der Raspberry nur das Logging in eine MySql Datenbank mit Webinterface, Wettervorhersage (aus dem Internet) und Fernbedienung. Wenn ich es nochmal neu machen würde, wäre wohl der Zero W/WH meine Wahl, eben weil der noch etwas sparsamer ist und WLAN direkt drauf hat.
K. K. schrieb: > welches System würdet ihr für eine selbst entwickelte Steuerung > empfehlen Ein zuverlässig jahrzehntelang durcharbeitendes. Also kein Linux, kein rPi. Wenn man Web-Zugriff will, darf das ein rPi machen, aber die Steuerung sollte getrennt davon sein und den bei nicht-Antworten rücksetzen.
Das tolle an einer Eigenbau Lösung ist: Man weiß in drei Jahren nicht mehr was man damals alles verbrochen hat und das ist ein Problem von sehr vielen Programmierprojekten. Hat man das Grundgerüst am Laufen und möchte in paar Jahren optimieren, scheitert es an Software, Hardware oder dem Verstand der alles vergessen hat.
Christian M. schrieb: > Das tolle an einer Eigenbau Lösung ist: Man weiß in drei Jahren nicht > mehr was man damals alles verbrochen hat und das ist ein Problem von > sehr vielen Programmierprojekten. Hat man das Grundgerüst am Laufen und > möchte in paar Jahren optimieren, scheitert es an Software, Hardware > oder dem Verstand der alles vergessen hat. Anders ausgedrückt: - Dokumentation nicht auf bessere Tage verschieben. - Programmierumgebungen in der zuletzt für dieses Projekt verwendeten Fassung aufbewahren, Hardware wie Software. Bei PCs empfiehlt sich eine VM pro Projekt. - Komponenten auf Reserve halten. Ist blöd, wenn die Heizung nicht am Gas scheitert, sondern am nicht verfügbaren ATtiny84. Wenn man sich daran hält, sind auch 20 Jahre kein Problem.
:
Bearbeitet durch User
MaWin schrieb: > Wenn man Web-Zugriff will, darf das ein rPi machen, aber die Steuerung > sollte getrennt davon sein und den bei nicht-Antworten rücksetzen. Das möchte ich nachdrücklich unterstreichen, sofern Fehlverhalten hässliche Folgen haben kann. Die kritische Steuerungskomponente sollte dann keinesfalls auf dem RPi laufen, sondern autark z.B. in Form eines vergleichsweise einfachen Mikrocontrollers, mit Watchdog, Sanity-Checks, regelmässigem CRC-Check vom ROM etc. Ggf eine Risikoanlyse durchführen. Also welches Fehlverhalten von Steuerung, Sensoren, Aktuatoren welche Folgen hat.
:
Bearbeitet durch User
Bei mir läuft für die FBH ein RPi mit FHEM und Unipi Relais und IO. Bei mir läuft um 4 Uhr die Ölheizung los bis eine Wettervorhersage abhängige Rücklauftemperatur erreicht ist, dan geht die Ölheizung aus und der Puffer wird geleert. Die Raumtemperatur ist zw. 8 und 21 Uhr auf +- 1 Grad im Sollbereich OHNE Raumtemperaturfühler.
:
Bearbeitet durch User
(prx) A. K. schrieb: > MaWin schrieb: >> Wenn man Web-Zugriff will, darf das ein rPi machen, aber die Steuerung >> sollte getrennt davon sein und den bei nicht-Antworten rücksetzen. > > Das möchte ich nachdrücklich unterstreichen, sofern Fehlverhalten > hässliche Folgen haben kann. Die kritische Steuerungskomponente sollte > dann keinesfalls auf dem RPi laufen, sondern autark z.B. in Form eines > vergleichsweise einfachen Mikrocontrollers, mit Watchdog, Sanity-Checks, > regelmässigem CRC-Check vom ROM etc. Die Sicherheitskomponente bleibt in Form des Sicherheitstemperaturbegrenzers und des Flammenwächters genau da wo sie hingehört, beim Hersteller der Anlage; aus gutem Grund sind die mechanisch bzw. aus einfachster Optoelektronik ohne µC. Ich habe darum bei mir lediglich die Heizung auf manuellen Handbetrieb geschaltet und schalte mit meiner Steuerung nur eine zusätzliche Unterbrechung eben dieses Dauerbetriebes aufgrund diverser Eingangsgrößen. Somit gibt es eine Sicherheitseinrichtung durch den STB, die eingestellte maximale Kesseltemperatur im Handbetrieb, den Flammenwächter am Brenner, sowie eine Weitere durch meine Software im Mikrocontroller. > Ggf eine Risikoanlyse durchführen. Also welches Fehlverhalten von > Steuerung, Sensoren, Aktuatoren welche Folgen hat. Braucht man eigentlich nicht, da die herstellerseitigen Sicherheitskomponenten ja voll erhalten bleiben und ohne diese eh die Betriebsgenehmigung der Anlage erlöschen würde.
Heutige Heizungsanlagen sind deutlich anders gebaut als jene von vor 5 Jahrzehnten, mit der ich zu tun hatte. Folglich war der Eingriff deutlich höher, als das was heute sinnvoll sein dürfte. So hatte man damals weder Nachtabschaltung noch Pumpennachlauf vorgesehen und der Brenner hatte 7x24 Durchzug, was den Kessel erheblich auskühlte. Das ist heute alles anders. Natürlich habe ich keine der genannten Sicherheitskomponenten umgangen. Aber es gab dabei schon potentielle Szenarien zu vermeiden. Dass die Heizungsteuerung nicht wirklich nach Hersteller-Original aussah, war übrigens unübersehbar und hat Generationen von Schornsteinfegern und Heizungsmonteuren nicht gestört. Wenn keinerlei Risiko entsteht, also auch keine hohe Rechnung nach längerem Urlaub, wird die Risikobetrachtung einfach. Ich beschrieb das oben auch für Steuerungen allgemein, nicht für den Einzelfall.
:
Bearbeitet durch User
Es geht dabei ausserdem nicht allein um die Sicherheit, auch wenn das natürlich der kritischste Teil ist. Einen als Webserver arbeitenden RasPi im Netz, und wenn es nur das Hausnetz ist, kann man nicht 20 Jahre unverändert stehen lassen. Da sollte man mit Updates rechnen, auch wenn man das bei IoT gerne unterlässt - u.U. mit Folgen. Trennt man die eigentliche Steuerung vom RasPi ab, dann sind die möglichen Folgen solcher Updates überschaubar. Es kann nur das ausfallen, was der RasPi dazu beträgt. Die autarke Steuerung hingegen ist nicht betroffen. Integriert man beides im RasPi, sollte man genau genommen nach jedem Update gründlich testen, auch was die Stabilität angeht - nur macht das natürlich keiner.
:
Bearbeitet durch User
K. K. schrieb: > Angeblich soll die Bewegungserkennung bei Linux mit entsprechenden > Programmen erheblich besser sein als eine bereits in der Kamera > eingebaute Erkennung, die oft schon bei vorbeiziehenden Wolken Alarm > auslöst. Falls zuverlässige Bewegungserkennung für mehrere Streams > jedoch anstrengend für Einplatinencomputer sein sollte, Vorbei ziehende Wolken, sich bewegende Vegetation, das ist auch für kommerzielle Systeme von z.b. FLIR kein einfaches Terrain. Man behilft sich da am einfachsten mit Masken. So oder so dürfte z.b. etwas wie Zoneminder schon in der Basisversion einen RPi deutlich überlasten. Überlegt man noch den EventServer für Zoneminder (ZM ES) mit einzubinden, kann man je nach Anzahl der Kameras und deren Auflösung durchaus auch ausgewachsene Server ins Schwitzen bringen. Ich hab das bspw. So gelöst daß die Auswertung auf dem sekundären Stream der Kamera läuft und nicht auf dem FHD/4k Stream. Für die 6 Kameras ist der Xeon E3 v5 aber dennoch sichtlich beschäftigt.
Lohnt Raspi etc überhaupt? Ist das wirklich einfacher als alles direkt mit einem ATmega oder STM32 zu machen? ICh habe noch nicht mit Rasberry und co gearbeitet, aber irgendwie auch gar nicht das Verlangen danach. Daher eine ernstgemeinte Frage
KArl Fred M. schrieb: > Ist das wirklich einfacher als alles direkt mit einem ATmega oder STM32 > zu machen? Ist es, sobald Software mitspielt, die es im Linux-Umfeld fertig und adaptierbar gibt, die aber zu Fuss erheblichen Aufwand darstellt. Beispielsweise Webserver mit grafischer Darstellung von Datenauswertung, Datenbanken etc.
KArl Fred M. schrieb: > ICh habe noch nicht mit Rasberry und co gearbeitet, Ein RasPi ist ein Linux-PC(*) in Schrumpf&Stromspar. Plus ein paar Schnittstellen, die man beim PC nicht findet. Was auf dem PC leichter zu implementieren ist, als z.B. auf einem Mega168, ist es wahrscheinlich auch auf dem RasPi. *: Das Windows für RasPi lasse ich gnädigerweise weg. Aber jedem wie er es mag. ;-)
:
Bearbeitet durch User
Hallo, vielen Dank für eure Antworten. Ich habe mit Linux (Debian) auf selbst gebauten Systemen hinsichtlich Dauerbetrieb weder mit LAMP noch mit Python jemals Probleme gehabt, also von problematischen Updates mal abgesehen. Aber ich verstehe das Argument hinsichtlich eines Ausfalls, besonders wenn ich mit dem selben System den umfangreichen Traffic diverser Kameras in Echtzeit verarbeite. Wenn während eines knackigen Winters die Regelung ausfällt und ich nicht da bin, ist das nicht lustig und bei den Preisen momentan überlegt man es sich zwei mal, ob man alles doppelt kauft. Hier scheinen ja mehrere ihre Heizungssteuerung von einem Pi steuern zu lassen...wie lange laufen die bei euch schon und ist bei euch schon mal etwas ausgefallen? Ich werde aber wohl wie empfohlen einen kleinen µC mit eigener Stromversorgung verwenden und den über eine möglichst simple API steuerbar machen, damit ein flexibleres System über das Web-Interface die Parameter darstellen und ändern kann. Eventuell via RS232, so wie ich das von alten SMS-Gateways kenne, die man mit AT-Kommandos steuern konnte. Oder gibt es zuverlässige µCs, auf denen man eine einfache API via Ethernet programmieren kann? In beiden Fällen hätte ich notfalls mit einem beliebigen Computer mit Ethernet oder RS232-USB-Wandler Zugriff auf die Heizungssteuerung, notfalls auch per Fernwartung. Oder würdet ihr in jedem Fall ein eigenes Display an den µC anschließen? Ein komfortables graphisches Display ist bei "einfachen" µCs mit begrenzten Ressourcen ja immer so eine Sache und ich bezweifle, dass außer mir im Notfall jemand das verschachtelte 16x2-Zeichen-Menü mit kryptischen Abkürzungen und Taster-Steuerung zuverlässig bedienen kann. Hier gibt es regelmäßig schon mit der Menü-Steuerung des Fernsehers Verständnis-Probleme. Bezüglich der Sicherung der Software habe ich auch noch eine Frage: bei Debian zieht man sich die Pakete z.B. mit apt und da werden dann jede Menge Abhängigkeiten mit den zu diesem Zeitpunkt aktuellen Versionen aufgelöst. Wichtige Webserver-Umgebungen habe ich bisher immer in virtuellen Maschinen konserviert. Ich habe mich daher nie mit der Frage beschäftigt, ob man mit Hilfe des damaligen Installations-Mediums im Notfall auch nach vielen Jahren noch die ursprügnlichen Versionen mit dem Paketmanager aus den Repositories ziehen kann? Lässt sich alternativ mit Tools der komplette Installations-Verlauf für einen Raspberry offline gestalten oder sollte man den Inhalt der fertig eingerichteten SD-Karte einfach mit dd sichern?
(prx) A. K. schrieb: > Anders ausgedrückt: > - Dokumentation nicht auf bessere Tage verschieben. > - Programmierumgebungen in der zuletzt für dieses Projekt verwendeten > Fassung aufbewahren, Hardware wie Software. Bei PCs empfiehlt sich eine > VM pro Projekt. > - Komponenten auf Reserve halten. Ist blöd, wenn die Heizung nicht am > Gas scheitert, sondern am nicht verfügbaren ATtiny84. > > Wenn man sich daran hält, sind auch 20 Jahre kein Problem. Und dann liegt man im KH oder eine Etage tiefer und Frau sitzt im Kalten und kein Elektriker kann die Selbstbau-Pfrimel-Kacke mehr zum laufen bringen.
:
Bearbeitet durch User
KArl Fred M. schrieb: > Lohnt Raspi etc überhaupt? > Ist das wirklich einfacher als alles direkt mit einem ATmega oder STM32 > zu machen? > ICh habe noch nicht mit Rasberry und co gearbeitet, aber irgendwie auch > gar nicht das Verlangen danach. > Daher eine ernstgemeinte Frage Tja, es war einfacher dafür einen Raspberry zu nehmen, als die Datenbank, den Webserver und WLAN dem Mikrocontroller beizubringen. Der Mikrocontroller kommuniziert mit dem Raspberry auch einfach nur über RS232 und übergibt ihm die Wettervorhersage, Heizzeit- und Temperaturänderungen und Fernbedienungsbefehle, den Rest macht der µC alleine. Der µC gibt an den Raspberry wiederum den Schaltzustand des Brenners, der Pumpen und die diversen Temperaturen zurück.
Cyblord -. schrieb: > (prx) A. K. schrieb: >> Anders ausgedrückt: >> - Dokumentation nicht auf bessere Tage verschieben. >> - Programmierumgebungen in der zuletzt für dieses Projekt verwendeten >> Fassung aufbewahren, Hardware wie Software. Bei PCs empfiehlt sich eine >> VM pro Projekt. >> - Komponenten auf Reserve halten. Ist blöd, wenn die Heizung nicht am >> Gas scheitert, sondern am nicht verfügbaren ATtiny84. >> >> Wenn man sich daran hält, sind auch 20 Jahre kein Problem. > > Und dann liegt man im KH oder eine Etage tiefer und Frau sitzt im Kalten > und kein Elektriker kann die Selbstbau-Pfrimel-Kacke mehr zum laufen > bringen. Quark, einfach das Relais der Eigenbauschaltung durch die original Drahtbrücke ersetzen, die Pumpen auf die Heizungssteuerung des Herstellers stecken und alles läuft wieder wie vorher. DAS traue ich unserem Fachhandwerk, eventuell auch wegen meiner eindeutigen Beschriftungen der Kabel, gerade noch zu.
:
Bearbeitet durch User
Tim T. schrieb: > DAS traue ich unserem Fachhandwerk, eventuell auch wegen meiner > eindeutigen Beschriftungen der Kabel, gerade noch zu. Ja? Dieses Fachhandwerk, hat letztens eine 230V Zuleitung zu einem meiner FH-Ventile schön mittig durchgeschnitten, Ventil getauscht, Kabel mit fetter LÜSTERKLEMME von 1984 verbunden und das ganze Ding mit Isoband umwickelt. Dabei geht da jedes Ventilkabel in einen Verteilerkasten. Aber den muss man aufschrauben. Das spart man sich so natürlich. Und ja, ich glaube nicht viele Elektriker bauen mal schnell deine Schaltung zurück.
:
Bearbeitet durch User
Cyblord -. schrieb: > Und dann liegt man im KH oder eine Etage tiefer und Frau sitzt im Kalten > und kein Elektriker kann die Selbstbau-Pfrimel-Kacke mehr zum laufen > bringen. Ich hatte deshalb einen Schalter dran, der die ganze Steuerung auf klassischen Betrieb umschaltete. Der war auch ganz nützlich für den Schornsteinfeger. Obendrein hing daneben eine triviale Ersatzplatine mit Beschreibung, bestehend nur aus Drahtbrücken, die genau diese Fallback-Funktion implementierte.
KArl Fred M. schrieb: > Lohnt Raspi etc überhaupt? > Ist das wirklich einfacher als alles direkt mit einem ATmega oder STM32 > zu machen? > ICh habe noch nicht mit Rasberry und co gearbeitet, aber irgendwie auch > gar nicht das Verlangen danach. > Daher eine ernstgemeinte Frage Ja, ist in der Hinsicht einfacher, dass man (gerade bei "langsamem" Heizungskram) völlig problemlos mit Interpretersprachen (Perl, Python, etc.) arbeiten kann. Das beschleunigt die Entwicklung enorm. Debugging bzw. Logging sind auch einfacher. Und Netzwerksteuerung geht von selbst ;)
Für den Ausfall haben meine Relais alle 3 Stellungen: Aus, Auto, Ein. Im Fehlerfall schaltet man alle auf ein und der Notbetrieb läuft.
Hier steuert ein OrangePi seit >10 Jahren die Heizung eines Gewächshauses, Programm in Python, watchdog ist ein MC, hätte auch ein 555 sein können.
Das hier ist gut aber wegen Nichtlieferbarkeit von Raspberry Pi Compute Module nicht zu bekommen: https://revolutionpi.de/shop/de/revpi-compact Daher als Alternative "normales" Pi verbunden mit sowas: https://www.controllino.com/
Tim T. schrieb: > Habe dafür einen Raspberry 1B+ mit RS232 angeflanschtem AtMega328 im > Einsatz. Die eigentliche Arbeit macht der AtMega und der Raspberry nur > das Logging in eine MySql Datenbank mit Webinterface, Wettervorhersage > (aus dem Internet) und Fernbedienung. > Wenn ich es nochmal neu machen würde, wäre wohl der Zero W/WH meine > Wahl, eben weil der noch etwas sparsamer ist und WLAN direkt drauf hat. Ich würde ein ESP32 nehmen. Was das Logging angeht reicht ein SD-Adapter mit alter SD-Karte völlig aus (Kosten 1 Euro + Karte). Ansteuerung zur Prg-Änderung via Wlan. Das Hauptproblem ist der "Motor" der den Regler steuert. Oder man hängt den ESP an ein fertiges System (Falls der Hersteller es zulässt).
Ich würde das aufteilen: die eigentliche Heizungssteuerung (Brenner, Mischer, Pumpe) mit so etwas wie einer UVR16x2, alles andere mit Raspi/NUC/was auch immer. Oliver
Bevor du die Hardware wählst: Anlagenliste: Welche haustechnischen Anlagen willst du abdecken? Bei der Heizung solltest du das in Erzeuger, Verteilung und Wärmegeber trennen. Eine Regelung einer Feuerungsanlage ist Teil des CE Kennzeichens und deckt z.B. sicherheitsrelevanten Funktionen ab, die der schwarze Mann testet. Da hat es Vorteile nur mitzulesen und Sollwerte vorzugeben, statt in die Regelung und Funktionen einzugreifen. Welche Funktionen brauchst du? Da du die Fussbodenheizung schon hast: mach mal eine Sprungantwort um dir zu verdeutlichen was überhaupt geht. Was nützt ein PI Regler, der in ms denkt, wenn Verteilung und Wärmegeber ein schnarchlangsames PT2 Glied bilden. Im instabilen Schwingfall willst du ja nicht enden. Wenn du die Funktionen hast, kannst du die digitalen und anlogen i/o zählen. Erst dann die Kommunikationswege (analog, digital, modbus, M-bus, mqtt, sonstwieBus) under Berücksichtigung der Leitungslängen abklabüstern. Denke an den WAF. Gebäudetechnik (GLT) und ccTV auf einer Plattform kann man, muss man aber nicht machen. Selbst ein älterer Raspberry kann GLT problemlos visualisieren. Da gibt es viel Software die du "nur" zu konfigurieren brauchst. ccTV ist dagegen speicherhungrig, mit Bildanalyse auch CPU intensiv. Die üblichen NAS Plattformen haben da was welches manche OpenSource Lösung übertrifft. ccTV kann ausfallen ohne das das Haus unbenutzbar wird. Wenn die Lichtschalter nicht ohne GLT Zentrale funktionieren, bleibt es dunkel und der WAF ist dann in 0,nix negativ. ccTV: Willst du monitorieren, detektieren, observieren, erkennen oder gar identifizieren? "Das ist eine 4k Kamera" reicht nicht. Um DORI (Detection, Observation, Recognition, Identification) Betrachtungen kommst du nicht herum. Die Geometrie musst du schon rechnen. BTW: modbus ist toll, weil offen, das heisst aber auch das jeder Hersteller da rumpfuscht. Wenn du modBus Adressregister revers engineeren musst, dann brauchst du vor allem eines: ZEIT, viel ZEIT. viele vergessen es: Dokumentation, Dokumentation, Dokumentation. Haustechnik läuft schon mal 10 Jahre
Musik og F. schrieb: > Bevor du die Hardware wählst: > > Anlagenliste: Welche haustechnischen Anlagen willst du abdecken? > Bei der Heizung solltest du das in Erzeuger, Verteilung und Wärmegeber > trennen. > Eine Regelung einer Feuerungsanlage ist Teil des CE Kennzeichens und > deckt z.B. sicherheitsrelevanten Funktionen ab, die der schwarze Mann > testet. Da hat es Vorteile nur mitzulesen und Sollwerte vorzugeben, > statt in die Regelung und Funktionen einzugreifen. Nein, genau dieser schwarze Mann wurde natürlich gefragt, bevor ich angefangen habe an der Anlage zu schrauben. Antwort: Solange der STB und Thermoschalter des Kessels und der FW des Brenners weitergenutzt werden, hat der Rest der keine Sicherheitsrelevante Funktion und könnte problemlos getauscht werden. Allerdings wollte er auch weiter seine Schornsteinfeger Taste haben um die Messungen durchführen zu können, also habe ich diese entsprechend angeschlossen. > Welche Funktionen brauchst du? > Da du die Fussbodenheizung schon hast: mach mal eine Sprungantwort um > dir zu verdeutlichen was überhaupt geht. Was nützt ein PI Regler, der in > ms denkt, wenn Verteilung und Wärmegeber ein schnarchlangsames PT2 Glied > bilden. Im instabilen Schwingfall willst du ja nicht enden. Bei mir hat es z.B. damit angefangen das Buderus einen zwingenden Warmwasservorrang beim HK1 eingebaut hat, zusammen mit einer bescheuerten Hysterese, was letztlich zu häufigem Takten und langen Ausfallzeiten im HK1 geführt hat.
:
Bearbeitet durch User
Tim T. schrieb: > Musik og F. schrieb: >> Eine Regelung einer Feuerungsanlage ist Teil des CE Kennzeichens und >> deckt z.B. sicherheitsrelevanten Funktionen ab, die der schwarze Mann >> testet. > Nein, genau dieser schwarze Mann wurde natürlich gefragt, bevor ich > angefangen habe an der Anlage zu schrauben. Antwort: Solange der STB und > Thermoschalter des Kessels und der FW des Brenners weitergenutzt werden, > hat der Rest der keine Sicherheitsrelevante Funktion und könnte > problemlos getauscht werden. Genau das meinte ich doch. Die Sicherheitstechnik der Feuerung muss dran bleiben. Je nach Brennstoff ist die unterschiedlich realisiert. > Bei mir hat es z.B. damit angefangen das Buderus einen zwingenden > Warmwasservorrang beim HK1 eingebaut hat, Das ist dann nicht mehr Feuerung (Wärmeerzeuger) sondern Wärmeverteilung.
Ich steuere meine Heizung, Solaranlage, Beschattung seit 2013 mit Raspi. Bisher kein Ausfall. Gutes Netzteil und Filesystem Readonly, Blitzschutz. Ich habe lediglich 2017 auf eine neue Hardwaregeneration umgestellt, der Raspi ist aber noch der gleiche. Warum Raspi: Programmierung mit Interpretersprache sehr einfach, Netzwerkanschluss sehr einfach. Allerdings habe ich auch noch einen ATMega328 als Backup, der zumind. dafür sorgt, dass im Fehlerfall die Fußbodenheizung weder überhitzt noch einfrieren kann. Zum Thema Wartung der "Selbstfrickel-Kacke" durch einen Installateur: Kann man vergessen. Wird keiner machen. Entweder man begibt sich auf den Weg alles selbst zu machen oder man lässt es bleiben. Hat alles sein Für und Wider. Bei mir sind alle Kabel und Abzweigdosen beschriftet, sodass ein Heizungsmonteur eine neue (professionelle) Steuerung relativ einfach wird einbauen können - im Fall des Falles.
Heinz schrieb: > Bei mir sind alle Kabel und Abzweigdosen beschriftet, sodass ein > Heizungsmonteur eine neue (professionelle) Steuerung relativ einfach > wird einbauen können - im Fall des Falles. Hab ich auch so gemacht. Im Zweifel kann man alles durch Stromstoßschalter, zeitgesteuerte Schalter usw. ersetzen. In anderen Fällen kann man die eigene Steuerung sehr einfach entfernen. Allerdings setzt es immer voraus, dass der jeweilige Handwerker sein Fach wirklich beherrscht und nicht einfach nur ein Teiletauscher ist. Wer sein Fach beherrscht, wird die jeweilige Integration, nicht die Steuerung selbst, der eigenen Steuerungen in max. 5 Minuten durchschauen und wissen wo er seine eigene Technik anschließen muss. Insofern betrachte ich es als eingebauten Handwerker-Qualitätstest für meine eines Tages hinterbliebenen.
Angehängte Dateien:
-
Regelung.jpg
800 KB -
Schema.png
160 KB
Selbst entwickelte Steuerung (Eigentlich Regelung): Angefangen hab ich ca. 2004 mit der Ansteuerung der Grundfos-Pumpen über den Genibus (RS485) und den Pt1000 Fühlern. Im Zuge des Einbaus einer thermischen Solaranlage brauchte es eine neue Regelung. Alles käufliche war zwar cool aber auch sehr teuer (Industriesteuerungen z.B.). Die erste Version lieferte die Daten noch über eine serielle Leitung an einen Rechner der das ganze auf einer Webseite darstellen konnte. Immer wieder hatte ich das Teil erweitert, erst mit dem Ebus (Weishaupt Bus vom Kessel dekodiert) für die Ansteuerung mit Sollwert und Status/Fehlerabfragen, dann mit einem EERAM für die Speicherung von Zählwerten bei Stromausfall. Ein Display und ein anderer Spannungsregler kam auch noch dazu.. Nur leider für größere Dinge wie eine Webseite reicht der Speicher des ATMega644 nicht, dafür ist er auch zu langsam. Läuft aber so seit fast 20 Jahren, es gab nur etwa eine Handvoll Störungen in der Zeit (Heizung bzw. Wasser kalt) ;) Konnte aber alle beheben oder debuggen. Dumm halt weil es ein großes Haus mit Ferienwohnungen ist. Ist hier live zu sehen: http://tux.zugspitzort.de/heizung Die Daten holt sich der Rechner über Netzwerk und UDP mit einem C-Programm vom AVR. Der Kessel ist zur Zeit hart ausgeschalten weil Sommer und deshalb die Störung. Könnte man auch noch umprogrammieren. Programmänderungen sind möglich über C-Code bearbeiten, Firmware kompilieren und per Bootloder über LAN laden in sekundenschnelle. So eine eigene Software zum Einstellen gab es auch mal war aber sehr umständlich immer aktuell zu halten. Da ist man mit einem Raspi o.ä. flexibler mit Python. (Fehler-) Meldungen gibt es auch über Telegram, sehr praktisch. Fazit: Hat Spaß gemacht, war extrem viel Arbeit, würde ich heute nicht mehr so machen. Lieber einen Raspi nehmen wie weiter oben beschrieben aber selber die Erweiterungen bauen mit Gehäuse. Z.B. ähnlich dem RevPi Compact aber seitlich erweiterbar mit variablen Steckmodulen wie z.B. das Priva HX System: https://www.kka-online.info/artikel/kka_Nachhaltig_klimatisiertes_Finanzzentrum_1418817.html (Beispiel, die ersten zwei Bilder) Die Schwierigkeit dabei sind die passenden Gehäuse zu finden. Die Idee der Raspberry Pi HATs sind ja eigentlich nicht schlecht aber für sowas ungeeignet. Manuelle Schalter für jeden Ausgang sind sowieso Pflicht und auf jeden Fall einen Ersatzraspi daneben legen mit Backup-SD Karte..
K. K. schrieb: > aber da scheinen viele Modelle > momentan ausverkauft zu sein Raspberry Pi 400 kaufen und glücklich sein. Die meisten Einkäufer sind zu blöd etwas kreativ zu werden oder sie sind tatsächlich auf den Formfaktor des Pi 4 angewiesen bzw. wollen ein PoE Shield aufsetzen. Gibt die CM4 teils fertig in Hutschienengehäusen mit IO Board, dürfte vermutlich die einfachste Lösung sein wenn du nix selber bauen willst in der Richtung. Was ggf. auch reichen könnte: Ein ESP32, die bekommt man relativ günstig und hat mit ESP-IDF auch ein halbwegs brauchbares OS. Wobei so ein Pi dann doch deutlich mehr Spaß macht, einfach einen nginx aufsetzen und schon hat man einen Webserver, man kann auch seine Steuerungen in Snaps packen und so schön automatisch aktualisieren mit Rollback...
Ich A. schrieb: > Ich hab das bspw. So gelöst daß die Auswertung auf dem sekundären Stream > der Kamera läuft und nicht auf dem FHD/4k Stream. Für die 6 Kameras ist > der Xeon E3 v5 aber dennoch sichtlich beschäftigt. Was zieht das denn für Strom? Das wird nicht unerheblich sein!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.