Bausätze

Hallo ELV,

mit diesem Modul bietet eQ-3 auf den 1. Blick ein tolles Sendemodul an.

1. Unter anderem wird mit der Realsierung eines galvanischen Einganges (DU30/DUI30) die Möglichkeit geboten, selbst zu bestimmen, wenn die anstehenden Statusinformationen an die Zentrale übertragen werden sollen.

Damit lassen sich die vorhandenen Nachteile:..
*..fehlende zyklische Statusmeldung
*..fehlende alive-Meldung
*..falsche Statusübernahme bei Zentralen-Neustart
kompensieren.

2. Leider steht dieser Trigger-Eingang nur galvanisch, als physikalischer Eingang auf dem Modul zur Verfügung. Will man diesen nutzen, muss im Bedarfsfall dieser elektrisch vor Ort aktiviert/angesteuert werden --> eigene Elektronik/Taktgeber o.ä.

Damit entfällt leider ein wesentlicher Vorteil ...nämlich, daß man per Programm den Abruf der Daten von der Zentrale aus aktivieren kann. Würde man dies können.. wäre dies ein Weg hin..zum Pollingverfahren..und damit eine Erhöhung von Verfügbarkeit und Sicherheit.

Nur mit zusätzlichen Aufwand läßt sich diese Funktion nachbilden ..z.B. mit dem Empfangsmodul HM-LC-Sw1-Ba-PCB. Damit kann per Programm von der Zentrale aus..die Datenübertragung aufgerufen/abgerufen werden.

Warum eQ-3 den Empfangsmodus nicht bereits mit integriert hat, wird vielleicht nur der Entwickler wissen.

Hinweis an die Doku-Abteilung: Die lfd. Numerierung der Modus-Vorwahl ändern in (0...6, statt 1..7).

Gruß

Hallo elotek,

mal wieder ein guter Beitrag mit sinnvollem Lösungsvorschlag.

Was mich nun grundsätzlich wundert ist, dass zumindest im 'alten' 8-Kanal-Sender HM-MOD-EM-8 ein aktiver Empflänger zwingend notwendig sein muss.
In meinem Erfahrungsbericht zum 'alten' Sender hatte ich festgestellt, dass eine Programmverknüpfung in der CCU2 zwingend auch an das Modul gesendet werden muss.

Also mal wieder eine Frage an ELV/eQ-3:
Warum wird der Empfänger nicht 'freigegeben' um tatsächlich die Funktion á la elotek realisieren zu können?
Und was liefern die beiden Script-Funktionen Value() und State() dann wirklich???

Gruß Sternthaler

Hallo sternthaler,

trotz BidCoS-Funkprotokollsystem ist das HomeMatic-System im wesentlichen eine Einbahnstraße ...vom Sender/Sensor(..bei Änderung auslösen) --> Zentrale .

Auch die Skript-"Abfrage" greift nur auf das interne Abbild in der CCU2 zurück, nicht auf den aktuellen /physischen Status --> siehe Systemprotokoll, Anzeige- und Kontrollfeld.

Läßt sich einfach testen. TFK oder HM-MOD-EM-8 oder HM-SCI-3 bei Status = offen einfach die Zentrale kurz von der Betriebsspannung trennen und neu starten. Die entsprechenden Kanäle werden danach als geschlossen angezeigt, obwohl ja die Schalterstellung (noch) offen ist.

Dieses Problem ist ja bekannt..gerade im Bereich der Sicherheitstechnik nicht ganz unkritisch!! Möglich Abhilfe und die Vermeidung von Fehlinterpretation gibt es hier nur indirekt. Eine Korrektur der Anzeige erfolgt erst nach einem erneuten öffnen/schließen oder nach erfolgter zyklischen Statusmeldung (opt. TFK spästestens nach 1 Std, beim HM-MOD-EM-8 überhaupt nicht).

In diesem "fehlerhaften" Zustand jetzt einfach einmal ein Skript-Statusabfrage(STATE, Value) durchführen..dann sieht man false statt true, obwohl der physische Status ja noch offen ist.

Gruß