nanoCUL + Raspi + ser2net: disconnected nach Reboot

[DecaTec]

Hi,

ich habe hier vielleicht ein etwas spezielles Problem, hoffe aber, dass vielleicht jemand einen Tipp für mich hat.

Was ich will: Einfache IT-Steckdosen aus dem Baumarkt schalten (433MHz).

Mein FHEM-System ist eine (Ubuntu Server) VM, die auf Windows Server 2016 mittels Hyper-V läuft. Da Hyper-V nicht das Durchschleifen von USB-Geräten unterstützt, kann ich keinen USB-CUL verwenden, sondern bin auf Gateways angewiesen, die per Netzwerk erreichbar sind.

Daher habe ich nun folgende Lösung gefunden:
Ich habe mit einen nanoCUL gebastelt (siehe hier) und diesen an einen alten Raspberry Pi gehängt. Das Flashen mittels culfw ging problemlos.
Damit ich den "RaspiCUL" nun per Netzwerk in FHEM ansprechen kann, nutze ich ser2net (siehe hier). In der ser2net.conf ist folgendes definiert:

Code Auswählen Erweitern

2000:raw:0:/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9IPLJJR-if00-port0:38400$

Die Einbindung in FHEM erfolgt dann über

Code Auswählen Erweitern

define nanoCUL433 CUL <IP>:2000 0000
attr nanoCUL433 group CUL
attr nanoCUL433 icon cul_wlan
attr nanoCUL433 rfmode SlowRF

Die IT-Steckdosen kann ich nun problemlos mit diesem "Selbstbau-CUNO" schalten.

Nun aber zu meinem Problem:
Der CUL funktioniert nach einem Restart von FHEM noch problemlos, allerdings nicht, wenn ich die FHEM-Kiste komplett neu starte (sudo reboot now). Wenn FHEM dann wieder hochkommt, ist der Status des CULs "disconnected" und im Log findet man folgende Einträge:

Code Auswählen Erweitern

2017.11.08 16:11:16 3: nanoCUL433: Unknown code Port already in use, help me!
2017.11.08 16:11:16 1: 192.168.178.152:2000 disconnected, waiting to reappear (nanoCUL433)

Die Verbindung wird als anscheinend nicht korrekt freigegeben, wenn die FHEM-VM neu gestartet wird. In diesem Fall ist dann auf dem Raspi ebenfalls ein Reboot notwendig (oder zumindest ein service ser2net restart).
Ein möglicher Workaround wäre nun, eine Timeout für ser2net auf dem Raspi zu definieren (in der ser2net.conf, z.B. 60 Sekunden Timeout):

Code Auswählen Erweitern

2000:raw:60:/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9IPLJJR-if00-port0:38400$
Dann geht allerdings die Verbindung zum CUL immer nach 60 Sekunden kurzzeitig verloren und wird sofort wieder aufgebaut. Hier wird das Log dann mit folgenden Einträgen zugemüllt:

Code Auswählen Erweitern

2017.11.09 09:52:12 1: 192.168.178.152:2000 disconnected, waiting to reappear (nanoCUL433)
2017.11.09 09:52:17 3: nanoCUL433: Possible commands: ABCEeFfGhiKklMmRTtUVWXxYZz
2017.11.09 09:52:17 1: 192.168.178.152:2000 reappeared (nanoCUL433)
2017.11.09 09:52:19 1: 192.168.178.152:2000 disconnected, waiting to reappear (nanoCUL433)
2017.11.09 09:52:27 3: nanoCUL433: Possible commands: ABCEeFfGhiKklMmRTtUVWXxYZz
2017.11.09 09:52:27 1: 192.168.178.152:2000 reappeared (nanoCUL433)

Das kann also nicht die Lösung sein.
Gibt es vielleicht jemanden, der schon mal ähnliche Probleme hatte und eine bessere Lösung gefunden hat?

[DecaTec]

Hi,

da sich niemand gemeldet hat, ist das glaube ich wohl doch ein sehr spezielles Problem. 

Ich habe aber ein wenig rumgeforscht und bin nun evtl. zu einer Lösung gekommen. Vielleicht können andere damit ja was anfangen:

Das Problem habe ich immer wieder in den Griff bekommen, wenn ich nach einem Neustart der FHEM-Kiste den ser2net Service am Raspberry neu gestartet habe. Um das zu Automatisieren, waren nun einige Schritte erforderlich.
Zunächst bin ich nach dieser Anleitung  vorgegangen, um SSH-Befehle remote auf dem Raspberry ausführen zu können.
Per visudo wurden Shutdown, Reboot und Neustarten von ser2net ohne Passwort ausführbar gemacht:

Code Auswählen Erweitern


fhem ALL=NOPASSWD: /sbin/shutdown, /sbin/reboot, /usr/sbin/service ser2net restart


Danach ein Dummy-Device in FHEM anlegen, welches die Raspi-Hardware repräsentiert:

Code Auswählen Erweitern


define RaspiCul dummy
attr RaspiCul event-on-change-reading .*
attr RaspiCul event-on-update-reading .*
attr RaspiCul group CUL
attr RaspiCul icon RPi
attr RaspiCul room Technik
attr RaspiCul webCmd Reboot:Shutdown:RestartSer2net


Damit die Web-Commands "mit Leben gefüllt werden" habe ich ein paar Notifies definiert:

Code Auswählen Erweitern


# Notify für RaspiCul Reboot
define Notify.RaspiCulReboot notify RaspiCul:Reboot { system("ssh fhem\@<IP> sudo reboot now") }

# Notify für RaspiCul Shutown
define Notify.RaspiCulShutdown notify RaspiCul:Shutdown { system("ssh fhem\@<IP> sudo shutdown now") }

# Notify für RaspiCul 'service ser2net restart'
define Notify.RaspiCulServiceSer2netRestart notify RaspiCul:RestartSer2net { system("ssh fhem\@<IP> sudo service ser2net restart") }


Und damit ser2net immer dann neu gestartet wird, wenn FHEM neu geladen wird kommt noch folgendes Notify zum Einsatz:

Code Auswählen Erweitern


# Notify für Restart ser2net auf RaspiCul wenn FHEM initialisiert wurde
define Notify.FhemInit notify global:INITIALIZED set RaspiCul RestartSer2net


Damit scheint es nun erst einmal zu funktionieren. Ich werde noch etwas weiter testen, ob die Lösung auch im Alltagseinsatz überzeugt.

Edit: visudo-Code angepasst, hier hat noch ein /usr/ für den Service-Restart gefehlt.

[wdx]

Servus,

ich hatte mit einer ganz normal angeschlossen nanoCUL (V1.66) auch das Problem, dass sie nach einem Raspi Neustart nicht connected war.
Nur nach einem ein Ab- und wieder Anstecken der CUL funktionierte sie problemlos.
Nach einigem Stöbern im Netz, hab ich folgendes gefunden:

https://ai.rs/reviews/rgb-delight-raspberry-pi2-arduino-nano-ws2812b-using-hyperion-on-openelec/arduino-with-raspberry-pi-boot-detection-problem-solved/

Seither funktioniert's problemlos

Viel Erfolg!
wdx

[DecaTec]

Hi,

guter Hinweis, allerdings hatte mein Problem eine andere Ursache: Der CUL wurde ja ordnungsgemäß gefunden (also ohne aus- und wieder einstecken), nur der Port, über den ser2net läuft, war blockiert.
Aber seitdem ich die oben beschriebene Lösung eingerichtet habe, funktioniert die Sache wunderbar - auch ohne Löten. 

[Bastel-Frank]

Hi,

da sich niemand gemeldet hat, ist das glaube ich wohl doch ein sehr spezielles Problem. 

Ich habe aber ein wenig rumgeforscht und bin nun evtl. zu einer Lösung gekommen. Vielleicht können andere damit ja was anfangen:

Hallo Jan,

vielen Dank für deinen wertvollen Hinweis. Ich habe das gleiche Problem (6 CUL's an verschiedenen Raspi's), werde deinen Vorschlag umsetzen und gehe davon aus, mein Problem damit auch zu lösen. Ich habe auch beobachtet, dass man dies nur mit einem Restart von ser2net lösen kann.
Frage: Hast Du dieses Thema auch auf deiner Webseite veröffentlicht?

Viele Grüße
Frank

[DecaTec]

vielen Dank für deinen wertvollen Hinweis. Ich habe das gleiche Problem (6 CUL's an verschiedenen Raspi's), werde deinen Vorschlag umsetzen und gehe davon aus, mein Problem damit auch zu lösen. Ich habe auch beobachtet, dass man dies nur mit einem Restart von ser2net lösen kann.
Frage: Hast Du dieses Thema auch auf deiner Webseite veröffentlicht?

Ja, seitdem ich das so umgesetzt habe, hatte ich keinerlei Probleme mehr. Wird sicher also auch bei dir funktionieren.
Und nein, auf meiner Website habe ich das noch nicht - das Thema Heimautomatisierung ist sehr weitläufig und momentan kann ich für den Blog leider nicht so viel Zeit aufwenden.