FHEM ist umgezogen; wie nun SCC auf RPi ansprechen?

[M_I_B]

Hallo liebe Leute,

heute ist endlich der Speicher für meinen ProLiant aus USA aufgeschlagen. Somit läuft endlich auch mal die DB wieder richtig ungewohnt flott und nun sind auch reichlich Ressourcen für den sowieso geplanten FHEM- Umzug vorhanden. Also habe  ich auf dem ProLiant mit aktueller Debian mal eben FHEM installiert, die komplette Config 1:1 rüber kopiert, noch mal ein Update gemacht und erst mal die Transceiver auskommentiert... So weit alles super; rennt wie der Teufel

So... Der HM-LAN ist ja kein Problem, aber womit ich noch etwas hadere, sind die beiden vorhandenen SCC auf dem RPi...
Ich dachte so:
FHEM auf dem RPi entsorgen, socat oder ser2net auf beiden Systemen installieren (derzeit haben beide socat) und dann vom Server aus die beiden SCC auf dem RPi ansprechen...
Aber da ich bekanntermaßen ein DAU bin, fehlen mir erst einmal die Informationen, auf welchen Schnittstellen die SCC denn laufen (und vor allem welcher SCC auf welcher Schnittstelle), ob ich auf dem RPi noch irgend etwas starten muss (irgend einen Daemon oder was weiß ich) und wie dann die cocat Zeile auszusehen hat, um den richtigen SCC (HM und IT) zu treffen.

Ok, hier im Forum und an vielen anderen Stellen steht da einiges zu, aber inzwischen habe ich so viel darüber gelesen, oft auch widersprüchliche Aussagen, das ich nun extrem unsicher bin, wie ich nun vorzugehen habe... Immerhin ein Live- System, was ich nicht zu lange inaktiv lassen kann ...

Wer mag mir helfen?

[rudolfkoenig]

Die SCC's multiplexen ihre Daten ueber den untersten, und diese wird vom FHEM Modul 00_CUL.pm bedient. Also ser2net fuer die als CUL definierte serielle Schnittstelle konfigurieren, und in der ProLiant-FHEM-Konfig die CUL Definition auf die ser2net TCP-Adresse (IP:Port) aendern. Die andere SCC am besten auch gleich in der Konfig aktivieren, sonst wird sie neu angelegt.

[M_I_B]

... ahhh ok. Also brauchen (theoretisch) mehrere SCC nur eine einzige Schnittstelle? Also in etwa so?

Code Auswählen Erweitern

define UFO1 HMLAN 192.168.1.198:1000
attr UFO1 alias UFO HomeMatic 868MHz
attr UFO1 event-on-change-reading .*
attr UFO1 group CUL
attr UFO1 hmId F10000
attr UFO1 hmLanQlen 1
attr UFO1 loadLevel 0:low,40:batchLevel,90:high,99:suspended
attr UFO1 room System

define SCC1 CUL 192.168.1.196:2000 0706
attr SCC1 alias SCC1 InterTechno 433MHz
attr SCC1 event-on-change-reading .*
attr SCC1 group CUL
attr SCC1 rfmode SlowRF
attr SCC1 room System

define SCC2 STACKABLE_CC SCC1
attr SCC2 alias SCC2 HomeMatic 868MHz
attr SCC2 event-on-change-reading .*
attr SCC2 group CUL
attr SCC2 hmId F10000
attr SCC2 rfmode HomeMatic
attr SCC2 room System

define VCCU CUL_HM F10000
attr VCCU IODev UFO1
attr VCCU IOList UFO1,SCC2
attr VCCU alias Virtuelle CCU
attr VCCU group CUL
attr VCCU model CCU-FHEM
attr VCCU room System
attr VCCU subType virtual
attr VCCU webCmd virtual:update

ser2net.conf auf dem Server:
Is natürlich Quatsch! Das gehört auf den RPi mit den SCC (voll den Knoten im Hirn)...

Code Auswählen Erweitern

# SCC1 434MHz InterTechno, SCC2 868MHz HomeMatic Stack
2000:raw:0:/dev/ttyAMA0:38400 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE

Und das Script (wie macht man noch mal einen Autostart?) auf dem RPi mit den SCC's:
Und das braucht es nicht bei Verwendung von ser2net (da ist das WiKi etwas doof geschrieben finde ich...)

Code Auswählen Erweitern

#!/bin/sh
DEV=/dev/ttyAMA0

while (true)
do
       /usr/bin/socat -ly -lh GOPEN:$DEV,raw,echo=0 TCP-LISTEN:2000
       sleep 2
done

Also alles gut: Es funktioniert vollkommen schmerzfrei, wenn man es erst mal durch den Hirnknoten gelockt hat

Da der RPi jetzt eigentlich nichts mehr zu tun hat, würde dafür ja auch ein älteres Modell wie z.B. ein PI2(b) vollkommen reichen, oder?