[gelöst] FHEM2FHEM: Vorhaben möglich?

[ChristianKnorr]

Hallo zusammen,
Stein des Anstoßes ist der miserable Funkempfang des CUL's im Keller zu den Steckdosen im Erdgeschoss.

Hardware:

• Ubuntu 14.04 Server mit aktuellem fhem (via svn) im Keller und bleibt die Hauptinstanz
• Fritzbox 7240 ist mit Freetz, ebenfalls aktuellem fhem, USB-Speicherstick (für fhem) und CUL im Erdgeschoss

Jetzt versuche ich seit Tagen am Haupt-fhem die Steckdose, die via CUL am Slave-fhem 'angeschlossen' ist zu schalten: erfolglos. Überaschend stelle ich jetz fest, dass die Klingelsignalerkennung funktioniert hat (genauer gesagt, der Server hat es erkannt und getriggert)

Was mache ich falsch? Oder geht das was ich vorhabe überhaupt nicht?

Config Server (Haupt-fhem):

Code Auswählen Erweitern

define FHEM2FHEM FHEM2FHEM fritz7240 RAW:CUL_Freetz7240 <secret>

define CUL_Freetz7240 CUL none 0000
attr CUL_Freetz7240 dummy 1

define Steckdose IT 1FFF1FF0FF FF 00
attr Steckdose IODev CUL_Freetz7240

Config Fritz!Box (Zweit-fhem mit CUL):

Code Auswählen Erweitern

define telnetPort telnet 7072 global
attr telnetPort globalpassword <secret>

define CUL_Freetz7240 CUL /dev/ttyACM0@38400 1034

Danke schonmal im Voraus
Christian...

[rudolfkoenig]

Manche FHEM Module (IT, CUL_HM) sind nicht FHEM2FHEM:RAW faehig, da sie statt IOWrite()/Dispatch() zu verwenden direkt auf das drunterliegende Device (CUL, etc) zugreifen.

Workaround in diesem Fall waere ein dummy device auf dem Haupt-Fhem, ein FHEM2FHEM:LOG (mit dummy Filter) auf dem Slave zum Haupt-FHEM, und ein notify von dummy nach IT auf dem Slave.

[ChristianKnorr]

Manche FHEM Module (IT, CUL_HM) sind nicht FHEM2FHEM:RAW faehig, da sie statt IOWrite()/Dispatch() zu verwenden direkt auf das drunterliegende Device (CUL, etc) zugreifen.

Also müsste FS20 doch prinzipiell gehen, oder? Die Klingelsignal-Erkennung ist FS20 und funktioniert; das Licht steuer ich mit FS20, das geht nicht. Will heißen: das Log im Server zeigt keine Fehler wenn ich Licht schalten will (via WEB), als hätte er das Licht geschaltet; das Log in der FritzBox zeigt gar nix.

Workaround in diesem Fall waere ein dummy device auf dem Haupt-Fhem, ein FHEM2FHEM:LOG (mit dummy Filter) auf dem Slave zum Haupt-FHEM, und ein notify von dummy nach IT auf dem Slave.

Ach herrje, das hört sich nicht einfach an

[rudolfkoenig]

FS20 geht.

[ChristianKnorr]

Aber an was fehlt es denn, weil ich das Licht nicht schalten kann? Laut Log schon, aber es schaltet nix.

Code Auswählen Erweitern

define Klingel_1 FS20 f0a0 00
attr Klingel_1 IODev CUL_Freetz7240

define ELV_8CH__1 FS20 13424243 1111 lm 1144 fg 4411 gm 4444
attr ELV_8CH__1 IODev CUL_Freetz7240
attr ELV_8CH__1 alias Esstisch

[rudolfkoenig]

Wie ist  CUL_Freetz7240auf dem Haupt-Fhem definiert?

[ChristianKnorr]

Eeh, sorry, vergessen zu schreiben:

Code Auswählen Erweitern

define CUL_Freetz7240 CUL none 0000
attr CUL_Freetz7240 dummy 1

[rudolfkoenig]

Das zu schaltende Geraet muss auf dem Master FHEM2FHEM als IODev haben.
Wenn das auch nicht war, dann bitte beide configs wenigstens in Auszuegen hier anhaengen.

[ChristianKnorr]

Ja, das war's Danke.

Bis dato wusste ich nur nicht, dass ich die Steckdosen nicht schalten kann. Mit denen hatte ich das nämlich probiert

[ChristianKnorr]

Es ist zum Mäuse melken

Ich habe alle IO-Devices angepasst; Config gespeichert; getestet - alles OK!
Egal ob ich jedes Device einzeln umschreibe via WEB, oder ob ich die .cfg in einem Rutsch editiere.
Es funktioniert!

Aber wehe ich starte fhem neu. Dann kommt:

Code Auswählen Erweitern

Error messages while initializing FHEM:
configfile: ELV_8CH__3: unknown IODev specified
ELV_8CH__1: unknown IODev specified
ELV_8CH__2: unknown IODev specified
ELV_8CH__4: unknown IODev specified
[...]und alle IO-Devices stehen wieder falsch auf CUL_Freetz7240 !?

Habe sogar fhem gestoppt und die Datei auf dem Server via Console bearbeitet.
Irgendwas schreibt die Devs immer wieder um.

Was mache ich falsch?

[ChristianKnorr]

grmpf

Die Reihenfolge muss stimmen in der .cfg! (Anfängerfehler)

So geht's:

Code Auswählen Erweitern

define CUL_Freetz7240 CUL none 0000
attr CUL_Freetz7240 dummy 1

define FHEM2FHEM FHEM2FHEM fritz7240 RAW:CUL_Freetz7240 huzgtfz675

define Licht 13424243 1113 lm 1144 fg 4411 gm 4444
attr Licht IODev FHEM2FHEM

[ChristianKnorr]

Workaround in diesem Fall waere ein dummy device auf dem Haupt-Fhem, ein FHEM2FHEM:LOG (mit dummy Filter) auf dem Slave zum Haupt-FHEM, und ein notify von dummy nach IT auf dem Slave.

Okay, das habe ich mir angeguckt und auch zum Laufen bekommen. Ich frage mich, ob ich das noch weiter absichern/filtern kann.

Server:

Code Auswählen Erweitern

define wz_Pfirsichbaum dummyDer wird vom Script "on" oder "off" geschaltet.

FritzBox:

Code Auswählen Erweitern

define Server_fhem_Log FHEM2FHEM <ip>:7072 LOG:.* <password>
define wz_Pfirsichbaum IT 1FFFF1F0FF FF 00
define Pfirsichbaum notify wz_Pfirsichbaum set wz_Pfirsichbaum %Womit Pfirsichbaum dann auf ALLES hört. Muss das sein oder geht das schöner?

[rudolfkoenig]

Man koennte sowohl das .* nach dem LOG:, wie auch das notify-regexp einschraenken.
Und SSL aktivieren.