IPS auf Raspberry PI 4 und Digitus USB / RS232

[physman]

Moin zusammen,

Ich bin absoluter Neuling in Sachen IPS und Raspberry PI - daher hoffe ich hier auf Hilfe, da ich auch bei der Suche nicht so richtig schlau geworden bin:

ich habe nun meine IPS auf einem Raspbery Pi 4 laufen.
KNX konnte ich auch erfolgreich konfigurieren und alles schalten und RM bekommen.

Zuvor auf Windows hatte ich über einen
DIGITUS USB auf Seriell Adapter - RS232 Konverter - USB 2.0 Typ-A zu DSUB 9M - FTDI FT232RL Chipsatz
meine Alarmanlage über den COM3 Port laufen.

Nun dachte ich mir ich kann diesen USB / RS232 Konverter auch einfachst in den RaspPi an den USB port stecken und es läuft.

Geht aber nicht - leider.

Es kommt der Fehler:
16.02.2022, 08:41:00 | ScriptEngine | Result for Event 57162

Fatal error: Uncaught Error: Call to undefined function COMPort_SendText() in /-:4
Stack trace:
#0 {main}
thrown in /- on line 4

ID 57162 ist ein Pollen alle 5sec auf die RS232 - gelinkt an die ID des serial ports.
Im Serial Port steht: /dev/ttyUSB0

Zuvor habe ich über: dmesg |grep „tty“ gemacht
Dabei kam:
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:1920x1080M@50 smsc95xx.macaddr=E4:5F:01:7F:1D:F0 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=tty1 root=PARTUUID=53e0f7e2-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
[ 0.000321] printk: console [tty1] enabled
[ 1.527954] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 23, base_baud = 0) is a PL011 rev2
[ 2.906098] systemd[1]: Created slice system-getty.slice.
[ 5.181947] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0

Hat jemand hier eine Idee?

[steppe]

Auf den ersten Blick schaut es für mich so aus, als ob COMPort_SendText eine PHP Funktion und keine Symcon Funktion ist.

Schau dir doch mal folgendes an:

https://www.symcon.de/service/dokumentation/modulreferenz/io/serialport/sprt-sendtext/

Vielleicht musst du nur die COMPort_SendText Funktion ersetzten.

Grüße
Stefan

[physman]

Witzigerweise lief der Befehl unter Windows.
Ist das für den Raspi anders?

[physman]

Klappt soweit erstmal - Danke!

[physman]

Hmmm - da war ich zu schnell:

Vorher habe ich Antworten in HEX bekommen:

21f1f280330111910000000000010000011911910053

Nun sind sie kürzer und variieren in Länge.

21f1f280330191191000000000000000000191

330191191000000000000000000191191001b

0191191000000000000000000191191001b

Was kann das sein?

[Nall-chan]

Nein, aber du hast damals eine alte Funktion benutzt, welche nur noch aus Kompatibilität vorhanden ist.
Diese Kompatibilität kostet Ressourcen und sind aber Werk bei dem RPi deaktiviert.
Bei Neuinstallation unter Windows sind sie wohl noch immer aktiv, auch wenn man sie eigentlich nicht mehr benötigt.

@physman

Was kann das sein?

Serielle Daten sind ja immer ein Stream und werden vom OS stückweise durchgereicht. Du musst also in deinem Script oder Cutter die Daten sammeln und wieder als Paket verarbeiten.
In den Scripten hast du dazu die Möglichkeit in der RegisterVariable Daten zwischenzuspeichern mit RegVar_Set/GetBuffer.

Michael

[physman]

Ok - klar.
Aber ich wundere mich, warum die unter Windows komplett in einem String kamen und nun „abgeschnitten“ sind?
Zumal ich mir die nicht zusammensetzten kann, da gar nicht alle Werte durchkommen.

Kann es sein, dass der „Digitus“ am USB port da nicht alles transportiert - obwohl den hatte ich ja vorher auch benutzt?
Hat der USB nicht genug power auf dem Raspi?

Wäre es auch eine Lösung, die GPIOs zu nehmen mit entsprechenden RS232 Board hukepack auf dem Raspi? Kämen dann die Strings komplett durch?

[Nall-chan]

@physman

Zumal ich mir die nicht zusammensetzten kann, da gar nicht alle Werte durchkommen.

Worauf stützt sich diese Annahme?
Hast du im Debug der IO-Instanz geschaut was rein/raus geht?
Michael

[physman]

@Nall-chan

schaut was rein/raus geht?

OOps - sorry - stimmt.
Ich habe mir nur die Skript Variable angeschaut - im Debug der RegisterVar kommt alles an - nur eben halt abgehackt.

Warum wird das denn abgehackt beim RasPi und unter Windows nicht?
Ist das Hardware bedingt die USB schnittstelle / Treiber RasPi für den Digitus?
Was kann helfen?
a) GPIO benutzten
b) oder eben das zusammensetzten - wie mache ich denn wenn dieses (bin da wirklich zu neu in IPS / PHP)?

[Nall-chan]

a) muss keine Besserung bringen
b) wäre die langfristig bessere Variante.
Entweder ganz simple einen Cutter-Instanz mit Timeout oder Länge zwischen IO Instanz und RegVar Instanz legen. Oder aber ein Script für die RegVar benutzen welches wirklich die Daten korrekt zerlegt und nicht nur den Inhalt vergleicht.
Letzteres wäre also ein Script was das Protokoll verarbeitet.
Michael

[physman]

@Nall-chan

wäre die langfristig bessere Variante.
Entweder ganz simple einen Cutter-Instanz mit Timeout oder Länge zwischen IO Instanz und RegVar

Leider haut das nicht hin:
Cutter auf Serial Port
Register Var auf Cutter

Es kommen immer noch untersch. lange Strings an, die in Summe schon den richtigen String liefern aber mal in 2 Strings mal in 3 oder gar 4 strings.

Ich habe hier das mal gelesen - muss ich den Digitus flashen?

Thermal Printer Hardware Handshake (DTR-Pin) - Deutsches Raspberry Pi Forum

[physman]

Das kann es nicht sein, da ich ja Daten bekomme…

Es schaut so aus - siehe unten DUMP im DEBUG von der Seriellen Schnittstelle - da sieht man dass die Werte total unterschiedlich lang sind.
Ein Cutter hat nicht gewirkt.

Hat hier noch jemand eine Idee?
Ist das Timing hier irgendwie falsch?
Anderer Treiber - da ja der Digitus für Windows war und jetzt am RaspPi arbeitet?
Doch an den GPIO gehen?

TXT: 16.02.2022, 14:07:15 |             TRANSMIT | <ENQ>
HEX: 16.02.2022, 14:07:15 |             TRANSMIT | 05 
TXT: 16.02.2022, 14:07:15 |             RECEIVED | <ACK>
HEX: 16.02.2022, 14:07:15 |             RECEIVED | 06 
TXT: 16.02.2022, 14:07:15 |             TRANSMIT | <STX><ETX><ETX><STX>��<NUL><RS><ETX>
HEX: 16.02.2022, 14:07:15 |             TRANSMIT | 02 03 03 02 80 9E 00 1E 03 
TXT: 16.02.2022, 14:07:15 |             RECEIVED | <ACK><ENQ>
HEX: 16.02.2022, 14:07:15 |             RECEIVED | 06 05 
TXT: 16.02.2022, 14:07:15 |             TRANSMIT | <ACK>
HEX: 16.02.2022, 14:07:15 |             TRANSMIT | 06 
TXT: 16.02.2022, 14:07:15 |             RECEIVED | <STX><US><US><STX>�3<NUL><EM><SOH><EM><SOH><NUL><NUL><NUL><NUL><NUL><NUL><NUL>
HEX: 16.02.2022, 14:07:15 |             RECEIVED | 02 1F 1F 02 80 33 00 19 01 19 01 00 00 00 00 00 00 00 
TXT: 16.02.2022, 14:07:15 |             RECEIVED | <NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><EM><SOH><EM><SOH><NUL><NUL><ESC><ETX>
HEX: 16.02.2022, 14:07:15 |             RECEIVED | 00 00 00 00 00 00 00 00 00 00 00 19 01 19 01 00 00 1B 03 
TXT: 16.02.2022, 14:07:20 |             TRANSMIT | <ENQ>
HEX: 16.02.2022, 14:07:20 |             TRANSMIT | 05 
TXT: 16.02.2022, 14:07:20 |             RECEIVED | <ACK>
HEX: 16.02.2022, 14:07:20 |             RECEIVED | 06 
TXT: 16.02.2022, 14:07:20 |             TRANSMIT | <STX><ETX><ETX><STX>��<NUL><RS><ETX>
HEX: 16.02.2022, 14:07:20 |             TRANSMIT | 02 03 03 02 80 9E 00 1E 03 
TXT: 16.02.2022, 14:07:20 |             RECEIVED | <ACK>
HEX: 16.02.2022, 14:07:20 |             RECEIVED | 06 
TXT: 16.02.2022, 14:07:20 |             RECEIVED | <ENQ>
HEX: 16.02.2022, 14:07:20 |             RECEIVED | 05 
TXT: 16.02.2022, 14:07:20 |             TRANSMIT | <ACK>
HEX: 16.02.2022, 14:07:20 |             TRANSMIT | 06 
TXT: 16.02.2022, 14:07:20 |             RECEIVED | <STX><US><US><STX>�3<NUL>
HEX: 16.02.2022, 14:07:20 |             RECEIVED | 02 1F 1F 02 80 33 00 
TXT: 16.02.2022, 14:07:20 |             RECEIVED | <EM><SOH><EM><SOH><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><EM><SOH><EM><SOH><NUL><NUL><ESC><ETX>
HEX: 16.02.2022, 14:07:20 |             RECEIVED | 19 01 19 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 01 19 01 00 00 1B 03 
TXT: 16.02.2022, 14:07:25 |             TRANSMIT | <ENQ>
HEX: 16.02.2022, 14:07:25 |             TRANSMIT | 05 
TXT: 16.02.2022, 14:07:25 |             RECEIVED | <ACK>
HEX: 16.02.2022, 14:07:25 |             RECEIVED | 06 
TXT: 16.02.2022, 14:07:25 |             TRANSMIT | <STX><ETX><ETX><STX>��<NUL><RS><ETX>
HEX: 16.02.2022, 14:07:25 |             TRANSMIT | 02 03 03 02 80 9E 00 1E 03 
TXT: 16.02.2022, 14:07:25 |             RECEIVED | <ACK>
HEX: 16.02.2022, 14:07:25 |             RECEIVED | 06 
TXT: 16.02.2022, 14:07:25 |             RECEIVED | <ENQ>
HEX: 16.02.2022, 14:07:25 |             RECEIVED | 05 
TXT: 16.02.2022, 14:07:25 |             TRANSMIT | <ACK>
HEX: 16.02.2022, 14:07:25 |             TRANSMIT | 06 
TXT: 16.02.2022, 14:07:25 |             RECEIVED | <STX><US><US><STX>�3<NUL><EM><SOH><EM><SOH><NUL><NUL><NUL>
HEX: 16.02.2022, 14:07:25 |             RECEIVED | 02 1F 1F 02 80 33 00 19 01 19 01 00 00 00 
TXT: 16.02.2022, 14:07:25 |             RECEIVED | <NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><EM><SOH><EM><SOH><NUL><NUL><ESC><ETX>
HEX: 16.02.2022, 14:07:25 |             RECEIVED | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 01 19 01 00 00 1B 03 

[steppe]

Ist der Cutter auf „Feste Schritte“ eingestellt, oder welche Einstellungen wurden gemacht?

[physman]

Ich hatte beides Probiert.
Feste Zeichen oder Feste länge.

Der Debug der seriellen Schnittstelle in IPS zeigt mir ebenfalls das oben in Beitrag 12 an.
Das das von der Seriellen Schnittstelle kommt, bringt der Cutter nichst - oder?

[physman]

Lösung ist hier:

RS232 Werte nur bei Änderung an KNX übergeben

Ich habs - es liegt an der Einstellung der seriellen Schnittstelle. Mit der min Zeichenlänge klappt es - ggf war die free floating oder so vorher. „stty -F /dev/ttyUSB0 speed 19200 cs8 -cstopb -parenb min 40“ Help: „min N mit -icanon, N Zeichen Minimum für ein vollständiges Lesen setzen“