HMCCU und CCU2: Timing nach Neustart durch Stromausfall?

[dadoc]

Hi,

Wenn FHEM vor der CCU gestartet wird und dann die HMCCU Devices nicht angelegt werden, wie folgt vorgehen:

- FHEM Config NICHT speichern
- Autosave ausschalten !!!
- FHEM stoppen
- Warten bis CCU gestartet ist (ggf. per Login in CCU WebUI prüfen)
- FHEM starten

Dann geht die Config nicht verloren. Leider hat die aktuelle CCU Firmware einen Bug. Der RPC-PING funktioniert nicht. Sobald EQ-3 das gefixt hat, werde ich mir mal ein paar Gedanken zu dem Thema machen.

Gibt es da schon eine Lösung? Ich denke, ich habe ein ähnliches Problem. Hier ist öfters Stromausfall. Wenn der Strom wiederkommt, starten Raspi mit HMCCU und die CCU2, aber die CCU23 braucht ja dramatisch länger als Raspbian/fhem. Daher findet HMCCU (zumindest in Sachen Wired? Die CCU2 scheint ja trotzdem "gefunden" zu werden, auch wen sie über ihr WebUI behauptet, noch nicht bereit zu sein) nicht das vor, was erwartet wird.
Folge (Logauszug nach Stromrückkehr):

Code: [Auswählen]

2018.07.13 13:38:03 1: Including fhem.cfg
2018.07.13 13:38:03 3: telnetPort: port 7072 opened
2018.07.13 13:38:03 3: WEB: port 8083 opened
2018.07.13 13:38:03 3: WEBphone: port 8084 opened
2018.07.13 13:38:03 3: WEBtablet: port 8085 opened
2018.07.13 13:38:03 2: eventTypes: loaded 1177 events from ./log/eventTypes.txt
2018.07.13 13:38:03 3: Opening OWL device /dev/serial/by-id/usb-Silicon_Labs_OWL_Wireless_Electricity_Monitor_USB_version_is_connected_01044FAF-if00-port0
2018.07.13 13:38:04 3: OWL device opened
2018.07.13 13:38:37 1: HMCCU: Device d_ccu. Initialized version 4.2.007
[Fri Jul 13 13:38:38 2018] fhem.pl: Use of uninitialized value within %HMCCU_RPC_FLAG in pattern match (m//) at ./FHEM/88_HMCCU.pm line 3772, <DATA> line 1.
2018.07.13 13:38:38 1: HMCCU: Read 33 devices with 386 channels from CCU 192.168.0.133
2018.07.13 13:38:38 1: HMCCU: Read 6 interfaces from CCU 192.168.0.133
2018.07.13 13:38:39 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet/:
2018.07.13 13:38:39 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2018.07.13 13:38:39 1: HMCCURPCPROC: [d_rpcBidCos_RF] Initialized version 1.0.005 for interface BidCos-RF with I/O device d_ccu
2018.07.13 13:38:39 1: HMCCURPCPROC: [d_rpcVirtualDevices] Initialized version 1.0.005 for interface VirtualDevices with I/O device d_ccu
2018.07.13 13:38:40 1: define d_rpcBidCos_Wired HMCCURPCPROC 192.168.0.133 BidCos-Wired: Can't connect to CCU 192.168.0.133 port 2000
2018.07.13 13:38:40 1: Including ./log/fhem.save
2018.07.13 13:38:40 1: configfile: Can't connect to CCU 192.168.0.133 port 2000
./log/fhem.save: Please define d_rpcBidCos_Wired first
Please define d_rpcBidCos_Wired first
Please define d_rpcBidCos_Wired first

2018.07.13 13:38:43 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2018.07.13 13:38:43 0: Featurelevel: 5.8
2018.07.13 13:38:43 0: Server started with 80 defined entities (fhem.pl:16866/2018-06-14 perl:5.024001 os:linux user:fhem pid:514)
2018.07.13 13:39:08 1: HMCCU: [d_ccu] No RPC device defined for interface BidCos-Wired
2018.07.13 13:39:08 1: HMCCU: [d_ccu] Creating new RPC device d_rpcBidCos_Wired
2018.07.13 13:39:08 1: define d_rpcBidCos_Wired HMCCURPCPROC 192.168.0.133 BidCos-Wired: Can't connect to CCU 192.168.0.133 port 2000
2018.07.13 13:39:08 1: HMCCU: [d_ccu] Definition of RPC device failed.
2018.07.13 13:39:08 1: HMCCU: [d_ccu] Can't connect to CCU 192.168.0.133 port 2000
2018.07.13 13:39:08 0: HMCCU: [d_ccu] Definition of some RPC devices failed
2018.07.13 13:53:12 1: HMCCUCHN: HM_Rel_DigitalIn_Poolcontr Invalid datapoint
2018.07.13 13:53:12 2: PowerControlDoif: set HM_Rel_DigitalIn_Poolcontr off: HMCCUCHN: HM_Rel_DigitalIn_Poolcontr Invalid datapointDie letzte Meldung (Invalid datapoint) kommt dann permanent, bis man fhem neustartet.
Was könnte man tun, um das zu verhindern? Den fhem-Raspi an ein HM-Relais hängen und erst fünf Minuten nach dem Neustart der CCU2 anwerfen?
Vielleicht gibt es ja eine unaufwändigere Lösung, etwa die HMCCU nach x Minuten per at neu starten zu lassen?
Viele Grüße
Martin

[zap]

Leider gibt es keine verlässliche Möglichkeit von FHEM aus festzustellen, ob die CCU (und insbesondere ihre Prozesse) schon gestartet ist. Das hat dann zB den Effekt, dass der Rega Port zwar erreichbar ist, die CCU aber trotzdem noch in einem undefinierten Zustand ist. Dann kommt es zu diesen Effekten (invalid datapoint usw).

Eine Lösung habe ich dafür leider bis heute nicht gefunden.

[dadoc]

Gibt es denn einen Weg, die HMCCU-Server entweder zeitversetzt (z.B. 10 min nach fhem-Neustart) zu starten oder es so einzurichten, dass - wenn invalid datapoint gemeldet wird - die Server nach x Minuten neu gestartet werden?
Wäre das einfach mit set d_ccu off ... set d_ccu on zu bewerkstelligen oder hätte das Nebenwirkungen?
Grüße
Martin

[dadoc]

Habe gerade https://forum.fhem.de/index.php/topic,77581.30.html gefunden - das werde ich mal ausprobieren.
Grüße
Martin
PS. Hier in Spanien habe ich sehr häufig Stromausfälle, nicht nur die richtigen, sondern auch die von den neuen „Intelligenten Stromzähler“ der Versorger bewusst verursachten. Die schalten Dir nämlich den Hausstrom vorübergehend hart ab, wenn Dein Momentanverbrauch die gebuchte Leistung (z.B. 5kW) übersteigt.

[Rewe2000]

Hallo Martin,

die Lösung wie von mir im Beitrag https://forum.fhem.de/index.php/topic,77581.msg762515.html#msg762515 beschrieben funktioniert (bei mir) nun schon seit Monaten problemlos.
Zumidest bis Zap mal eine Möglichkeit findet die CCU2 abzufragen, ob da tatsächlich schon alle Prozesse gestartet sind, solange wird es da nicht viele andere Möglichkeiten geben.
Dies ist zwar  von Experten gesehen keine saubere Lösung, aber sie funktioniert und löst das Problen vorübergehend 

Gruß Reinhard

[zap]

Gibt es denn einen Weg, die HMCCU-Server entweder zeitversetzt (z.B. 10 min nach fhem-Neustart) zu starten oder es so einzurichten, dass - wenn invalid datapoint gemeldet wird - die Server nach x Minuten neu gestartet werden?
Wäre das einfach mit set d_ccu off ... set d_ccu on zu bewerkstelligen oder hätte das Nebenwirkungen?
Grüße
Martin

Das Problem ist nicht der RPC Server sondern die Definition des IO Device beim FHEM Start. Zu diesem Zeitpunkt werden von der CCU alle möglichen Infos abgefragt, u.a. auch die Datenpunkte. Wenn die CCU dabei noch nicht komplett gestartet ist, liefert sie ggf. unvollständige Infos.

Die Lösung von Rewe2000 greift vermutlich nicht in jedem Fall. Man sollte vor dem Neustart des RPC Servers noch ein get devicelist ausführen, damit auch alle Geräte der CCU inklusive der Datenpunkte bekannt sind.

[dadoc]

Das Problem ist nicht der RPC Server sondern die Definition des IO Device beim FHEM Start. Zu diesem Zeitpunkt werden von der CCU alle möglichen Infos abgefragt, u.a. auch die Datenpunkte. Wenn die CCU dabei noch nicht komplett gestartet ist, liefert sie ggf. unvollständige Infos.

Capito, danke!

Die Lösung von Rewe2000 greift vermutlich nicht in jedem Fall. Man sollte vor dem Neustart des RPC Servers noch ein get devicelist ausführen, damit auch alle Geräte der CCU inklusive der Datenpunkte bekannt sind.

Mit Reinhards Lösung wird ja nicht (nur) der RCP-Server neugestartet, sondern per shutdown restart fhem komplett. Ist da ein explizites get devicelist auch noch erfordelich?
Grüße
Martin

[zap]

Nein, ist nicht notwendig, da ein Neustart und damit ein Define() explizit ein "get devicelist" macht.

Wenn man allerdings nicht die große Keule Neustart auspacken möchte, könnte auch ein "get devicelist" gefolgt von einem Neustart der RPC-Server ausreichen. Das würde dann andere FHEM Devices nicht betreffen.
Wenn Du Lust hast, kannst Du das ja mal manuell testen:

get d_ccu devicelist
set d_ccu rpcserver off
set d_ccu rpcserver on

Sofern das IO Device d_ccu heißt.

[dadoc]

Du meinst, statt

Code: [Auswählen]

fhem("sleep 10 ;; shutdown restart")\aus Reinhards notify

Code: [Auswählen]

fhem("sleep 10 ;; get d_ccu devicelist ;; set d_ccu rpcserver off ;; set d_ccu rpcserver on")\
? Denn den sleep braucht es ja so oder so, damit die ccu in die Hufe kommt?

[zap]

mm, das sleep 10 am Anfang ist zu wenig. Das Kommando muss ja sehr viel später nach dem FHEM Start ausgeführt werden. Ich glaube nicht, dass das in der Lösung von Rewe schon 10 Sekunden nach dem FHEM Start ausgeführt wird.

Ich würde das so machen:

Code: [Auswählen]

fhem("get d_ccu devicelist ;; set d_ccu rpcserver off ;; sleep 10 ;; set d_ccu rpcserver on")\

Und das wie gesagt einige Minuten nach dem FHEM Start.

[dadoc]

mm, das sleep 10 am Anfang ist zu wenig. Das Kommando muss ja sehr viel später nach dem FHEM Start ausgeführt werden. Ich glaube nicht, dass das in der Lösung von Rewe schon 10 Sekunden nach dem FHEM Start ausgeführt wird.

Ich glaube, der 10-Sekunden-Schlaf hier ist nicht die Startverzögerung. Die wird im Dummy festgelegt, s. Comment von Reinhard:

Dieses Dummy wird 15 Minuten nach einem Systemstart von Fhem über ein notify gesetzt.
In Verbindung mit diesem dummy wird die HMCCU geprüft, läuft diese aus irgend einem Grund nicht, so wird die HMCCU über ein weiteres notify neu gestartet.

Wobei hier gemeint sein dürfte, dass fhem neu gestartet wird, nicht die HMCCU.

[Rewe2000]

Hallo,

nachdem meine Funktion des Fhem Neustarts doch einige Fragen aufwirft, habe ich den Ablauf noch ein wenig besser im Beitrag https://forum.fhem.de/index.php/topic,77581.msg762515.html#msg762515 dokumentiert.

Da für mich (derzeit) Fhem ohne funktionierende CCU2 unbrauchbar ist (nahezu alle Sensoren/Aktoren hängen an CCU2), habe ich mich bewusst für ein "shutdown restart" von Fhem entschieden. Wenn für mich ein funktionierendes Fhem, auch ohne laufende CCU2, Sinn ergäbe, so würde ich nur die RPC Server neu starten (wie zap schon geschrieben hat) .

Gruß Reinhard

[zap]

Das war sowieso ein Trugschluss von mir. Der Neustart des RPC Servers genügt nicht. Es muss ein Shutdown Restart sein!

Denn: Die Devices vom Typ HMCCUDEV und HMCCUCHN können nur definiert werden, wenn HMCCU die entsprechenden Adressen der CCU kennt. Diese Adressen holt sich HMCCU bei der Definition des IO Device von der CCU.

Das bedeutet, beim Start von FHEM bzw. bei der Definition der Devices muss die CCU laufen. Selbst wenn es möglich wäre zu prüfen, ob alle Prozesse auf der CCU gestartet sind, müsste FHEM beim Start so lange warten. Das wäre für die meisten Anwender vermutlich inakzeptabel, denn der Start der CCU kann schon mal einige Minuten dauern. Wird mit der CCU3 vielleicht besser.

Also: Die von Rewe2000 erarbeitete Lösung ist momentan die einzig funktionierende.