ser2net CUL ser2net.yaml

[Otto123]

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?

[cbl]

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.

[cbl]

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?

[Otto123]

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 (/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.

Ein serial-getty@ttyACM* gibt es doch bei Dir nicht?

Code Auswählen Erweitern

systemctl list-units serial*Kommt Punkt 1 als Fehlerquelle bei Dir in Frage?

[cbl]

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:

Code Auswählen Erweitern

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

[cbl]

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.

Code Auswählen Erweitern

%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.

[Otto123]

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