Hi Forum, leider suche ich mich mit folgendem Problem zu Tode und bitte euch um Unterstützung. Ich möchte eine Heizungs/Energieanlagensteuerung bzw. Energiemanagementsystem aufbauen, dafür suche ich eine geeignete Plattform. Falls möglich möchte ich kein neues Hardware-Produkt entwickeln, also ich suche nicht ein Bauteil, sondern irgendwas zwischen RasPi/Arduino und SPS, ggf. aus mehreren Modulen bestehend, mit folgenden Anforderungen: - bezahlbar, bereits incl. Gehäuse und Industriestandard - geeignet für 10-30 Jahre 24/7 Laufzeit - programmierbar idealerweise mit Java, ggf. auch wie Arduino, ggf. andere Sprache (Wichtig ist mir keine zu hohe Einstiegshürde) - Ich möchte Analog und Digitalwerte einlesen und ansteuern, z.B. -10V...10V, 0...10V, 0/5V etc. sowie RTD-Inputs (PT1000) - Ich benötige möglichst flexibel verschiedene Bussysteme für Ansteuerung von Energieanlagen - Anschluss an Internet, zur Kommunikation mit Server, später über Smart Meter Gateway - Anbindung eines Touch Screens zur Visualisierung und für Einstellungen verändern Leider weiß ich nicht recht wie ich an das Problem der Hardware Auswahl herangehen soll. Wie gesagt ich habe schon extrem viel recherchiert, jedoch nicht wirklich erfolgreich. Vielen Dank für eure Hilfe und Ideen! mfg fchri
Ohne jetzt näher zu suchen, wie wäre es mit einer Siemens LOGO. Die ist günstig und einfach Programmierbar. Sie hat Ethernet und viele Erweiterungsmodule für analog und digital. Mittlerweile gibt es meine ich auch eine ganze Reihe an BUS Modulen, unter anderem auch EIB.
Franz C. schrieb: > Anforderungen: > - bezahlbar, bereits incl. Gehäuse und Industriestandard > - geeignet für 10-30 Jahre 24/7 Laufzeit > - ..... > - .. Wenn da nicht die Forderung nach Java wäre, würde sich das für mich anhören, wie wenn du nach einer Beckhoff SPS suchst. Aber die könntest du ggfs mit "strukturiertem Text" oder letztlich gar in C++ programmieren. Allein das mit dem "bezahlbar" wird dann angesichts der Lizenzgebühren für das TwinCAT doch noch interessant... ;-) Falls du übrigens vor hast, dein Haus zu modifizieren und das später wieder zu verkaufen: lass die Sache mit der selbstgebauten Zentralsteuerung. Keiner ausser dir kennt sich damit aus, der Käufer muss das alles herausreißen (lassen) und neu machen (lassen). In einer bestehenden Installation entwertet das die Hütte gewaltig.
Hallo, Danke für die Rückmeldungen. Die Siemens LOGO Steuerungen lassen sich meines Wissens nicht sinnvoll über Java ansteuern, Siemens hat seine Systeme sehr Proprietär aufgebaut. Oder ist mein Wissensstand falsch? Beckhoff habe ich auch schon öfter nachgedacht... Angeblich sind deren EtherCAT Schnittstellen offen, das heißt man könnte einen Linux Rechner über EtherCAT mit den Schnittstellen Karten verbinden. Nur die Frage wie bringt man auf einen Linux Rechner EtherCAT zum laufen? Damit müsste sich dann das Thema Lizenz auch gegessen haben... Das Thema mit der Entwertung des Hauses ist mir bewusst, das ist auch nicht das was ich möchte. Danke trotzdem für den Hinweis. Viele Grüße, fchri
Franz C. schrieb: > irgendwas zwischen RasPi/Arduino und SPS https://www.controllino.biz/ https://revolution.kunbus.de/
Hallo Franz, ich habe mir selber schon ähnliche Gedanken gemacht, da wir eine sehr komplexe Heizungsinstallation haben, d.h. Ölheizung, Holzheizung und Solarthermie mit mehreren Pufferspeichern, sowohl für Heizung, als auch für Brauchwasser und das ganze ist auch noch auf zwei Gebäude verteilt. Implementiert habe ich bisher noch nichts aber hier sind meine Gedanken dazu: 1. "Backend" und "Frontend" sollten klar getrennt sein. 2. Das "Backend" (die eigentliche Heizungssteuerung) sollte so einfach wie möglich gehalten sein. Wartbarkeit und Ersatzteilversorgung sind neben der Zuverlässigkeit des Systems essentiell. 3. Das Backend muss unbedingt autark lauffähig und parametrierbar sein. 4. Das "Frontend" (alles was etwa auf einer Linuxkiste läuft und über Handy, Tablet, Webbrowser, etc. bedient wird) dient nur der Visualisierung und als komfortablere Möglichkeit der Parametrierung und Steuerung einzelner Funktionen. Zur Begründung: Wir haben hier schon eine bestehende KNX-Installation die auch vom Tablet, Smartphone, etc. mittels OpenHAB angesteuert werden kann. OpenHAB läuft auf einem Raspberry Pi der im Schaltschrank hängt und das auch seit mittlerweile über sieben Jahren (und das nebenbei bemerkt, bisher ohne einen einzigen Ausfall). Trotzdem bin ich sehr froh, dass auch wenn es mal zu Problemen mit OpenHAB kommen sollte, man Licht, Jalousien und Fußbodenheizung ganz klassisch an den Schaltern steuern kann. Die einzelnen KNX-Geräte könnte ich jederzeit (auch durch Geräte anderer Hersteller) ersetzen, sollte da mal ein Aktor kaputt gehen. Wichtig ist jedoch auch, dass jeder Elektriker, der nur ein bisschen Ahnung von KNX hat, einen Aktor tauschen und neu parametrieren könnte, falls ich zufällig morgen vom Bus überfahren würde. Der berühmte "Bus-Faktor" ist hier also deutlich über eins. Für OpenHAB sieht das zwar etwas schlechter aus, weil sich meine buckelige Verwandschaft vermutlich Hilfe über irgendwelche Foren suchen müsste aber zumindest würden sie nicht im Dunkeln sitzen. Für meine Heizungssteuerung bedeutet das, dass ich sie entweder mit einer (bzw. mehreren) "Allerwelts-SPS" oder mit eigener Hardware auf Arduinobasis aufbaue, d.h. ein Arduino-Nano und ein bisschen Peripherie auf Lochraster. In beiden Fällen ist natürlich die Dokumentation essentiell (was übrigens natürlich auch für KNX gilt), wobei es dann eine sehr große Anzahl an Menschen gibt, die so ein System warten könnten. Die Ersatzteilversorgung wäre bei der SPS grundsätzlich besser, wobei bei einer Arduino-Lösung die Komponenten so günstig wären, dass ich durchaus Ersatzgeräte "auf Halde" legen könnte, die dann relativ einfach zu tauschen wären. Da bei uns die ganze Heizungsmimik räumlich sehr verteilt ist, werde ich als Bussystem sehr wahrscheinlich auf Modbus zurückgreifen. Das hat zwar den Nachteil, dass es nicht Multimaster-fähig ist (im Gegensatz zu CAN) aber mir gefällt die Einfachheit des Protokolls und der benötigten Hardware, was für mich persönlich diesen Nachteil überwiegt (da es ebenfalls den "Bus-Faktor" erhöht). Als "Frontend" werde ich die bestehende OpenHAB Installation nutzen, zum einen weil sie schon da ist und zum anderen, weil OpenHAB meiner Meinung nach sehr elegant ist. Es gibt Plugins (sog. "Bindings") für so ziemlich jede Spielerei, die man in einem Haus automatisieren kann und man hat nahezu unendliche Konfigurationsmöglichkeiten. OpenHAB ist übrigens in Java geschrieben, so dass du dir gegebenenfalls sogar eigene Plugins schreiben könntest. Das würde ich mir an deiner Stelle auf jeden Fall mal anschauen.
Hallo Christopher, danke für die sehr ausführliche Antwort, dein Projekt scheint auch recht umfangreich. Das ganze Thema Smart Home, auf welches du auch mit eingehst, ist für mich erstmal nicht so wichtig - also auch die KNX Thematik. Der Gedanke mit Front-end und Back-end aufteilen finde ich gut, wobei ich mit recht komplexer Mathematik die optimale Betriebsweise der Gesamtanlage berechnen möchte. Naja - das bedeutet dass ich schon etwas Rechenleistung brauche und als Frontend "nur" einen Screen welcher letztendlich den Anlagenzustand darstellt und Parametrierungen etc. zulässt. Letztendlich lese ich aus deinem Artikel im Wesentlichen den Vorschlag für folgende Lösungen, was mein oben genanntes Problem betrifft: - eine (bzw. mehrere) "Allerwelts-SPS" - eigene Hardware auf Arduinobasis, d.h. ein Arduino-Nano und ein bisschen Peripherie auf Lochraster Eigene Hardware kommt für mich leider nicht in Frage. Bleiben Allerwelts-SPS. Hast du da schon Ideen? Mit welchen Sprachen willst du das dann implementieren? VG Franz
Franz C. schrieb: > eigene Hardware auf Arduinobasis Wie schon geschrieben ist das nicht nötig weil es zertifizierte SPS auf Arduino-Basis und mit Arduino IDE programmierbar gibt z.B. https://www.controllino.biz/controllino-maxi/ RTD kannst Du über Analog-Konverter anschliessen oder über MODBUS RTD-Klemme z.B. https://www.meilhaus.de/ex-9033.htm Genauso gibt es zertifizierte SPS auf Raspberry Pi Basis die Du in Python programmieren kannst z.B. https://revolution.kunbus.de/revpi-core/ Und dafür gibt es eine RTD-Klemme: https://revolution.kunbus.de/analoges-io-modul/
Franz C. schrieb: > Eigene Hardware kommt für mich leider nicht in Frage. Bleiben > Allerwelts-SPS. Hast du da schon Ideen? Mit welchen Sprachen willst du > das dann implementieren? Mit "Allerwelts-SPS" meinte ich so typische Kleinsteuerungen wie die Siemens Logo oder "Easy" von Möller (jetzt Eaton). Für "komplexe Mathematik" würde ich wenn überhaupt "Structured Text" nutzen wollen, was etwa an Pascal angelehnt ist. Die Logo kann meines Wissens nach kein ST, die Easy dagegen schon. Für "komplexe Mathematik" würde ich sogar eine Lösung auf Arduino- oder RPi-Basis, wie von Lothar vorgeschlagen, in Erwägung ziehen. Für mich persönlich ist das aber für so etwas essentielles wie eine Heizungssteuerung etwas zu viel "High Level". Ich habe auch Ideen für solche Spielereien aber es sollte immer so sein, dass die Heizung in ihrer Grundfunktionalität immer funktioniert und das nicht in Abhängigkeit von irgendeiner Linuxkiste. Wenn es doch mal im Januar -10 Grad hat und die super-duper Steuerung streikt, weil beim RPi gerade irgendetwas quer liegt, dann ist der WAF ganz schnell im Keller. An Controllino u. Ä. würde ich halt die Langzeitverfügbarkeit zumindest anzweifeln. Mein Vorschlag wäre Kleinsteuerung <-> Modbus <-> Linuxkiste Die Kleinsteuerung überwacht die Temperatursensoren und schaltet in Abhängigkeit davon Ventile und Pumpen. Programmiert ist sie in einer SPS-typischen "Programmiersprache", d.h. Kontaktplan, FUP, AWL oder ST. Parameter (etwa eine Differenztemperatur ab der eine Pumpe anspringt) müssen ohne Neuprogrammierung der Steuerung, direkt an der Steuerung einstellbar sein, im einfachsten Fall über Potentiometer und einfache Schalter. Die Linuxkiste hat mittels Modbus Zugriff auf sämtliche Temperatursensoren, sowie den Istzustand von Pumpen und Ventilen. Per zentralem Schalter an der Steuerung kann man die Steuerung auf "standby" schalten. Nun hat die Linuxkiste die Deutungshoheit über Ventile und Pumpen. Sollzustände werden von der SPS per Modbus abgefragt und entsprechend umgesetzt. Auf der Linuxkiste (kann ein RPi sein, muss aber nicht unbedingt) kann dann eine beliebige Software laufen um die SPS per Modbus mit Sollwerten zu füttern. Ebenfalls kann man die Daten natürlich auch loggen und visualisieren. Gegenüber den vorgeschlagenen SPS auf Raspberry- bzw. Arduinobasis hat das meiner Meinung nach den Vorteil, dass die einzelnen Teile besser verfügbar sind, falls mal etwas kaputt geht und das die grundlegende Steuerung zwar "dumm" aber "einfach" und "robust" ist. Das ganze erkauft man sich mit einem höheren Preis gegenüber einer integrierten Lösung. Zur Sache bei uns: Momentan läuft die ganze Heizungssteuerung bei uns eher manuell bzw. teilautonom. Wenn man im einen Haus mit Holz geheizt hat, wird auch die Ölheizung im anderen Haus mit dem warmen Wasser durchflossen, weil die Kreisläufe verbunden sind. Davon bekommt man im Haus mit der Ölheizung jedoch noch nicht automatisch warmes Duschwasser, weil dafür eine Boilerladepumpe laufen muss. Die aktuelle Hosenträgerhilfskonstruktion ist eine "Eieruhr", über welche man die Pumpe eine bestimmte Zeit laufen lassen kann. D.h. erst Feuer machen, dann ca. eine Stunde warten bis die Heizung auf Temperatur ist, dann Eieruhr drehen. Andersrum gibt es im Haus mit der Holzheizung, wenn mal mit Öl geheizt wird, kein warmes Brauchwasser wenn nicht da eine Pumpe zu einer bestimmten Zeit läuft. Die Hosenträgerhilfskonstruktion ist hier eine Wochenzeitschaltuhr, die manuell mit der Wochenzeitschaltuhr der Ölheizung synchronisiert werden muss (inkl. Vorlaufzeiten, etc.). Diese ganzen Pumpenschaltvorgänge würde ich gerne automatisieren und nebenbei auch noch die Möglichkeit einer Visualisierung haben. Für die eigentliche Steuerung brauche ich aber definitiv keine höhere Mathematik ;)
:
Bearbeitet durch User
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.