Nach PI2-Ableben: Funk-Gateway ser2net (Rasbian11) klappt nicht

Begonnen von OberFrickler, 06 Juni 2023, 15:53:43

Vorheriges Thema - Nächstes Thema

OberFrickler

Hallo liebe FHEM'ler,

vor zwei Tagen ist einer meiner allerersten PI2's abgeraucht. Daher bin ich gezwungen, nun ein neues Funk- Gateway aufzubauen.
Im Grunde besteht das Ganze aus einem PI (nun PI3 b) mit drei SCC's huckepack (HM, MAX IT). Angesprochen wurde das schlicht via ser2net- Proxy auf dem PI. Hat zumindest jahrelang vollkommen störungsfrei funktioniert.
Nun aber habe ich ein Problem, bei dem ich mir inzwischen zwei Tage und Nächte die Zähne dran ausbeiße :-\

Basis ist nun ein PI3b und die drei SCC's. Als OS kommt Rasbian11x64-lite headless zum Einsatz.

Grundsätzlich läuft alles, aber es ist mir bisher erst einmal gelungen, eine stabile Verbindung zwischen der FHEM- Instanz und dem Funk-Gateway zu etablieren. Nach einem Neustart des PI ist alles kaputt; keine Verbindung mehr möglich, egal was ich anstelle...

ser2net (4.3.3) läuft:
root@SH-PI-TRANSCEIVER:~# 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 Tue 2023-06-06 15:00:21 CEST; 1min 12s ago
       Docs: man:ser2net(8)
   Main PID: 627 (ser2net)
      Tasks: 1 (limit: 839)
        CPU: 42ms
     CGroup: /system.slice/ser2net.service
             └─627 /usr/sbin/ser2net -n -c /etc/ser2net.yaml -P /run/ser2net.pid
Jun 06 15:00:21 SH-PI-TRANSCEIVER systemd[1]: Starting Serial port to network proxy...
Jun 06 15:00:21 SH-PI-TRANSCEIVER systemd[1]: Started Serial port to network proxy.

... resp. mit der alten conf:
Jun 06 15:46:14 SH-PI-TRANSCEIVER systemd[1]: Starting Serial port to network proxy...
Jun 06 15:46:14 SH-PI-TRANSCEIVER systemd[1]: Started Serial port to network proxy.
Jun 06 15:46:14 SH-PI-TRANSCEIVER ser2net[858]: ser2net:WARNING: Using old config file format, this will go away
Jun 06 15:46:14 SH-PI-TRANSCEIVER ser2net[858]: soon.  Please switch to the yaml-based format.

Die yaml der aktuellen ser2net sieht so aus (keine TAB's drin):
connection: &con0096
    accepter: tcp,2000
    enable: on
    options:
#      banner: *banner
        kickolduser: true
#        telnet-brk-on-sync: true
    connector: serialdev,/dev/ttyAMA0,38400n81,local

Den Thread https://forum.fhem.de/index.php?topic=124384.0;all hab ich auch schon komplett durch und die Änderungen von Diblominschenör eingebaut. Auch den Trick mit der alten ser2net.conf habe ich ausprobiert.
Da hier alles nicht zum Erfolg geführt hat, vermute ich die Probleme schon fast woanders.
Noch was: FHEM läuft auf meinem NAS unter Debian11. NAS ist ein OMV6 und dort ist in der Firewall natürlich eingehend und ausgehend für das LAN Port 2000-2100 freigegeben (ich nutze seit jeher Port 2000 für ser2net).


Könnte mit hier bitte jemand weiterhelfen und mich von einer Verzeiflungstat abhalten?

LG


mumpitzstuff

Ist dein Problem der Neustart des Systems oder bekommst du grundsätzlich gar keine Verbindung hin? Wenn es lediglich der Neustart ist, kann es helfen, den Start zu verzögern. Funktioniert denn die Verbindung, wenn du den Service manuell restartest, nachdem das System ein paar Minuten gelaufen ist?

OberFrickler

#2
... eine Verbindung kommt gar nicht mehgr zu stande. Auch ein Restart hilft nicht: Es bleibt wie es ist...

Zwischenzeitlich bekomme ich, wenn ich den Status von ser2net abfrage, NACHDEM ich in FHEM einmal die DEF des ersten SCC angefasst und ohne Änderungen gespeichert habe, beri dser Statusabfrage folgendes:
Jun 06 19:00:09 SH-PI-TRANSCEIVER systemd[1]: Starting Serial port to network proxy...
Jun 06 19:00:09 SH-PI-TRANSCEIVER systemd[1]: Started Serial port to network proxy.
Jun 06 19:01:12 SH-PI-TRANSCEIVER ser2net[840]: The dev write(2) for port con09 had error: Remote end closed connection
Jun 06 19:01:12 SH-PI-TRANSCEIVER ser2net[840]: The dev write(3) for port con09 had error: Object was not ready for operation

Jedes mal, wenn ich einmal die DEF aufrufe und ohne änderungen verlasse und speichere, verdoppeln sich die letzten beiden Fehler-Zeilen...

Korrektur:
Ich muss gar nichts machen und habe jetzt ...

Jun 06 19:17:18 SH-PI-TRANSCEIVER ser2net[840]: The dev write(2) for port con09 had error: Remote end closed connection
Jun 06 19:17:18 SH-PI-TRANSCEIVER ser2net[840]: The dev write(3) for port con09 had error: Object was not ready for operation
Jun 06 19:18:18 SH-PI-TRANSCEIVER ser2net[840]: The dev write(2) for port con09 had error: Remote end closed connection
Jun 06 19:18:18 SH-PI-TRANSCEIVER ser2net[840]: The dev write(3) for port con09 had error: Object was not ready for operation
Jun 06 19:19:18 SH-PI-TRANSCEIVER ser2net[840]: The dev write(2) for port con09 had error: Remote end closed connection
Jun 06 19:19:18 SH-PI-TRANSCEIVER ser2net[840]: The dev write(3) for port con09 had error: Object was not ready for operation
Jun 06 19:20:18 SH-PI-TRANSCEIVER ser2net[840]: The dev write(2) for port con09 had error: Remote end closed connection
Jun 06 19:20:18 SH-PI-TRANSCEIVER ser2net[840]: The dev write(3) for port con09 had error: Object was not ready for operation
Jun 06 19:21:18 SH-PI-TRANSCEIVER ser2net[840]: The dev write(2) for port con09 had error: Remote end closed connection
Jun 06 19:21:18 SH-PI-TRANSCEIVER ser2net[840]: The dev write(3) for port con09 had error: Object was not ready for operation

Mit dem Anfassen des DEF kann ich das nur manuell triggern...
Mit "Remote end..." ist dann wohl FHEM gemeint?!? Oder hat Perl/Fhem irgend welche Probleme mit Bullseye?!? So langsam komme ich immer mehr ins Schwimmen...
Ich bin schon am überlegen, ob ich das Bullseye platt mache und Buster drauf mache. Ich habe fast das Gefühl, das ser2net in dieser Version irgendwie nicht mit Bullseye verträglich ist...

OberFrickler

Noch ein Update:

Ich habe jetzt einen zweiten PI3 mit dem selben Grundsystem wie den SCC-PI aufgesetzt und dort FHEM installiert so wie nur und ausschließlich die Definition der SCC eingebaut.
Dann habe ich den SCC-PI/ser2net auf die IP des FHEM-PI umgebogen und umgekehrt.
Es ist genau der selbe Effekt: Keinerlei Verbindungsaufbau möglich.

Damit kann ich das FHEM-NAS als Fehlerquelle eigentlich ausschließen. Es bleibt damit das Bullseye und/oder ser2net auf dem SCC-PI als Ursache übrig.

Ich werde also den SCC-PI mal plätten und dort ein neues Buster aufspielen. Mal sehen, was dann passiert...

LG

Wernieman

Was ich nicht verstehe:
Bekommst Du jetzt KEINE Verbindung, oder nur nach manuelkler Nacharbeit? Wenn ja, welche Nacharbeit ist nötig?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Otto123

Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

OberFrickler

#6
Zitat von: Otto123 am 06 Juni 2023, 22:58:46daran hast Du gedacht?
https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f%C3%BCr_Zusatzmodule

Jo, daran habe ich auch gedacht, brachte aber keinen Erfolg, auch nicht der Downgrade auf Buster.

Inzwischen bin ich auch weiter. Knackpunkt scheint bei Bullseye das BT- System zu sein. Ich habe vergangene Nacht noch mal ganz von vorne angefangen und jetzt scheint es zu gehen, nachdem ich den ganzen BT-Kram entsorgt habe.
Die Eintragung "dwc_otg.lpm_enable=0" in der /boot/cmdline.txt ist nicht mehr nötig, wohl aber das Entsorgen des Verweises auf ttyAMA0
In der config.txt habe ich lediglich "dtoverlay=disable-bt" eingebaut. "enable_uart=1" stand bereits nach Nutzung von raspy-config (3, I6, NO, YES) drin.
Dann noch "systemctl disable hciuart.service && systemctl disable bluealsa.service && systemctl disable bluetooth.service && apt purge bluez -y && apt autoremove -y", um den ganzen BT-Kram loszuwerden. Zur Sicherheit noch ein "systemctl stop serial-getty@ttyAMA0.service && systemctl disable serial-getty@ttyAMA0.service" hinterher und Neustart.
Anschließend fröhliches Blinken nach Freimachen des gpio17. Das habe ich dann mit in die /usr/lib/systemd/system/ser2net.service mit eingebaut nebst dem Hack von Diblominschenör.
Soweit war ich ja vorher auch schon, nur konnte ich i.d.R. nie per z.B. picocom auf die SCC zugreifen, somit wohl auch ser2net nicht. Nun aber klappt das offensichtlich erst mal... Mal sehen, wie lange...

Nachtrag:
das Freimachen des gpio17 in der ser2net.service scheint so nicht zu funktionieren.
Gibt es eine Möglichkeit, ser2net erst dann zu starten wenn...
1. das Netzwerk da ist und
2. der gpio17 frei gemacht wurde?
Da fehlen mir die Kenntnisse, wie man so was sicherstellt ^^

Im Übrigen: Auf allen SCC's ist a-culfw 1.26.01 drauf. Ist das ok oder sind die neueren Versionen empfehlenswert?

LG

PS: Das war ja ein Akt... Ich werde echt zu alt für den Scheiß ^^

Wernieman

Wie startest Du ser2net? Wenn über systemd kannst Du eine Abhänigkeit zum Netzwerk in der config einsetzen. Eine Abhängigkeit zum Abschalten von GPIO17 .. wie wird der denn bei Dir abgeschaltet?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

OberFrickler

... ja, ich starte das mit systemctl.
Und ich denke, die Sache mit dem Netzwerk ist da bereits von "Diblominschenör" (https://forum.fhem.de/index.php?msg=1199409) gelöst.

Und genau da hatte ich folgendes eingebaut:

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

Das ist ja die übliche und allseits veröffentlichte Art, den gpio zur Nutzung der SCC zu initiieren.
Das scheint aber an der Stelle keine Wirkung zu haben?!

LG

Wernieman

KannstD Du bitte mal Dein Komplettes ser2net.serviceposten? Wo hast Du das "if" eingebaut?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

OberFrickler

... bideschöön ...

[Unit]
Description=Serial port to network proxy
Documentation=man:ser2net(8)
After=network-online.target
Wants=network-online.target

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

[Service]
EnvironmentFile=-/etc/default/ser2net
ExecStart=/usr/sbin/ser2net -n -c $CONFFILE -P /run/ser2net.pid
Type=exec
Restart=always

[Install]
WantedBy=multi-user.target

Wernieman

Also so wird es definitiv nichts. Du müsstest dem if schon ein "ExecStartPre" (o.Ä. nicht genau geprüft) voranstellen, oder besser gleich in eine eine Unit-File Auslagern. Diese config ist keine Shell o.Ä. ... so dürfte sie fürs System sogar "kapput" sein, das habe ich aber jetzt nicht geprüft.

Zum Nachlesen:
https://www.freedesktop.org/software/systemd/man/systemd.unit.html
https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files
https://wiki.ubuntuusers.de/systemd/Units/
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

OberFrickler

... ahhh, ich dachte mir das schon, das es so nicht geht. Aber wenn man selbst keine Ahnung hat, dann probiert man eben erst mal herum.

Danke für die Links und die Hilfe im Allgemeinen: Da werde ich mich mal durchhangeln. Mal sehen, ob ich damit weiterkomme.

LG

OberFrickler

#13
HAH!!  ;D

[Unit]
Description=Serial port to network proxy
Documentation=man:ser2net(8)
After=network-online.target
Wants=network-online.target

[Service]
Type=exec
EnvironmentFile=-/etc/default/ser2net
ExecStartPre=bash /root/init_scc_io17.sh
ExecStart=/usr/sbin/ser2net -n -c $CONFFILE -P /run/ser2net.pid
Restart=always

[Install]
WantedBy=multi-user.target

Ich weis jetzt nicht, ob ich "bash" mit angeben muss, wenn ich von dort aus ein ShellScript ausführen möchte, aber so geht's zumindest...

Danke noch mal!

LG


UPS... Type ist doppelt... Gleich mal entsorgen... (oben bereinigt)

MadMax-FHEM

Zitat von: OberFrickler am 07 Juni 2023, 18:07:23Ich weis jetzt nicht, ob ich "bash" mit angeben muss, wenn ich von dort aus ein ShellScript ausführen möchte, aber so geht's zumindest...

Wenn in dem Script
Zitat von: OberFrickler am 07 Juni 2023, 18:07:23ExecStartPre=bash /root/init_scc_io17.sh

#!/bin/bash
o.ä. also eine Shell angegeben ist, dann sollte es auch ohne bash gehen...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)