[DISKUSSION] Notlauf, wie habt Ihr das Thema implementiert

[markusrohr]

Guten Tag Jochen @Dragonos2000 und Robert @Robert_Mini ,

ein reiner Gedankenaustausch ohne Dringlichkeit: Ihr habt unter viewtopic.php?f=46&t=1829&p=19476&hilit=notlauf#p19476 eine Diskussion begonnen, wie ein Notlaufkonzept aussehen könnte.

Ich habe in der zwischenzeit eine Vielzahl an Logiken laufen (sehr viele die Ihr ins Forum eingebracht habt) und über die CV Bedienung und Visualisierung implementiert.
Es ist nun Zeit sich Gedanken über ein gutes Notlaufkonzept zu machen, falls der TWS doch einmal ausfallen sollte (Ich bin mir sehr wohl bewusst, dass "Galaxien" bezüglich Zuverlässigkeit zwischen einem RPi aus dem obigen Post und einem TWS liegen, aber Murphey kann eben auch beim TWS zuschlagen).

Bei mir bedeutet dies wahrscheinlich den Übergang auf einen reinen Handbetrieb, weil ich die meiste Sensorik über 1-Wire Komponenten realisiert habe, die bei einem Ausfall des TWS auch nicht mehr funktionieren würden. Das ist bei der angegebenen Ausfallwahrscheinlichkeit des TWS akzeptabel.

Licht (über 2 unabhängige DALI-Gateways) und die Notfunktionen für die Beschattung (über einen Heartbeat am SMI Aktor) funktionieren unabhängig vom TWS.
Zusätzlich habe ich ein Bedienpaneel "ohne Schnickschnack" von IPAS installiert, über das ich im Notbetrieb direkt auf KNX Ebene steuern kann.
Dieser Aufbau bringt es mit sich, dass ich Befehle und Zustände auf Logik- und KNX Ebene synchronisieren muss (ich verwende getrennte GA für Befehle und Zustände). Die professionelle Lösung wäre wahrscheinlich über eine "hörende GA" auf KNX Ebene. Ich kann dieses Konzept aber nicht wirklich umsetzen (bin da etwas begriffsstutzig) und nicht im vollen Umfang überblicken, besonders wenn ich die CV mit einbeziehe.

Mein Work Around im Augenblick: ich lasse grundlegende (zentrale) Befehle wie "vorOrt-auf Reise" oder "schlafen-wach"im Normalbetrieb über die Logiken laufen und wandle sie dort in "Zustände" um. Im Notbetrieb muss ich aber direkt Zustände (über mein IPAS Paneel) eingeben können. Also eine Vermischung von Befehlen und Zuständen im Normalbetrieb bei bedienung über das Paneel. Ich vermeide Konflikte, indem ich Robert's Baustein "der letzte Wert gewinnt" viewtopic.php?f=65&p=23860#p23860 als Eingang benutze.
ine saubere und durchdachte technische Lösung sieht wohl anders aus.

Wie habt Ihr das Thema "Notlauf" bei Euch implementiert. Im Post von Jochen wird eine MDT Baustein erwähnt, der die Umschaltung macht. Wie funktioniert dies genau?

Danke für Euren Input und freundliche Grüsse
Markus

[Robert_Mini]

Hallo Markus!

Interessantes Thema. Ich muss aber eingestehen, dass ich über den Fall nur mehr wenig nachgedacht habe, weil:
- Weder mit WG noch TWS jemals ein Problem bestanden hat
- Die Komplexität beliebig steigt

Ich halte das bez. Zuständen und Schalten nicht ganz so strikt wie du, d.h. bei Aktoren ist der Zustand getrennt im Schalt- und Rückmeldeobjekt gehalten (ähnlich dir). Bei Zuständen, die sich aus der Logik ergeben, verwende ich auch diesen direkt in der CV / Infodisplay etc. d.h. kann diesen auch Umschalten, wenn die Logik nicht da wäre. Bei aktiver Logik muss man da eben die Logik auch sperren, wenn man nicht will, dass der Zustand nach einer gewissen Zeit wieder Überschrieben wird.

Wichtiger ist da aus meiner Sicht das Thema Persistenz, so dass nach einem Stromausfall alle Zustände etc. passen.
Der TWS (und damit all Komfort) sind eben ein Single Point of Failure, daran ändern auch ein paar Zustände nichts, da am Ende wieder auch viele davon wieder in einer Logik münden und ohnehin am TWS hängen.

Dennoch ist die Diskussion gut, denn mir wird grad auch bewusst, was alles ohne TWS nicht funktionieren würde.

lg
Robert

[markusrohr]

Hallo Robert @Robert_Mini ,
danke für den schnellen Feed Back. Ein Grundproblem ist tatsächlich das Überscheiben. Ich habe bei vielen Logiken eine Trigger gesetzt und sende die Zustände periodisch auf den Bus. Ein Hauptgrund ist, dass ich nach wie vor (zu) viel an den Logiken herumbastle und periodisch wieder definierte Zustände haben will. Nach diesen Triggern kommtes von Zeit zu Zeit zu ungewollten Effekten

Das Problem der Persistenz und Zurückschreiben der Parameter habe ich wieder einmal mehr nur dank Deiner Logiken gelöst. Ich weiss jetzt, dass ich wieder mit definierten Zuständen starten kann. Davor konnte ein Neustart sehr zeitaufwändig werden. Diese Logiken waren überhaupt die Voraussetzung, dass ich überhaupt auf Paramter in der Visu übergehen konnte, ich hatte zuvor die Parameter in den Logiken fest programmiert.

Es "beruhigt" mich etwas, dass auch bei Dir die bei solchen Fragestellungen Komplexität steil ansteigt, ich bin mir jeweils nicht sicher ob ich zu kompliziert denke.
Beste Grüsse und bleib gesund
Markus

[StefanW]

Hallo,

das Thema "Was bei Ausfall tun" ist wichtig und das wird von uns auch beachtet

1. Der Server hat genau deshalb soviele Statusanzeigen für wichtige Funktionen, damit man sehr schnell einen Überblick bekommt, wo es denn nun hängt.

2. Für eine ganze Reihe dieser Statusanzeigen werden bei Mouse-Over auch Handlungsempfehlungen gegeben, was man als nächstes prüfen soll.

3. Alle Server haben ein Notfall-Bootsystem inkl. Support-VPN. Bei Problemen könnten wir selbst bei einer völlig toten Installation (ist noch nie vorgekommen) darüber ein neues System installieren

4. Alle Server sind mit einem separaten Flash nur für Backup ausgestattet, das sollte man auch regelmäßig nutzen

5. Wir bieten mit den Care-Stufen ab Silber genau dafür entsprechende priorisierte Austausch-Services für die Server an. Es ist letztlich wie eine Versicherung, wir halten fertig installierten Ersatz vor und senden zügig und vorab ein Ersatzgerät

6. Die größte Gefahr für Elektronik geht von Überspannung aus. Wer die Verfügbarkeit des Servers erhalten möchte, sollte in entsprechende BlitzART Module für alle genutzten Interfaces investieren. https://shop.elabnet.de/blitzart/ueberspannungsschutz

Wir empfehlen, das Licht in Treppenhaus und wichtigen Technikräumen und Küche auch von Hand geschaltet werden kann (direkte Aktorbedienung oder manuellen Lichtschalter). Es gibt auch DALI-Lichtschalter, die direkt am DALI-Bus laufen. Heizungsventile sollten unserer Ansicht nach stromlos offen installiert werden, damit bei Ausfall der Ansteuerung nichts ausfällt (Vorlauftemperatur und hydraulischer Abgleich sollten für diesen Fall schon passen).


lg


Stefan

[markusrohr]

Hallo Stefan,
es geht mir wirklich nur um meine eigene Implementierung und wie sinnvoll meine Gedankengänge sind.

Der TWS ist in Bezug auf Ausfallsicherheit und Unterstützung im Falle eines Falles vorbildlich, keine Frage. Ich nutze die Flash Card für ein Backup. Alle 1-Wire und KNX Leitungen sind bereits mit Blitzart geschützt, es fehlen noch die Speisungen. Dafür fehlten ja die BlitzArt Module für lange Zeit, wenn ich mich richtig erinnere. Diese kommen aber sofort an die Reihe, wenn ich eine vernünftige Bestellgrösse zusammenbringe. Ist eine wirklich geniale Produktlinie, Hut ab! (ich habe vor sehr langer Zeit einmal ein paar Semester Hochspannungstechnik studiert)

Für DALI habe ich 2 Gateways an zwei verschiedenen Phasen mit je separatem FI/LS, damit meine Frau keinesfalls im Dunkeln sitzt. DALI hat ja auch den Vorteil, dass bei einer Wiederkehr der Phasenspannung und zum Teil bei einem Komponentenausfall die Lichter angeschaltet werden.

Bei der Heizung habe ich für mich den Ansatz "stromlos geschlossen" gewählt. Wir haben "nur" eine Wohnung mit nur einer exponierten Fassade, der Temperaturabfall beträgt im Winter um die 1°K pro Woche, wenn die Ventile geschlossen sind und die Sonne nicht scheint. "Stromlos offen" würde die Wohnung bei Stromausfall innert kürzester Zeit sinnlos überheizen. Sieht bei einem freistehenden Haus aber natürlich ganz anders aus.

Beste Grüsse
Markus

[gbglace]

Wenn man eine zentrale Logikengine abkoppeln können soll, dann kannst eigentlich nur auf rein KNX basierte Logikmodule setzen und alle Befehle durch eine Tor-Logik schicken, die eben auf ein Hartbeat vom TWS / bzw. dessen Logikengine oder anderem benötigten Subsystem horcht. Fehlt dessen Telegramm, dann geht das Tor auf und es werden die Befehle vom Taster plump direkt an den Aktor gegeben ohne das erst noch Nebenbedingungen im TWS abgearbeitet werden und ggf passende Dimmstufen je Szenario beimischen. Das passt dann auch alles mit einer Visu usw. zusammen, weil so lange die alle via dem KNX Ihre Befehle abgeben, kann man die auch durch ein solches Tor bringen. Ansonsten ist die Visu wahrscheinlich auch einfach weg wenn die auf dem TWS läuft und später dann ggf auch per MQTT statt KNX mit dem TWS kommuniziert.

[markusrohr]

Hallo Göran,

das tönt sehr vernünftig und wäre auch für mich umsetzbar. Vielen Dank. Ich habe nur auf die Schnelle keinen KNX Logikbaustein gefunden, der eine vernünftige Anzahl von Gattern bietet. Hast Du hier einen Tipp?

Beste Grüsse
Markus

[gbglace]

Naja am günstigsten ist noch das MDT. im KNX-UF DIY Bereich stellt Waldemar oder mit Nickname mumpf noch ein Projekt vor, das hat dann 80 Logikkanäle. Er hat sich da auch eine komplett eigene ETS-Applikation programmiert und spielt die da auf eine Platine rauf die ein anderer User da entwickelt hat (Konnekting). Die Platine kann neben dieser KNX-Applikation wohl auch noch ein paar andere optionale Module aufnehmen. unteranderem auch 1-wire. Ist aber eben DIY.

Waldemar hat damit in seinem Haus auch eine zentrale Visu/Logik-Instanz aber für alles eine BackupVariante in quasi nativem KNX. Wobei er auch viele einfache Abhängigkeiten direkt in sein Modul einbaut. Da er das wohl als Taster nutzt hat er davon nun einfach min eines je Raum und somit auch verteilt genügend Logiken um das alles umzusetzen. Mit dem MDT Modul wird das schnell eine teure Sicherheitslösung. Da hast wohl eher nen zweiten TWS am Start der über eine intelligente Schaltung erst bei Ausfall des anderen hochfährt.

[EarlBacid]

Also wenn ich als backup für meine tws logiken schon extra was kaufen wollen würde, warum dann nicht gleich nen kleinen tws350? Dann bin ich mir wenigstens sicher, dass egal was ich mir als logik ausdenke, ich im backup fall noch immer die selbe Funktionalität habe.

Vg
Earl

[Dragonos2000]

@markusrohr
Das MDT Logikmodul hat nicht direkt was mit dem Notlauf zu tun. Mit dem initialisiere ich nur die ganzen Logiken nach einen Restart (Stromausfall o.ä.). Das war aber nur eine Behelfslösung, inzwischen geht das auch mit dem TWS und Roberts Baustein.

Die Umschaltung auf Notlauf funktioniert mit einem retriggerbaren Treppenlichtautomat. Das zyklische Keepalive vom TWS geht auf den Eingang des Treppenlichtautomats, wodurch der Timer wieder zurückgesetzt wird. Bleibt der Keepalive aus, dann lauft der Timer vom Treppenlichtautomat ab und er schaltet um. Mit dem Statusobjekt entsperre/sperre ich bspw. die Beschattungsfunktionen der Wetterstation und einige andere KNX-Teilnehmer und Torbausteine, damit die Steuerung nun ohne TWS über die internen Funktionen der Aktoren/Sensoren erfolgt.

Die von Dir beschriebenen Zustandsobjekte habe ich ebenfalls und diese werden im Automatikbetrieb von der Wetterstation (Tag/Nacht), Präsenzmeldern (anwesend/abwesend), TWS (Sommer/Winter), usw "bedient". Zusätzlich hab ich Taster oder Visu-Widgets drin, um ohne die Automatik auch selbst schalten zu können. Macht natürlich nur Sinn, wenn die Automatik gesperrt oder "tot" ist. Zumindest bei mir werden die Zustandsobjekte zyklisch gesendet und dann würde die Automatik den manuellen Eingriff geradewegs wieder überschreiben.
Ausnahme: Das Tag/Nacht Objekt. Da sendet die Wetterstation zwar auch zyklisch, aber ich habe mir eine Logik gebaut, womit ich manuell umschalten kann, ohne dass mir die Wetterstation das wieder zyklisch überbügelt. Sobald von der Wetterstation dann der selbe Zustand wie der von mit vorgegebene kommt, läuft es wieder automatisch. Ich kann also vorzeitig auf Tag oder Nacht schalten, ohne die Automatik zu deaktivieren.