Zustände von HM-SCI-3-FM Kanälen nach CCU Restart richtig

Problemlösungen und Hinweise von allgemeinem Interesse zur Haussteuerung mit HomeMatic

Moderator: Co-Administratoren

Nightman
Beiträge: 30
Registriert: 24.01.2013, 07:29
Wohnort: Ratingen

Zustände von HM-SCI-3-FM Kanälen nach CCU Restart richtig

Beitrag von Nightman » 22.02.2013, 10:03

Zustände von HM-SCI-3-FM Kanälen auch nach CCU Restart richtig auswerten können

Der HM-SCI-3-FM arbeitet ja mit einer Batterie und muss somit energiesparend betrieben werden. Daher wird der Sender und Empfänger jedes einzelnen Kanals im HM-SCI-3-FM nur bei einer Statusänderung der Kontakte oder ca. alle 24 Std. aktiv. Dies führt dazu, dass eine CCU leider nicht aktiv den Status der Eingänge (Schließer) abfragen kann, sondern auf eine Meldung jedes einzelnen Kanals des HM-SCI-3-FM warten muss.

Wird nun eine CCU neu gestartet (Reboot) so merkt sich die CCU leider nicht den letzten Status des HM-SCI-3-FM, sondern geht bis zur nächsten Meldung des HM-SCI-3-FM einfach davon aus, dass alle Eingänge geschlossen sind. War ein Eingang des HM-SCI-3-FM vor dem Neustart der CCU offen so geht die CCU von einem falschen Zustand aus, bis sich entweder der Zustand am HM-SCI-3-FM ändert oder die 24 stündige Regelmeldung an der CCU eintrifft.

Wie kann man nun mit diesem Verhalten umgehen?

Hier kann man sich zu Nutze machen, dass in den neuen Firmware-Versionen der CCU bei einem Neustart der Zustand von Systemvariablen erhalten bleibt.

Man weist also einfach mittels eines Programms bei jeder Statusänderung der Kanäle des HM-SCI-3-FM einer entsprechenden Systemvariablen den Status zu und arbeitet bei der Auswertung des Status nur mit den Systemvariablen.

Leider ist es doch etwas komplizierter, denn bei Neustart der CCU werden die entsprechenden Programme auch ausgelöst, da die CCU die Eingangsdaten des HM-SCI-3-FM mit "geschlossen" belegt und somit das Ereignis auslöst. Damit würde man dann in einfachen Programmen prompt den "geretteten" Zustand direkt wieder überschreiben und hätte nichts gewonnen.

Glücklicherweise gibt es auch dafür eine Lösung. Man macht die Zuweisung an die Systemvariable in einem Script und wertet dort die Variable $src$ aus. $src$ ist bei Auslösung eines Ereignisses mit einem Verweis auf das Auslösende Gerät / Kanal belegt. Wird ein Ereignis durch einen CCU Start ausgelöst, so ist $src$ aber nicht definiert. Dies kann man in einen kleinen Skript prüfen und die Zuweisung des Status an die Systemvariable nur durchführen, wenn das Ereignis von einem Gerät kommt.

Da bei absolut erstmaliger Benutzung der Systemvariablen vor der erstmaligen Meldung des HM-SCI-3-FM ein quasi undefinierter Zustand herrscht, auf den. man ggf. speziell reagieren möchte, habe ich meine Systemvariablen als Werteliste erstellt (in meinem Beispiel die Systemvariable 'AA-aktiv' mit den Werten 'undefiniert;aktiv;inaktiv' - siehe Bild 1).
Definition_der_Systemvariable.png
Bild 1: Definition der Systemvariable.

Nun erstellt man sich für jeden Kanal des HM-SCI-3-FM ein Programm, welches bei Aktualisierungsmeldung vom Schließer den Zustand in die entsprechende Systemvariable übernimmt. In meinem Beispiel heißt das Programm 'AA Aktivierung' und verarbeitet die Aktualisierungsmeldungen der Kanals 'Alarm aktiviert' des HM-SCI-3-FM (siehe Bild 2). Je nach Meldung 'offen' oder 'geschlossen' wird das jeweilige Skript zum Setzen der Systemvariablen ausgeführt.
Programm.png
Bild 2: Programm zu Übernehmen des Status des Kanals in die Systemvariable.

Bei den Skripts wird zunächst die Variable $src$ benutzt, um der lokalen Variablen 'source' den Verweis auf das Ereignis auslösende Objekt zuzuweisen. Wir erinnern uns, dieser Verweis ist nicht gültig, sofern das Skript aus einem Programm aufgerufen wurde, dass die CCU im Rahmen eines Neustarts ausführt. Daher wir dann im Skript mit der folgenden 'if' Abfrage die Gültigkeit von 'source' überprüft und nur bei Gültigkeit die Zuweisung an die Systemvariable 'AA-aktiv' durchgeführt (siehe Bild 3 und Bild 4).

Bei Systemvariablen mit Wertelisten muss man in einem Skript anstatt des Wert-Textes einen Dezimalwert zuweisen, welcher der Position des Wert-Elements in der Werteliste entspricht. Meine Werteliste ist ja 'undefiniert;aktiv;inaktiv'. Hierbei hat der Wert 'undefiniert' den Dezimalwert '0', der Wert 'aktiv' entspricht '1' und der Wert 'inaktiv' wird mit '2' repräsentiert. Das Skript in Bild 3 setzt also die Systemvariable 'AA-aktiv' auf den Wert 'aktiv' (1). Das Skript in Bild 4 setzt die selbe Systemvariable auf den Wert 'inaktiv' (2).
Skript1.png
Skript1.png (10.75 KiB) 5426 mal betrachtet
Bild 3: Script setzt die Systemvariable 'AA-aktiv' auf den Wert 'aktiv' (1)
Skript2.png
Skript2.png (10.04 KiB) 5426 mal betrachtet
Bild 4: Script setzt die Systemvariable 'AA-aktiv' auf den Wert 'inaktiv' (2)

Ich hoffe, ich kann Euch damit helfen und freue mich auf Euer Feedback.

Ich habe diesen Post nun auch auf einem Blog veröffentlicht http://d0wn.biz/hausautomatisierung-zus ... auswerten/

Gruß
Nightman
Zuletzt geändert von Nightman am 26.02.2013, 22:54, insgesamt 1-mal geändert.

Benutzeravatar
JPS
Beiträge: 1007
Registriert: 07.08.2010, 22:51
Kontaktdaten:

Re: Zustände von HM-SCI-3-FM Kanälen nach CCU Restart richti

Beitrag von JPS » 23.02.2013, 23:28

Nightman hat geschrieben:Hier kann man sich zu Nutze machen, dass in den neuen Firmware-Versionen der CCU bei einem Neustart der Zustand von Systemvariablen erhalten bleibt.(...)Leider ist es doch etwas komplizierter, denn bei Neustart der CCU werden die entsprechenden Programme auch ausgelöst, da die CCU die Eingangsdaten des HM-SCI-3-FM mit "geschlossen" belegt und somit das Ereignis auslöst. Damit würde man dann in einfachen Programmen prompt den "geretteten" Zustand direkt wieder überschreiben und hätte nichts gewonnen.

Das mit dem Umweg über die Systemvariablen ist ein altbekannter Trick, dem von dir aufgezeigten Problem zu begegnen. Die von dir gewählte Art, beim Start der CCU zur verhindern, dass diverse Programme die Systemvariablen wieder überschreiben habe ich so noch nicht gesehen, scheint aber auch vergleichsweise aufwändig zu sein.

Ich mache es so, wie hier beschrieben...
http://homematic-forum.de/forum/viewtop ... t=8#p78798, funktioniert sehr zuverlässig.
SMART WOHNEN by sTeRn AV
Meine Lösungen, um das Leben zuhause "smarter" zu machen.


Verwendung meiner Hinweise und Skripte auf eigenes Risiko | Ich übernehme hierfür keinerlei Gewährleistung bzw. Haftung

paul53
Beiträge: 2459
Registriert: 26.04.2012, 20:42
Wohnort: Berlin

Re: Zustände von HM-SCI-3-FM Kanälen nach CCU Restart richti

Beitrag von paul53 » 24.02.2013, 00:07

Ja, das Speichern von Werten aus batteriebetriebenen Sensoren ist wegen der Reboot-Problematik generell zu empfehlen.
Nightman hat geschrieben:...Leider ist es doch etwas komplizierter, denn bei Neustart der CCU werden die entsprechenden Programme auch ausgelöst, da die CCU die Eingangsdaten des HM-SCI-3-FM mit "geschlossen" belegt und somit das Ereignis auslöst. Damit würde man dann in einfachen Programmen prompt den "geretteten" Zustand direkt wieder überschreiben und hätte nichts gewonnen.

Glücklicherweise gibt es auch dafür eine Lösung. Man macht die Zuweisung an die Systemvariable in einem Script und wertet dort die Variable $src$ aus. $src$ ist bei Auslösung eines Ereignisses mit einem Verweis auf das Auslösende Gerät / Kanal belegt. Wird ein Ereignis durch einen CCU Start ausgelöst, so ist $src$ aber nicht definiert. Dies kann man in einen kleinen Skript prüfen und die Zuweisung des Status an die Systemvariable nur durchführen, wenn das Ereignis von einem Gerät kommt.
Die Methode mit der Auswertung von dom.GetObject("$src$") hat den Nachteil, dass die bedingten Anweisungen if (source) {Anweisung(en);} auch bei manueller Programmauslösung nicht ausgeführt werden. Der Effekt ist so, als wäre das Programm als "nicht bedienbar" deklariert.
Versionen: HM-CC-TC 2.1, HM-LC-Sw1 1.9, HM-CC-RT-DN 1.1, HM-MOD-RPI-PCB 1.2.1 (keine CCU)

Daimler
Beiträge: 5616
Registriert: 17.11.2012, 10:47
Wohnort: Köln

Re: Zustände von HM-SCI-3-FM Kanälen nach CCU Restart richti

Beitrag von Daimler » 24.02.2013, 00:28

Oder ihr schreibt mal kräftig hier etwas zu diesem unleidigen Thema, vielleicht wird der Bug dann endlich behoben!
http://homematic-forum.de/forum/viewtop ... 30&t=10513
Gruß Günter

pivccx mit 2.35.16 in Produktiv, pivccx mit 3.41.11 Testsystem, Yahx 2.35.16 im 2. Testsystem, 3 * HPCx Studio 4.1,
4 * L-Gateway, 3 * RS-L-Gateway, FHZ200x, vereinzelt noch FS2x-Komponenten.
HM: Zur Zeit knapp 250 Komponenten mit ~ 650 Kanälen .

Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!

Benutzeravatar
Herbert_Testmann
Beiträge: 11102
Registriert: 17.01.2009, 11:30

Re: Zustände von HM-SCI-3-FM Kanälen nach CCU Restart richti

Beitrag von Herbert_Testmann » 24.02.2013, 23:08

Hallo

Es ist eine systembedingte Unzulänglichkeit des Funksystems zu Gunsten der Batterielaufzeit. Kein Bug.
Wenn der Status nach dem Reboot systemrelevant ist, dann hat der User den falschen Sensor ausgesucht :)
---
Dieses Schreiben wurde maschinell erstellt und ist ohne Unterschrift gültig

Daimler
Beiträge: 5616
Registriert: 17.11.2012, 10:47
Wohnort: Köln

Re: Zustände von HM-SCI-3-FM Kanälen nach CCU Restart richti

Beitrag von Daimler » 25.02.2013, 12:27

Herbert_Testmann hat geschrieben:Es ist eine systembedingte Unzulänglichkeit des Funksystems zu Gunsten der Batterielaufzeit. Kein Bug
Lies Dir bitte einmal meine Beiträge in dem Fred durch!
wenn Du dann immer noch der Meinung bist - OK, dann sind wir beide geteilter Meinung.
Herbert_Testmann hat geschrieben:Wenn der Status nach dem Reboot systemrelevant ist, dann hat der User den falschen Sensor ausgesucht :)
Fehlen halt nur machmal die Alternativen. :cry:
Gruß Günter

pivccx mit 2.35.16 in Produktiv, pivccx mit 3.41.11 Testsystem, Yahx 2.35.16 im 2. Testsystem, 3 * HPCx Studio 4.1,
4 * L-Gateway, 3 * RS-L-Gateway, FHZ200x, vereinzelt noch FS2x-Komponenten.
HM: Zur Zeit knapp 250 Komponenten mit ~ 650 Kanälen .

Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!

ayngush
Beiträge: 322
Registriert: 02.02.2012, 12:05

Re: Zustände von HM-SCI-3-FM Kanälen nach CCU Restart richti

Beitrag von ayngush » 25.02.2013, 13:19

Hallo,

dieses Verhalten stört mich auch. Eine Alternative zum Drehgriffsensor gibt es halt nicht.
Die Tatsache, dass man die Batteriebetriebenen Geräte mit State() nicht abfragen kann liegt einfach daran, dass die Batteriebetriebenen Geräte keinen Dauerempfang haben und nur dann das BIDCos-RF Interface aufbauen, wenn von ihnen aus eine Änderung durchgeführt wird (also der fest eingebaute Push-Interval oder eine Statusänderung am Sensor).
Das ist bei allen Batteriebetriebenen Sensoren so, egal ob das der Drehgriffsensor, die Funkzellen für die Dosenmontage oder das Wandthermostat, Bewegungsmelder, etc. ist. Das Wandthermostat meldet sich jedoch häufiger bei der CCU als es zum Beispiel der Drehgriffsensor oder der Fenstersensor tut.

Es bleibt NUR die hier beschriebene Möglichkeit des Speicherns des Zustands in Systemvariablen oder einfach nichts "Systemrelevantes" durch diese Sensoren auslösen. Dumm nur, dass ELV diese Sensoren zum Teil auch für Alarmsysteme verkauft... Eine Möglichkeit wäre es, wenn die CCU den letzten bekannten Status, wie bei den Variablen eben auch, bei einem Neustart für solche Geräte speichern würde, dann könnte man sich die selbst gebauten "Krücken" sparen... aber das spricht eigentlich wieder gegen das gesamte "Neustartkonzept" von Systemdiensten...

Wie auch immer, man kann fluchen wie man will, es ist kein "Bug" per Definition: "Bug", den man mit ein bisschen Software beheben könnte, sondern ein fest eingebautes Feature in den Geräten und lösen lassen die die dadurch resultierenden Unzulänglichkeiten nur durch Softwarekrücken, egal, wer die am Ende programmiert (der Schöpfer, die User oder die Isos ;) )

Grüße

AnZa
Beiträge: 191
Registriert: 03.01.2014, 09:07

Re: Zustände von HM-SCI-3-FM Kanälen nach CCU Restart richti

Beitrag von AnZa » 27.06.2014, 16:51

Man kann festhalten, dass die CCU bei einem organisierten Neustart nicht in der Lage ist, den aktuellen Zustand für 5 Minuten (während Neustart) zu behalten. Ob dies ein Bug ist, bleibt jedem frei, dies zu bewerten. :wink: Tatsache ist aber, dass jeder Betroffene seine Scripts zur Behebung deswegen selber zu schreiben hat.

Klar ist, dass bei batteriebetriebenen Sensoren Strom gespart werden muss. Komisch ist nur, dass dies bei batteriebestriebenen Sensoren (z.B. HM-LC-Sw4-Ba-PCB) deutlich weniger der Fall sein muss.

Bei mir bleiben alle Kontakte unabhängig aller Programmierung nach einem Neustart auf "geschlossen". Dies kann bei der Verdrahtung teilweise berücksichtigt und so behoben werden. Der Blitzwarner hat jedoch nur Schliesskontakte und so ist es wohl von Vorteil, den Blitzwarner in der Nähe und nicht auf dem Dach zu montieren, so dass der Benutzer nach einem Neustart "schnell mal" den Knopf drücken kann.
813 Kanäle in 160 Geräten und 4025 Datenpunkte, welche in 2 unabhängigen Gebäuden, welche per VPN verbunden sind und mit nur einer CCU3 arbeiten.

Benutzeravatar
Herbert_Testmann
Beiträge: 11102
Registriert: 17.01.2009, 11:30

Re: Zustände von HM-SCI-3-FM Kanälen nach CCU Restart richti

Beitrag von Herbert_Testmann » 28.06.2014, 19:02

Hallo

wenn der SCI nicht mit einer Knopfzelle, sondern mit einer externen Spannungsversorgung betrieben wird, dann hilft es ebenfalls, nach dem Neustart der CCU den SCI aus / einzuschalten. Dadurch wird der wirkliche Status der 3 Kontakte übertragen. Ich habe dazu eine Taste (Öffner) in die Spannungsversorgung des SCI gebaut.
---
Dieses Schreiben wurde maschinell erstellt und ist ohne Unterschrift gültig

Daimler
Beiträge: 5616
Registriert: 17.11.2012, 10:47
Wohnort: Köln

Re: Zustände von HM-SCI-3-FM Kanälen nach CCU Restart richti

Beitrag von Daimler » 28.06.2014, 19:46

Hi Herbert,

dass:
Herbert_Testmann hat geschrieben:dann hilft es ebenfalls, nach dem Neustart ......den SCI aus / einzuschalten. Dadurch wird der wirkliche Status der 3 Kontakte übertragen.
ist mal ein Tip - danke :o
Weißt Du zufällig, ob die DGKs und TKs ihren Zustand auch bei Wiedereinschalten der Stromversorgung übermitteln?
Gruß Günter

pivccx mit 2.35.16 in Produktiv, pivccx mit 3.41.11 Testsystem, Yahx 2.35.16 im 2. Testsystem, 3 * HPCx Studio 4.1,
4 * L-Gateway, 3 * RS-L-Gateway, FHZ200x, vereinzelt noch FS2x-Komponenten.
HM: Zur Zeit knapp 250 Komponenten mit ~ 650 Kanälen .

Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!

Antworten

Zurück zu „HomeMatic Tipps & Tricks - keine Fragen!“