X10 SEC senden

Begonnen von herrmannj, 15 April 2013, 10:39:57

Vorheriges Thema - Nächstes Thema

herrmannj

Hallo zusammen,

ich suche eine Möglichkeit wie ich FHEM einen X10 sec Sensor "emulieren" lassen kann.

Ziel: "weiche Migration" von X10 auf HM: ich habe derzeit eine Marmitek SC9000 mit diversen SD, DS, MS und KS im Einsatz. Mittelfristig möchte ich das FHEM mit HM SD und HM-Sec-SC die Funktion übernimmt, allerdings soll der Übergang mit Rücksicht auf WAF fließend erfolgen.

Dazu möchte ich die X10 Sensoren Stück für Stück gegen HM austauschen, die am FHEM anlernen und in FHEM quasi ein X10-Dummy device anlegen *das dazu senden können muss* und dieses Dummy dann an der SC9000 anlernen. Für meine GöGa würde sich deshalb erst einmal nichts ändern (FB scharf / unscharf, Fehlalarm an der SC löschen, Doorbell) und parallel-Betrieb FHEM auf Tablet.

Wenn die Akzeptanz für das FHEM-Tablet komplett hergestellt ist nehm ich die SC9000 einfach raus.

Nur, wie schaffe ich es mit FHEM einen X10 sec Sender zu erstellen / emulieren ? Die X10 msg könnte ich komplett erstellen, im Zweifel würde mir also auch eine Form von raw send helfen.

Danke und Grüße
Jörg



Willi

Zitat von: herrmannj schrieb am Mo, 15 April 2013 10:39Nur, wie schaffe ich es mit FHEM einen X10 sec Sender zu erstellen / emulieren ? Die X10 msg könnte ich komplett erstellen, im Zweifel würde mir also auch eine Form von raw send helfen.

Die Datagramme beim RFXtrx433 haben nichts mit dem normalen X10-Message-Format zu tun. RFXCOM hat ein eigenes Format definiert, um protokollunabhängig zu sein. Du könntest natürlich die bestehenden Datagramme loggen oder bei RFXCOM anfragen, dass Du die SDK erhälst und dies dann in 46_TRX_SECURITY programmieren.

Ansonsten kannst Du mir (als Autor von den TRX-Modulen) sagen, was Du genau haben willst.
Ich kann dann die entsprechenden set-Befehle realisieren.

Z.B. bei DS10A:
  set Tuer1 open
  set Tuer1 closed

Ich vermute mal, dass Du nicht alles senden willst, was DU empfängst. Vermutlich willst Du beispielsweise kein "battery:low" senden....

Am besten loggst Du über 46_TRX_SECURITY.pm, was Deine Sensoren so senden und was Du haben willst. Dann kann ich Dir dazu kompatible set-Befehle realisieren.

Ändere dazu die Zeile 388 von
Log 1, "TRX_SECURITY: $name devn=$device_name first=$firstdevice subtype=$subtype command=$command, delay=$delay, batt=$battery cmd=$hexdata" if ($TRX_SECURITY_debug == 1);
in
Log 1, "TRX_SECURITY: $name devn=$device_name first=$firstdevice subtype=$subtype command=$command, delay=$delay, batt=$battery cmd=$hexdata";

Du findest dann die Loggings Deiner X10-Security-Sensoren in fhem-2013-04.log
Pro Gerät brauche ich dann die entsprechenden Logzeilen der zu implementierenden Befehle.
Mittels des Hexstrings kann ich dann auch prüfen, ob ich das set richtig realisiert habe.

Diese Woche komme ich allerdings wegen Dienstreise nicht dazu dies zu realisieren.

-- Willi





FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

herrmannj

Hallo Willi,

folgende Einträge erscheinen im log


2013.04.20 20:51:42 1: TRX_SECURITY: sec_MotionFlur devn=TRX_MS10A_2057 first=1 subtype=1 command=alert, delay=, batt=batt_ok cmd=04
2013.04.20 21:03:46 1: TRX_SECURITY: sec_MotionFlur devn=TRX_MS10A_2057 first=1 subtype=1 command=normal, delay=, batt=batt_ok cmd=05


2013.04.20 20:52:14 1: TRX_SECURITY: TRX_DS10A_2273 devn=TRX_DS10A_2273 first=1 subtype=0 command=alert, delay=min_delay, batt=batt_ok cmd=02
2013.04.20 20:52:49 1: TRX_SECURITY: TRX_DS10A_2273 devn=TRX_DS10A_2273 first=1 subtype=0 command=normal, delay=min_delay, batt=batt_ok cmd=00


Der SD90 sieht nach aussen wie ein DS10 aus.

Kannst Du mit diesen Daten arbeiten oder benötigst Du zusätzliche Infos ?

Grüße
Jörg

Willi

Hallo Jörg,

im neuen 46_TRX_SECURITY.pm (jetzt im SVN, morgen per update) gibt es jetzt set für DS10A und MS10A:

fhem> set TRX_DS10A_72cf Open
fhem> set TRX_DS10A_72cf Closed


sowie

fhem> set TRX_MS10A_55c9  normal
fhem> set TRX_MS10A_55c9 alert


Um konsistent zu sein, gibt es beim DS10A "Open" und "Closed" und beim MS10A "normal" und "alert". Also so wie es jetzt beim Empfangen gesetzt wird. Damit wird auch gleich STATE/state, devicelog, battery richtig gesetzt.

-- Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

herrmannj

Hey, cool! Dankeschön

Ich werde leider erst am kommenden WE testen können. Wäre es Dir noch möglich auch einen KR18 set einzubauen ?

vielen Dank und viele Grüße
Jörg

Willi

Zitat von: herrmannj schrieb am So, 21 April 2013 20:26Hey, cool! Dankeschön

Ich werde leider erst am kommenden WE testen können. Wäre es Dir noch möglich auch einen KR18 set einzubauen ?

vielen Dank und viele Grüße
Jörg
Hallo Jörg,

sagt mir Bescheid, ob DS10A und MS10A so läuft und ok ist. Bei mir hat es insofern funktioniert, dass der alte RFXCOM-Receiver (siehe meine alten RFXCOM-Module) die sets des RFXtrx433 richtig empfangen hat.
Der RFXtrx433 empfängt natürlich seine eigenen gesendeten Signale nicht.

KR18 ist dann schnell eingebaut.

MfG Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

herrmannj

Hallo Willi,

ein kurzer Test mit dem DS10 war eben drin:

WORKS LIKE A CHARME.

Dann werde ich mal beginnen die DS10 durch HM-SEC-SC zu ersetzen.

Super Sache, und vielen Dank für Dein Engagemant!

Grüße
Jörg