FHEM2FHEM nicht bidirektional

Begonnen von hazelnut, 15 Januar 2017, 21:02:18

Vorheriges Thema - Nächstes Thema

hazelnut

Hallo in die Runde,

ich versuche gerade die Reichweite meines TCM auf den Keller auszudehnen und greife hierbei auf die FHEM2FHEM - Lösung zurück.

Grundsätzlich funktioniert das auch erst einmal, sprich ich bekomme die Log's etc. allerdings lässt sich der Schalter von der Serverinstanz nicht schalten. Die Kommunikation scheint also nur in eine Richtung zu funktionieren.
Ich poste mal die Config - vielleicht fällt ja einem von euch etwas auf...

Server:


define RemoteTCM TCM ESP3 none
attr RemoteTCM dummy 1
attr RemoteTCM learningMode always
attr RemoteTCM sendInterval 0

define KellerTCM FHEM2FHEM 192.168.221.21:7072 RAW:RemoteTCM PassWort
# define KellerTCM FHEM2FHEM 192.168.221.21:7072:SSL RAW:RemoteTCM PassWort

define EnO_01 EnOcean 01907XXX
attr EnO_01 IODev RemoteTCM
attr EnO_01 comMode biDir
attr EnO_01 defaultChannel 0
attr EnO_01 devChannel 255
attr EnO_01 eep D2-01-09
attr EnO_01 manufID 033
attr EnO_01 room EnOcean
attr EnO_01 subDef FFB85801
attr EnO_01 subType actuator.01
attr EnO_01 teachMethod UTE
attr EnO_01 webCmd on:off



Und ja, SSL ist auskommentiert. Läuft auch aus irgendwelchen Gründen nicht. Ein

openssl s_client -connect fhemhost:fhemport

funktionert zwar, beim FHEM2FHEM geht's leider nicht. However, auf der Client-Seite sieht das ganze dann so aus:


define RemoteTCM TCM ESP3 /dev/ttyUSB0@57600
attr RemoteTCM sendInterval 0
attr RemoteTCM smartAckMailboxMax 0
attr RemoteTCM verbose 5

define EnO_01907DEC EnOcean 01907XXX
attr EnO_01 IODev RemoteTCM
attr EnO_01 comMode biDir
attr EnO_01 defaultChannel 0
attr EnO_01 devChannel 255
attr EnO_01 eep D2-01-09
attr EnO_01 manufID 033
attr EnO_01 room EnOcean
attr EnO_01 subDef FFB85801
attr EnO_01 subType actuator.01
attr EnO_01 teachMethod UTE
attr EnO_01 webCmd on:off:dim


Wie gesagt, da ich hier den Wald anscheinend vor Bäumen nicht sehe, würde ich mich über ein Feedback sehr freuen.

Grüße

Hazelnut

MadMax-FHEM

Zitat von: hazelnut am 15 Januar 2017, 21:02:18
Grundsätzlich funktioniert das auch erst einmal, sprich ich bekomme die Log's etc. allerdings lässt sich der Schalter von der Serverinstanz nicht schalten. Die Kommunikation scheint also nur in eine Richtung zu funktionieren.

Ja, ist so.
Also nur eine Richtung.

Wenn das das Problem ist, dann ist es keins...

Wenn du Befehle schicken willst, dann RFHEM!?

https://wiki.fhem.de/wiki/RFHEM

Halt aufpassen, dass man keine "Loop" baut...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

hazelnut

Hallo Joachim,


vielen Dank für deine Antwort. Dann kann ich ja letztlich wirklich auch überlegen, den LOG-Modus zu verwenden (die Versuche mit ser2net, was bidirektional wäre, sind ja leider am Anlernen gescheitert) Auf der anderen Seite ... Es läuft und ich hab die notwendige Funktionalität :-)

Dann vielen Dank und bis zum nächsten mal :-)

Hazelnut

AndreasHH

Moin,
ZitatGrundsätzlich funktioniert das auch erst einmal, sprich ich bekomme die Log's etc. allerdings lässt sich der Schalter von der Serverinstanz nicht schalten. Die Kommunikation scheint also nur in eine Richtung zu funktionieren.

Wenn man auf beiden FHEM-Systemen FHEM2FHEM definiert dann funktioniert es auch bidirektional.

Läuft bei mir seit über einem Jahr.


Gruß

Andreas
FHEM 5.8, FB7490, FB7390, Linux-Server, Raspi 1, Raspi 2, FHEM2FHEM, div. FS20, div. FHT, div. HMS, div. Homematic, MQTT, ESP8266, Arduino

hazelnut

Hallo Andreas,

vielen Dank für deine Antwort. Das ist ein sehr interessanter Gedanke. Beim Client müsste ich dann ja einmal den physisch vorhandenen TCM definieren und dann noch den DummyTCM. Beide mästen das gleiche Device schalten (können).

Hmm...

Und auf der Serverseite wäre das quasi analog: hier müsste ich dann doch zwei Devices anlegen: eins, das die Logdateien und Statusmeldungen bekommt und eins, dass ich anspreche um zu schalten, richtig?

Hmm, ich denk mal drüber nach, wobei da für meinen Fall (das Auslesen einer einzelnen PSC234 via TCM) die ser2net - Lösung die einfachste wäre ... und bidirektional ... wenn das pairing geklappt hätte... (ich hatte hier dazu geschrieben...).

Wie auch immer - vielen Dank dir :-)

Hazel


MadMax-FHEM

Warum nicht für das Schalten RFHEM??

RFHEM ist (soweit ich verstanden) zum Ausführen von remote-Befehlen (RFHEM).

Und FHEM2FHEM zum "abfragen/übermitteln" von Werten...

Bidirektionales wurde hier im Forum schon mal wo diskutiert...
...und soweit ich mich erinnere war die Kombination aus FHEM2FHEM und RFHEM die/eine Lösung...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Helmi55

Hallo AndreasHH
kannst du uns ein Beispiel zeigen? Ich möchte auch so umsetzten zwischen Haus RPi und Garagen RPi
Gruß
Helmut
System1 fhem 6.1 auf RPi 4B mit 4GB, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 6.1 auf RPi 4B mit 4GB (Bullseye) mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/

Grinsekatze

Nimm F2F im LOG-Modus und kombiniere es mit RFHEM. Wenn Du den STATE des zu überwachenden/Schaltenden Remote-Systems brauchst denke daran, diesen in ein eigenes Reading zu stecken, da F2F STATE nicht übergeben kann.

Ich habe so bei mir vor einem halben Jahr meine TV-Steuerung umgesetzt.