Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

Begonnen von noansi, 09 Juni 2014, 19:16:01

Vorheriges Thema - Nächstes Thema

noansi

Hallo yersinia,

ZitatHast du eine Idee, woran das liegen könnte?
Ja.
2024.04.17 08:33:03 1: TSCUL_Parse: nanoCUL_868_2_Net Restart: C_ReadyCSM868sagt, dass Dein nano jedes mal einen Reset bekommt. Und das triggert wieder ein reopen, was ich auch nicht wieder raus nehmen will, damit seriell angebundene CULs neu initalisiert werden, wenn sie einen Reset durchlaufen.

Das passiert vermutlich beim Schließen und anschließendem Öffnen der nano Schnittstelle.
Beim nano ist die DTR Leitung via Kondensator mit dem Reset Pin des Atmel verbunden. Beim Öffnen wird da wohl ein Puls drauf gegeben. Gleiches dürfte auch für miniCUL und megaCUL gelten.
Mit
stty -F /dev/ttyUSB0 -hupclsoll man das abstellen können. /dev/ttyUSB0 wäre durch Deine Schnittstelle zu ersetzen.
Kann man wohl auch via udev rules automatisieren. Schau mal z.B. hier zum Thema https://raspberrypi.stackexchange.com/questions/9695/disable-dtr-on-ttyusb0


ZitatWenn ich raten müsste, hängt es mit den _noAnsw zusammen
richtig geraten. Register reads scheitern da.
Die Ausgabe der TSCUL logHist habe ich in CUL_HM eingebaut, damit man sehen kann, was kurz zuvor los war.

Kann daran liegen, dass es conditional burst devices sind oder einfach daran, dass zu viel "geplappert" wurde. Müsstest Du für eines der devices mal mit verbose 4 loggen nebst list vom device, wenn Registerwerte fehlen..

Gruß, Ansgar.

yersinia

Hallo noansi,

Danke für deine schnelle Antwort. :)

Zitat von: noansi am 03 Mai 2024, 23:17:56Beim nano ist die DTR Leitung via Kondensator mit dem Reset Pin des Atmel verbunden. Beim Öffnen wird da wohl ein Puls drauf gegeben. Gleiches dürfte auch für miniCUL und megaCUL gelten.
Mit
stty -F /dev/ttyUSB0 -hupclsoll man das abstellen können. /dev/ttyUSB0 wäre durch Deine Schnittstelle zu ersetzen.
Kann man wohl auch via udev rules automatisieren. Schau mal z.B. hier zum Thema https://raspberrypi.stackexchange.com/questions/9695/disable-dtr-on-ttyusb0
Danke für den Hinweis, das teste ich mal. Für ser2net könnte schon -RTSCTS und LOCAL reichen. Ich frage mich, ob ich ggf noch DTRLO und RTSLO setzen muss.
ZitatControls are: DTRHI, DTRLO Turns on and off the DTR line. RTSHI, RTSLO Turns on and off the RTS line
(https://manpages.debian.org/experimental/ser2net/ser2net.8.en.htm)

Zitat von: noansi am 03 Mai 2024, 23:17:56Kann daran liegen, dass es conditional burst devices sind oder einfach daran, dass zu viel "geplappert" wurde. Müsstest Du für eines der devices mal mit verbose 4 loggen nebst list vom device, wenn Registerwerte fehlen..
Ok, kann beides möglich sein: zu viel geplappert weil die neuen tempListen an alle RT und TCs gehen; aber auch könnten die TCs conditional burst devices sein. Bei der nächsten Umstellung (Mitte Herbst ;)) werde ich es beobachten. :)
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

noansi

Hallo yersinia,

ZitatDanke für den Hinweis, das teste ich mal.
Gib bitte feedback dazu, ob es klappt.

Ich kann nur sagen, dass ein ergänztes
, RUN+="/bin/stty -F /dev/%k -hupcl"in der betreffenden Zeile in meiner /etc/udev/rules.d/99-usb-serial.rules die Einstellung der Schnittstelle auch verändert. Abfrage mit stty liefert dann -hupcl.

ZitatFür ser2net könnte schon -RTSCTS und LOCAL reichen. Ich frage mich, ob ich ggf noch DTRLO und RTSLO setzen muss.
Scheint mir nicht das gleiche zu sein.

Gruß, Ansgar.

yersinia

Werde ich beobachten und mich dann hier wieder melden. Für den nano am pi habe ich es umgesetzt, für den via ser2net an OpenWRT angebundenen muss ich schauen, da es nicht funktioniert hat (und stty ist dort auch nicht vorhanden; muss mich erst einmal belesen, wie der Treiber kmod-usb-serial-ftdi das dort eigtl umsetzt).

Eine udev rule benötige ich nicht, da es zuverlässig über serial/by-id/ funktioniert; der OpenWRT hat nur einen USB-port ;)
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl