Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

[gelöst] nanoCUL über WLAN immer initialized

Begonnen von frober, 11 Mai 2020, 07:12:12

Vorheriges Thema - Nächstes Thema

frober

Hallo,
ich habe meinen nanaCUL von USB auf einen Pro Mini umgestellt, der an einem LaCrosseGateway (LGW) hängt. Dort wird die serielle Schnittstelle durchgereicht und ist an einem IP-Port verfügbar.

Das funktioniert soweit wunderbar.

Nun habe ich festgestellt, dass wenn der LGW abgeschaltet ist, der nanoCUL weiterhin auf initialized bleibt.

Gestern hat der CUL nicht mehr reagiert, nach einem reopen war wieder alles ok.
Das Problem ist, dass er auch hier auf initialized bleibt.
Am USB war er in solch einem Fall nur opened und ich habe mit einem notify ein reopen ausgelöst.
Wenn sich der Status aber nicht ändert fällt diese Möglichkeit aus.

Kann man das Problem mit dem Status irgendwie beheben, bzw. wir kann ich die Funktion des nanoCUL's sonst überprüfen?

Danke und Gruß
Bernd
Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

yersinia

DAS würde mich auch interessieren, ich habe ein ähnliches Problem mit meinen nanoCULs (a-culfw) - wenn diese sich aufhängen (kommt vor, allerdings selten), bekommt FHEM das nicht mit; erst recht nicht die VCCU. Der Status bleibt dann auch lange auf Initialized. Einer ist via ser2net über LAN verbunden, der andere direkt am USB Port des RasPis.
Was allerdings funktioniert ist den nanoCUL zu pollen via zB get <nanoCUL> uptime, ist dieser nicht erreichbar, dann meldet dieser auch nichts zurück ("-"). Wie man darauf mit einem Notify, at oder DOIF reagieren könnte - keine Ahnung. :-\ Ein regelmässiges Pollen wäre wahrscheinlich auch nicht förderlich (Systemlast?) - und selbst wenn dies ginge, wie werte ich via notify, at oder DOIF das Ergebnis aus?
Bisher nutze ich ein DOIF um ein Disconnect zu erkennen, das funktioniert auch soweit gut - außer der nanoCUL hängt sich auf, das bekommt FHEM nicht mit.
(["^nanoCUL_:DISCONNECTED"] or
["^nanoCUL_:OPENED"] or
["^nanoCUL_:disconnected"] or
["^nanoCUL_:opened"])
(set $DEVICE reopen)
DOELSE ()

(alle meine nanoCULs heißen auch nanoCUL*.)
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

rudolfkoenig

ZitatWas allerdings funktioniert ist den nanoCUL zu pollen via zB get <nanoCUL> uptime, ist dieser nicht erreichbar, dann meldet dieser auch nichts zurück ("-"). Wie man darauf mit einem Notify, at oder DOIF reagieren könnte - keine Ahnung.
Mit einem watchdog?

frober

Zitat von: rudolfkoenig am 11 Mai 2020, 09:44:44
Mit einem watchdog?
Wäre es nicht möglich das Modul 09_CUL.pm anzupassen, das es auch bei Netzwerkanbindung so reagiert, als ob es am USB angeschlossen wäre. -> opened/disconnect

Leider habe ich dazu zu  wenig Perl-Kentnisse...

Watchdog ist auch ne Idee, ich hatte an readingswatcher gedacht. Da der nanoCUL aber keine Veränderung zeigt, muss jeweils auf das Nichtsenden eines Devices getriggert werden.
Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

rudolfkoenig

ZitatWäre es nicht möglich das Modul 09_CUL.pm anzupassen, das es auch bei Netzwerkanbindung so reagiert, als ob es am USB angeschlossen wäre. -> opened/disconnect
Diese Funktionalitaet ist nicht im Modul (09_CUL.pm kenne ich nicht, nur 00_CUL.pm) implementiert, sondern im OS (fuer Netzwerkfehler) bzw. im ser2net/etc, was zum Konvertieren der Schnittstelle (USB=>TCP) verwendet wird.
Mir waellt nur die periodische Abfrage ein ("get uptime" + watchdog im Modul nachimplementieren), es betrifft aber meines Wissens wenig Benutzer, und ist in manchen Konstellationen (wie RFR) problematisch.

ZitatLeider habe ich dazu zu  wenig Perl-Kentnisse...
Das kann man aneignen, dafuer ist nie zu spaet.

frober

Zitat von: rudolfkoenig am 11 Mai 2020, 10:30:09
(09_CUL.pm kenne ich nicht, nur 00_CUL.pm)

09_CUL.pm sorry Tippfehler [emoji16]

Zitat von: rudolfkoenig am 11 Mai 2020, 10:30:09
Mir waellt nur die periodische Abfrage ein ("get uptime" + watchdog im Modul nachimplementieren), es betrifft aber meines Wissens wenig Benutzer, und ist in manchen Konstellationen (wie RFR) problematisch.

OK, danke dafür werde einen watchdog nutzen.


Zitat
Das kann man aneignen, dafuer ist nie zu spaet.

Ich bemühe mich, meine erste eigene myUtils sub habe ich schon hinter mir...[emoji6]
Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...