FHEM2FHEM RAW: Fehler "IODev device didnt answer is command correctly: No answer"

[nicor2k]

Ich würde gern von einem Haupt-FHEM auf einen zweiten Raspberry Pi im Arbeitszimmer zugreifen - per FHEM2FHEM. Per LOG zum Auslesen von Werten klappt das prima, ich möchte jetzt aber per RAW auch den CUL darin steuern. Der CUL, am Arbeitszimmer-Pials CUL_0 definiert funktioniert, lässt sich dort mit FHEM auch schalten. Telnet ist aktiv, denn FHEM per LOG geht ja.

Ich habe das RAW so definiert wie hier:
http://forum.fhem.de/index.php?topic=25554.0

Code Auswählen Erweitern


# Arbeitszimmer CUL_0 als RAW ----------------------
define CUL_0 CUL none 0000
attr CUL_0 dummy 1
define RemoteCULAB FHEM2FHEM 192.168.1.100:7072 RAW:CUL_0



Es passiert aber nichts und ich bekomme folgende Fehlermeldungen im Log-File:

Code Auswählen Erweitern


2015.10.20 22:58:33 2: IT set LICHT2 on
2015.10.20 22:58:33 2: IT IODev device didn't answer is command correctly:   raw => No answer


Licht 2 hat als IODev den Remote-angeschlossenen CUL:
attr LICHT2 IODev CUL_0


Hat jemand eine Idee, was ich falsch habe?


Ist es möglich (habe das LOG jetzt zum Testen auskommentiert) ein FHEM doppelt mit FHEM2FHEM zu haben?
Also der Hauptrechner soll sich von dem kleinen Pi einmal die Daten abgreifen per LOG (für eine Bluetooth-Personenerkennung), soll aber per RAW auch noch den CUL in dem Arbeitszimmer-Pi steuern können.

Vielen Dank!

[Wzut]

Licht 2 hat als IODev den Remote-angeschlossenen CUL:
attr LICHT2 IODev CUL_0
Hat jemand eine Idee, was ich falsch habe?

ich würde als Ziel auch wirklich den Remote CUL nehmen und nicht den Dummy

Code Auswählen Erweitern

attr LICHT2 IODev RemoteCULAB

[nicor2k]

Klingt logisch, stimmt!

Klappt leider nicht - habe Licht1 auf den RemoteCULAB gesetzt, LICHT2 auf den CUL_0 - keins schaltet. Wenn ich über FHEM auf dem anderen Rechner, an dem der Remote-CUL ja direkt als CUL_0 angeschlossen ist, schalte, geht es...

Code Auswählen Erweitern


attr LICHT IODev RemoteCULAB
...
attr LICHT2 IODev CUL_0


[nicor2k]

Noch jemand eine Idee, oder habe ich das falsch eingebaut?
Danke!

[rudolfkoenig]

Nicht alle Module sind FHEM2FHEM faehiig, weil der Modulautor "unerlaubte" Abkuerzungen verwendet.
Das ist der Fall IT, und mWn auch bei HomeMatic.

[nicor2k]

Nicht alle Module sind FHEM2FHEM faehiig, weil der Modulautor "unerlaubte" Abkuerzungen verwendet.
Das ist der Fall IT, und mWn auch bei HomeMatic.

Das ist jetzt aber blöd, weil ich mit dem CUL IT-Geräte schalten wollte...
Gibt es denn eine andere Möglichkeit? Ich hatte zunächst überlegt, das andersherum zu machen und auf dem "Haupt-FHEM" einen Dummy zu schalten, der dann per FHEM2FHEM:Log ausgelesen und dann verarbeitet wird - hatte aber gedacht, dass das eher zu Verzögerungen führen würde?

[rudolfkoenig]

Gibt es denn eine andere Möglichkeit?

Ich sehe drei:
- das IT-Modul fixen, d.h. Patch bauen, und dem Modulautor vorschlagen. Oder ihm solange auf dem Geist gehen, bis er das selbst macht
- statt sich mit zwei FHEMs und FHEM2FHEM rumzuaergern nimmt man ser2net (oder socat/etc) auf dem "slave" RPi. Ist vermutlich die Loesung mit der geringsten Verzoegerung, die aber auch bei den anderen Loesungen unter 0.1s liegen duerfte. Das IT-Protokoll selbst duerfte fuer den Loewenanteil der Verzoegerung zustaendig sein.
- ein umgekehrtes FHEM2FHEM der Sorte LOG auf dem "slave" RPi einrichten, was auf einem dummy der "master" horcht, und bei einem Event ueber ein notify das lokale CUL steuert.

[1of16]

- statt sich mit zwei FHEMs und FHEM2FHEM rumzuaergern nimmt man ser2net (oder socat/etc) auf dem "slave" RPi. Ist vermutlich die Loesung mit der geringsten Verzoegerung, die aber auch bei den anderen Loesungen unter 0.1s liegen duerfte. Das IT-Protokoll selbst duerfte fuer den Loewenanteil der Verzoegerung zustaendig sein.

ich habe mich mit dem gleichen Problem herumschlagen, und die Umsetzung mit ser2net (siehe z.B. http://www.fhemwiki.de/wiki/CUL_ueber_Netz) brachte für mich eine zufriedenstellende Lösung.
Verbraucht auf dem Raspberry nicht unnötig viel Ressourcen und ist meinem Gefühl nach nicht viel langsamer als das Schalten über die Fernbedienung.
Danke dir rudi, für den Gedankenanstoß in die richtige Richtung