Am KNX-Bus feststellen on openHAB läuft

[tiknx]

Hallo zusammen.

Ich bin gerade dabei, meine Sicherheits-Einstellungen vom KNX-Bus auf einen openHAB Server auszulagern

D.h. momentan schließen meine Dachflächenfenster mittels Sperrglied wenn es regnet. Und sperrt natürlich dann auch. So wie es sein soll.

Was ich nun aber ändern will ist Folgendes.
Läuft mein openHAB Server warum auch immer nicht (und kann ja schon mal vorkommen), soll es weiterhin so sein, dass alle Fenster mittels Sperrglied geschlossen werden. Sicher ist sicher!

Läuft mein openHAB Server allerdings, will ich die Möglichkeit haben die Fenster ein Stück, und wenns auch nur die Lüftungsklappe ist zu öffnen. Das ist auch soweit kein Problem. Eine entsprechende Rule wird das schon ermöglichen.

Um was es mir nun genau geht, ich will am BUS zu jeder Zeit und sicher wissen ob der Server läuft. D.h der BUS muss fragen. Habe vorher gedacht es reicht wenn der Server meldet, dass er lebt. Dem ist aber nicht der Fall.
Gedankenspiel:
Er meldet, dass er lebt, sprich eine Gruppenadresse wird true gesetzt und mehr oder weniger im selben Moment stürtz er ab. Also steht am BUS, dass er lebt. Die BUS seitige Sicherheit wird danach aufgehoben, Fenster sind offen, Regen setzt ein, Fenster bleiben offen, weil BUS denkt openHAB kümmert sich darum, openHAB macht aber nichts, weil abgestürtzt, Wasser in der Wohnung

Ich hoffe euch ist verständlich was mein Anliegen ist.
Wenn ich den sicheren Zustand vom Server am BUS weiß, verknüpfe ich den Status vom Regenwächter und den Status vom Server mit einem NOR Gatter, und ich habe mein gewünschtes Ergebnis

RW (0/0/1) | openHABServer_läuft || RW_manipuliert (0/0/2)
-----------+---------------------++-----------------------
     1     |          0          ||           1          
     1     |          1          ||           0

Die Aktoren bekommen dann als Sperropjekt nicht mehr 0/0/1 sondern 0/0/2

mfg
tiknx

[udo1toni]

Das Problem dabei ist, dass openHAB gegenüber dem Bus nicht als Gerät auftritt, es reagiert also nicht auf Read Requests anderer Busteilnehmer.

Was ich mir vorstellen könnte, wäre eine Art Watchdog, also ein Timer, der regelmäßig über ein Command retriggert werden muss (und damit wieder von vorne losläuft, ohne umzuschalten). Wenn der Timer abläuft, muss er die entsprechenden Funktionen umsteuern. In openHAB musst Du dann eine Rule anlegen, die regelmäßig das entsprechende Kommando auf den Bus schickt, um den Timer neu zu starten. Den Timer könnte man über einen ungenutzten Binärausgang realisieren, der Rest müsste über Dein Logikmodul laufen.

[tiknx]

Hi, danke für deine Antwort.

Soweit hab ich dich glaube ich verstanden.
Ich starte auf dem BUS einen Timer. Dieser setzt einen Binärwert auf 1, solange dieser nicht abläuft. Sobald der Timer abgelaufen ist, wird der Wert auf 0 gesetzt.
Mittels openHAB resette ich den Timer.
Damit habe ich also den Status "openHABServer_läuft" auf einem Binärglied. Noch nor verknüpft mit dem "RW" fertig ist mein "RW_manipuliert"
Alles klar soweit.

Soweit die Theorie. Die genau das erfüllt, was ich haben will. Wie ich das aber in der Praxis realisiere ist mir noch nicht wirklich klar. Wie genau erstelle ich einen Timer im KNX Project?

mfg
tiknx

[udo1toni]

Du brauchst dazu Hardware. Wenn Du z.B. einen Binärausgang übrig hast, könntest Du den dazu missbrauchen, indem Du einen "Treppenhaustimer" programmierst (das ist in vielen Binärausgängen eine Standardfunktion). Dann verbindest Du openHAB mit dem Trigger für den Timer und den Status des Ausgangs mit deiner Logik.

[tiknx]

Alles klar, danke dir für die Hilfe

[mitch77]

Andere Idee: warum lässt du den BUS nicht auf jeden Fall=immer das Fenster schließen und OH öffnet dann wieder, was du geöffnet haben möchtest.
IN OH also einfach einen Timer setzen, der solange dauert, wie das Fenster geschlossen wird und dann entsprechende Aktionen fährt.
Ich gebe zu, das ist vielleicht eines deutschen Ingenieurs nicht würdig, aber das Ergebnis wäre das gleiche, oder?
Grüße
Mitch

[tiknx]

Das es eines deutschen Ingenieurs nicht würdig ist, ist weiters nicht schlimm. Bin Österreicher!

Ich denke das mal durch. Eine recht saubere Lösung scheint mir das nicht zu sein, aber vielleicht reicht es ja

mfg
tiknx

[tiknx]

Da Fällt mir ein. Nein geht nicht, denn sobald das Sperrobjekt gesetzt ist, ist es gesetzt. Dann kann keiner mehr was machen. Ich brauche am BUS einen binären Wert, der bei Regen 1 ist, wenn openHAB nicht läuft und 0 ist wenn es läuft. Das ist mit deiner Version nicht möglich denke ich.

Aber wie gesagt, ich denke es am Abend nochmal durch. Bin gerade auf Arbeit

[tiknx]

So habe jetzt einen Schaltaktor. Meinen letzten freien, den ich eigentlich noch brauche dazu missbraucht.

Auf diesen läuft ein Treppenlicht Timer, den ich über OH immer wieder starte. Damit habe ich meinen Status von OH.

Grundsätzlich behaupte ich mal habe ich meine zwei Eingänge für das Logikmodul. Leider kommt da am Ausgang irgendwas undefiniertes raus.

Muss nochmal genauer schauen

[bwurst]

Da Fällt mir ein. Nein geht nicht, denn sobald das Sperrobjekt gesetzt ist, ist es gesetzt. Dann kann keiner mehr was machen. Ich brauche am BUS einen binären Wert, der bei Regen 1 ist, wenn openHAB nicht läuft und 0 ist wenn es läuft. Das ist mit deiner Version nicht möglich denke ich.

Wieso kann da keiner mehr was machen, wenn ein Sperrobjekt aktiv ist? Man kann es doch dann einfach wieder ausschalten?

OpenHAB kann ja auf das Regen-Objekt reagieren und dann gibt es halt eine zweite GA, die auch an das Sperrobjekt sendet und dort sendet OH immer gleich eine 0 hinterher sobald der Regensnsor eine 1 gesendet hat. Damit wird das Fenster gleich wieder entsperrt so lange OpenHAB läuft und ist gesperrt wenn OH nicht läuft.

Es kommt jetzt auf deine Hardware an, ob ständiges an und aus der Sperre ein Problem ist oder nicht. (Angenommen dein Regensensor sendet zyklisch.)

[tiknx]

Zum einen sendet der Regensensor zyklisch. Zum anderen sind meine Aktoren so eingestellt, dass sie bei Regen automatisch die Fenster schließen. Wüsste auch nicht, wie es anders Sinn macht.
Meldet jetzt der Regensensor, dass es regnet, schließen sich die Fenster und sind gesperrt.

Sendet nun openHab auf die GA des Sensor 0, wird es nicht lange dauern, bis der Sensor wieder speert

[bwurst]

Naja, also OpenHAB kann bei entsprechender Konfiguration die 0 ja sehr schnell senden (millisekunden-bereich) und da zuckelt am fenster noch nix. Kann natürlich trotzdem der Hardware ggf. schaden, wenn da ein Motor kurz Strom bekommt. Also im Zweifel messen ob da schon was passiert oder ob OH schnell genug antwortet damit eben noch nichts passiert.

OH muss ja nicht an die GA des Sensors senden sondern an eine eigene, falls du das (wahre) Regen-Objekt sonst noch wo brauchst.

[tiknx]

Das kommt ja auch noch dazu, dass ich das wahre Regenobjekt auch noch brauche.
Dafür hätte ich aber eine Lösung, in dem ich es mir mit dem Logik modul kopiere.

Eigentlich habe ich meine Lösung schon. Nur leider kommt aus dem Logik Modul nicht das raus was ich erwarten würde

[bwurst]

Jetzt wird natürlich kaum einer wissen was du in welchem Logikmodul eingestellt hast und daher kann eigentlich keiner so recht helfen den Fehler zu finden.
(Wer überwacht dann eigentlich das Logikmodul auf Ausfall?

[tiknx]

Bezüglich Ausfall Logikmodul. Kann natürlich passieren. Es kann aber auch der Regensensor ausfallen. Es kann aber auch die gesamte BUS-Spannung abfallen. Oder gar ein Stromausfall sein. Soll heißen man kann nicht alles absichern.
Natürlich je komplexer etwas wird, desto fehleranfälliger wird es.

Schaltung des Logikmoduls ist, bzw sollte es sein. Mein im Eingangspost genanntes NOR Gatter war natürich ein Blödsinn!
RW_manipuliert (0/0/2) == RW (0/0/1) && !openHABServer_läuft

RW (0/0/1) | openHABServer_läuft || RW_manipuliert (0/0/2)
-----------+---------------------++-----------------------
     0     |          0          ||           0          
     0     |          1          ||           0          
     1     |          0          ||           1          
     1     |          1          ||           0

RW_manipuliert ist aber nicht das gedachte. Momentan konnte ich das Ergebnis noch nicht so wirklich reproduzieren. Vielleicht ist aber doch die oben genannte logische Verknüpfung falsch.