2 x FHEM
appi
Ich habe immer wieder mal Probleme mit CULRFR welcher mir die Distanz
ins Nebengebäude überbrückt. ( Abstürze vom Remote CUL, Firmware
upgrade auf altem CUL etc.) Ich habe mir überlegt ob es möglich ist
den FHEM Server auf zwei Rechnern zu installieren und mit einem
Webinterface zuzugreifen?
FHEM mit CUL funktioniert perfekt und mit einem günstigen Dockstar
können locker zwei Server laufen. Arbeiten die irgendwie zusammen?
Was auch möglich wäre, USBIP. Finde ich aber etwas kompliziert. Die
Lösung sollte einfach sein und auch nach einem Reboot ( Stromusfall )
selbständig wieder funktionieren.
Wie sehen eure Lösungen aus?
gruss Remo
Gerhard Pfeffer
was spricht denn gegen den Einsatz eines CUN? Das kannst du direkt
über TCP/IP ansprechen und läuft wunderbar. Hab es bei mir selbst im
Einsatz und keinerlei Probleme. Ein CUL direkt beim Server und ein CUN
um auch den Rest abzudecken. ;-)
Greetz,
Gerhard
Zrrronggg!
läuft einwandfrei.
Aber wenn man eine Kabel legen kann, ist CUN sicher auch ne Lösung.
Rudolf Koenig
> installieren und mit einem Webinterface zuzugreifen?
Ich habe zwar auch keine Probleme mit CUL_RFR, aber ich will die Frage mal
beantworten. Manchmal will man eine Antwort, und nicht Gegenvorschlaege :)
Z.zt ist eine Kopplung mehrerer fhem's nicht moeglich, obwohl die Idee mich
seit laenger wurmt. Ich sehe zwei Wege es zu koppeln:
- "Cooked": via "inform timer" werden alle Events abgefangen und nochmal als
Trigger ausgesendet. Das ist verglichen mit dem naechsten Weg einfacher zu
realisieren, generisch, und man kann auch leicht Filter einbauen.
Problematisch ist das rausfiltern doppelter Nachrichten (wenn beide fhems die
gleiche Nachricht empfangen).
- "Raw": analog zu CUL_RFR (bei dem man ein CUL fuer die Weiterleitung angeben
kann), mit Verwendung von Dispatch() und ein neu einzufuehrenden "inform
raw". Wuerde nur Nachrichten von Geraeten treffen, die Dispatch verwenden:
CUL, FHZ, CM11, SISPM, RFXCOM.
Ich wechsele meine Meinung stuendlich, was besser ist.. :)
appi
vorgestellt, das ein FHEM server auf dem slaverechner läuft, welcher
den CUL als Device dem priären FHEM weiterleitet.
So etwa wir CUL_RFR anstatt über Funk einfach übers Lan. Ja, der CUN
kann das, aber wenn ich für meine web-cam sowieso
einen dockstar betreibe, könnte ich den CUN sparen.....
einen gruss
remo
Olaf Droegehorn
dann nimm doch "socat" auf dem Dockstar und h�nge einen CUL quasi-remote
dran. Dann brauchst Du keinen 2. FHEM Server, kannst den Dockstar nutzen
und der 2. CUL h�ngt remote am FHEM Server.
Gru�,
Olaf
appi schrieb:
> danke an alle f�r die vielen ideen. Ich habe mir ganz einfach
> vorgestellt, das ein FHEM server auf dem slaverechner l�uft, welcher
> den CUL als Device dem pri�ren FHEM weiterleitet.
> So etwa wir CUL_RFR anstatt �ber Funk einfach �bers Lan. Ja, der CUN
> kann das, aber wenn ich f�r meine web-cam sowieso
> einen dockstar betreibe, k�nnte ich den CUN sparen.....
>
> einen gruss
>
> remo
>
--
------------------------------------------------------------------------
Dr. Olaf Droegehorn
General Manager Tel. : +49-561-82020-410
DHS - Computertechnik GmbH Fax. : +49-561-82020-399
Carlsdorfer Stra�e 3 E-Mail: O.Droe...@dhs-computertechnik.de
WEB: www.dhs-computertechnik.de
D-34128 Kassel
------------------------------------------------------------------------
Zrrronggg!
Einsatz,
läuft einwandfrei. "
CUL … äh … reaktionsarm.
LOL
On 19 Okt., 15:49, Olaf Droegehorn <O.Droegeh...@dhs-
> Hi,
>
> dann nimm doch "socat" auf dem Dockstar und h nge einen CUL quasi-remote
> dran. Dann brauchst Du keinen 2. FHEM Server, kannst den Dockstar nutzen
> und der 2. CUL h ngt remote am FHEM Server.
>
> Gru ,
> Olaf
>
> appi schrieb:
>
> > danke an alle f r die vielen ideen. Ich habe mir ganz einfach
> > vorgestellt, das ein FHEM server auf dem slaverechner l uft, welcher
> > den CUL als Device dem pri ren FHEM weiterleitet.
> > So etwa wir CUL_RFR anstatt ber Funk einfach bers Lan. Ja, der CUN
> > kann das, aber wenn ich f r meine web-cam sowieso
> > einen dockstar betreibe, k nnte ich den CUN sparen.....
>
> > einen gruss
>
> > remo
>
> --
> ------------------------------------------------------------------------
> Dr. Olaf Droegehorn
> General Manager Tel. : +49-561-82020-410
> DHS - Computertechnik GmbH Fax. : +49-561-82020-399
Zrrronggg!
Ich hatte aus Versehen die Sendefrequenz des RFR verstellt.
Fixed.
Rudolf Koenig
> seit laenger wurmt. Ich sehe zwei Wege es zu koppeln:
Ich habe heute beide Wege implementiert im neuen Modul 93_FHEM2FHEM.pm, etwas
getestet, und eingecheckt. Feedback wuerde mich freuen.
Eine FHEM2FHEM Verbindung kann man entweder im "LOG" Modus herstellen, oder im
RAW Modus. Im LOG Modus werden alle events weitergereicht, man kann also auf
dem lokalen fhem die notifys oder FileLogs implementieren. Die Geraete werden
aber lokal nicht angelegt, also weder list noch set/get funktionieren.
Im RAW Modus muss man auch ein an dem remote fhem angeschlossenes Geraet (z.Bsp
MyCUL) spezifizieren, dessen Rohdaten werden dann lokal verteilt, und von den
(evtl. per autocreate angelegten) lokalen Geraeten verarbeitet. set
funktioniert auch, get noch nicht, hier brauche ich noch feedback bzw. mehr
Erfahrung. Es koennen nur die Geraete via RAW angebunden werden, die Dispatch()
verwenden, das ist z.Zt CUL, FHZ, CM11, SISPM und RFXCOM, getestet habe ich nur
CUL. Zum verwenden der RAW Modus muessen beide fhems auf dem neuesten Stand
sein (inkl. fhem.pl)
appi
das geht aber super schnell. Ich werde bis am nächsten Wochenende die
Installation anpassen und berichten.
danke und gruss
remo
appi
ich habe auf beiden servern die neueste cvs versin vonfhem
installiert.
im log wird folgendes protokolliert:
2010.10.25 21:42:50 3: CUL opening MyCUN device 192.168.1.43:2323
2010.10.25 21:42:50 3: CUL device opened
2010.10.25 21:42:50 3: FHEM2FHEM opening ds1 at 192.168.1.202:7072
2010.10.25 21:42:50 3: Can't connect to 192.168.1.202:7072: Connection
refused
2010.10.25 21:42:50 2: FHEMWEB port 8086 opened
muss ich noch weitere konfigurationen vornehmen? muss ich auf dem
client fhem-server auch fhem2fhem konfigurieren?
gruss
remo
Rudolf Koenig
Nein. Kann man vom lokalen Rechner (der Rechner mit der FHEM2FHEM Definition)
den anderen (remote) fhem per telnet erreichen?
> muss ich auf dem client fhem-server auch fhem2fhem konfigurieren?
Das remote fhem muss auch die neueste fhem.pl haben, falls das RAW Modus
verwendet werden soll. Fuer LOG ist auch eine alte Version ok.
appi
hallo rudi
danke für den tip mit telnet, das wars. ich musste noch die etc/hosts
ergänzen.
nun ist deas fhem2fhem connected.
frage: kann ich nun das device ds1 als IODev definieren, damit der
remote CUL verwendet wird?
meine Definition in der fhem.conf:
define ds1 FHEM2FHEM 192.168.1.202:7072 RAW:RemiseCUL
gruss und danke
remo
Rudolf Koenig
> remote CUL verwendet wird?
Ja.
Manfred Caspari
> Ich habe heute beide Wege implementiert im neuen Modul 93_FHEM2FHEM.pm, etwas
> getestet, und eingecheckt. Feedback wuerde mich freuen.
ich hab mich heute mal damit beschäftigt, weil mir die Reaktionszeiten
auf Fernbedienbefehle bei meinem Setup auf den Keks gingen.
Ich hab 7 1-Wire Sensoren per OWFS eingebunden, wovon einige in 10s
Intervallen abgefragt werden. Heute hab ich FS20/FHT und 1-Wire auf zwei
Rechner aufgeteilt. Das 1-Wire interface war mangels serieller
Schnittstelle eh schon an einem anderen Rechner (Voip-Anlage)
angschlossen und per OWSERVER mit der FHEM-Kiste verbunden. Jetzt läuft
FHEM mit minimaler Konfig auf der VOIP-Anlage für 1-Wire und die
Hauptinstallation wie gehabt auf meinem openrd_Fileserver.
> Eine FHEM2FHEM Verbindung kann man entweder im "LOG" Modus
> herstellen, oder im RAW Modus. Im LOG Modus werden alle events
> weitergereicht, man kann also auf dem lokalen fhem die notifys oder
> FileLogs implementieren. Die Geraete werden aber lokal nicht
> angelegt, also weder list noch set/get funktionieren.
Die nicht vorhandene set/get Funktion ist in meinem Fall zu verschmerzen
:-)
Die response auf Schaltbefehle ist spürbar besser. Den Unterschied sieht
man bereits beim Starten von FHEM:
Mit 1-Wire/OWFS:
> time /etc/init.d/fhem start
> Starting /etc/init.d/fhem
>
> real 0m16.424s
> user 0m4.310s
> sys 0m0.150s
> openrd1:/etc/FHZ#
Ohne 1-Wire/OWFS und mit FHEM2FHEM:
> time /etc/init.d/fhem start
> Starting /etc/init.d/fhem
>
> real 0m4.483s
> user 0m4.100s
> sys 0m0.070s
> openrd1:/etc/FHZ#
DANKE!
Manfred