Inbetriebnahme CCU2

[chq]

Hallo,

im Rahmen dieser Anleitung habe ich ein paar Fragen:

https://wiki.fhem.de/wiki/HMCCU#Inbetriebnahme

Im Text unter "Installation" steht Folgendes:

"Das RPC-Server Modul HMCCURPC benötigt zusätzlich die Module threads, Thread::Queue sowie Time::HiRes. Der interne RPC-Server legt für den Datenaustausch zwischen CCU2 und FHEM Dateien im Verzeichnis /tmp an. Der fhem Prozess benötigt daher Schreibrechte für dieses Verzeichnis. Das Verzeichnis kann mit dem Attribut rpcqueue geändert werden. Der mit dem Modul HMCCURPC bereitgestellte externe RPC-Server verwendet keine temporären Dateien."

In der Commandref konnte ich keine Module namens treads, Thread::Queue sowie Time::HiRes finden. Wie und wo muss man diese Module installieren?

Wie ermöglicht man es dem "fhem Prozess" (Was ist das?) Schreibrechte für /tmp zu gewähren?

Nach einem Stromausfall kann ich keine Verbindung mehr zu meiner CCU2 herstellen und zudem sind auch sämtliche Aktoren verschwunden. Habe sowohl FHEM, als auch die CCU2 bereits mehrfach neu gestartet; leider ohne Erfolg. Zuvor funktionierte die CCU2 an FHEM anstandslos.

Die o.a. Installationen hatte damals bei der Installation der CCU2 übersprungen und befürchte nun, dass dies die Ursache meiner Problem ist.

ccuflags steht bereits auf procrpc.

Den grundsätzlichen Unterschied zwischen einem int. und einem ext. RPC-Server habe ich leide auch noch nicht so wirklich verstanden. Ich möchte die CCU2 eigentlich lediglich als Sende- und Empfangsantenne nutzen, um diese vom Raspberry absetzen zu können. Sämtliche Logiken usw. sollen ausschließlich innerhalb von FHEM stattfinden. In nicht alluferner Zukunft soll jedoch zusätzliche evtl. eine Homematic-Wetterstation angebunden werden können.

Gruß Chris

[dkreutz]

threads, Thread::Queue sowie Time::HiRes.

Das sind keine Module in FHEM sondern Perl-Erweiterungen. Je nach Betriebssystem kannst Du diese über cpan oder über einen Paketmanager installieren z.B. bei Debian-Linux dpkg/apt-get.

[zap]

lass einfach ccuflags auf procrpc stehen. Dann brauchst Du weder HMCCURPC noch Threads.

Es gibt:
- den internen RPC Server (ccuflags = intrpc oder leer). Das ist der älteste. Der ist langsam und benötigt Schreibrechte auf /tmp => NICHT MEHR VERWENDEN
- den externen RPC Server 1 (ccuflags = extrpc). Der ist neuer, nutzt aber Threads, was zu Problemen mit anderen FHEM Modulen führt, die JSON verwenden. Fliegt beim nächsten Update raus. => NICHT MEHR VERWENDEN
- den externen RPC Server 2 (ccuflags = procrpc). Neu, schnell, basiert auf Subprozessen => VERWENDEN!

Die oben beschriebenen Probleme bei einem Stromausfall kommen daher:
- FHEM startet viel schneller als die CCU
- daher kann das IO DEvice HMCCU nicht definiert werden
- das führt dazu, dass alle Aktoren nicht definiert werden können
- das führt dazu, dass die Homematic Config in FHEM nicht mehr sichtbar ist. Steht aber natürlich noch in der fhem.cfg, solange man in FHEM nicht "Speichern" drückt oder Autosave eingeschaltet ist.

Also warten, bis die CCU läuft. Dann FHEM neu starten und alles sollte wieder so sein wie zuvor.

[chq]

Vielen Dank!

Das war wirklich ein ganz toller Beitrag von Dir! 

Jetzt läuft's wieder und die CCU2 hängt nun halt auch noch auf der USV- hahaha!

Gut, ich habe dadurch festgestellt, dass es sich auch aus dem Keller raus noch hervorragend in's EG funkt. 

Gruß Chris

[chq]

Sorry für's erneute posten, aber wie begegnet Ihr der Thematik des Stromausfalls?

Irgendwie dafür sorgen, dass FHEM nach einem Stromausfall jedesmal mit ca. drei bis vier Minuten verzögert einschaltet?

Wir haben aufgrund dessen, dass hier grad ein Neubaugebiet entsteht leider rel. oft Stromausfälle.

Gruß Chris

[Pfriemler]

Wir haben aufgrund dessen, dass hier grad ein Neubaugebiet entsteht leider rel. oft Stromausfälle.

Schon das wäre für mich ein Grund für eine USV...

[chq]

Die ist ja vorhanden und funktioniert auch. Mir geht es jedoch um den Workaround, wenn die halbe Stunde (in meinem Fall) überschritten wird. 

Bitte keine Diskussion darüber, wie oft das in der Realität passiert. Danke. In meinem Fall kommt es vor.

Gruß Chris

[Pfriemler]

Nich falsch verstehen: Mein aufrichtiges Beileid. Regelmäßige Stromausfälle, nur weil irgendwelche Spacken zu blöd sind, eine kontinuierliche Stromversorgung trotz Bauarbeiten zu gewährleisten, würden mich tierisch ärgern. Von der USV schriebst Du ja, die habe selbst ich, trotz gefühlt einem Ausfall in zwei Jahren.
Zur Sache: Meines Wissens habe ich schon viele Ideen (quer)gelesen, die Verzögerung zu realisieren, aber wer wenn nicht zap wüsste da am besten Abhilfe. Als Außenstehender würde ich begrüßen, wenn HMCCU beim Start von FHEM auch ohne Kontakt zur CCU zumindest den Status quo der Geräte vor dem letzten Neustart zunächst restaurieren würde und ein Update der Defs erst fährt, wenn die CCU redebereit ist. Mit dem Start von FHEM auf die CCU zu warten ist für mich derzeit das NoGo beim Umstieg auf CCU und HMCCU. 

[zap]

Ja, warten auf die CCU kommt nicht in Frage. Derzeit ist das so realisiert, dass beim Definieren der Client Devices mit HMCCUDEV oder HMCCUCHN geprüft wird, ob das angegebene Gerät oder Kanal in der CCU auch existiert. Dabei wird nicht die CCU gefragt sondern das IO Device. Dazu muss HMCCU bei der Definition des IO Device alle Geräte der CCU auslesen, und das setzt voraus, dass die CCU läuft.

Aber ich denke mal drüber nach. Man könnte ja unterscheiden, ob der Define beim Start von FHEM passiert oder interaktiv durch Anlegen eines neuen Device. Im ersten Fall könnte ich auf die Prüfung verzichten.

Den RPC Server müsste man dann deutlcih verzögert starten. Dazu muss die CCU da sein.

Bleibt noch ein Problem: ich kenne keine sichere Methode festzustellen, dass die CCU läuft und v.a. dass auch alle Prozesse laufen. Derzeit prüft HMCCU ob der Rega Port der CCU erreichbar ist. Aber selbst damit habe ich schon Überraschungen erlebt

[chq]

Wenn Du für diese Problematik eine Lösung finden solltest, wärst Du mein Held! 

Gruß Chris

[zap]

Helden werden überschätzt 🤫

Aber ich habe es mir schon mal angeschaut und sehe da durchaus Lösungswege

[Depechem]

Hallo, wegen HMIP bin ich auch gerade dabei nun meine HM-Geräte vom FHEM Raspberry auf eine externe CCU (Raspimatic) auszulagern und mit der HMCCU in FHEM einzubinden.
Dies hat soweit funktioniert.

- Nur wenn ich die CCU3 vom Stromnetz trenne (das evtl. USV nicht so lang hält wie der FHEM Raspi) bekommt FHEM keine Info das die CCU offline ist (es steht weiterhin "running/OK" drin) ! Kann ich kein Reading der CCU abfassen das mir sagt das die CCU3 nicht mehr online ist?

- Der wie hier bereits beschriebe "Neustart der CCU darf FHEM noch nicht online sein, ansonsten verbinden sie sich nicht" ist bei mir nicht der Fall. Ich habe CCU3 vom Strom getrennt, FHEM lief weiter, nach Neustart der CCU3 war in FHEM wieder alles ansprechbar. (Scheinbar passiert dies nur wenn beides Offline war!?

Ich möchte gern das ich eine Nachricht bekomme wenn die CCU3 oder FHEM nicht mehr läuft(bei FHEM habe ich es umgesetzt) daher ist es mir für die CCU3 auch wichtig

Vieleicht könnt ihr mir noch etwas Licht ins dunkle bringen.

Viele Grüße Thomas

[zap]

Die Schnittstellen Devices vom Typ HMCCURPCPROC triggern ein Event, wenn für eine konfigurierbare Zeit kein Event / Update von der CCU gekommen ist. Auf dieses Event kannst Du per Notify reagieren. Den genauen Wortlaut müsste ich nachschauen. Du findest das aber auch im Logfile.

[Depechem]

Die Schnittstellen Devices vom Typ HMCCURPCPROC triggern ein Event, wenn für eine konfigurierbare Zeit kein Event / Update von der CCU gekommen ist. Auf dieses Event kannst Du per Notify reagieren. Den genauen Wortlaut müsste ich nachschauen. Du findest das aber auch im Logfile.

Also ich habe jetzt bei der "HMCCU" und "HmIP-RF" verbose 5 gesetzt

dann habe ich die CCU herunter gefahren und 10min gewartet.
Das einzige was immer wieder im Log erscheint ist folgendes:

Code Auswählen Erweitern

2018.10.29 12:09:24.258 5: CCURPC: [d_rpcHmIP_RF] RPC server CB2010002200 accepting connection

Kannst du mir diesbezüglich bitte noch etwas weiterhelfen.

Gruß Thomas

[zap]

Mit dem Attribut rpcEventTimeout legst du die Zeit in Sekunden fest, nach der der Event getriggert wird, wenn dazwischen kein Update von der CCU kommt.

Der getriggerte Event lautet

No events from interface ... for xx seconds