HomeMatic-Forum / FHZ-Forum

Danke für die vielen Rückmeldungen.
Hab die CCU jetzt in einem Serverschrank verbaut, welcher an einer USV hängt.

Ich verwendete im Gewerbeobjekt zweckentfremdete magnetische Tür/Fensterkontakte zur Verschlußüberwachung (Riegel) von Klotüren. Der Status wird im Systray der PCs und teilweise in den Räumen mit Klappanzeigen Männlein/Weiblein angezeigt, damit die Leute nicht umsonst loslaufen. Das nur zur Erläuterung.
Nach Neuboot, zB nach Software-Update, werden die Türen also max. 24h (bis sich der Kontakt mal gemeldet hat), als 'geschlossen' angezeigt.
Nach Neuboot rumlaufen und die Türschlösser mal betätigen ist die aktuelle Lösung.
Aber kann man nicht per Script nach Neuboot einfach den Status der fraglichen Kontakte in der CCU auf OFFEN setzen?
Gerne eine Idee wie das zu bewerkstalligen wäre. Danke!

Moooooment.... Wenn ein Mitarbeiter den Weg zum Klo auf sich nimmt und dieses benutzt, wird das im Tray der Rechner angezeigt?
Also können alle sogar verfolgen wie lange der Kollege da "gesessen" hat?

Das ist schon ein bisschen naja... spoooky

...ich wußte, daß ich als Erstes keine Antwort auf meine Frage, sondern zu den Details der Klotürüberwachung bekomme...
Es wird angezeigt, ob die Toiletten besetzt sind, mit 1-2Min. Abstand zwischen den Abfrage-Intervallen. WER da hingegangen ist läßt sich in einer Firma mit 50 Nasen kaum verfolgen, und wie lange er drin war auch kaum... es könnte ja, eben wegen der Verzögerung, zwischendurch auch mal 'grün' gewesen sein.
Wenn die Kollegen mit Arbeitsplatz in der Nähe der Toiletten verfolgen würden, wer da rein- und rausgeht, und darüber Aufzeichnungen anfertigen würden, fände ich das wesentlich 'spookier'.
Dem Firmeninhaber spart das Feature wahrscheinlich täglich eine Mannstunde Arbeitszeit, denn wer weiß was die Kollegen bei BESETZT machen? Warten, das kann aber dauern? Solange mit anderen Kollegen quatschen und die von der Arbeit abhalten? Zurück an den Arbeitsplatz laufen, in 5 Min wieder kommen und feststellen, es ist wieder/noch besetzt?
Aber bitte, ich hatte eine technische Frage gestellt....

Hallo!

sambasamba hat geschrieben: ↑

23.01.2020, 19:50

Nach Neuboot, zB nach Software-Update, werden die Türen also max. 24h (bis sich der Kontakt mal gemeldet hat), als 'geschlossen' angezeigt.
[...]
Aber kann man nicht per Script nach Neuboot einfach den Status der fraglichen Kontakte in der CCU auf OFFEN setzen?

Meines Erachtens ist das der falsche Weg - egal ob Fenster, oder WC-Tür!

Während des Neustarts, der ja auch ein paar Minuten dauert, kann jemand das Fester oder die Tür auch betätigen. Somit kann weder der alte Wert vor dem Neustart, noch ein "geschlossen" per Default richtig sein.

Ich mache das über eine Systemvariable als Werteliste, die neben "offen" und "geschlossen" auch noch ein "unbekannt" beinhaltet!

Beim Systemstart ein Programm
WENN {leer}
DANN Status = unbekannt

und ein
WENN Fenster geöffnet (Auslösen auf Aktualisierung)
DANN Status = geöffnet
SONST Status = geschlossen

In deinem Fall könnte man im Systemtray leicht ein zusätzliches Symbol (z.B. Fragezeichen) einblenden, bei der Klappanzeige eben deinen gewünschter Zustand auch bei "unbekannt" setzen.

Mir ist auch nichts bekannt, wie man den Status des Gerätes "verbiegen" kann...


Roland

Hallo Roland,
eigentlich eine gute Idee.
Nur mache ich Firmware-updates mit Neustart immer abends, wenn niemand mehr im Betrieb ist.... also auch keiner auf der Schüssel sitzt.
Deshalb würde ich keinen Fehler machen, die Türen einfach auf 'offen' zu setzen.
Viell. hat ja noch jemand eine Idee, wie man den default-Wert 'geschlossen' in der CCU nach Neustart überschreiben kann. Wenn nicht, ist es auch nicht so tragisch.

sambasamba hat geschrieben: ↑

24.01.2020, 00:23

wie man den default-Wert 'geschlossen' in der CCU nach Neustart überschreiben kann

Ich könnte mir schon vorstellen, dass es irgendein glücklich machendes Kommando gibt, mit dem man der ReGa den Zustand vorgaukeln kann.
Letztendlich macht der RFD auch nix anderes, als ein Event an die ReGa zu schicken.

Ich bin ja da eher der Praktiker und würde mit der AskSin++ ein Dummy Device bauen, das sich als "die Fensterkontakte" ausgibt und "offen" sendet, nachdem es einen Befehl beim Starten der CCU bekommt. Evtl. mit einer kleinen Verzögerung, da beim Booten u.U. ja eh schon ne Menge Funkverkehr herrscht.

sambasamba hat geschrieben: ↑

24.01.2020, 00:23

Viell. hat ja noch jemand eine Idee, wie man den default-Wert 'geschlossen' in der CCU nach Neustart überschreiben kann. Wenn nicht, ist es auch nicht so tragisch.

Und warum arbeitest du nicht mit Systemvariablen? Die behalten ihren Zustand ja bekanntlich nach einem kontrollierten Neustart der CCU. Also einfach bei jeder Änderung des Sensors den Zustand in eine entsprechende Systemvariable schreiben und diese dann für die weitere Auswertung verwenden.

Ein Stromausfall bzw. eine Änderung während der Neustart-Phase ist dadurch natürlich weithin nicht abgedeckt. Aber, um das Risiko zu minimieren, wurde hier ja schon der Einsatz einer USV empfohlen.

Hallo Volkmar,

ich meine dass sowas hier schon mal im Forum gemacht wurde (Alchy, Black, BadenPower ?).
Frag am besten im CCU-Unterforum nach "per Skript Gerätestatus in CCU setzen" oder suche nach genau diesen Begriffen.

Viele Grüße und viel Glück,
Sammy

Hier das Beispiel von Badenpower, welche vollkommen OHNE Skript auskommt und ausschließlich mit UI-Mitteln umsetzbar ist:

Reboot mit System und Ablauflogik
viewtopic.php?f=31&t=39187&hilit=reboot+in+reih+und

Während des Reboots können entsprechende Werte der SysVars gesetzt werden, wie z.B. Fensterkontakte/Drehgriffsensoren u.v.m.
Dazu die SysVars (wie Roland schon beschrieben hat) als Werteliste anlegen.
Bsp. für SysVars:
TFK (Tür-/Fensterkontakt) -> unbekannt;geschlossen;geöffnet
TFG (Fenstergriffdrejsensor) -> unbekannt;geschlossen;gekippt;offen

Nun legt man für jeden TFK/TFG ein UI-Programm an, welches die Zustände der SysVar ändert (oder macht es per Skript).
Die SysVar als Trigger/Prüfung in Programmen zu den Sensoren nutzt man dabei die Zustände OHNE den Zustand "unbekannt (State 0)".

Diese SysVars packt man in eine gewünschte Reboot-Sequenz (hier als Bsp. CCU-Reboot-02-Init-Geierlicht).



die SysVars der Tür-/Fensterkontekt(e) und setzt sie der Reihe nach auf "unbekannt".
Je nach Bedarf auch andere SysVars für den Täglichen Betrieb.

Da der Zustand/Wert "unbekannt" kein Auslöser/Trigger oder Prüfungspunkt ist, reagieren die Programme darauf nicht.

Ebenfalls kann man über den Wert der "SYS-RebootSequenz-Id" festlegen, wann Programme überhaupt erst reagieren dürfen.
Da die Reboot-Sequenz in o.g. Beitrag bei "10" (oder je nach Anwendungsfall höher) endet, nimmt man eben für alle Programme (welche erst nach abgeschlossener Reboot-Sequenz laufen sollen) im
"Wenn"
den Systemzustand "SYS-RebootSequenz-Id" -> den Wert: -kleiner 10- (Beispiel)

Die Nutzung der Reboot-Sequenz dient nicht nur einer vordefinierten Abarbeitung von Programmen, sondern auch einer Möglichkeit "mal eben" ALLE Programme zu deaktivieren, die nach obigem Beispiel aufgebaut sind indem man einfach die SysVar " true" auf false stellt (z.B. mit virtueller Taste).


Der Programmaufbau (siehe auch genau in den Fred von Badenpower) ist so gestaltet, das man die Auslöser/Trigger im EXEC-Bereich hat.
Somit kann man über die weitern "Sonst, wenn" die weiteren Bedingungen gestalten.

Auszug aus dem Beitrag Seite 1:

Alle andern Programme (ausser die, welche nur manuell gestartet werden und daher deaktiviert sind) sind in 3 Teilbereiche gegliedert.

Der WENN-Abschnitt (Header-Bereich) jedes Programme enthält als Bedingungen einige Systemvariablen in einer bestimmten Konstellation, welche dafür sorgt, dass im Normalbetrieb dieser Abschnitt nie ausgeführt wird. Und beim Neustart eben nur notwendige Programme in einer bestimmten Reihenfolge Tätigkeiten ausführen.

Der 1. SONST-WENN-Abschnitt (Exec-Bereich) enthält alle Programmauslöser und am Anfang des Bereichs immer 2 mal die Systemvariable "SYS True". Alle Auslöser sind hierbei UND-verknüpft. Das Prüfen der Systemvariable "SYS True" auf die Werte true und false und die UND-Verknüpfungen sorgen dafür, dass der dazugehörige DANN-Abschnitt auch nie ausgeführt werden kann.

Ab dem 2. SONST-WENN-Abschnitt folgt der eigentliche Arbeitsbereich. Hier werden die Bedingungen nur noch geprüft.

Selbstverständlich können auch die "normalen" Programme in die Abarbeitungsreihenfolge beim Start eingebunden werden:

Da bei einem Reboot ALLE aktiven Programme getriggert werden ist bis zur Beendigung der Reboot-Sequenz eine Abarbeitung der Programme ausgeschlossen, bis die Reboot-Sequenz-Id "10" erreicht ist.
Somit werden bei veralteten SysVar-Werten auch keine Programme ausgeführt, wenn der veraltete SysVar-Wert ein Programm triggern würde.

Man muss auch nicht in jeden "Sonst, wenn" Zweig die SysVar für den Reboot einsetzen, 1x im "Wenn" eingesetzt reicht.


Hier ein sehr nützlicher Hinweis zur Programmgestaltung:
viewtopic.php?f=31&t=39187&hilit=reboot ... nd#p386519

In der Problemstellung mit den TFK's ändert sich der Zustand der SysVars nach dem Reboot erst bei manueller Auslösung (auf entsprechenden SysVar-Wert), oder nach Übermittlung der zyklischen Statusmeldung (sofern der Sender das macht).

Bei Programmen, welche z.B. Rollladen steuern und die Fenster-/Türstellung berücksichtigen ist das ebenfalls nützlich.
Hat man einen unbemerkten Reboot/Ausfall und das Fenster/Tür wurde während der Downtime geöffnet stimmen SysVar-Werte (geöffnet/geschlossen) halt nicht mehr... und schwuppps ausgesperrt, Beule o.ä.


..