Junkers 1-2-4 Stetigregelung (Arduino/ PWM/ Transistorlösung)

Begonnen von KaiK, 30 Dezember 2013, 17:37:27

Vorheriges Thema - Nächstes Thema

Ragnar

Anscheinend haben die beiden aber eine "Schaltungslösung" für das Thema das bei einem Ausfall des Controllers (Stromlos warum auch immer) die normale Steuerung durchreicht.

hexenmeister

Stromlosen Zustand alleine ist einfach zu erkennen. Ein Relay fällt ab - das reicht schon. Aber das bringt dich nicht sicher weiter. Was ist mit dem Fall, wenn der neue Controller "hängt"? Also abgestürzt ist. Dabei wird ja nichts "stromlos".
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Ragnar

Und wenn ich in den Code einfach zustätzlichen zur Relaissteuerung eine alive Meldung über den SerialMonitor ausgeben, den dann der RasPi prüft und ggf. die Stromversorgung neu startet und mir eine Meldung auf alle Smartphones per Push ausgibt? Dafür brauch ich doch keine redundante Hardware. Also aus dem Stand kann ich nicht sagen wie der Code aussehen muss. Aber so in etwas muss das doch zu lösen sein.

hexenmeister

Und wer prüft und reagiert auf die alive-Meldung? Und was ist, wenn diese Instanz auch ausfällt?
Die Frage nach der Notwendigkeit der Redundanz richtet sich nach der gewünschten Sicherheit.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Ragnar

Also irgendwie kann man es auch übertreiben :) Das Bauteil des orignal Reglers wird ja auch nicht redundant ausgelegt oder geprüft. Wenn das ausfällt geht die Heizung auch nicht mehr.

Zitat von: hexenmeisterUnd wer prüft und reagiert auf die alive-Meldung?

Zitat von: Ragnareine alive Meldung über den SerialMonitor ausgeben, den dann der RasPi prüft und ggf. die Stromversorgung neu startet und mir eine Meldung auf alle Smartphones per Push ausgibt?

Gut ok, dann schau ich jetzt mal im Netz wie man ein Relaise abfallem lässt.

hexenmeister

Du hast nach Sicherheit gefragt ;) Es ist halt die Frage des Aufwandes und was man eigentlich haben will. Das letztere musst Du schon etwas genauer definieren.
Der Vergleich mit dem Originalregler stimmt dennoch nicht wirklich. Mit dem Hardwareausfall würde ich zwar auch nicht rechnen, mit der Softwareproblemen jedoch schon.
Etwas, wo ein "normales" Betriebsystem läuft, stürtz mit zimlicher Sicherheit irgendwann ab. Einer Bastelkiste, und dann noch so einer instabielen, wie Raspberry (obwohl B+ soll angeblich besser sein), würde ich mine Heizung nicht ohne weiteres anvertrauen. Die "richtigen" Industrieplatienen kosten nicht umsonst vielfaches davon.
Und das Problem der eigenen Software. Zur Erstellung eines stabilen Systems gehört eine Menge Erfahrung. Die Entwickler des Originalteils haben diese und auch andere Möglichkeiten zum Testen. Ein durchschnittlicher Bastler hat i.d.R. nichts von Beidem.

Daher würde ich schon ein zweiteiliges System aufbauen:
1. Ein Arduino, der auf das Ausbleiben einer Alive-Meldung reagiert (z.B. schaltet ein Releay ab). Das Teil ist fast so einfach, wie ein Bügeleisen, da kann die Software in Griff bekommen.
2. Ein Linux-Rechner mit der eigentlichen Steuerung und aktivierten Watchdog.

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

JanK

Zu diesem Thema gibt es übrigens einen Wiki Artikel, der das ganze elektronisch sehr schön löst.

http://www.fhemwiki.de/wiki/Junkers_Therme_Stetigregelung

Da wird auch die redundanz betrachtet und dies ist mit einer einfachen Diode gelöst ...

Weitere sich selbst überwachende mikrocontroller erhöhen lediglich die Systemkomplexität und reduzieren nicht unbedingt das Ausfallrisiko ;)

Da der Raumtemperaturregler optimalerweise auf einem niedrigen Wert steht wird dieser nur im Fehlerfall ein höheres Signal als der eigene Regler liefern, daher ist das was man benötigt eine Schaltung, die aus zwei Spannungen die Höhere an die Therme weiterleitet.

kpwg

#22
Zitat von: JanK am 11 Januar 2015, 14:17:33
Zu diesem Thema gibt es übrigens einen Wiki Artikel, der das ganze elektronisch sehr schön löst.

http://www.fhemwiki.de/wiki/Junkers_Therme_Stetigregelung
Habe die Lösung seit etwa sechs Monaten in Betrieb- sie funktioniert einwandfrei und ausreichend sicher. Lediglich dem DAC sollte man per C6-script einen Sollwert beim Starten mitgeben (Initialisierung), da in Ausnahmefällen (!) noch falsche Daten im DAC stehen. Habe zusätzlich noch 3x DS18B20 an den Rohren (VL, RL, WW). Meine Therme hat also eine IP...  8)

Edit: paar Bilder dazu: http://www.ethersex.de/index.php/FHEM_Kueche_(Deutsch)
Mittlerweile ist ein Mega644p drin der noch einen BMP180 bedient und reichlich Luft für weitere Ideen hat.

Cihan

Mit dem simplen ein und ausschalten habe ich das Problem, das die Therme zu oft taktet, da sie auf Volllast läuft.
Wie habt ihr das gelöst?
RPi4 Shelly Zigbee

sim

Hallo,

ich möchte KaiKs Lösung mit dem Optokoplers (PC817) nachbauen. Dazu habe ich noch eine Frage:

Kann ich die Steuerspannungsleitung der Therme einfach mit GND der Therme "kurzschließen" oder brauche ich da einen Widerstand? Wenn ja, wie kann ich herausfinden welchen?

Ich kenne mich leider nicht so gut aus und möchte meine Therme nicht beschädigen indem ich es es einfach mal ausprobiere.

Vielen Dank schon mal im Voraus :-)

KaiK

Hey,

es wird kein Widerstand benötigt.
Die Steuerleitung geht über den Optokopler auf GND.

VG
Kai
FHEM auf Raspberry Pi, HM-CFG-LAN, 3x HM-CC-RT-DN
Testbed: Arduino Mega 2560 mit Config. Firmata als Sensor/Aktuator

sim

#26
Danke für die schnelle Antwort, Kai.

Ich überlege zusätzlich noch über ein Relais den Original-Regler wieder aktiv zu schalten wenn der RasPi ausfallen sollte. Ein "Aufhängen" der Software kann ich dadurch natürlich nicht abfangen. Das ist mir klar.


Zitat von: Cihan am 16 August 2015, 02:18:55
Mit dem simplen ein und ausschalten habe ich das Problem, das die Therme zu oft taktet, da sie auf Volllast läuft.
Wie habt ihr das gelöst?

Ich verstehe deine Frage so, dass bei dir die Therme zu oft an und aus geschaltet wird. Das lässt sich vielleicht durch eine etwas "träge" Regelung umgehen. Dazu ein Beispiel:
Eingestellte Solltemperatur in einem Raum: 20°C
Jetzt würde ich FHEM so programmieren, dass die Therme erst aktiviert wird wenn die Temperatur unter 19,5°C fällt. Und sie soll heizen bis die Temperatur 20,5°C erreicht hat. Erst dann wird die Therme deaktiviert. Aktiviert wird sie erst wieder wenn die Temperatur auf 19,5°C gefallen ist.

Hört sich das machbar und sinnvoll an?

KaiK

Daas mit der "Trägheit" würde ich so auch lösen.
Im Modul HCS ist das bereits vorgesehen. Stichwort Threshold.
FHEM auf Raspberry Pi, HM-CFG-LAN, 3x HM-CC-RT-DN
Testbed: Arduino Mega 2560 mit Config. Firmata als Sensor/Aktuator

swther

Moin Moin,

Ich beschäftige mich auch gerade mit dem Thema und wenn ich das richtig verstanden habe, kann man ganz einfach die 24V via Aktor oder Relais auf die Klemme 2 durchschalten und mittels HCS-Modul steuern.

Da ich Eltako-Enocean-Komponenten im Haus nutze, würde ich somit gerne den FSR61/8-24VUC Aktor einsetzen. Ist mein Gedankengang richtig?

Als Sensoren verwende ich die Heizungsthermostate von Homematic, sodass bei bestimmten Temperaturabfall in einem Raum die Therme (bzw. der Eltako-Aktor) angesteuert werden soll.

MfG
Wolle

wthiess

#29
Hallo!
Ich hoffe ich bekomme hier noch Antwort. Wenn ich das richtig verstanden habe benötige ich nur einen Schalter/Relais um die Heizung ein oder auszuschalten. Welche Pins muss/darf ich kurzschließen. 1,2,4??. Wenn das so läuft dann werde ich einfach ein Relais mit Fernsteuerung/Funk einbauen. ausfallsicherheit ist mir egal.
Danke im voraus
lg
Wolfgang
Raspberry Pi 3; 8xRelais; Aptodec Nano V3.0 Pro; FS1000a; RF-5V; Hama TS33C; 3x Brennerstuhl FunkSteckdosen; 9x Dooya funk Rollo; KWL Systemair VR400; Thermokon Modbusthermostat; diverse China Modbus Thermostate; 1-wire Bus; Telegram; QuickFhem; FhemNative; Firmata; Alexa ......