SCC Busware 1101 unter Buster lite nicht mehr zu öffnen

[Sonic]

Zur Ergänzung:
nachdem ich im Forum folgendes gefunden habe:

sudo systemctl unmask serial-getty@ttyAMA0.service
sudo systemctl enable serial-getty@ttyAMA0.service
sudo systemctl start serial-getty@ttyAMA0.service

kommt nun:

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Dec  9 19:31:47 2019 from 192.168.0.11
pi@raspberrypi:~ $ systemctl status serial-getty@ttyAMA0.service
● serial-getty@ttyAMA0.service - Serial Getty on ttyAMA0
   Loaded: loaded (/lib/systemd/system/serial-getty@.service; enabled; vendor pr
   Active: active (running) since Mon 2019-12-09 19:32:23 CET; 38s ago
     Docs: man:agetty(
           man:systemd-getty-generator(
           http://0pointer.de/blog/projects/serial-console.html
Main PID: 416 (agetty)
   Memory: 140.0K
   CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyAMA0.servi
           └─416 /sbin/agetty -o -p -- \u --keep-baud 115200,38400,9600 ttyAMA0

Dec 09 19:32:23 raspberrypi systemd[1]: Started Serial Getty on ttyAMA0.
lines 1-12/12 (END)


Trotzdem immer noch keine Funktion 

[Sonic]

Hallo Rudolf

es sieht so aus.
Ich hoffe ich habe es richtig erzeugt

2019.12.09 19:58:40 4: WEB_192.168.0.11_51231 GET /fhem?XHR=1&inform=type=status;filter=;since=1575917919;fmt=JSON&fw_id=657×tamp=1575917920792; BUFLEN:0
2019.12.09 19:58:43 4: Connection closed for WEB_192.168.0.11_51231: EOF
2019.12.09 19:58:43 4: Connection accepted from WEB_192.168.0.11_51233
2019.12.09 19:58:43 4: WEB_192.168.0.11_51233 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2019-12.log; BUFLEN:0
2019.12.09 19:58:44 4: WEB_192.168.0.11_51233 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1575917922;fmt=JSON&fw_id=659×tamp=1575917924011; BUFLEN:0
2019.12.09 19:59:00 5: IP: 192.168.0.12 -> 192.168.0.12
2019.12.09 19:59:01 5: IP: 192.168.0.27 -> 192.168.0.27
2019.12.09 20:00:01 5: IP: 192.168.0.27 -> 192.168.0.27
2019.12.09 20:01:00 5: IP: 192.168.0.12 -> 192.168.0.12
2019.12.09 20:01:01 5: IP: 192.168.0.27 -> 192.168.0.27
2019.12.09 20:02:01 5: IP: 192.168.0.27 -> 192.168.0.27
2019.12.09 20:02:35 5: exec at command Initializedreset
2019.12.09 20:02:35 5: Cmd: >IF ([WZ_Fussbautom:state] eq "Initialized") (set WZ_Fussbautom on)<
2019.12.09 20:02:35 5: Cmd: >{if(ReadingValIf('WZ_Fussbautom','state','') eq "Initialized"){fhem('set WZ_Fussbautom on')}}<
2019.12.09 20:02:35 5: redefine at command Initializedreset as +*00:10:00 IF ([WZ_Fussbautom:state] eq "Initialized") (set WZ_Fussbautom on)
2019.12.09 20:02:35 5: Starting notify loop for Initializedreset, 1 event(s), first is Next: 20:12:35
2019.12.09 20:02:35 5: createNotifyHash
2019.12.09 20:02:36 5: End notify loop for Initializedreset
2019.12.09 20:03:00 5: IP: 192.168.0.12 -> 192.168.0.12
2019.12.09 20:03:01 5: IP: 192.168.0.12 -> 192.168.0.12
2019.12.09 20:03:01 5: IP: 192.168.0.27 -> 192.168.0.27
2019.12.09 20:03:01 5: IP: 192.168.0.27 -> 192.168.0.27
2019.12.09 20:03:13 4: Connection accepted from WEB_192.168.0.11_51248
2019.12.09 20:03:13 4: WEB_192.168.0.11_51248 GET /fhem; BUFLEN:0
2019.12.09 20:03:13 4: WEB: /fhem / RL:1449 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2019.12.09 20:03:13 4: Connection accepted from WEB_192.168.0.11_51249
2019.12.09 20:03:13 4: Connection accepted from WEB_192.168.0.11_51250
2019.12.09 20:03:13 4: WEB_192.168.0.11_51248 GET /fhem/pgm2/jquery-ui.min.js; BUFLEN:0
2019.12.09 20:03:13 4: WEB_192.168.0.11_51248 => 304 Not Modified
2019.12.09 20:03:13 4: WEB_192.168.0.11_51249 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2019.12.09 20:03:13 4: WEB_192.168.0.11_51249 => 304 Not Modified
2019.12.09 20:03:13 4: WEB_192.168.0.11_51250 GET /fhem/pgm2/jquery.min.js; BUFLEN:0
2019.12.09 20:03:13 4: WEB_192.168.0.11_51250 => 304 Not Modified
2019.12.09 20:03:13 4: WEB_192.168.0.11_51248 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2019.12.09 20:03:13 4: WEB_192.168.0.11_51248 => 304 Not Modified
2019.12.09 20:03:13 4: WEB_192.168.0.11_51249 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2019.12.09 20:03:13 4: WEB_192.168.0.11_51249 => 304 Not Modified
2019.12.09 20:03:13 4: WEB_192.168.0.11_51250 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2019.12.09 20:03:13 4: WEB_192.168.0.11_51250 => 304 Not Modified
2019.12.09 20:03:13 4: WEB_192.168.0.11_51248 GET /fhem?XHR=1&inform=type=status;filter=;since=1575918192;fmt=JSON&fw_id=660×tamp=1575918193510; BUFLEN:0
2019.12.09 20:03:15 4: Connection closed for WEB_192.168.0.11_51248: EOF
2019.12.09 20:03:15 4: WEB_192.168.0.11_51250 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2019-12.log; BUFLEN:0

[rudolfkoenig]

Mit "verbose 5 log" meinte ich das Initialisieren von SCC, also beim FHEM Startup, oder wenn man ein "set SCC reopen" durchfuehrt, d.h. da, wo auch die Meldung "Cannot init" erscheint.
Und bitte das "verbose 5 log" unbedingt _ohne_ diesen getty Dienst testen, sonst bestaetigt das FHEM-Log nur meine Beschreibung von heute um 11:11

[Otto123]

Hallo Klaus,

was Du in #13 gezeigt hast ist absolut in Ordnung.
Mit Deiner Aktion in #15 (was das ganze Gegenteil von dem ist was im Wiki steht) hast Du den Consolen Dienst wieder aktivert. Damit kann AM UART kein Modul richtig funktionieren. Zumindest ist das beim HMUART Modul so.

Also mach das bitte rückgängig, der Consolendienst (serial-getty) würde die Kommunikation mit der Schnittstelle verhindern/stören.

Aber ich habe keinen SCC und rede nur Theorie die ich vom HMUART Modul habe. Offenbar hat aber auch kein Anderer den SCC oder ist in der Lage zu helfen

Gruß Otto

[Sonic]

Hallo Rudi,
hier das Ergebnis:
2019.12.09 21:00:00 5: SCC sending F1b1b2038ce
2019.12.09 21:00:00 5: SW: F1b1b2038ce
2019.12.09 21:02:12 3: Setting SCC serial parameters to 38400,8,N,1
2019.12.09 21:02:12 5: SW: V
2019.12.09 21:02:15 5: SW: V
2019.12.09 21:02:18 5: SW: V
2019.12.09 21:02:21 1: Cannot init /dev/ttyAMA0, ignoring it (SCC)


Hallo Otto,
ja, du hast Recht.
ich habe es soeben rückgängig gemacht.

Danke Euch Beiden .....

[rudolfkoenig]

Das Log sagt: FHEM kann schreiben, kriegt aber keine Daten.

Entweder gibt es noch weitere Prozesse die auf diese Schnittstelle zugreifen (z.Bsp. getty war noch configuriert), oder es gibt ein Problem weiter "unten" (Treiber/Verdrahtung/Firmware/etc). Ich meine mit fuser kann man rauskriegen, welche Prozesse eine Datei geoeffnet haben.

culfw kann man auch ohne FHEM testen: man verbindet sich direkt (z.Bsp. mit "screen /dev/ttyAMA0"), und man tippt (blind) die Befehle ein: V<RETURN> sollte Versionsinfo liefern, t<RETURN> uptime, usw, siehe http://culfw.de/commandref.html

[Otto123]

Hallo Klaus,

hier gab es auch mal einen Anleitung. Vor allem die GPIO Befehle hast Du ausgeführt? Das funktioniert problemlos?
https://forum.fhem.de/index.php/topic,66670.0.html#ratethis

Gruß Otto

[Sonic]

ohh, ich gebe auf.

Bestelle mir jetzt einen CUL USB Stick von Busware.
Mal sehen ob es damit dann läuft.

Wenn es dann immer noch nicht funktioniert, liegt es wohl an Buster.

Danke jedenfalls für Eure Mühe

[Otto123]

Für welche Anwendung? Für Homematic nimm lieber was anderes ...

[Sonic]

Ich habe derzeit immer noch mu FS 20 im Einsatz.
Zu viele Aktoren die ich nicht alle austauschen möchte

[Otto123]

Ja stimmt - ich erinnere mich.

Schade tut mir leid, dass niemand einen besseren Tipp hat.

[Sonic]

Hallo Otto,
Hallo Rudi,

danke trodzdem Euch beiden.
Ich werde berichten ob es dann final mit dem USB CUL geklappt hat.

Interessant wäre zu erfahren, ob hier im Forum jemand einen Busware SCC auf Raspi mit Buster ins laufen gebracht hat.

Gruss aus dem Allgäu

[isy]

Klinke mich mal ein.

Bei  mir ist über Weihnachten ein Umzug von Raspi2 Wheezy auf Raspi4 Buster geplant.
Ich nutze ebenfalls noch einen SCC, den ich erneut einsetzen möchte.

Ich werde dann im Forum berichten.

Gruß Helmut

[Sonic]

ich bin immer noch hartnäckig auf der Fehlersuche.
SCC lässt sich nach wie vor unter Buster nicht öffnen.

Kann mir jemand sagen wie ich feststellen kann, ob FHEM auf meinem Raspberry unter dem Benuterz Pi oder Benutzer FHEM angelegt wurde.

sorry für die dumme Frage... ich weiss Newbies nerven 

Oder spielt das am Ende keine Rolle ?
Die Rechte unter @pi sollten umfänglich passen.
Unter @fehm kann ich es nicht prüfen, weil ein Passwort verlangt wird.
(Ich habe keines vergeben und verstehe das auch nicht)

[Otto123]

normalerweise läuft FHEM unter user fhem.

Code Auswählen Erweitern

ps -aux|grep fhem
Das ist aber bezüglich der Rechte auf dem SCC nicht das Problem.
fhem sollte Mitglied der Gruppe dialout sein

Code Auswählen Erweitern

groups fhem