[Gelöst/Anderer Thread]HMIP Devices verschwinden aus FHEM nach Kaltstart

[SkeeveKlah]

Hallo,
ich habe eine CCU2 am FHEM hängen, beides auf je einem eigenen Raspberry 3.
Aktuell habe ich von HMIP nur 2 Schalt/Messaktoren HMIP-PS aktiv, in den nächsten Tagen kommen 11 HMIP-BROLL Rollladenaktoren hinzu.

Aus dem Wiki habe folgenden Befehl :
get d_ccu devicelist create ^HM-KL.* t=dev f=HM_%n defattr save room=Homematic

um die beiden Aktoren nach FHEM zu holen. Das klappt mit etwas Anpassung auch super, bis auf das Setzen des Raumes, warum auch immer, das ist auch nicht ganz soooo wichtig.
Da ich derzeit noch mit dem Verlegen der Stromversorgung für die Rollladen beschäftigt bin, habe ich auch schon das eine oder andere mal die Sicherung ausknipsen müssen an der auch die beiden Raspberrys für FHEM und die CCU2 hängen.
Und jedes mal wenn die beiden Geräte nach diesem "Kaltstart" wieder hoch kommen, sind die HMIP-Devices wieder verschwunden.
Alle anderen Devices sind aber noch da, nur die HMIP-Geräte nicht.

Hat jemand eine Idee woran das liegen kann?

[gamauf]

vor dem Kaltstart im FHEM-Web ganz links oben "Save config" gedrückt?

...bis auf das Setzen des Raumes...

nach dem "OK" im Popup-Fenster zum Auswählen des Raumes auch links den "attr" Knopf drücken damit die Änderung auch unten in der "Attributes" Liste auftaucht!

[SkeeveKlah]

Ja, "save config" ist gedrückt.
Und die Raumzuweisung sollte ja auch aus der Befehlszeile kommen?!

[gamauf]

..dann weiß ich auch nicht!

[SkeeveKlah]

Ich habe jetzt mal die CCU2 per YAHM direkt mit auf dem PI von FHEM mitlaufen.
Leider immer noch das Problem, wenn der PI stromlos war, sind die HmIP Devices weg...

Im Log sieht das dann so aus:

Please define HM_HMIP_BROLL_OG_NZ first
Please define HM_HMIP_BROLL_OG_NZ first
Please define HM_HMIP_BROLL_OG_NZ first
Please define HM_HMIP_PSM_01 first
Please define HM_HMIP_PSM_01 first
Please define HM_HMIP_PSM_01 first

Hat den niemand eine Idee woran das liegen kann???

[chris1284]

Stehen die Definitionen denn in der cfg nach einem Save?

[SkeeveKlah]

Also ich denke schon, das steht am Ende, wenn ich über
Edit files -> config file -> fhem.cfg
nach schaue:

define HM_HMIP_PSM_01 HMCCUDEV 0001D709901015
attr HM_HMIP_PSM_01 IODev ccu
attr HM_HMIP_PSM_01 ccureadingfilter (STATE|CURRENT|POWER|^ENERGY_COUNTER1POWER)
attr HM_HMIP_PSM_01 controldatapoint 3.STATE
attr HM_HMIP_PSM_01 room Meiner
attr HM_HMIP_PSM_01 statedatapoint 3.STATE
attr HM_HMIP_PSM_01 statevals on:true,off:false
attr HM_HMIP_PSM_01 stripnumber 1
attr HM_HMIP_PSM_01 substitute STATE!(true|1):on,(false|0):off
attr HM_HMIP_PSM_01 webCmd control
attr HM_HMIP_PSM_01 widgetOverride control:uzsuToggle,off,on
define HM_HMIP_PSM_02 HMCCUDEV 0001D709904371
attr HM_HMIP_PSM_02 IODev ccu
attr HM_HMIP_PSM_02 ccureadingfilter (STATE|CURRENT|^ENERGY_COUNTER1POWER)
attr HM_HMIP_PSM_02 controldatapoint 3.STATE
attr HM_HMIP_PSM_02 room Meiner
attr HM_HMIP_PSM_02 statedatapoint 3.STATE
attr HM_HMIP_PSM_02 statevals on:true,off:false
attr HM_HMIP_PSM_02 stripnumber 1
attr HM_HMIP_PSM_02 substitute STATE!(true|1):on,(false|0):off
attr HM_HMIP_PSM_02 webCmd control
attr HM_HMIP_PSM_02 widgetOverride control:uzsuToggle,off,on

und so sieht das im Log dann nach einem Neustart aus:

2017.09.29 22:14:27 1: Including fhem.cfg
2017.09.29 22:14:28 2: eventTypes: loaded 327 events from ./log/eventTypes.txt
2017.09.29 22:14:29 1: sduino/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL02VIC4-if00-port0@57600
2017.09.29 22:14:29 1: sduino/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL02VIC4-if00-port0@57600
2017.09.29 22:14:45 1: HMCCU: Device ccu. Initialized version 4.1.001
2017.09.29 22:14:45 1: HMCCU: No devices read from CCU 192.168.150.101
2017.09.29 22:14:46 1: HMCCURPC: Device ccu_rpc. Initialized version 0.96 beta
2017.09.29 22:14:46 1: define HM_HMIP_PSM_01 HMCCUDEV 0001D709901015: Cannot detect IO device
2017.09.29 22:14:46 1: define HM_HMIP_PSM_02 HMCCUDEV 0001D709904371: Cannot detect IO device
2017.09.29 22:14:46 1: Including ./log/fhem.save
2017.09.29 22:14:46 1: configfile: Cannot detect IO device
Cannot detect IO device
./log/fhem.save: Please define HM_HMIP_PSM_01 first
Please define HM_HMIP_PSM_02 first

2017.09.29 22:14:46 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2017.09.29 22:14:46 2: Messages collected while initializing FHEM: configfile: Cannot detect IO device Cannot detect IO device ./log/fhem.save: Please define HM_HMIP_PSM_01 first Please define HM_HMIP_PSM_02 first
2017.09.29 22:14:46 0: Featurelevel: 5.8
2017.09.29 22:14:46 0: Server started with 65 defined entities (fhem.pl:15112/2017-09-21 perl:5.020002 os:linux user:fhem pid:1061)

[zap]

Das Problem ist die Zeile "no devices read from CCU". Wenn FHEM startet, scheint die Netzwerkverbindung zur CCU noch nicht da zu sein. Die Defines der einzelnen HMIP Devices schlagen dann fehl, weil die entsprechenden Adressen nicht bekannt sind.
Wichtig: nach dem Start mit den fehlenden Devices nicht save drücken, sonst sind die Definitionen aus der fhem.cfg weg.
Ist dein Raspi per WLAN verbunden? Oder ist auch die CCU stromlos und vielleicht noch nicht komplett gestartet?

Im Prinzip sehe ich nur die Möglichkeit: Du konfigurierst den FHEM Start per systemctl. Da kann man da Netzwerk als Abhängigkeit definieren, d.h. FHEM startet erst nach dem Netzwerk.

[SkeeveKlah]

Ich verstehe zwar nicht ganz warum die Devices "verschwinden" aber der Zusammenhang ist klar.
Ja, die echte CCU2 war deutlich langsamer beim Booten als der Raspi mit FHEM und jetzt mit der Virtualisierung ist es auch noch so.
Der FHEM ist echt mega schnell wieder einsatzbereit.

Dann müsste also die CCU zuerst starten und dann erst der FHEM... kannst du mir das mit dem systemctl noch etwas erläutern?

Ich muss aber auch noch mal auf das Kernproblem eingehen. Ist das nur ein "CCU2"-Kopplungs Problem? Oder verschwinden alle "aktiven" Devices die bei einem FHEM Start nicht erreichbar sind direkt wieder aus dem FHEM? Da kann es ja diverse Gründe für geben..., evtl. sogar gewollte.

[zap]

Die Devices verschwinden nicht. Wenn die einmal in der CCU angelernt wurden, bleiben sie bekannt. Sollte ein Device mal aus sein (Batterie leer oder sowas), ändert sich nur der Status in der CCU auf unreachable, das Device bleibt aber bis zum gewollten Ablernen in der CCU bekannt.

Beim Start von FHEM passiert nun folgendes, sofern die CCU bzw. der CCU Service nicht schon gestartet sind:

Zunächst wird das IO Device mit HMCCU definiert. Das klappt, auch wenn die CCU nicht da ist. Dabei fragt HMCCU aber auch bei der CCU sämtliche dort registrierten Geräte ab. Da die CCU aber noch nicht läuft, erhält HMCCU kein einziges Gerät.

Nun werden mit HMCCUDEV oder HMCCUCHN die Devices in FHEM definiert. Dabei wird für jedes Device beim IO Device nachgefragt, ob das bekannt ist. Nur wenn vom IO Device eine positive Meldung kommt, wird das Device auch tatsächlich angelegt. Kann aber nicht gehen, da in Schritt 1 das IO Device keine Geräte von der CCU erhalten hat.

Lange Rede kurzer Sinn: die CCU bzw die CCU Services müssen vor FHEM gestartet werden. Dazu solltest Du Dich mit den verschiedenen Startmöglichkeiten vertraut machen, die Linux bietet: systemctl, initd usw. Ich meine, im FHEM Wiki gibt es dazu Infos. Eine Einführung an dieser Stelle würde definitiv zu weit gehen und wäre auch off topic.

[chris1284]

habe leider nicht im post 1 rausgelesen das du eine occu auf dem selben pi wie fhem fährst sonst hätte ich dir sagen können dass das normal ist.
leider bringt es nicht zu warten bis zb netzwerk da ist oder ide ccu per zb ping erreichabr ist. die stehe nach dem start immer noch ein paar sekunden im  "ccu ist noch nicht bereit screen.

ich für mich weiss das die YAHM-ccu auf dem garten pi erst nach fhem erreichabr ist und starte dann fhem einfach nach ca.1-2 minute neu (shutdown restart). diese will ich noch in ein notify / doif einbauen das auf global:INITIALIZED triggered.
im notify einfach prüfen ob ein hmccudev defined ist (wenn nicht -> fhem zu schnell, fhem neustart).
das wäre sinnvoller weil man ja auch mal fhem neu startet ohne yahm/die occu neuzustarten, somit wäre die ja bereits erreichbar und ein neustart von fhem nicht notwendig

[zap]

Das mit dem Restart kann man natürlich machen. Allerdings halte ich es nach wie vor für die beste Lösung, die Startscripts von FHEM und CCU anzupassen. So könnte man z.B. das Startscript der CCU in das von FHEM (/etc/init.d/fhem) integrieren und so die Startreihenfolge beeinflussen.

Wichtig: in den einzelnen Start-Verzeichnissen /etc/rc?.d müssen dann die Softlinks auf /etc/init.d/ccu (Namen ist Vermutung) entfernt werden.

[SkeeveKlah]

Ich habe schon mit den Service Units gespielt.
FHEM after lxc
Leider startet FHEM dann gar nicht mehr alleine.
Ich muss aber auch zugeben dass das mit YAHM/lxc nicht so 100% durchsichtig ist für mich.
Evtl. muss ich für FHEM auf einen anderen Dienst als den lxc.service schauen.
Aber den Weg halte ich auch für gut.

[chris1284]

Allerdings halte ich es nach wie vor für die beste Lösung, die Startscripts von FHEM und CCU anzupassen. So könnte man z.B. das Startscript der CCU in das von FHEM (/etc/init.d/fhem) integrieren und so die Startreihenfolge beeinflussen.

zu einfach gedacht meine ich. klar kann man die occu vor fhem so starten. heisst aber nicht das sie auch schon bereit ist eine verbindung von fhem entgegen zu nehmen wenn fhem dann gestartet ist.
wie willst du den prüfen ob die ccu schon "aufnahme bereit" ist? nur weil der container gestartet ist sagt das nichts über den ccu zustand

[SkeeveKlah]

Ja, genau an dem Punkt hing ich auch schon... FHEM ist auch verdammt schnell einsatzbereit, die CCU braucht da schon deutlich länger.
Gefühlt würde ich sagen schafft FHEM 10 Neustarts oder sogar mehr bis die CCU so weit ist. Egal ob die virtuelle oder auf einem eigenen Raspi.

Aber mit den Diensten habe ich es bis jetzt auch nur geschafft FHEM gar nicht zu starten 
Ich tu mich super schwer mit dem Mix der verschiedenen "Systeme" ... systemd und init.d... YAHM/lxc und FHEM setzen da wohl auf verschiedenes...
Wenn ich richtig verstanden habe, wird FHEM noch auf die "alte" Art behandelt.
Ist da evtl. in naher Zukunft mit einer Änderung zu rechnen?