HMCCU und CCU2: Timing nach Neustart durch Stromausfall?

Begonnen von dadoc, 14 Juli 2018, 13:32:08

Vorheriges Thema - Nächstes Thema

dadoc

Hi,
Zitat von: zap am 12 Juli 2017, 16:14:38
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):
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 datapoint

Die 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
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

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.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

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
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

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.
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

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
Fhem 6.3 auf Raspberry Pi4 SSD mit Raspbian Bookworm, Homematic, Homematic IP, CCU3 mit RapberryMatic, WAGO 750-880, E3DC S10E Hauskraftwerk, E3DC Wallbox, my-PV AC ELWA-E Heizstab, Fritz!Box 7590, KIA Bluelinky

zap

#5
Zitat von: dadoc am 14 Juli 2018, 19:37:47
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.

2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

dadoc

Zitat von: zap am 15 Juli 2018, 10:55:11
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!
Zitat
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
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

zap

#7
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.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

dadoc

Du meinst, statt
fhem("sleep 10 ;; shutdown restart")\
aus Reinhards notify

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?
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

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:


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.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

dadoc

Zitat von: zap am 15 Juli 2018, 17:55:55
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:
ZitatDieses 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.
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Rewe2000

#11
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
Fhem 6.3 auf Raspberry Pi4 SSD mit Raspbian Bookworm, Homematic, Homematic IP, CCU3 mit RapberryMatic, WAGO 750-880, E3DC S10E Hauskraftwerk, E3DC Wallbox, my-PV AC ELWA-E Heizstab, Fritz!Box 7590, KIA Bluelinky

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.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB