knx-Plugin

[arnix]

Hallo,

kann ich im knx-Plugin das Attribut "readonly" auch zur Laufzeit ändern, bspw. per Logik?

Mir ist letztens der Raspi abgeschmiert, weil der Speicher vollgelaufen ist. Damit so etwas nicht bei längerer Abwesenheit passiert, würde ich gerne einen zweiten Raspi mit "readonly : true" parallel laufen lassen und im Bedarfsfall dann automatisch wechseln.

Falls das nicht geht, hat jemand eine andere Idee?

Viele Grüße

[Msinn]

Nein, die Parameter werden qua Definition beim Start eines Plugins ausgewertet. Für so etwas müsste ein Plugin eine extra Methode zur Verfügung stellen.

Aber wieso ist bei Dir im Zusammenhang mit dem KNX Plugin der Speicher vollgelaufen? Von so einem Verhalten habe ich noch nicht gehört.

[arnix]

Das war, weil die Backups aufs NAS nicht funktioniert haben und dann unter /root auf der SD-Karte abgelegt wurden. Habe ich natürlich korrigiert, aber wer weiß, was als nächstes passiert.

[mumpf]

Hi,

ich würde (bzw. habe) das KNX-System so parametrisieren, dass es auch ohne Logik-Engine läuft... Bei vernünftigem Aufbau kann man auf die Komfortfunktionen von shNG auch ne Zeit lang verzichten.

Ansonsten noch eine Idee zu Deinem Punkt: Dein "readonly" shNG hört immer auf irgendeinen "Heartbeat" des produktiven shNG. Sobald der ausbleibt, re-startet er sich selbst per shell-schript, wobei dieses Script vorher noch ein Configfile umkopiert, dass eben kein "readonly" enthält.

Gruß, Waldemar

[arnix]

Danke für die Antworten schon einmal.

@mumpf: Ja, ich weiß, KNX sollte nur das i-Tüpfelchen sein. Aber mit der Zeit hängt da halt immer mehr von ab. Bei mir laufen die Rollladen bspw. über das Autoblind und wenn im Urlaub nun der Raspi aussteigen würde, wären Tag und Nacht alle Rollladen oben (oder unten).
Die Sache mit dem Neustart des Standy-by-Raspi habe ich auch schon mal überdacht. Es hätte nur den Nachteil, dass viele Zustände wieder in der Grundkonfiguration wären. Bspw. wäre nach meiner aktuellen Konfiguration der Modus "Urlaub" dann gar nicht aktiv. Aber das wiederum könnte man natürlich über den Cache lösen, wobei das viel gründliche Fleißarbeit wäre, alle relevanten Zustände so zu sichern, was in anderen Situationen (geplanter Neustart des Systems) vielleicht auch gar nicht gewollt ist. Daher hatte ich die Hoffnung, man könnte einfach mit dem Attribut "readonly" zwischen zwei Raspis live hin- und herswitchen.

Grüße

Arne

[mumpf]

Hi Arne,

Du musst nochmal über deinen Item-Aufbau nachdenken...

Dein produktiv System muss ja so aufgebaut sein, dass es jederzeit neu gestartet werden kann. Wenn das mal nachts oder bei Abwesenheit passiert, dann willst du ja auch nicht, dass die Rollläden Unsinn machen.
Also musst du sowieso alles so aufbauen, dass es sich den Letzten Stand aus dem Cache, der DB oder von knx holt.
Da das Backup System immer mit hört und natürlich genau den gleichen Stand wie das produktiv System hat, wird es nach einem Neustart genau so reagieren (müssen).
Somit hast du schon ein Problem beim Produktiv System, und das würde ich dann erstmal lösen, bevor ich an ein Backup denke...

Gruß Waldemar

[Sandman60]

Wie Waldemar schon schreibt geht das auch ohne Read-Only, habe das bei mir am laufen. Im Prinzip simple und ohne Neustart und ohne read-only zu machen:
1. Auf jedem System gibt es ein Item was beschreibt wer Prod und wer Backup ist.
2. KNX-Schreibende Logiken haben in der ersten Zeile eine Prüfroutine welche die Logik abbricht wenn das System ungleich Prod ist.
3. Die Systeme pingen sich regelmäßig gegenseitig und im Falle eines Problems mit dem Prodsystem macht das Backup sich selbst zum Master oder aber ich schalte das manuell um (Button in der Visu).
4. Bei Änderungen in der Konfig (Logik, Items) habe ich ein Transportskript was die Änderungen von D nach Q nach P transportiert (Q ist gleichzeitig mein Backupsystem).
Läuft so inzwischen seit mehreren Jahren

[arnix]

Hi Arne,

Du musst nochmal über deinen Item-Aufbau nachdenken...

Dein produktiv System muss ja so aufgebaut sein, dass es jederzeit neu gestartet werden kann. Wenn das mal nachts oder bei Abwesenheit passiert, dann willst du ja auch nicht, dass die Rollläden Unsinn machen.
Also musst du sowieso alles so aufbauen, dass es sich den Letzten Stand aus dem Cache, der DB oder von knx holt.
Da das Backup System immer mit hört und natürlich genau den gleichen Stand wie das produktiv System hat, wird es nach einem Neustart genau so reagieren (müssen).
Somit hast du schon ein Problem beim Produktiv System, und das würde ich dann erstmal lösen, bevor ich an ein Backup denke...

Gruß Waldemar

Ja, im Prinzip könnte ich das so machen. Aber ich finde es eigentlich auch ganz okay, wenn einige Zustände nach dem Neustart in einer Grundkonfiguration sind, also bspw. die manuellen Sperren der Rollladen nicht übernommen werden oder die Erfassung der Anwesenheit wieder auf null ist. Ist aber natürlich Geschmackssache.

[arnix]

Wie Waldemar schon schreibt geht das auch ohne Read-Only, habe das bei mir am laufen. Im Prinzip simple und ohne Neustart und ohne read-only zu machen:
1. Auf jedem System gibt es ein Item was beschreibt wer Prod und wer Backup ist.
2. KNX-Schreibende Logiken haben in der ersten Zeile eine Prüfroutine welche die Logik abbricht wenn das System ungleich Prod ist.
3. Die Systeme pingen sich regelmäßig gegenseitig und im Falle eines Problems mit dem Prodsystem macht das Backup sich selbst zum Master oder aber ich schalte das manuell um (Button in der Visu).
4. Bei Änderungen in der Konfig (Logik, Items) habe ich ein Transportskript was die Änderungen von D nach Q nach P transportiert (Q ist gleichzeitig mein Backupsystem).
Läuft so inzwischen seit mehreren Jahren

Das klingt gut, aber wie hältst Du die Plugins, z.B. das Autoblind, davon ab, das alles doppelt auf den Bus geschrieben wird?

[bmx]

Wenn Du den Sandman60 höflich fragst, schreibt der vielleicht einen kleinen Beitrag für die SmartHomeNG Webseite....

[Sandman60]

arnix : Sorry, kenne bzw. nutze das Plugin nicht, bei mir schreiben eigentlich nur Logiken auf (KNX-)Items (die dann knx auslösen).
bmx : Wink mit dem Zaunpfahl ist angekommen , hatte ja versprochen wieder miteinzusteigen. Muß mich eh mal wieder mit René verabreden, dann besprechen wir mal wo ich was sinnvolles beisteuern kann.

[arnix]

Guten Abend,

ich habe zu dem Thema nochmal eine Frage: Wenn ich einen Raspi mit SmathomeNG einen Heartbeat ausführen lasse, wie kann der Standby-Raspi den dann eigentlich auslesen? Ich habe es jetzt so versucht, dass der Haup-Rapsi alle zwei Minuten die Uhrzeit auf ein Item schreibt. Ich habe dem Item eine Gruppenadresse zugeordnet. Auf dem Standby-Raspi habe ich auch ein Item mit derselben Gruppenadresse angelegt. Aber so scheint der Austausch nicht zu funktionieren, denn die Uhrzeit ist in dem Item auf dem Standby-Raspi nicht angekommen. Muss ich da ein physisches KNX-Gerät einbinden, damit das funktioniert?

So sehen die Items aus

SmarthomeNG:
    Primaergeraet:
        Herzschlag:
            #wird als Zeit gespeichert
            type: foo
            knx_dpt: 10
            visu_acl: r
            knx_send: 4/0/0
            knx_listen: 4/0/0
            knx_reply: 4/0/0
            knx_cache: 4/0/0

Grüße

[mumpf]

Hi,

versuch es doch erstmal mit nem boolean... das klappt auf jeden Fall.

Gruß, Waldemar

[arnix]

Okay, das werde ich versuchen. Ich stehe nur gerade auf dem Schlauch, wie ich mit boolean einen regelmäßigen Heartbeat machen kann. Also ich gehe davon aus, dass der Haupt-Raspi einfriert (ist zuletzt passiert) und damit der Zustand des Items nicht mehr geändert wird. Wenn der jetzt auf True ist und der Raspi einfriert, bekommt es der Standby doch gar nicht mit.

[bmx]

Du kannst auf Deinem Slave-Rechner ein Item A (Ausfall) mit einem Cycle anlegen was in regelmäßigen Abständen getriggert wird.
Bei Triggerung, prüfst Du mit eval nach, ob das letzte Update Deines Masteritems M schon älter ist als x sekunden (also sowas wie sh.shtime.now()-M.prev_update)
Wenn ja, erhält das Item ein True => Alarm, ansonsten bleibts bei False (alles ok).
Sonderfall könnte noch sein, das das Item von Init erst initialisiert worden ist, das müßte man extra betrachten.