Hallo,
im Rahmen dieser Anleitung habe ich ein paar Fragen:
https://wiki.fhem.de/wiki/HMCCU#Inbetriebnahme (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
Zitat von: chq am 08 August 2018, 09:19:40
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.
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.
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. :P
Gruß Chris
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
Zitat von: chq am 08 August 2018, 21:11:26
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...
Die ist ja vorhanden und funktioniert auch. Mir geht es jedoch um den Workaround, wenn die halbe Stunde (in meinem Fall) überschritten wird. :o
Bitte keine Diskussion darüber, wie oft das in der Realität passiert. Danke. In meinem Fall kommt es vor.
Gruß Chris
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.
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
Wenn Du für diese Problematik eine Lösung finden solltest, wärst Du mein Held! :D
Gruß Chris
Helden werden überschätzt 🤫
Aber ich habe es mir schon mal angeschaut und sehe da durchaus Lösungswege
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
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.
Zitat von: zap am 29 Oktober 2018, 11:46:32
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:
2018.10.29 12:09:24.258 5: CCURPC: [d_rpcHmIP_RF] RPC server CB2010002200 accepting connectionKannst du mir diesbezüglich bitte noch etwas weiterhelfen.
Gruß Thomas
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
Zitat von: zap am 29 Oktober 2018, 18:33:26
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
muss ich das attr im "d_rpcHmIP_RF" Modul oder in der "HMCCU" vornehmen?
und welches "verbose" Level muss ich einstellen um diesen Event im Log nach dem ausschalten der CCU3 zu loggen?
Also ich habe im Modul "HmIP-RF" "rpcEventTimeout 20" gesetzt
und "verbose 3"
Danach Raspimatic heruntergefahren
nun finde ich einen Eintrag im fhem.log
HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010002200 for 20 seconds
Damit kann ich jetzt einen notify setzen das die Verbindung zwischen CCU3 und FHEM verloren gegangen ist!?
Gleichzeitig könnte man doch ein set d_ccu rpcserver on somit müsste sobald die CCU wieder online ist die Verbindung wieder aufgebaut werden.
Oder ist dies eher Kontraproduktiv?
wie viele Sekunden würdes du den Timeout festlegen?
Viele Grüße Thomas
Genau, darauf kann ein notify reagieren. Es geht aber einfacher. Setze ccuflags im jeweiligen RPC device auf reconnect, dann versucht sich FHEM automatisch neu bei der CCu zu registrieren, sobalsd der event timeout auftritt
Hallöle,
Seit heut morgen bringt mir FHEM im Log minütlich immer die Nachricht das er die CCU nicht finden kann.
HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010002200 for 60 seconds
Also genau der Log den ich fürs notify nutzen sollte.
Wenn ich einen Schaltvorgang von einem HMiP Gerät vornehme wird dieser in FHEM auch abgebildet. Also kann es ja nicht daran liegen das keine Verbindung zw. CCU und FHEM besteht?
Gesendet von iPhone mit Tapatalk
Diese Meldung bedeutet nicht, dass keine Verbindung mehr zur CCU besteht. Sie besagt einfach nur, dass von der CCU in den letzten 60 Sekunden kein Update für ein HmIP Gerät gekommen ist.
Wenn du nur wenige Geräte hast und diese nicht sonderlich geschwätzig sind, kann das durchaus vorkommen.
Du musst dich auch von dem Gedanken lösen, dass HMCCU eine ständige Verbindung zur CCU hat. HMCCU baut nur in folgenden Fällen eine temporäre Verbindung zur CCU auf:
- Beim Start von FHEM, um die Geräte der CCU abzufragen
- Beim Starten und Stoppen der RPC Server für die Event Registrierung
- Bei der Ausführung von Befehlen oder Programmen
Im laufenden Betrieb ist es v.a. die CCU, die sich bei FHEM meldet, sofern Updates für Geräte vorliegen. Und genau auf diese Updates achtet HMCCU und triggert ein Event, wenn sie für die definierte Zeit ausbleiben.
Die RPC Schnittstelle der CCU bietet einen Ping Request an. Dieser erzwingt eine Antwort der CCU per Pong Event. Theoretisch könnte man das für einen regelmäßigen Keepalive Test nutzen. Leider kommt aber die Rega der CCU damit nicht klar und produziert endlose Fehlermeldungen im Log der CCU. Wenn EQ3 das mal fixed, werde ich das in HMCCU einbauen.
Ich muss nochmal nachfragen.
- FHEM läuft
- CCU3 wird neu gestartet
Nachdem die CCU wieder läuft kann man die Aktoren wieder über FHEM schalten, aber sie werden in FHEM nicht ausgewetet(also der Status ändert sich nicht) sozusagen wird bekommt FHEM es auch nicht mit wenn außerhalb von FHEM Aktoren geschalten werden.
Erst duch einen Neustart des "rpcserver" läuft wieder alles. Meine attr im Anhang. Laut meinen attr müsste doch FHEM allein mitbekommen das die CCU nicht mehr angebunden ist und des Server neu starten oder!?
In: d_ccu
attr d_ccu ccuGetVars 360
attr d_ccu ccuaggregate name:battery,filter:name=^HM_.*,read:battery,if:any=low,else:ok,prefix:battery_,coll:comment!Batterien OK;;name:voltage,filter:type=(HM-CC-RT-DN|HM-TC-IT-WM-W-EU),read:BATTERY_STATE,if:le=2.2,else:0,prefix:voltage_,coll:comment!Batteriespannung OK;;name:lock,filter:name=^HM_TF.*,read:state,if:any=open,else:closed,prefix:lock_,coll:comment!Alle Fenster/Türen geschlossen;;name:lockroof,filter:group=Dachfenster,read:state,if:any=open,else:closed,prefix:lockroof_,coll:comment!Alle Dachfenster geschlossen;;name:lockwin,filter:name=^HM_TF.*!Haustuer$,read:state,if:any=open,else:closed,prefix:lockwin_,coll:comment!Alle Fenster/Türen geschlossen;;name:hummax,filter:name=^HM_KL.*,read:HUMIDITY,if:ge=60,else:0,prefix:hummax_,coll:alias!Luftfeuchte OK;;name:unreach,filter:name=^HM_.*,read:activity,if:any=dead,else:alive,prefix:unreach_,coll:comment!Alle Devices erreichbar
attr d_ccu ccudef-readingfilter ^(LOW_?BAT|UNREACH)$
attr d_ccu ccudef-readingname ^(.+\.)?LOW_?BAT$:battery;; ^(.+\.)?UNREACH$:activity
attr d_ccu ccudef-substitute AES_KEY!(0|false):off,(1|true):on;;LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;;UNREACH!(0|false):alive,(1|true):dead;;MOTION!(0|false):noMotion,(1|true):motion;;DIRECTION!0:stop,1:up,2:down,3:undefined;;WORKING!0:false,1:true;;INHIBIT!(0|false):unlocked,(1|true):locked
attr d_ccu ccuflags procrpc
attr d_ccu cmdIcon on:general_an off:general_aus
attr d_ccu event-on-change-reading .*
attr d_ccu eventMap /rpcserver on:on/rpcserver off:off/
attr d_ccu room CCU3
attr d_ccu rpcevtimeout 600
attr d_ccu rpcinterfaces BidCos-RF,HmIP-RF
attr d_ccu rpcport 2001,2010
attr d_ccu rpcserver on
attr d_ccu stateFormat rpcstate/state
In: d_rpcHmIP_RF
attr d_rpcHmIP_RF alias CCU RPC HmIP-RF
attr d_rpcHmIP_RF ccuflags reconnect
attr d_rpcHmIP_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpcHmIP_RF room CCU3
attr d_rpcHmIP_RF rpcEventTimeout 60
attr d_rpcHmIP_RF stateFormat rpcstate/state
attr d_rpcHmIP_RF verbose 2
Liebe Grüße
Thomas
Ein Neustart der RPC Server ist nicht notwendig. Die müssen sich nur neu bei der CCU registrieren. Momentan geht das nur, indem du in den HMCCURPCPROC Devices ccuflags auf reconnect setzt.
Bin aber gerade dabei, das zu vereinfachen
Zitat von: zap am 22 Dezember 2018, 08:30:05
Ein Neustart der RPC Server ist nicht notwendig. Die müssen sich nur neu bei der CCU registrieren. Momentan geht das nur, indem du in den HMCCURPCPROC Devices ccuflags auf reconnect setzt.
Bin aber gerade dabei, das zu vereinfachen
Habe ich ja, sie meinen attr weiter oben.
Das funktioniert aber nicht?!
Oder fehlt da noch was?
Ok, wer lesen kann ...
Eigentlich müsstest Du 2 HMCCURPCPROC Devices haben. Bei beiden muss ccuflags gesetzt sein (BidCos ist immer da, weil das die Standard Schnittstelle der CCU ist).
Außerdem müssten im Logfile 60 irgendwann nach dem CCU Neustart (bei dir vermutlich nach 60 Sekunden) Timeout Meldungen erscheinen mit entsprechenden Reconnect Ankündigungen. Sind solche Meldungen vorhanden?
Zitat von: zap am 22 Dezember 2018, 13:23:00
Eigentlich müsstest Du 2 HMCCURPCPROC Devices haben. Bei beiden muss ccuflags gesetzt sein (BidCos ist immer da, weil das die Standard Schnittstelle der CCU ist
Ist bei beiden Devices aktiv
Zitat von: zap am 22 Dezember 2018, 13:23:00
Außerdem müssten im Logfile 60 irgendwann nach dem CCU Neustart (bei dir vermutlich nach 60 Sekunden) Timeout Meldungen erscheinen mit entsprechenden Reconnect Ankündigungen. Sind solche Meldungen vorhanden?
2018.12.22 16:28:55.915 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010002200 for 60 seconds
2018.12.22 16:28:55.916 2: HMCCURPCPROC: [d_rpcHmIP_RF] Reconnecting to CCU interface HmIP-RF
2018.12.22 16:28:55.918 2: HMCCURPCPROC: [d_rpcHmIP_RF] Registering callback http://192.168.2.200:7420/fh2010 of type A with ID CB2010002200 at http://192.168.2.199:2010
2018.12.22 16:28:56.077 2: CCURPC: [d_rpcHmIP_RF] CB2010002200 NewDevice received 10 device and channel specifications
2018.12.22 16:29:56.192 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010002200 for 60 seconds
2018.12.22 16:29:56.192 2: HMCCURPCPROC: [d_rpcHmIP_RF] Reconnecting to CCU interface HmIP-RF
2018.12.22 16:29:56.195 2: HMCCURPCPROC: [d_rpcHmIP_RF] Registering callback http://192.168.2.200:7420/fh2010 of type A with ID CB2010002200 at http://192.168.2.199:2010
2018.1
Grundsätzlich scheint der Reconnect ja ausgeführt zu werden ("Registering callback ..."). Seltsam nur, dass bei Dir trotzdem keine Readings in FHEM aktualisiert werden. Zumal beim Neu-Registrieren anscheinend keine Fehlermeldung kommt.
Zitat von: zap am 22 Dezember 2018, 18:19:54
Grundsätzlich scheint der Reconnect ja ausgeführt zu werden ("Registering callback ..."). Seltsam nur, dass bei Dir trotzdem keine Readings in FHEM aktualisiert werden. Zumal beim Neu-Registrieren anscheinend keine Fehlermeldung kommt.
Genau, wie könnte ich das weiter eingrenzen?
Nach der ersten Neuregistrierung kommt zumindest einmal eine NewDevice Meldung. Die Kommunikation funktioniert also. Ich nehme an, es liegt am kurzen Timeout von 60 Sekunden und den wenigen Devices (10). Die schicken einfach innerhalb von 60 Sekunden keine Events, was zum erneuten Reconnect führt.
In der nächsten Version wird das per RPC Ping gelöst, der dafür sorgt, dass regelmäßig Events geschickt werden. Bis dahin könntest Du den Timeout erhöhen, vielleicht auf 180 oder 240.