[Erledigt]: Transparente Anbindung von Devices einer Remote-FHEM Installation

[RaspiCOC]

Hallo zusammen,

mir ist bewusst, dass ich mich mit meiner Idee auf dünnes Eis begebe, da möglicher Weise so etwas schon geht:

Ausgangslage: Habe 12 FHT8b und auch noch diverse Fenstersensoren (FHT8TF) dir allesamt bislang über einen RPi mit COC angebunden sind. Mit den ganzen FHTs bin ich natürlich schon völlig am Limit dessen angekommen, was die 1% Regel so hergibt. Jetzt habe ich bei ebay einen zweiten COC sehr günstig geschossen, den ich auf einen zweiten RPi gepackt habe und im anderen Stockwerk einsetze. Von der ganzen Topologie her macht es nun völlig Sinn die FHTs zu je 6 Stück auf die zwei COCs zu verteilen.

Dank FHEM2FHEM werden die Logs weiterhin auf der "alten" Master-FHEM-Installation geschrieben. Mit RFHEM gelingt es mir auch Änderungen an den Einstellungen der FHTs, die am Remote-FHEM hängen, zu ändern. Insgesamt habe ich jetzt wieder ordentlich Luft und könnte nun auch - was vorher aufgrund der 1%-Regel nicht ging - in die programmierten Heizzyklen eingreifen.

Daran stört mich aber das eine oder andere:
- Die sozusagen gespiegelt am Master-FHEM angelegten FHT sind eben nur Dummys / CloneDummys. Eine direkte Anwahl einer Zieltemperatur (Dropdown in FHEM-Web oder über andFHEM) geht so leider nicht. Auf dem Master-FHEM sind die FHT eben keine echten FHT.
- Wenn ich aus einem notify / at / oder sonst was einen Befehl sende, dann ist der Syntaxaufbau natürlich auch anders.

Mein Gedanke daher:
Wenn ich einen FHT anlege:

define FHT1234 FHT 1234

dann muss ich ja auch noch der FHEM Instanz mitteilen, wie das Gerät erreichbar ist. Also:

attr FHT1234 IODev COC

um es an den als "COC" in FHEM anzubinden.

Wäre es jetzt eventuell denkbar, hierüber direkt die Remote-FHEM installation anzusprechen? Also:

attr FHT1234 IODev REMOTEFHEM

Das dann angesprochene "virtuelle" Device REMOTEFHEM würde dann quasi mittels der RFHEM Funktionalität den jeweiligen Befehl direkt an den Remote-FHEM absetzen und dort ausführen. Statusmeldungen etc. würde man dann weiterhin über FHEM2FHEM einsammeln und verwerten. Der FHT oder welches Device auch sonst noch denkbar wäre, könnte, obgleich remote angebunden, so verwendet werden, als ob es lokal angebunden wäre - eben transparent! Das wäre dann irgendwie so ähnlich, als ob die FHTs an einem CUNO hängen würden (den ich nicht habe!)

Wäre das was?

Grüße
RaspiCOC

PS: Sollte all das schon gehen, dann bitte ich um Verzeihung, um ein Verschieben des Posts und wahnsinnig gern um ganz viele präzise Hinweise, wie ich all das schon heute machen kann.

[Wuppi68]

Ich hab mal irgendwo im Forum/Wiki/Web gelesen, dass man auch "problemlos" den IO auf dem COC Pi einen TCP Port umleiten kann und dann soll es mit dem "Ethernet CUL" funktionieren ...

steht bei mir auch auf der noch zu erledigen Liste, bin aber nicht dazu gekommen

Viel Erfolg

Ralf

[RaspiCOC]

Das das mit dem Ethernet-CUL so gehen muss, dachte ich mir auch schon. Da spricht FHEM aber nach meinem Verständnis vermutlich "raw"  mit der culfw. Hier müsste mit "FHEM Befehlen" mit dem Remote-FHEM gesprochen werden.   

[Prof. Dr. Peter Henning]

Halte ich für vollkommen obsolet: Man braucht nur einen virtuellen USB-Port zwischen den beiden Raspberrys einzurichten und betreibt den zweiten nicht als FHEM, sondern nur (ganz doof) als Ethernet-Koppler für den COC. Wenn statt des COC ein echter CUL dran hängt, geht es auch ohne Raspberry mit einer billigen Ethernet/USB Bridge

pah

[RaspiCOC]

Ok, klingt durchaus nach einer Idee. Der COC auf dem zweiten Pi wäre dann quasi ein zweites IODev auf dem ersten Pi, richtig? Dann wären alle Devices lokal auf dem ersten Pi definiert und das 1% Problem ebenfalls gelöst.

Und vermutlich könnte ich dann am zweiten Pi auch noch einen zweiten RFXTRX anschließen,  der ebenfalls wie ein lokales IODev auf dem ersten wäre.

Bleibt nur die Frage, wie das mit dem virtuellen USB-Port realisiert wird. Ein wenig Hilfestellung wäre da ganz prima, denn offenbar gibt es zumindest - neben mir - noch einen weiteren Interessenten. Da wäre ich wirklich dankbar. 

[Wuppi68]

Habe es jetzt zum Laufen gebracht

die Beschreibung http://www.fhemwiki.de/wiki/CUL_ueber_Netz

mit netcat anstelle von socat

keine Ahnung ob es rebootfest auf dem Remote Device ist (Baudrate und Co)

und dann in FHEM habe ich das Device so installiert

Code Auswählen Erweitern

define max.coc.1 CUL 192.168.1.1:2323 9999
und dann die Attribute so wie sie in dem "alten anderen" FHEM eingestellt sind ...

und nu hast Du einen "normalen" CUL der alles wie ein lokaler macht

[RaspiCOC]

Vielen Dank! Das wird gleich ausprobiert - dann berichte ich!

Hmmm..... Komplette Fehlanzeige. RCOC (so hatte ich ihn lokal genannt): disconnected

Läuft bei Dir FHEM auf dem Remote-Pi?

[RaspiCOC]

Habe jetzt noch mal in das Log geschaut. Da steht "connection refused" drin.

Habe es mit netcat wie auch mit socat ausprobiert.

[Wuppi68]

Habe jetzt noch mal in das Log geschaut. Da steht "connection refused" drin.

Habe es mit netcat wie auch mit socat ausprobiert.

Hast Du auch den Port vorher wieder freigegeben? --> FHEM gestoppt?

[RaspiCOC]

Ja, FHEM ist auf dem remote PI gestoppt.

Hier mal der Inhalt meiner rc.local:

Code Auswählen Erweitern


Linux RPiFHEM2 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Oct 31 15:30:05 2014 from atos.fritz.box
pi@RPiFHEM2 ~ $ cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi

DEV=/dev/ttyACM0
while (true)
do
       netcat -l -p 2323 < $DEV >$DEV
       sleep 2
done



exit 0


Und hier die Definition des remote COC auf der FHEM Hauptinstanz:

Code Auswählen Erweitern


define RCOC CUL 192.168.1.35:2323 3432
attr RCOC model CUL


Netcat und socat hatte ich vorher auch noch mit apt-get installiert...

Was könnte ich noch übersehen haben?

[immi]

have you tried ser2net?
maybe it is easier... and is making a similar job.
I am using it since 2 year in combination with fhem for another module and it is very stable.
immi

[RaspiCOC]

Sounds interesting to me and seems to be the solution pah had proposed without going into detail.

But can you exactly tell me how you have set it up? Would I have ser2net running on both RPi?

[immi]

use ser2net only on the raspi with the cul you want to redirect (call it 10.0.2.5).
With ser2net you connect /dev/ttyACM0 (or what you have as ser interface ttyUSB0) to port 2003 (or what you want) for speed  115200 (or what you have)
in ser2net config

Code Auswählen Erweitern


2003:raw:500:/dev/ttyACM0:115200 NONE 1STOPBIT 8DATABITS


on the second raspi without the cul (10.0.2.6), you run fhem

Code Auswählen Erweitern


define cul868 CUL 10.0.2.5:2003 <fhtid>
attr cul868 model CUL


I have no cul. Nevertheless I use ser2net for my  heatpump (THZ) in a similar way.
have fun
immi

[RaspiCOC]

immi, thank you very much! It did take some time to get it running, but now it's perfect!

Dokumentation, damit - wer auch immer es mag - diese Lösung ohne großes Herumgesuche umgesetzt werden kann:

Austattung:
1 x RPi mit COC und laufender FHEM Instanz (genannt MasterPi)
1 x RPI mit COC und frisch aufgesetztem Raspian Wheezy (genannt SlavePI)

Nach Einrichtung des SlavePI auf diesem ser2net installieren:

Code Auswählen Erweitern

sudo apt-get install ser2net

Nun die Datei /etc/ser2net.conf editieren und die Zeile:

Code Auswählen Erweitern

2003:raw:0:/dev/ttyAMA0:38400 NONE 1STOPBIT 8DATABITS

unten anhängen. Ggf. die 2003 durch eine andere Portnummer ersetzen.

Nun die /etc/rc.local editieren und folgendes vor "exit 0" einfügen:

Code Auswählen Erweitern

/usr/sbin/service ser2net stop
echo "resetting 868MHz extension..."
/usr/bin/logger -p local0.notice "Reset COC"
if test ! -d /sys/class/gpio/gpio17; then echo 17 > sys/class/gpio/export; fi
if test ! -d /sys/class/gpio/gpio18; then echo 18 > sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo out > /sys/class/gpio/gpio18/direction
echo 1 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 3
/usr/sbin/service ser2net start


Diesen Code würde man normaler Weise in der /etc/init.d/fhem einfügen (natürlich ohne die service ser2net befehle).

Jetzt die /etc/inittab editieren und die Zeile

Code Auswählen Erweitern

T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

auskommentieren oder löschen.

Die /boot/cmdline.txt editieren. Sollte nun so aussehen:

Code Auswählen Erweitern

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait


Jetzt den Rpi mal rebooten. Hier sollte jetzt alles erst mal erledigt sein.

Auf dem MasterPI die fhem.cfg editieren und den Eintrag für den SlavePi einfügen:

Code Auswählen Erweitern

define NAME_DES_COC CUL IP_ADRESSE_DES_SLAVEPI:PORTNUMMER_WIE_IN_SER2NET.CONF FHTID
attr NAME_DES_COC model CUL


Jetzt muss man nur noch die FHT80b-Einträge dahingehend abändern, dass mit

Code Auswählen Erweitern

attr NAME_DES_FHT IODev NAME_DES_COC

die Verbindung über den SlavePI hergestellt wird. An den FHT80b CENT auf n/a stellen und z.B. eine Temperaturänderung senden. Nun sind die FHT80b mit dem SlavePI verbunden.

Ich musste übrigens nach Bearbeitung der FHEM.cfg (über das WebGUI) FHEM noch einmal mit shutdown restart neu starten.

Vielleicht kann einer der Admins diesen Thread an eine geeignete Stelle schieben.