Hallo zusammen,
ich habe scheinbar ein Reichweitenproblem, da meine Homematic Funkdimmer im Dachgeschoss regelmäßig mit ACK antworten. Meine FHEM Instanz läuft im EG auf einem Raspi mit CUL.
Da ich hier noch einige RASPI und auch noch eine weitere CUL liegen habe, dachte ich mir im Dachgeschoss noch eine weitere FHEM Instanz anzulegen.
Welcher Betriebsmodi ist denn dann der richtige? Wenn ich das richtig gelesen habe, dann erscheint mir LOG die richtige Einstellung zu sein?
Die Funkdimmer würde ich dann in der Haupt FHEM Instanz löschen und in der remote-Instanz definieren ?
Kann mir da jemand einmal auf die Sprünge helfen?
Vielen Dank!
Poste doch mal ein List vom Device. Ich nehme mal an es antwortet NACK.
Vieleicht kannst du auch einfach mit einer USB Verlängerung arbeiten und einen weiteren CUL zur VCCU hinzufügen.
Hi,
mach lieber eine Instanz, eine VCCU (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU)und eine zweiten IO.
Nimm lieber so etwas hier und keinen CUL -> http://www.fhemwiki.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Aber Du kannst natürlich auch einen CUL remote anbinden :-\ mit socat ist das glaub ich easy.
Gruß Otto
Vielen Dank für die Antworten.
Ich habe hier insgesamt 14 Rollladen (wiredHM), diverse Lampen, Schalter, Steckdose mit FHEM und einer CUL wunderbar am laufen und würde da auch nichts dran machen wollen. Lediglich zwei Dimmer im DG machen mir etwas Probleme, was den Empfang angeht.
Außerdem habe ich die Hardware ja auch noch übrig.
Meine Frage bezieht sich auf die Konfiguration eine Fhem2Fhem Verbindung. Die verstehe ich trotz wiki und commadred noch nicht so richtig.
Mit FHEM2FHEM im RAW Modus kannst Du meines Wissens einen CUL anbinden, ich würde diese Art aber für Homematic ausschließen. Meines Wissen ist diese Art der Anbindung nur in eine Richtung.
Deswegen nochmal mein Rat : VCCU und ein zweiter IO und Du brauchst an der bestehenden FHEM Instanz nichts zu ändern.
Bei Deiner Formulierung: etwas Probleme... reicht es meist aus den IO (CUL ) etwas anders zu platzieren. Also eventuell einfach eine USB Verlängerung.
Gruß Otto
Ich kann da Otto auch nur zustimmen.
Falls du im OG/DG WLAN haben solltest, wäre es relativ einfach ein weiteres HM Modul mit einem WeMos zu modifizieren und als weiteres IO mithilfe einer VCCU in deine Hauptinstanz zu integrieren.
Mit FHEM2FHEM wirst du nicht glücklich werden, da das Schalten der Dimmer nicht ohne weiteren Aufwand machbar ist!
Mein Tipp:
WeMos D1 mini + HM-MOD-UART mit esp-link flashen (sollte paar Anleitungen dazu im Forum geben) und diesen dann per 5V Netzteil im OG positionieren. Somit würde dieses IO dann das DG + OG und EG abdecken (je nachdem wie groß das Haus ist ;D )
In FHEM benötigst du dann noch eine VCCU und das war es dann auch schon fast.
Im Anhang habe ich noch zwei alte Bilder gefunden, so ähnlich habe ich es damals gemacht.
Gruß
Mathze
Jetzt verstehe ich das mit der VCCU. Das macht ja wirklich Sinn :-)
Ich habe in meiner Installation einen SCC - Stackable CC1101 und ein HMW-LAN-GW eingebunden. Beide haben unterschiedliche HmID's.
Wenn nich nun eine VCCU einrichte, dann nehme ich die gleiche HmID wie die des SCC, oder ? Die HMwired müssen ja nicht zwingend der VCCU zugeordnet werden?
Als weiteres IO habe ich hier noch eine SCC und einen Raspi liegen. LAN-Anschluss ist ebenfalls vorhanden.
Wie bekomme ich denn mit dieser vorhandenen Hardware ein weiteres (remote) IO gebastelt?
Zitat von: derHeimwerker am 07 Januar 2020, 19:54:36
Wie bekomme ich denn mit dieser vorhandenen Hardware ein weiteres (remote) IO gebastelt?
Per socat :) such mal hier rechts und links, ich glaube es gab vor Tagen erst einen Beitrag.
Zu dem HM wired kann ich nichts sagen, sicher hast Du da Recht. Die VCCU bekommt die hmId vom SCC, das wäre korrekt.
Gruß Otto
@Otto123 du liegst richtig, mit fhem2fhem kann man nur empfangen oder senden, aber nicht beides. Würde mit einer ziemlichen Frickelei über Dummys sicher trotzdem gehen. (Umständlich und fehleranfällig)
socat hab ich früher eingesetzt, war mir zu instabil ("Sender" war ein Raspberry 3B, FHEM lief auf FreeBSD).
Im Moment fahre ich sehr gut mit ser2net. Funktioniert ähnlich wie socat (macht aus dem CUL quasi nen CUN) aber ist meiner Beobachtung nach, zumindest in meiner Umgebung, deutlich stabiler. ser2net kommt auf das Gerät, dass den CUL hat und in FHEM wird der CUL wie ein CUN per IP:Port definiert.
Anleitung zu ser2net ist im Wiki zu finden.
So oder so, auf dem socat/ser2net-Gerät unbedingt an die Firewall denken. Ich bin fast ausgerastet, bis mir eingefallen ist, dass ich die Firewall auf der Himbeere extrem restriktiv eingestellt hatte...
Problematisch kann dann aber die Netzwerklatenz werden, wenn HM zu (de)codieren ist. Wenn die Strecke über WLAN läuft, kann es zu NACKs kommen, wenn die Funkverbindung nicht optimal ist. Daher hatte ich dem CUL die TSCUL-Firmware spendiert, da die doch spürbare Verbesserungen im Timing bringt.
Gesendet von meinem VOG-L29 mit Tapatalk
Zitat von: OiledAmoeba am 08 Januar 2020, 01:18:51
Daher hatte ich dem CUL die TSCUL-Firmware spendiert, da die doch spürbare Verbesserungen im Timing bringt.
Die sehe ich beim CUL sowieso als Pflicht an - aber das muss jeder CUL Besitzer selbst wissen. Ich rede dabei sowieso um Dinge die ich nicht habe und daher nur so nebenbei kenne.
Ich binde das HMUART Modul auch immer mit ser2net an, das war für mich immer wesentlich simpler. Ich wusste nicht das es mit dem CUL auch geht.
Gruß Otto
Hallo Otto,
ich versuche nun meinen Raspi 3 mit der SCC unter Raspbian Buster zum Laufen zu bringen. Ich hangel mich dabei durch deine Anleitung unter https://forum.fhem.de/index.php/topic,106060.45.html (https://forum.fhem.de/index.php/topic,106060.45.html). Bisher leider ohne Erfolg.
Deine Erklärungen dort beziehen sich ja aber auch auf eine Installation inkl. Fhem. Wenn ich das aber richtig verstehe, dann benötige ich in meinem Fall auf dem Raspi kein Fhem bzw. um den SCC über das Netz anzusprechen darf er lokal gar nicht betrieben werden?!
Was mach ich denn mit den Schritten 2 und 3 OHNE eine Fhem Installation ?
Zitat[/2. Schritt Script erzeugen
Code: [Auswählen]
cat <<EOF > /opt/fhem/EnableSCC.sh
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value
EOF
3. Schritt fhem.service ergänzen (nano /etc/systemd/system/fhem.service)
Vor dieser Zeile
Code: [Auswählen]
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
diese einfügen
Code: [Auswählen]
ExecStartPre=/bin/bash /opt/fhem/EnableSCC.sh
Zitat
Hi,
Zitatdann benötige ich in meinem Fall auf dem Raspi kein Fhem bzw. um den SCC über das Netz anzusprechen darf er lokal gar nicht betrieben werden?!
Richtig!
Zitat2 und 3 OHNE eine Fhem Installation ?
zunächst einfach per Hand ausführen und testen!
Von mir aus legst Du das Script in einen anderen Pfad - Beispiel:
mkdir /opt/scc
cat <<EOF > /opt/scc/EnableSCC.sh
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value
EOFWenn es funktioniert, baust Du dazu einen Service -> https://wiki.ubuntuusers.de/Howto/systemd_Service_Unit_Beispiel/
Ich will nochmal sagen: Ich habe keinen SCC, das ist für mich alles nur Theorie
Für ser2net kannst Du dann sicher analog dem Beispiel vorgehen https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Gruß Otto
Klasse. mein Abend ist erst einmal wieder gerettet :-)
Danke ich versuche das mal.
Das hat so wunderbar funktioniert. Vielen Dank!
Guten Morgen,
mir fällt noch ein: Eigentlich könnte man das Script analog wie es bei fhem.service gemacht wurde auch an den ser2net Service binden.
Es wird ja nur kurz gestartet und genau für den ser2net Service gebraucht.
Ist letztlich aber sicher nur Schönheits OP.
Ich habe jetzt irgendwie Beiträge für den SCC geleistet und im Wiki steht noch altes Zeug. Mal sehen wie ich das dort noch vorsichtig unterbringe, ich mache das ehrlich gesagt ungern wenn ich es nicht live umgesetzt habe.
Gruß Otto
Welchen Wiki Eintrag meinst du jetzt ?
Meines Wissens gibt es keinen für den SCC, aber wenn man nach GPIO17 sucht findet man zwei Artikel für den COC der wahrscheinlich so etwas ähnliches ist.
Man müsste eigentlich einen allgemeinen Artikel machen:
Wie starte ich etwas, was FHEM benötigt mit bei der Initialisierung eines anderen Dienstes z.B. des FHEM Service.
Am Beispiel: GPIO17 oder hmland usw...
Damit könnte man einige Artikel aufräumen und den allgemeinen Artikel einfach verlinken.
Gruß Otto
Da könnten wir ansonsten zusammen etwas zusammen basteln.
Leider habe ich mich wohl doch etwas zu früh gefreut. Ich Ich bekomme jetzt alle 30 Sekunden einen disconnect mit folgendem Log-Eintrag
2020.01.10 14:52:46 1: 192.168.178.48:4000 disconnected, waiting to reappear (HMLAN.Kino)
2020.01.10 14:52:46 1: HMLAN_Parse: HMLAN.Kino new condition disconnected
2020.01.10 14:52:47 5: HMLAN_Send: HMLAN.Kino I:A629CDA
2020.01.10 14:52:47 5: HMLAN_Send: HMLAN.Kino I:C
2020.01.10 14:52:47 5: HMLAN_Send: HMLAN.Kino I:Y01,00,
2020.01.10 14:52:47 5: HMLAN_Send: HMLAN.Kino I:Y02,00,
2020.01.10 14:52:47 5: HMLAN_Send: HMLAN.Kino I:Y03,00,
2020.01.10 14:52:47 5: HMLAN_Send: HMLAN.Kino I:T25AB3E2F,02,00,00000000
2020.01.10 14:52:47 1: HMLAN_Parse: HMLAN.Kino new condition init
2020.01.10 14:52:47 5: HMLAN_Send: HMLAN.Kino S:S8FBA96E8 stat: 00 t:00000000 d:01 r:8FBA96E8 m:99 8112 629CDA 000000
2020.01.10 14:52:47 5: HMLAN_Send: HMLAN.Kino I:K
2020.01.10 14:52:47 1: 192.168.178.48:4000 reappeared (HMLAN.Kino)
2020.01.10 14:52:48 5: HMLAN_Send: HMLAN.Kino I:K
2020.01.10 14:52:49 5: HMLAN_Send: HMLAN.Kino I:K
2020.01.10 14:52:50 5: HMLAN_Send: HMLAN.Kino I:K
2020.01.10 14:52:51 1: HMLAN_Parse: HMLAN.Kino new condition disconnected
und hier noch ein list bei connect :
Internals:
CFGFN
DEF 192.168.178.48:4000
DeviceName 192.168.178.48:4000
FD 29
FUUID 5e176770-f33f-0f85-30b7-087ea7dd1878aa15
NAME HMLAN.Kino
NR 8696
NTFY_ORDER 50-HMLAN.Kino
PARTIAL
STATE opened
TYPE HMLAN
XmitOpen 0
assignedIDsCnt 0
msgKeepAlive dlyMax:0.388 bufferMin:4
msgLoadCurrent 0
owner
owner_CCU VCCU
READINGS:
2020-01-11 17:26:10 Xmit-Events disconnected:5242 init:2621
2020-01-11 17:26:10 cond init
2020-01-11 17:26:09 prot_disconnected last
2020-01-11 17:26:10 prot_init last
2020-01-11 17:26:05 prot_keepAlive last
2020-01-11 17:26:10 state opened
helper:
assIdCnt 0
assIdRep 0
setTime 48179
cnd:
253 5242
255 2621
ids:
k:
BufMin 4
DlyMax 0.388
Next 1578759995.42779
Start 1578759970.42779
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0x4537920)
q:
HMcndN 255
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLastMax 0
loadNo 0
scnt 1
ald:
0
0
0
0
0
0
0
0
0
0
0
0
apIDs:
Attributes:
group Gateways
hmId 629CDA
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
room Hardware
verbose 5
Warte mal: Ich sehe gerade, Du hast den SCC jetzt wie einen HMLAN eingebunden? Das ist doch verkehrt? :o
Muss der nicht wie ein CUL eingebunden werden?
https://wiki.fhem.de/wiki/CUL_ueber_Netz
Gruß Otto
Habe das nun umgestellt. Ergebnis :
2020.01.12 15:30:27 3: Opening HMLanGateway.Kino device 192.168.178.48:4000
2020.01.12 15:30:36 1: Cannot init 192.168.178.48:4000, ignoring it (HMLanGateway.Kino)
list:
Internals:
CMDS
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF 192.168.178.48:4000 2323
DeviceName 192.168.178.48:4000
FHTID 2323
FUUID 5e1b26db-f33f-0f85-afbb-88b091c731210a08
NAME HMLanGateway.Kino
NR 62
STATE opened
TYPE CUL
initString X21
Ar
owner_CCU VCCU
MatchList:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2020-01-12 15:30:27 state opened
Attributes:
group Gateways
hmId 629CDA
rfmode HomeMatic
room Hardware
verbose 5
Was ich jetzt nicht weiß: Wie hast Du denn ser2net konfiguriert? Ich hatte ja, weil ich kein besseres Beispiel parat hatte, den Link zum RPI Modul gebgeben. Aber der CUL wird ja anders angebunden:
Also was steht denn in der ser2net.conf?
cat /etc/ser2net.conf
Gruß Otto
4000:raw:0:/dev/ttyAMA0:115200 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE
Zitat aus dem WIki:
Zitat2000:raw:0:/dev/ttyACM0:38400 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE
Der SCC läuft
mit 115200 ? Oder mit 38400
?gefunden (http://www.busware.de/tiki-index.php?page=SCC_Installation): mit define SCC CUL /dev/ttyAMA0@
38400 1234
Die Baudrate hatte ich vorher schon auf 38400 gestellt. Hat aber keine AUswirkug auf den log Eintrag
und du hast ser2net auch neu gestartet?
Hatte zwar ein ein Daemon-reload und ein stop/start des Dienstes durhgeführt, aber ein reboot hat nun tatsächlich den gewünschten Erfolg gebracht !!
Es läuft :-)
Danke
Ich denke, wenn die serielle Schnittstelle einmal durch Fehleinstellung verwurschtelt ist, kann das durchaus einen reboot erfordern. ;)