Hi,
also ich komm hier nicht weiter. Rasp3 als ser2net für cul aufgesetzt:
ser2net.yaml:
%YAML 1.1
---
# This is a ser2net configuration file, tailored to be rather
# simple.
#
# Find detailed documentation in ser2net.yaml(5)
# A fully featured configuration file is in
# /usr/share/doc/ser2net/examples/ser2net.yaml.gz
#
# If you find your configuration more useful than this very simple
# one, please submit it as a bugreport
define: &banner \r\nser2net port \p device \d [\B] (Debian GNU/Linux)\r\n\r\n
connection: &con01
accepter: tcp,2000
enable: on
options:
kickolduser: true
connector: serialdev,
/dev/ttyACM0,
38400n81,
local
systemctl status ser2net
● ser2net.service - Serial port to network proxy
Loaded: loaded (/lib/systemd/system/ser2net.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2022-03-12 22:44:19 CET; 2s ago
Docs: man:ser2net(8)
Main PID: 802 (ser2net)
Tasks: 1 (limit: 1717)
CPU: 42ms
CGroup: /system.slice/ser2net.service
└─802 /usr/sbin/ser2net -n -c /etc/ser2net.yaml -P /run/ser2net.pid
Mär 12 22:44:19 raspberrypi systemd[1]: Starting Serial port to network proxy...
Mär 12 22:44:19 raspberrypi systemd[1]: Started Serial port to network proxy.
netstat -tulpn
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:2000 0.0.0.0:* LISTEN 770/ser2net
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 482/cupsd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 500/sshd: /usr/sbin
tcp6 0 0 :::22 :::* LISTEN 500/sshd: /usr/sbin
udp 0 0 0.0.0.0:48191 0.0.0.0:* 360/avahi-daemon: r
udp 0 0 0.0.0.0:68 0.0.0.0:* 457/dhcpcd
udp 0 0 0.0.0.0:631 0.0.0.0:* 512/cups-browsed
udp 0 0 0.0.0.0:5353 0.0.0.0:* 360/avahi-daemon: r
udp6 0 0 :::5353 :::* 360/avahi-daemon: r
udp6 0 0 :::36092 :::* 360/avahi-daemon: r
list CUL_PI:
Internals:
CFGFN
CMDS
CUL_PI_MSGCNT 6
CUL_PI_TIME 2022-03-12 22:39:26
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF 192.168.1.95:2000 0000
DeviceName 192.168.1.95:2000
FHTID 0000
FUUID 622d120d-f33f-d06d-02dc-101a1a127e5fd58d
NAME CUL_PI
NEXT_OPEN 1647121226.03256
NR 904
PARTIAL
RAWMSG Device open failure: Remote end closed connection
STATE disconnected
TYPE CUL
devioNoSTATE 1
initString X21
MatchList:
0:FS20V ^81..(04|0c)..0101a001......00[89a-f]...
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04......a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2022-03-12 22:39:26 state disconnected
Attributes:
Bin ich zu blöd? Oder sehe ich etwas nicht?
Hi,
mach mal:
nc -z -v -w 1 192.168.1.95 2000
Und reduziere mal die yaml, die Zeilen enable und kick ... haben bei mir gestört. https://forum.fhem.de/index.php/topic,126059.30.html#lastPost
siehe Beispiel hier https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Variante_mit_ser2net
Gruß Otto
Ah Danke erstmal für die Antwort.
Blockt auf meinem pi etwas?
Lokal auf dem pi geht es aber auf dem FHEM Server:
root@raspberrypi:~# nc -z -v -w 1 192.168.1.95 4000
Connection to 192.168.1.95 4000 port [tcp/*] succeeded!
root@fhem:~# nc -z -v -w 1 192.168.1.95 4000
192.168.1.95: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.1.95] 4000 (?) open
Die ser2net.yaml habe ich mal ausgemisstet und Dienst startet ohne Probleme:
%YAML 1.1
---
connection: &con01
accepter: tcp,4000
connector: serialdev,
/dev/ttyACM0,
38400n81,local
tja da musst Du suchen. Sieht pauschal nach "Netzwerk geht nicht" aus :)
ping?
andere ports?
firewall?
fail2ban?
....
Hmmm....
Ping geht Problemlos
fail2ban im lokalen Netzwerk? - Nein nutze ich nicht...
Ich teste jetzt mal mit buster...
Also mit buster und ser2net 3.5.2 alles Problemlos. Also lag es nicht am Netzwerk sondern wahrscheinlich an bullseye, das ist meine Annahme da der Dienst ja den Port nachweislich lokal bereitstellt.
Evtl. findet sich ja jemand mit genügend Licht am Fahrrad um mir mal zu sagen was man tun kann um das neue ser2net mitbullseye zu betreiben...
Der Unterschied zwischen Bullseye und Buster ist die Version von ser2net 4.x vs 3.x und die damit völlig andere conf (yaml) Datei.
Ansonsten läuft das bei mir derzeit auf einem Pi B1 - mit den schon erwähnten Korrekturen - unter Bullseye.
Und mein Licht am Fahrrad ist auch in Ordnung und ausreichend ;D
Jetzt wo ich nochmal nachschaue fällt mir auf
tcp6 0 0 :::4000 :::* LISTEN
tcp6 0 0 192.168.56.219:4000 192.168.56.83:59592 VERBUNDEN
Warum steht da tcp6 ::)
Ich habe die Verbindung mit Namen gemacht und nicht mit ip4 Adresse.
Hallo Otto,
an der Helligkeit Deines Lichtes würde ich nie zweifeln. Ich habe bei mir schon einige sehr gute Tipps, Tricks und Workarounds von Dir implementiert...
Deshalb vielen Dank an Dich und Deiner Aktivitäten hier im Forum!
Ich vermute fast dass es etwas mit dem Adapter zu tun hat an dass sich der ser2net-Port bindet. Ich benutze nämlich den WLAN Adapter des pi3b.
Als kurzen Test habe ich auch mal ipv6 komplett deaktiviert gehabt.
Aber da es mit buster und der alten Version läuft besteht erstmal kein Handlungsbedarf. Aber ärgern tut mich das irgendwie schon...
Ich schaue mir das nochmal auf meinem Test raspi 3b an, jetzt war es erstmal wichtig dass es produktiv läuft...
Ich wärme nochmal diesen alten Thread auf, da er exakt mein Problem beschreibt und ich nicht abwarten möchte. Nachdem mir eine SD-Karte (mit Buster) abgeraucht ist, möchte ich die Chance nutzen, meinen Raspi frisch mit Bullseye (64bit) aufzusetzen und hoffe, dabei auch gleich auf 64bit wechseln zu können. Ich bin noch unsicher, ob es mittlerweile alles in 64bit gibt - mal sehen.
Auf jeden Fall komme ich damit nun nicht um den Wechsel von der ser2net.conf auf die ser2net.yaml herum.
Mit der oben geposteten ser2net.yaml startet ser2net auch:
%YAML 1.1
---
connection: &cul866
accepter: tcp,2000
connector: serialdev,
/dev/ttyACM0,
38400n81,local
connection: &cul433
accepter: tcp,3000
connector: serialdev,
/dev/ttyACM1,
38400n81,local
und ich kann über nc -z -v -w 1 <ipadresse oder hostname> 2000
und nc -z -v -w 1 <ipadresse oder hostname> 3000
offenbar beide Ports vom FHEM-Rechner aus ansprechen. NC gibt jedenfalls als Ergebnis "2000 port [tcp/*] succeeded!" zurück.
Wenn ich in ser2net.yaml
accepter: ipv4,tcp,3000
verwende, liefert mir
netstat -l | grep 3000
auch tcp LISTEN auf diesem Port. Bei 2000 bekomme ich hingegen mit netstat kein Ergebnis.
FHEM kann aus beiden Devides keine Verbindung aufbauen. Im EventMonitor bekomme ich diese Zeilen bei einem "reopen" auf dem Cul-Device (cul866):
2022.05.29 13:04:14 5 : CUL_ReadAnswer cul866: Device open failure: Remote end closed connection
2022.05.29 13:04:14 4 : CUL_Parse: cul866 Device open failure: Remote end closed connection
2022.05.29 13:04:14 5 : cul866: dispatch Device open failure: Remote end closed connection
2022.05.29 13:04:14 3 : cul866: Unknown code Device open failure: Remote end closed connection, help me!
2022.05.29 13:04:14 1 : <hostname>:2000 disconnected, waiting to reappear (cul866)
Um beim Bild aus dem März zu bleiben: Kann mich jemand erleuchten? Hat inzwischen jemand ser2net unter Bullseye und FHEM zusammen zum Laufen gebracht? Ich würde dann den WIKI-Eintrag (https://wiki.fhem.de/wiki/CUL_ueber_Netz) auch entsprechend überarbeiten.
Hallo cbl,
zeig doch mal ein
ls -lha /dev/ttyACM*
Gruß Otto
Hallo Otto,
das liefert mir
crwxrwxrwx 1 root dialout 166, 0 20. Mär 20:55 /dev/ttyACM0
crwxrwxrwx 1 root dialout 166, 1 20. Mär 20:55 /dev/ttyACM1
Da ich in der Vergangenheit durch Rechteproblemen hier gebremst wurde, habe ich das zuerst angeschaut und die Rechte in der ersten Analyserunde erhöht.
Gruß
Christian
es klingt irgendwie danach als ob kein Zugriff auf die Schnittstellen möglich ist.
ZitatHat inzwischen jemand ser2net unter Bullseye und FHEM zusammen zum Laufen gebracht?
Bei mir läuft das ohne Probleme mit einem HMUART Modul
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Variante_mit_ser2net
... und der user "FHEM" bzw. "fhem" muss der Gruppe "dialout" angehören.
Einen Punkt habe ich oben vergessen zu erwähnen.
ser2net läuft auf einem anderen Rechner als fhem. Damit spielt doch der FHEM-User keine Rolle, oder?
Aber der User, unter dem ser2net läuft, braucht die passenden Rechte ....
ser2net läuft doch normal als systemd Dienst und per default als root ...
Ich vermute es stimmt was mit dem Zugriff auf die CUL Sticks nicht ...
Man müsste mal schauen ob ser2net nicht ein Log schreibt?
Leider komme ich erst jetzt dazu, auf eure Hinweise zu reagieren:
/dev/ttyAC* hat ein chmod 777 bekommen (ohne Änderung). Damit dürfte niemand Zugriffsprobleme haben oder könnte sich ser2net an zu vielen Rechten stören?
Ein Start von ser2net mit der zusätzlichen Option -l für ein höheres Debuglevel brachte auch keine weiteren Einträge. Da ich Einträge bei doppelt laufendem ser2net im Syslog gefunden habe, würde ich auch dort Spuren auf abgebrochenene Verbindungsversuche von FHEM erwarten. Leider gab es gar nichts.
Nach einem "set ... reopen" im FHEM-Device sehe ich auf dem Ser2net-Raspi keinerlei Aktivität.
Zitat von: Otto123 am 29 Mai 2022, 23:36:07
es klingt irgendwie danach als ob kein Zugriff auf die Schnittstellen möglich ist. Bei mir läuft das ohne Probleme mit einem HMUART Modul
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Variante_mit_ser2net
Ich konkretisiere die Frage:
Laufen Ser2net auf einem Raspi mit 64bit Bullseye und FHEM auf einem Raspi mit 32bit Buster erfolgreich zusammen?
Ich konkretisiere nach ein paar Tests meine Antwort:
Bei mir läuft ser2net auf einem Pi2b mit Bullseye 32bit und einem Pi3+ mit Bullseye 64bit mit einem HMUART Modul (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Variante_mit_ser2net) (/dev/ttyAMA0)
Zugriff mit einem FHEM auf Buster.
Stolperfallen:
- ser2net startet bei einem reboot fehlerhaft, wenn man die Abhängigkeit im unit File nicht eingebaut hat (siehe Anleitung Link oben)
- Ich hatte zunächst vergessen den serial-getty@ttyAMA0.service zu deaktivieren, damit kämpfen zwei Dienste um die gleiche Schnittstelle. Siehe hier (https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule).
Ein serial-getty@ttyACM* gibt es doch bei Dir nicht?
systemctl list-units serial*
Kommt Punkt 1 als Fehlerquelle bei Dir in Frage?
Hallo,
vielen Dank für die Tests.
serial-getty habe ich nicht - frisch geprüft. Es gibt genau drei getty-Dienste (getty@tty1, system-getty, getty.target), die alle unverdächtig sind.
Und Punkt 1 habe ich auch schon drin gehabt:
After=network-online.target
Wants=network-online.target
Ich überlege, zurück zu 32bit zu wechseln, würde aber gerne herausfinden, wo hier das Problem liegt, da es ja offensichtlich funktionieren kann.
Hat noch jemand eine Stolperfalle 3?
Gruß
Christian
Ich habe die Lösung gefunden.
Im Zusammenspiel zwischen ser2net und FHEM in meiner Konstallation (ser2net auf einem 64bit-Bullseye Raspi3; fhem auf einem 32bit-Bullseye Raspi3) läuft die Kommunikation, seit ich in der ser2net.yaml die Nobreak-Option eingefügt habe.
%YAML 1.1
---
connection: &cul866
accepter: tcp,2000
enable: on
options:
banner: *banner
kickolduser: true
connector: serialdev,
/dev/ttyACM0,
19200n81,local,NOBREAK
connection: &cul433
accepter: tcp,3000
enable: on
options:
banner: *banner
kickolduser: true
connector: serialdev,
/dev/ttyACM1,
19200n81,local,NOBREAK
Vermutlich braucht man die Options nicht. Ich habe jetzt aber so ein lauffähiges System.
Ich habe das Wiki entsprechend um die gewonnenen Erkenntnisse ergänzt.
Hallo cbl,
schön das es funktioniert - wobei sich mir die Lösung logisch nicht erschließt. Ich hoffe also es hält :)
Den NOBREAK Parameter gibt es schon in der alten Version - warum war der in Deiner alten Config nicht nötig?
Es gab auch schon mal den umgekehrten Fall: https://forum.fhem.de/index.php?topic=85770.0
Ich selbst hatte aber auch ein unlogisches Problem :) https://forum.fhem.de/index.php/topic,126059.msg1210007.html#msg1210007
Gruß Otto