RFHEM - Modul für Befehle an andere FHEM-Instanzen

[SebastianStorb]

@chr2k
Es steht im Wiki (https://wiki.fhem.de/wiki/RFHEM) aber anders:

Code Auswählen Erweitern

Definieren des Device
Nun müssen wir uns ein Device anlegen. Dies machen wir klassisch in der Kommandozeile mittels

define Name RFHEM hostip [:port] [pw]

Für mich sieht pw wie Passwort des Telnet Port aus.

jedoch soll ssh nicht möglich sein:

Code Auswählen Erweitern

SSL Auth
SSL Auth ist leider auch nicht möglich.

Ich habe aber auch zur Zeit das Problem, dass es nur ohne Passwort funktioniert...

[Frank_Huber]

Ich habe für rfhem ne eigene Telnet Instanz ohne Passwort, dafür aber nur eine interne IP erlaubt. Das ist mir da sicher genug.

[SebastianStorb]

chris1284 hatte auf Seite 12 in diesem Treat die Funktion getestet und als funktionierend bestätigt. Ich könnte mir vorstellen, dass das Kennwort auf seinem Port noch nicht richtig gesetzt war, denn das war bei mir auch einmal so - und funktionierte nur scheinbar. -> s. Check

Gemäß der Ausführung im Wiki fuktioniert RFEHM mit Port Kennwort leider NICHT. Ich habe mit verschiedensten Geräten 3 RPi und ein debian server erfolglos den ganzen Tag probiert: Absicherung des Port mit einfachsten Kennwort

Code Auswählen Erweitern

SiLiCon Meine diversen Tests mit globalpasswort, passwort usw. im allowed Modul funktionieren, bringen aber keine Änderung für RFHEM. Die telnet Verbindung wird zwar aufgebaut, jedoch führt das Modul die Befehle auf der Empfängerseite nicht aus. Es funktioniert aber immer über die Konsole nach Eingabe des Port Kennwort (s. unten Check). Ein Fehler wird auch mit Verbose 5 weder beim Sender noch auf der Empfänger Seite angezeigt:
Beim Sender:

Code Auswählen Erweitern

Host present, executing command...
Command executed.
Beim Empfänger:

Code Auswählen Erweitern

Connection accepted from telnetPortClient_10.10.10.10_34708

Absicherung mit
-allowfrom  ("Nur Zugriff auf einen eigenen Port über eine bestimmte IP Adresse")
und
-Port [PW]

Wichtig scheint jedoch zu sein, dass für jede Verbindung (z.B. zu jedem weiteren RPi) oder auch (Gegen-)Richtung ein (zusätzlicher) eigener Port verwendet werden muss.

Client / Empfänger Seite / FHEM Seite auf der die Befehle ausgeführt werden sollen:

Code Auswählen Erweitern


Internals:
   DEF        7774 global
   FD         204
   FUUID      xxx
   FVERSION   98_telnet.pm:0.237270/2021-02-12
   NAME       telnetPortClient
   NR         734
   PORT       7774
   STATE      Initialized
   TYPE       telnet
   READINGS:
     2021-04-05 11:25:13   state           Initialized
Attributes:
   allowfrom  10.10.10.10
   group      RFHEM
   room       System

RFHEM Seite / Seite von der die Befehle gesendet werden:

Code Auswählen Erweitern

Internals:
   DEF        10.10.10.20:7774 SiLiCon
   FUUID      zzz
   FVERSION   93_RFHEM.pm:0.150580/2017-09-12
   HOSTNAME   10.10.10.20
   Interval   900
   NAME       RFHEM_Server
   NR         17
   NTFY_ORDER 50-RFHEM_Server
   PASSWORD   SiLiCon
   PORT       7774
   STATE      present
   TYPE       RFHEM
   READINGS:
     2021-04-05 11:21:17   ipadress        10.10.10.20
     2021-04-05 11:21:17   statedev        present
Attributes:
   group      RFHEM
   room       System
   stateFormat statedev

Check: Auf der Console z.B. über Putty auf dem Client RPi anmelden und dann über

Code Auswählen Erweitern

telnet 10.10.10.20 7774 testen, ob der Port das Passwort annimmt und nach der Anmeldung einfache Befehle wie

Code Auswählen Erweitern

set Lampe1 on ausgeführt werden.



Es wäre schön, wenn ein Entwickler hier die Absicherung über ein Kennwort ermöglichen könnte.

[mi.ke]

Ich kann leider nur bestätigen, dass es bei mir ebenfalls nur ohne Passort funktioniert, dann aber sehr gut.

Sehr, sehr schade, aber so leider nicht für mich geeignet.

Cheers
mi.ke

[juemuc]

Hallo mi.ke,

schau Dir mal fhem2fhem an. Da kannst Du eine verschlüsselte ssh-Verbindung nutzen.

Viele Grüße
Jürgen.

[mi.ke]

schau Dir mal fhem2fhem an. Da kannst Du eine verschlüsselte ssh-Verbindung nutzen.

Hi Jürgen,

ja Danke, ich weiss.
Alle meine Instanzen sind über FHEM2FHEM an den Master verbunden.
RFHEM hat (hätte) aber seinen eigenen (ergänzenden) Charme.
Gerade wenn Du mehr als 2-3 Systeme verbunden hast.
cheers
mi.ke



edit: Konjunktiv eingefügt

[Amenophis86]

Guten Morgen,

ich wollte gestern auch RFHEM auf einer neuen FHEM Instanz einrichten und habe mich ständig gewundert, warum es nicht geht. Bis ich irgendwann auf die Idee kam, dass RFHEM über Telnet versucht zu kommunizieren. Bei neuen Instanzen gibt es allerdings keine Telenetport, wenn man diese nicht selbst anlegt. Daher wäre es aus meiner Sicht sinnvoll einen entsprechenden Hinweis in der CommandRef hinzuzufügen, dass der empfangende Rechner eine Telnet Verbindung brauch

[Adimarantis]

Hallo,

Ich suche nach einer Lösung um ein Device bi-direktional über zwei FHEM Instanzen zu spiegeln.
Also soll auf Instanz 1 z.B. ein on/off Schalter (Relais) realisiert sein, welches diese Instanz auch selbst verwaltet (also z.B. über ein DOIF oder Webinterface ein/ausschaltet).
Auf Instanz 2 läuft jetzt z.B. TabletUI oder GoogleAssistant und der Schalter soll am Tablet korrekt angezeigt werden (an/aus) aber auch geschaltet werden können. Das kann jetzt ein Dummy sein, das aber auf Instanz 1 zurücksynchroniert werden muss.
(Warum verlagere ich nicht die Logik komplett nach Instanz 2? Weil das DOIF sehr viele Werte zur Entscheidungsfindung braucht und ich nicht alle nach Instanz 2 spiegeln möchte - ist außdem sauberer getrennt)

Mein Problem ist, da es mit FHEM2FHEM recht umständlich ist bzw. ohne das Risiko einer Loop gar nicht vollständig geht.
Ich habe jetzt RFHEM noch nicht probiert, aber zumindest vom Handling her scheint es einfacher zu sein (nicht so viele umständliche Notifies), aber ich vermute, dass bidirektional auch nicht gehen wird da es dann wieder zu eine Schleife kommt, oder?

Hat da jemand eine Idee/Lösung?

Ich hatte schon überlegt bei Gelegenheit selber ein Modul wie RFHEM zu bauen, allerdings so, dass die Befehle erstmal durch ein Modul in der Empfängerinstanz gehen (also statt "set dummydevice on" z.B. ein "set RFhem exec set dummydevice on"). Dieses checkt dann, ob ein update des Device überhaupt notwendig ist und durchbricht damit eine eventuelle Schleife. Zusätzlich könnte es gleich eine Autocreate Funktion (einfach Dummy anlegen) implemementieren.

Gruß,
Jörg

[Otto123]

Hallo Jörg,

es gäbe viele Möglichkeiten. FHEM2FHEM ist nicht kompliziert - aber ich würde es nicht bidirektional einsetzen.
2 Geräte (wert und wetter) komplett übertragen
raspib -> F2F -> raspib3

Code Auswählen Erweitern

defmod F2Fb FHEM2FHEM raspib:7072 LOG:wert.*|wetter
attr F2Fb addStateEvent 1
attr F2Fb room Status

defmod wert dummy
attr wert room Status

defmod wetter dummy
attr wetter room Outdoor

Mit rfehm Befehle im anderen FHEM auslösen:
raspib3 -> RFHEM -> raspib

Code Auswählen Erweitern

defmod Rraspib RFHEM 192.168.56.80
Kann irgendein Befehl sein den das FHEM auf raspib versteht.

Code Auswählen Erweitern

set Rraspib cmd set wert 25
Ist dann eigentlich völlig getrennt - aber eben auch "platt" nicht gespiegelt.

Moderner wäre es: Brücken mit mqtt bauen.

Gruß Otto

[Adimarantis]

Hallo Otto,

Ich probiere es jetzt mal mit Rfhem. Mit FHEM2FHEM hatte ich auch schon Probleme, dass beim forced restart einer Device (z.B. wenn mal eine Sicherung fliegt) die Verbindung brach lag bis hin zur Blockade. Ich hoffe mal da ist Rfhem robuster. Ausserdem gefällt mir der "push" Ansatz etwas besser (FHEM2FHEM pustet meines Wissens ja erstmal so ziemlich alle Events rüber und lässt die Remote Instanz wählen, während RFhem nur für gewählte Devices überhaupt etwas an die Remote Instanz schickt).

Mein Ansatz für birektional ist jetzt:

Device in RFhem eintragen, Remote Dummy erzeugen, Zweites Remote Dummy erzeugen (z.B. mit suffix _remote)
DOIF welches den Wert vom ursprünglichen Dummy auf das _remote überträgt (hier reicht ein DOIF für viele Werte). Da DOIF im Normalmodus nur einmal pro Zustandsänderung anspringt, wird automatisch eine Schleife verhindert (ein zweites "on" erzeugt kein Event mehr).

Dann das selbe in Retour, nur das _remote auf die Ursprungsinstanz übertragen wird und das dortige DOIF den Originalwert setzt.

Das klappt ganz gut, ist aber immer noch recht umständlich (braucht je ein zusätzliches Dummy und DOIF).
Wenn man die Befehle gleich durch die Remote RFhem Instanz "filtern" würde, wie in meinem vorigen Post beschrieben, könnte man sich das sparen.

Grundsätzlich geht was ich oben beschrieben habe auch mit FHEM2FHEM, aber da braucht man dann je ein Notify mit einer entsprechenden Logik - und das ist was ich mit "umständlich" meinte.

Jörg

[Otto123]

Ich denke, Du liegst falsch mit deiner Meinung über FHEM2FHEM.
Mit meiner obigen Logik:

• braucht es kein notify, was Du siehts ist alles was man braucht. Der Dummy wird automatisch gefüllt. Alle anderen Informationen im Web (notify, clonedummy usw.) sind uralt!
• werden eben nicht alle Events gepustet - sondern exakt die abbonniert die ich im regExp eingetragen habe.

[Adimarantis]

Wieder was gelernt.
Wobei ich noch nicht durch die Bedeutung des "defmod" gestiegen bin. Denn das scheint ja dafür verantwortlich zu sein, dass das Dummy befüllt wird, oder? Denn das "addStateEvent" verstehe ich nach Doku so, dass es lediglich auch das "state" reading mit berücksichtigt, oder?

Das wäre mal ein Doku Update fällig 

Jörg

[Otto123]

Hallo Jörg,

defmod ist lediglich die übliche Raw Definition Schreibweise des define. define legt ein neues Device an, defmod würde ein Vorhandenes modifizieren oder wenn nicht vorhanden ein Neues anlegen.

Das oben ist lediglich eine Kopie meiner komplette Umgebung für die Übertragung von zwei Werten. Die Namensgleichheit des Dummy sorgt dafür das er befüllt wird.

der Readingname state fehlt normalerweise  bei FHEM im EVENT, addStateEvent fügt diesen Readingnamen wieder zum EVENT hinzu.

Gruß Otto

[Adimarantis]

Ich habe jetzt noch ein wenig mit RFHEM rumgespielt und wieder geschafft eine Loop zu erzeugen. Bei Gelegenheit muss ich mir wirklich mal MQTT ansehen.
Habe es jetzt einfach so umgestellt, dass nur eine Seite Änderung triggert. Ist erstmal nicht ideal, aber wenigsten ohne Risiko.

Mir ist allerdings dabei aufgefallen, das RFHEM nicht ganz zuende programmiert ist. Der Zweig mit eingeschränkten events funktioniert nicht.
Da wird erstens die Variable "$exteventparts" falsch befüllt und dann fehlt der ganze Ausführungszweig für der das reading setzt.
Ich denke das müsste so aussehen:

Code Auswählen Erweitern

foreach $extevent (@{$extDevHash->{CHANGED}}) { #für jedes event des externen device / dort geänderte readings
my @exteventparts = split (": ", $extevent);
foreach $event (@myevents) { # mit jedme event aus rhfme attribut
if ($event eq $exteventparts[0]) {
Log3 $name , 3,  "RFHEM $name - triggered by Device:$extDevName with event $event";
my @eventparts = split (": ", $extevent);
Log3 $name , 3,  "RFHEM $name - event: $eventparts[0] with value $eventparts[1] ...";
    my $setcmd = "set $name cmd setreading $extDevName $eventparts[0] $eventparts[1]";
    fhem( $setcmd );
}
}
}

Hab ich zumindest mal so bei mir gepatcht und jetzt funktionieren eingeschränkte events.
Ich glaube außerdem das normale "set device on" events nicht korrekt behandelt werden (da fehlt ja im event dann der reading name), hab das aber jetzt nicht weiter verfolgt.

Jörg

[Otto123]

Hallo Jörg,

wenn Du eine Schleife bauen "willst" schaffst Du das mit jeder Technologie. Einfach "blind" jede Änderung von a nach b und von b nach a replizieren. Es sein denn man baut etwas ein, was erkennt das es eine Schleife ist. Meines Wissen ist weder RFHEM, FHEM2FHEM noch MQTT damit ausgestattet - also musst Du selbst dafür sorgen.

Die Übertragung von set device on über RFHEM funktioniert bei mir einwandfrei.

Gruß Otto