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

[chris1284]

Hallo,

ich habe vor langer zeit versucht meine it-1500 Steckdosen auf dem pi mit coc-modul über fhem2fhem vom cubietruck aus zu schalten.
dies geht nicht wie ich feststellen musste:

Das IT Modul ist nicht FHEM2FHEM:RAW faehig, da es einen direkten Zugriff auf das drunterliegende IODev benoetigt, um per get raw Kommandos abzusetzen. FHEM2FHEM:RAW faehige Module kommunizieren nur per IOWrite bzw. Dispatch mit dem IODev.

bei meiner Lösungssuche ist dies Modul (in Anlehnung an fhem2fhem) entstanden das von einer Instanz in die andere befehle über telnet sendet.
diese möchte ich hier bereitstellen falls auch andere eine einfache Möglichkeit suchen fhem mit fhem anzusteuern, die devices/module aber nicht von fhem2fhem unterstützt werden

define syntax:

Code Auswählen Erweitern

define <name> RFHEM host[:port] [pw]
wir kein port angegeben wird 7072 genommen

ihr erhaltet ein device über das ihr per

Code Auswählen Erweitern

set <name> cmd <befehl> fhem-befehle senden könnt.


Attribut RFHEMdevs : eine Komma getrennte Liste von Devices. Alle events dieser Devices werden autom. an die entfernte Instanz weitergeleitet (sprich wenn deviceX ein event wie temperature: 29.3 generiert, wird ein "set rfhem_device cmd setreading deviceX  temperature 29.3" angesetzt).



beispiel: IT-Steckdosen vom cubie der über kein Funkmodul verfügt schalten. das Modul sitzt auf dem pi

Code Auswählen Erweitern

# pi remote
define RemotePI RFHEM christian-pi testpw1

den schalter habe ich als dummy realisiert

Code Auswählen Erweitern

# remote steckdosen
define wz.LichtschlauchDummy dummy
attr wz.LichtschlauchDummy devStateIcon on:message_socket_on2 off:message_socket_off2
attr wz.LichtschlauchDummy setList on off


wird er betätigt greift ein notify welches den befehl, den man auf dem pi eingeben würde , vom cubi an den pi sendet:

Code Auswählen Erweitern

define LichtschlauchNotify notify wz.LichtschlauchDummy { fhem "set RemotePI cmd set Wohnzimmer.Lichtschlauch $EVENT" }

einfache befehle funktionieren, richtige Syntax vorausgesetzt:
schalter schalten

Code Auswählen Erweitern

set RemotePI cmd set wz.* on
readings eines dummys setzen

Code Auswählen Erweitern

set RemotePI cmd setreading KS300Dummy 'T: 12.1 H: 72 W: 8.6 R: 1.8'
dummy definieren

Code Auswählen Erweitern

set RemotePI cmd define dummy dummy
einfache notifys erstellen

Code Auswählen Erweitern

set RemotePI cmd define b3lampV1 notify btn3 set lamp on
set RemotePI cmd define b3lampV1 notify btn3 {}
einfache ats definieren

Code Auswählen Erweitern

set RemotePI cmd define a1 at 17:00:00 set lamp on 
set RemotePI cmd define a1 at 17:00:00 {}

komplexe Sachen mit Perl-code wie

Code Auswählen Erweitern

set RemotePI cmd define a1 at 17:00:00 {fhem("set xyz on");} gehen nicht da

Code Auswählen Erweitern

fhem("set xyz on"); von fhem gleich versucht wird auszuführen ...
ich habe heute bei mir ein telnet Passwort vergeben und das Modul darauf angepasst, funktioniert also auch. nur ssl-auth ist nicht gegeben wie fhem2fhem

da ich nicht alle befehle testen kann (und auch nicht kenne) wäre eine Rückmeldung gut was geht und was nicht.
Nutzung auf eigene Gefahr,  programmiere nur aus spass an der sache und als "fortgeschrittener leihe" 

es läuft bei mir seit februar täglich und stabil auf 3 kisten die sich so unterhalten
Mittlerweile hat es das Modul ins FHEM update geschafft und steht somit per update zur Verfügung
gruß

christian

[eldrik]

Hi,

gleich mal getestet, funktioniert prima, ich habe meine IT Devices, am Pi mit COC im Keller, bisher per absetzen der Befehle über die Web URL abgesetzt, deine Lösung finde ich aber vom Aufbau her angenehmer

Greetz
Eldrik

[chris1284]

danke für die Rückmeldung.
noch ein hinweis:
in Verbindung mit fhem2fhem im log-modus kann man am Hauptsystem auch gleich die Meldungen des remote-systems sehen und ggf drauf reagieren ...
auch in vebindung mit clone dummy sind sicher noch so einige sachen möglich

[Joachim]

Moin chris1284,
danke, dass Du es ansprichst, das wäre auch mein Gedankengang gewesen, dass man mit einem angepassten RFHEM aus der "nur Lesen" Funktion des cloneDummys eine "lesen und schreiben" Funktion bauen kann, also quasi einen "richtigen clone" eines entfernten Devices.
Ich werde mir das auch mal ansehen, wie man das eventuell kombiniert bekommt.

Gruß Joachim

[justme1968]

ich hätte noch einen vorschlag...

wie wäre es wenn wir versuchen den cloneDummy, RFHEM und den readingsProxy zu einem modul zusammen zu fassen?

ist zustand:
cloneDummy: kopiert mehrere readings aus einem device in ein neues, remote oder lokal
RFHEM: sendet kommandos von lokal an remote, im prinzip die gegenrichtung zu cloneDummy
readingsProxy: splittet ein reading oder ein teil eines readings in ein neues device, kann senden und empfangen

es gibt zwischen allen drei modulen überschneidungen und bereiche die sehr ähnlich sind und ich kann mir einige szenarien vorstellen bei denen jeweils zwei der module zusammen sinnvoll sind bzw in denen die kombinierte funktionalität aus  zwei modulen gebraucht wird.

gruss
  andre

[chris1284]

moin andre,

readingsProxy kenne und nutze ich nicht. muss ich mir mal ansehen.
aber ansonsten gute idee. bin gerne bereit an einer höheren kompatibilität  mit anderen modulen mitzuwirken / mein modul auch ganz in ein anderes zu packen wenn es weiter hilft

noch ein paar gedanken meiner seits:

für mich ist RFHEM eigentlich eine Komponente die in fhem2fhem gehört, leider hat  rudolfkoenig mir hier damals nicht mehr geantwortet http://forum.fhem.de/index.php/topic,20621.msg141658.html#msg141658 , also wurde ich selbst aktiv.

das thema fhem-instanzen zu verbinden kann noch viel weiter gehen, auch was redundanz, ausfallsicherheit usw angeht:
- fhem2fhem im log modus um logs event mitzubekommen / in andere instanzen zu übertragen
- fhem2fhem für raw, rfhem für normale befehle (wenn rfhem in fhem eingeht wäre es nur ein modul )
- clonedummy um devices zu spiegeln
- evtl. alle instanzen eine configdb in der man configs pro instanz unterscheiden kann + eine logdb für alle + redundanz dieser auf allen system (alle schlafen bis die main ausfällt) -> hier weis sich nicht ob dann noch fhem2fhem im log-modus benötigt wird
- warum in einem clonedummy nicht per devIO das rfhem-device setzen so das befehle je nach defIO direkt an die andere instanz gehen ohne den befehl in notifys rammen zu müssen

aber das ist alles wunschdenken / evtl nicht machbar und so umfangreich das sich erst mal einige entwickler zusammensetzen und auf einen weg einigen müssten

[strauch]

Ich muss mal ganz doof dazwischen Fragen. Ich hab zur Zeit nur CULs und möchte davon gerne einen irgendwie zum quasi CUN machen, an dem Bestimmungsort ist auch eine Fritzbox. Schön wäre, wenn man die Geräte von einer entfernten FHEM Installation in die eigenen einbinden kann. Ich weiß nicht ob sowas über IODev möglich ist?!
So ein bisschen wie das hier: http://www.fhemwiki.de/wiki/CUL_ueber_Netz nur das ich das mit allem möglichen machen kann. Ich kann den Aufwand dafür aber auch gar nicht einschätzen.
Wobei ich auch noch mal schauen wollte ob es socat auf der FB gibt.
Aber ich denke das würde die ganze Bastelei mit FHEM2FHEM, CloneDummy und jetzt RFHEM doch beseitigen oder? Also quasi eine Ebene tiefer anzusetzten?!

[justme1968]

das ist normalerweise eine ebene tiefer.

schau dir mal ser2net an.

gruss
  andre

[justme1968]

das ganze in richtung replikation und ausfall sicherheit weiter zu entwickeln wäre dann ein nächster schritt. und das mit dem IODev gefällt mir. um das aber richtig und für alle devices so transparent wie möglich zu machen ein ziemlicher aufwand. da wäre es interessant zu wissen wie groß der bedarf dafür ist. nicht das etwas sehr komplexes daraus wird das dann keiner benutzt.

unabhängig davon wäre es aber glaube ich ein erster schritt die drei module so nahe wie möglich zu bringen. ob das dann am ende ein oder zwei module werden oder drei bleiben wird sich zeigen. aber nachdenken und ansehen sollte man. die überschneidungen sind schon da und wenn nichts anderes dabei raus kommt das die dokumentation aufeinander verweist und sich gleiches auch gleich verhält und heißt.

gruss
  andre

[strauch]

Also wenn ich mir http://fhem.de/stats/statistics.html anschaue gibt es schon viele FHEM2FHEM Installationen. Ich selbst habe 3, zur Zeit auf dem raspbi noch die Hauptinstallation, dann in einer VM am Stromzähler und auf der Fritzbox für die ganzen Fritzboxfunktionen. Das wäre schon schön, wenn ich das alles direkt in der Hauptinstallation machen könnte. Wobei die FB vermutlich eher nicht geht.

[eldrik]

Hi,

also ich setzte derzeit drei fhem2fhem Installationen ein, eine um meinen Pi mit COC und IT Geräten im Keller an meinen Mac Mini Server anzubinden und neben der Hauptinstanz auf dem Mac Mini Server zwei weitere FHEM Instanzen als fhem2fhem zur Anbindung der jeweils im OG und EG aufgestecken Pi 1Wire Adapter über OWServer, für alle 1Wire fhem2fhem Instanzen wird cloneDummy, readingsProxy und neuerding RFHEM eingesetzt.

Daher fände ich die Bestrebungen sehr interessant sämtliche Aktoren, über die Hauptinstanz steuern zu können, ohne hier eine weitere OWServer Verbindung zu einem der Pis herstellen zu müssen (die selten abgefragt aber für das jetzige Steuern der z.B. Rollladenaktoren über die Hauptinstanz zwingend benötigt wird).

Die Verbindung plane ich jetzt auch, neben der bereits mit RFHEM ersetzten alten Lösung zur Steuerung meiner IT Devices, auf RFHEM umzustellen.

Edit: Via RFHEM habe ich nun auch meine 1Wire Rollladenaktoren umgestellt und die Steuerung funktioniert nach den ersten Tests wie bei einem direkten define einer OWServer Instanz auf meiner Hauptinstanz

Greetz
Eldrik

[Joachim]

Moin @ all,
Moin chris1284, Moin andre,

habe mal eben nur die commandref zu readingsProxy überflogen, und habe auch noch nicht mit RFHEM gespielt,
aber
ich glaube die Idee von Andre ist nicht schlecht. Komme mir vor, wie der Zauberlehrling (die Geister, die ich rief).

die Module cloneDummy und readingsProxy sind aus verschiedenen Beweggründen entstanden, machen aber fast das gleiche, und müssten sich eigentlich komplett zusammenführen lassen, einzig ihnen fehlt das richtige Backend um entfernte FHEM-Installationen zu bedienen.
die Module FHEM2FHEM und RFHEM wären die richtigen Backends dazu, die man eigentlich auch zusammenfassen kann.
Da wäre dann "nur" noch die Schnittstelle zu cloneDummy/readingsProxy nötig, um Daten an der Hauptschleife von FHEM vorbei an die Frontends zu übertragen. Sowie eine Schnittstelle, die die richtigen Daten (was kann das Modul auf dem lokalen/entfernten FHEM) an die Fronends überträgt.
So war damals eigentlich auch meine Grundidee, als cloneDummy entstanden ist.
Wenn daran Interese besteht, sollten wir dafür aber einen eigenen Thread aufmachen.

OT:
@ andre,
hattest Du Dir die gänderte cloneDummy version mal angesehen, kann die so eingecheckt werden?

Gruß Joachim

[justme1968]

ich habe inzwischen im wiki mit ein paar beispielen zum readingsProxy angefangen.

der haupt interschied zwischen cloneDummy und readingsProxy ist glaube ich zur zeit das ersterer mit mehr als einem reading funktioniert, es immer 1:1 durch reicht und nur in eine richtung funktioniert, letzterer zur zeit nur mit einem reading oder einem teil aus einem reading und es die möglichkeit gibt es beim durchreichen in jede richtung zu manipulieren. intern ist da schon sehr viel ähnlich. ein rfhem (oder ein bidirektionales fhem2fhem) als iodev könnte ich mir gut vorstellen. sicher hat rudi auch eine meinung .

die letzte version vom cloneDummy muss ich mir noch anschauen.

gruss
  andre

[Joachim]

@ Andre,
die Meinung von Rudi glaube ich zu kennen.
"Wenn sich ein neuer Maintainer für FHEM2FHEM findet, könnt ihr das machen"

warten wir mal auf die Rückmeldung von chris1284.

Gruß Joachim

[justme1968]

es gibt ja auch die option ein bidirektionales rfhem zu bauen und fhem2fhem ganz in ruhe zu lassen.