FHEM Forum

FHEM - Hausautomations-Systeme => Homematic => Thema gestartet von: Rewe2000 am 05 Oktober 2017, 18:44:40

Titel: Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 05 Oktober 2017, 18:44:40
Hallo,

ich habe nun eine CCU2 und Fhem auf Raspi ca. 6 Monate in Betrieb. Im Großen und Ganzen läuft alles sehr stabil und Zufriedenstellend (Dank der Erklärungen in den vielen Beiträgen und Foren). Nun habe ich aber noch einige Schwachstellen erkannt, welche ich nun noch angehen muss.

Wie bekommt Ihr Fhem, im Zusammenspiel mit einer CCU2, nach einem Stromausfall wieder zum laufen?

Problem:
Die CCU2 benötigt mehrere Minuten bis diese wieder Betriebsbereit ist, in dieser Zeit läuft Fhem längst wieder auf den Raspi, hat jedoch keinerlei Geräte und Readings, da die CCU2 beim Start noch nicht bereit war. Nach einen manuellen, zusätzlichen "shutdown restart" kann über Fhem wieder alles bedient werden.

Wie ist aber der korrekte Ablauf wenn niemand zu Hause ist (Urlaub etc.) Gibt es die Möglichkeit Fhem verzögert zu starten oder nach ca. 5 Minuten nach Stromausfall automatisiert ein "shutdown restart" auszuführen?

Wie habt Ihr dieses Problem bei euch gelöst?
Ich denke hier besonders an Lösungen ohne USV.

Danke für die zahlreichen Tipps und Antworten.

Gruß Reinhard

Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 05 Oktober 2017, 19:44:29
ich sehe zwei Möglichkeiten:

1. HMCCU wartet beim Define des IO Devices so lange bzw. eine zu definierende Zeit auf die CCU. Damit wird der Start von FHEM dann entsprechend lange blockiert.

2. ich stelle ein Script zur Verfügung, das in das FHEM Startscipt eingebunden werden kann und prüft, ob die CCU da ist

Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: connormcl am 05 Oktober 2017, 20:49:30
Zitat von: Rewe2000 am 05 Oktober 2017, 18:44:40
Gibt es die Möglichkeit Fhem verzögert zu starten oder nach ca. 5 Minuten nach Stromausfall automatisiert ein "shutdown restart" auszuführen?

Wie habt Ihr dieses Problem bei euch gelöst?
Ich denke hier besonders an Lösungen ohne USV.


Bin mir nicht ganz sicher, wie Fhem ohne USV 5 Minuten nach Stromausfall einen Restart machen soll und wozu...der Pi ist dann einfach aus...

Ausserdem geht das Filesystem der SD-Speicherkarte bei Stromverlust korrupt...im Gegensatz zum Desktop hilft hier wohl auch kein Journaling oder ähnliches...zumindest bei mir erholen sich die Filesystem auf SD-Karte nicht vom Stromausfall und müssen ausgeworfen und in einem anderen Rechner manuell fsck'ed werden, bis wieder alles in Ordnung ist...der Pi kann das selber nicht reparieren, er bootet ja davon....(mach mal ein "dmesg | grep unchecked", ob bei dir auch schon alles hinüber ist und fsck'ed werden sollte...)

Ausserdem wären dann noch so Dinge wie Alarmfunktionen/Alarmanlage und Internetausfall zu berücksichtigen...ich weiss noch nicht, ob das Internet/DSL hier noch einen Notstromaggregat hat und bei Stromausfall funktioniert...aber Hausseitig ist hier alles mit USVs abgepuffert, da auch Dinge wie Funk-Türklingel betroffen wären...

Der Einbrecher erzeugt sonst einfach einen Kurzschluss auf deinem Gelände und bei ungünstiger Verkabelung fällt im Keller alles aus inkl. Automatisierungsserver...da will ich noch eine Nachricht bekommen, nachdem das passiert ist...und sei es über einen zweit-Kanal wie SMS...
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 05 Oktober 2017, 21:02:01
Hallo zap,

genau das ist auch meine Beobachtung, es ist echt ein Zeitproblem, Fhem ist auf dem Raspi einfach zu schnell  :).
Ich hatte gestern wegen Problemen einen Neustart der CCU2 durchgeführt und vergessen Fhem neu zu starten. Da sind zwar dann noch alle Geräte vorhanden, aber die Kommunikation steht so lange bis ein shutdown restart von Fhem durchgeführt wird.

Für mich als Linux Neuling und Fhem Beginner ist das nicht so einfach zu lösen, ich bräuchte da schon noch ein wenig Unterstützung.
Gerne auch Tipps, wo ich mir das fehlende Wissen anlesen kann, oder noch besser einige Beispiele.

Ich denke aber hier sollte es schon bei irgend jemanden eine Lösung geben, denn CCU2 in Verbindung mit Raspi und Fhem ist doch eigentlich nicht so selten oder täusche ich mich da etwa?

Gruß Reinhard
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 05 Oktober 2017, 21:25:10
Hallo connormcl,

es ist unbestritten, dass die USV hier die beste Absicherung bietet. Irgendwann werde ich mein System auch auf USV umstellen.

Derzeit suche ich aber "nur" nach einer Lösung, damit meine Homematic (IP) Geräte, nach der Spannungswiderkehr überhaupt wieder mit Fhem sprechen. Bisher war ich immer bei einem Stromausfall zu Hause und konnte Fhem neu starten, aber irgend wann wird dies nicht mehr der Fall sein.

Irgendwie muss mein Filesystem vom Raspi da deutlich stabiler sein, es hat sicherlich schon mehr als 20 Spannungsausfälle ohne Probleme verkraftet. Ich werde zukünftig bei geplanten Abschaltungen zumindes meine Geräte CCU2 und Raspi vorher beenden.

Danke für den Tipp, ich will ja da nichts mutwillig riskieren.

Bitte aber hier keine Diskussion über pro und contra USV führen, ich brauche eine Lösung für mich ohne USV.
Es ist mir absolut bewusst, jede Softwareseitige Lösung ersetzt keine USV.

Gruß Reinhard
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Dragonfly am 06 Oktober 2017, 04:20:43
Zitat von: Rewe2000 am 05 Oktober 2017, 21:02:01
Ich hatte gestern wegen Problemen einen Neustart der CCU2 durchgeführt und vergessen Fhem neu zu starten

Dann bringt ja eine USV auch nicht viel...

In der CCU ein Programm anlegen, welches nach Neustart dieser einen HTTP-GET Befehl an FHEM schickt, daß jener neu starten soll.
Verzögert um 5 Minuten, damit die CCU genug Zeit hat, sich vom Reboot zu erholen und nicht gleich von FHEM überfordert wird.

Script in der CCU:
string stdout;
string stderr;
string url="http://192.168.1.100:80/weiss_nicht_wie";
system.Exec("wget -q -O /dev/null " # url, &stdout, &stderr);

Ohne "wenn"-Bedingung;
"dann Script verzögert um 5 Minuten"
"http://192.168.1.100:80/weiss_nicht_wie" gegen die URL austauschen, die FHEM zu einem shutdown/restart bewegt.

LG
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 06 Oktober 2017, 08:09:13
@Dragonfly: dann kann man auch gleich Netcat auf der CCU installieren und per CCU Programm ein "shutdown restart" an FHEM schicken. btw: shutdown restart funktioniert nicht, wenn FHEM über systemctl gestartet wird. Besser wäre m.E. ein Restart von FHEM per remote SSH Befehl, also so:

ssh -i mykey root@myfhem /etc/init.d/fhem restart

Zu beachten: es muss ein key ohne Passphrase verwendet werden.

@Rewe2000: wenn man nur die CCU neu startet, ist das nicht mit einem Stromausfall vergleichbar. Die CCU vergisst bei einem Neustart die registrierten Event-Empfänger. Daher muss sich FHEM neu bei der CCU registrieren. Dafür genügt ein Neustart des RPC-Servers. HMCCU generiert ein Event, wenn für eine bestimmte Zeit keine Updates von der CCU kommen. Auf dieses Event kann man per Notify mit einem Neustart des RPC Servers reagieren.


Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 06 Oktober 2017, 22:27:53
Hallo,

zunächst mal vielen Dank für eure Tipps zu meinem Problem.

@Dragonfly: Ich denke wenn ich mein Script in der CCU2 so anpasse wie du es vorgeschlagen hast und es im Fenster "Script testen" ausführe, sollte Fhem doch sofort neu gestartet werden.
Richtig oder falsch?
Bei mir tut sich da absolut nichts (habe einen WEB-Zugang extra ohne SSL und ohne Kennwort angelegt). Verwende ich aber im Script HTTP und spreche auf Fhem einen Port mit HTTPS an, erscheint im Log eine SSL Fehlermeldung mit der IP der CCU2. Grundsätzlich scheint Fhem schon erreicht zu werden, aber anscheinend wirkt der restart Befehl nicht.

@zap: Hab eben schon gesucht, finde aber wirklich nichts brauchbares dazu.
ZitatHMCCU generiert ein Event, wenn für eine bestimmte Zeit keine Updates von der CCU kommen.
Meinst du hier das Reading "rpcstate", welches ich hier für das Notify verwenden kann?
ZitatAuf dieses Event kann man per Notify mit einem Neustart des RPC Servers reagieren.
Auch hier noch eine Verständnisfrage:
Ich habe nur die beiden Befehle set d_ccu rpcserver on und set d_ccu rpcserver off gefunden.
Gibt es da noch eine andere Möglichkeit, den RPC-Server mit einem anderen Befehl neu zu starten?

Die Möglichkeit Fhem über SSH zu starten teste ich derzeit, wird aber heute sicher nichts mehr werden.
Ich möchte mich da noch ein wenig in den Foren und im Wiki einlesen, bevor ich euch da mit weiteren dazu Fragen nerve.

Bin noch am suchen, wie bei mir Fhem überhaupt auf dem Raspi automatisch gestartet wird. Nachdem die Lösung von Dragonfly bei mir vermutlich nicht funktioniert, denke ich bei mir wird Fhem über systemctl gestartet. Hab schon mal gesucht, aber leider nichts hierzu in Linux bei mir gefunden. Gib mir mal bitte einen Tipp wo ich das nachsehen kann.
Ist es überhaupt möglich in einem beliebigen Browser, Fhem nur durch Angabe einer URL mit Anhang neu zu starten??

Nehmt mir meine "blöden" Fragen bitte nicht Übel, aber ich komme noch aus der Zeit mit Wählscheibentelefonen und Commodore C64 Computern  :-[

Ich hoffe ihr verliert nicht die Geduld mit mir.
Gruß Reinhard
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Dragonfly am 07 Oktober 2017, 02:15:32
Zitat von: Rewe2000 am 06 Oktober 2017, 22:27:53
Ich denke wenn ich mein Script in der CCU2 so anpasse wie du es vorgeschlagen hast und es im Fenster "Script testen" ausführe, sollte Fhem doch sofort neu gestartet werden.
Richtig oder falsch?
Irgendwie beides... Richtig, wenn die Url korrekt formatiert ist (encoden).
Was du zusammen bekommen mußt, ist eine URL, die, wenn du sie im Browser aufrufst, FHEM neu startet.
Die postest du hier und dann helfe ich dir gerne auf der CCU-Seite weiter.

Oder es ist das Problem was zap geschildert hat:
Zitatbtw: shutdown restart funktioniert nicht, wenn FHEM über systemctl gestartet wird.

FHEM habe ich nicht mehr am laufen - bin jetzt auf openHAB (da habe ich das (für mich) richtige Verhältinis von Luxus/Handarbeit  :D ).
Aber ich kann mir nicht vorstellen, daß du der erste bist, der sowas machen will - eine Lösung wird sich sicher finden.
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 07 Oktober 2017, 18:48:20
Zitat von: Dragonfly am 07 Oktober 2017, 02:15:32
FHEM habe ich nicht mehr am laufen - bin jetzt auf openHAB (da habe ich das (für mich) richtige Verhältinis von Luxus/Handarbeit  :D ).

Ich liebäugle auch mit OpenHAB. Da ist die Entwicklung rasant. Oder vielleicht IO-Broker. Allerdings hat OpenHAB eine sehr große und v.a. internationale Community (und der Hauptentwickler ist ein Arbeitskollege ;-).


Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Dragonfly am 08 Oktober 2017, 00:42:29
<OT>
Zitat von: zap am 07 Oktober 2017, 18:48:20der Hauptentwickler ist ein Arbeitskollege
Dann kannst ja gleich einen Aufstand machen, weil OH keine HTTP-GET empfangen kann!
Jetzt hätte ich HW, die ihre Stati weitergeben kann, und dann muß ich noch den Umweg über die CCU nehmen! Wie altmodisch  ::)
</OT>
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 08 Oktober 2017, 12:05:35
Habt ihr nicht noch einige Tipps für mich?
Ich drehe mich ständig im Kreis und nichts klappt und ich finde auch nicht die richtigen Ansätze um meim Problem zu lösen.

In vielen Forenbeiträgen lese ich, dass Fhem auch über URL-Befehle gesteuert werden kann, mir gelingt es aber nur über den Befehl im Browser (Firefox unter WIN7) die WEB - Oberfläche in Fhem zu öffnen, mit "Befehlen" tut sich da überhaupt nichts.
Eigentlich sollte doch der Link:

http://192.168.1.33:8085/fhem?cmd=set%20Lampe%20on&XHR=1

oder

http://192.168.1.33:8085/fhem?cmd=set Lampe on&XHR=1


einen vorhandenen Dummy schalten, bei mir tut sich da absolut nichts, auch im Log von Fhem taucht kein Eintrag auf.

Hab extra für Port 8085 HTTPS und Kennwortanmeldung deaktiviert.

Muss ich da in Fhem oder im Raspi vorher noch etwas istallieren, damit das steuern über URL klappt.

Elegant wäre natürlich die von Dragonfly beschriebene Lösung schon, 5 Minuten nach Start der CCU2, von dieser über Http Befehl Fhem neu zu starten. Ob sich dann über URL überhaupt ein Neustart auslösen lässt (Anmerkung von zap) muss ich dann noch testen. Aber wenn nichtmal das steuern eines Dummys klappt, hab ich da noch einen weiten Weg vor mir.

Gruß Reinhard
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Dragonfly am 08 Oktober 2017, 13:55:03
Kämpf dich mal da durch: https://forum.fhem.de/index.php?topic=70764.0
Ich glaub, du musst noch was freigeben...
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 08 Oktober 2017, 16:36:31
Ich habe gerade ein Update für HMCCU in der Mache. Da kann man beim Define des IO Device einen Timeout angeben. HMCCU wartet dann die angegebene Zeit ab und prüft alle paar Sekunden, ob die CCU erreichbar ist. So lange wird der Start von FHEM angehalten.

Beispiel: define d_ccu HMCCU meineccu waitforccu=180

Damit würde HMCCU 3 Minuten auf die CCU warten.
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 09 Oktober 2017, 18:17:40
Hallo zap,

vielen Dank für deine Mühe, ich denke die von dir geplante Änderung macht die Kommunikation mit der CCU um einiges sicherer und die Lösung des Problems erfolgt im Modul sebst.
ZitatSo lange wird der Start von FHEM angehalten.
Hab ich mich da verlesen oder willst du wirklich wirklich Fhem komplett anhalten wenn die Kommunikation HMCCU <-> CCUx steht?
Oder meintest du den Start von HMCCU.

Wie würde HMCCU reagieren wenn z.B. die CCUx neu gestartet wird und HMCCU im laufenden Betrieb für ca. 3 Minuten die Kommunikation verliert. Wenn du diesen Umstand nicht abfangen kannst, gibt es irgend ein Reading was dies erkennen kann?
rpcstate und rpc zeigen ja bei laufender Kommunikation immer running/OK an, obwohl nach einem neustart der CCUx, die Kommunikation ohne neustart von RPC-Server oder Fhem nicht mehr funktioniert.

Gerne teste ich mal eine Betaversion der geänderten HMCCU bei mir im System wenn du mit der Änderung so weit bist.
Bitte bei Bedarf einfach melden.

Vielen Dank Reinhard

@Dragonfly: Auch dir vielen Dank für den Link, werde mich mal heute Abend damit mal ein wenig weiterbilden. :)
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 09 Oktober 2017, 18:42:45
Zitat von: Rewe2000 am 09 Oktober 2017, 18:17:40
Hab ich mich da verlesen oder willst du wirklich wirklich Fhem komplett anhalten wenn die Kommunikation HMCCU <-> CCUx steht?
Oder meintest du den Start von HMCCU.

Der Start von FHEM wird angehalten. Wenn es erst mal läuft und die CCU ausfällt, passiert gar nichts.

Zitat
Wie würde HMCCU reagieren wenn z.B. die CCUx neu gestartet wird und HMCCU im laufenden Betrieb für ca. 3 Minuten die Kommunikation verliert. Wenn du diesen Umstand nicht abfangen kannst, gibt es irgend ein Reading was dies erkennen kann?

In diesem Fall generiert HMCCU ein Event:

"No events from CCU since nnn seconds"

Das kannst Du per Notify abfangen und ggf. den RPC Server (verzögert) neu starten. Wenn Du den externen RPC-Server HMCCURPC nutzt, kannst Du beim Attribut ccuflags reconnect auswählen. Dann registriert sich der Server automatisch neu bei der CCU.


Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 11 Oktober 2017, 17:50:54
Ich habe gerade Updates für 88_HMCCU (4.1.002) und 88_HMCCURPC eingecheckt. Sollte morgen per FHEM update verfügbar sein.

Der define Befehl wurde um den Parameter waitforccu ergänzt. Damit kann man festlegen, wie lange FHEM beim Starten warten soll, bis die CCU2 verfügbar ist. Per Default wird nicht gewartet. Wenn die CCU2 als Software Service auf dem gleichen Raspi läuft, sollte man die Definition des IO Device wie folgt abändern:

define d_ccu HMCCU ip-address/hostname waitforccu=180

Damit wird maximal 3 Minuten auf die CCU gewartet. Wenn das nicht reicht, den Wert in 60 Sekunden Schritten erhöhen. Achtung! Der FHEM Start wird so lange angehalten.

Im I/O Device gibt es ein neues Internal "ccustate". Dieses Internal stellt den Status der CCU2 dar und kann folgende Werte annehmen:

active - CCU läuft und schickt Events
unreachable - CCU ist nicht erreichbar
timeout - CCU hat seit x Sekunden (wie festgelegt mit Attribut rpcevtimeout) keine Events mehr geschickt.

Bitte mal testen. Habe keine CCU auf dem Raspi, daher im Blindflug entwickelt.
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 11 Oktober 2017, 21:09:36
Hallo Zap,

das ging ja Blitzschnell.

Leider bin ich bis Sonntag zeitweise nicht zu Hause, werde das geänderte Modul sofort testen, wenn ich ein wenig "Luft" hab.
Vor dem Test möchte ich noch ein anderes Problem finden, welches ich seit Verwendung von HMCCURPC habe, mehr dazu aber im entsprechenden Beitrag.

https://forum.fhem.de/index.php/topic,69480.0.html (https://forum.fhem.de/index.php/topic,69480.0.html).

Vielen Dank für deine großartige Arbeit, diese wertet Fhem in Verbindung mit CCU gewaltig auf.

Gruß Reinhard
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Fischei am 12 Oktober 2017, 11:10:21
Hallo zap,

ich hab es gerade bei mir getestet. Hab weiterhin die Fehler bekommen.
Vermutlich ist noch nicht alles fertig/offen, wenn von HMCCU_TCPConnect ein "ok" zurück kommt.

Ich hab jetzt ein bißchen rumprobiert und mit einem weiterem sleep nach dem Aufruf von HMCCU_TCPConnect funktioniert es jetzt:

while (time () < $t+$timeout) {
my $t2 = time ();
if (HMCCU_TCPConnect ($addr, $port)) {
sleep (20);
return 1;
}
sleep (20);
}


Bei sleep(10) hat es noch nicht funktioniert.
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 12 Oktober 2017, 11:48:09
Ok, das hatte ich befürchtet. Ich prüfe derzeit nur, ob der tclrega da ist. Mal überlegen, ob ich noch weitere Ports einbeziehen oder deine Lösung übernehme.

Wobei HMCCU beim Start nur tclrega Schnittstelle benutzt.
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 12 Oktober 2017, 20:52:19
Hallo,

habe eben "Update all" gemacht um die neue HMCCU zu testen.
Aber nach einen "shutdown restart" lies sich Fhem überhaupt nicht mehr starten, auch nicht mehr über SSH.

Bin mir nicht sicher ob der Fehler bei mir selbst liegt, ich habe die beiden Module (HMCCU und HMCCURPC), über die Eingabezeile in Fhem WEB wie folgt erneuert.

set CCU2 rpcserver off
set ccuflags intrpc
set CCU2 rpcserver on
shutdown restart
delete HMCCURPC
shutdown restart
set CCU2 rpcserver off
delete HMCCU

define CCU2 HMCCU 192.168.1.32 waitforccu=300
set CCU2 rpcserver off
set ccuflags extrpc
set CCU2 rpcserver on
nun habe ich alle weiteren Attribute der beiden Module wieder wie vorher gesetzt
shutdown restart

Im Log war folgendes zu lesen:
2017.10.12 18:37:26 1: Including fhem.cfg
2017.10.12 18:37:27 2: eventTypes: loaded 3227 events from ./log/eventTypes.txt
2017.10.12 18:37:27 2: Switched COC rfmode to HomeMatic
Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 141, <$fh> line 294.


Was mir noch aufgefallen ist, in der fhem.cfg wurden die beiden Module ganz am Schluß angehängt. (Ich) konnte darin jedoch keine Fehler erkennen, aber das soll zunächst mal nichts bedeuten.
define CCU2 HMCCU 192.168.1.32 waitforccu=300
attr CCU2 DbLogExclude .*
attr CCU2 ccuflags extrpc
attr CCU2 icon hm_ccu
attr CCU2 room Homematic
attr CCU2 rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
attr CCU2 rpcinterval 5
attr CCU2 rpcport 2001,2010,9292
attr CCU2 rpcqueue /tmp/ccuqueue
attr CCU2 rpcserver on
attr CCU2 stateFormat rpcstate/state
define CCU2_rpc HMCCURPC 192.168.1.32
attr CCU2_rpc DbLogExclude .*
attr CCU2_rpc icon hm_ccu
attr CCU2_rpc room Homematic
attr CCU2_rpc stateFormat rpcstate/state
attr CCU2_rpc verbose 2


Hätte es auch gereicht, nach RPC stop, im Modul HMCCU, nur in der DEF, nach der IP "waitforccu=300" anzuhängen?

Gebt mir bitte mal bekannt, wie der korrekte Weg zur Änderung eines define ist.
Ich werde das Update dann nochmals ausführen und testen, derzeit bin ich noch auf der alten Version.

Somit habe ich zumindest mal ein Restore des Fhem Backups, und die Rechteanpassung in Linux durchführen dürfen :)
Nachdem nun alles wieder läuft, kann ich auch diesem Umstand eine positive Seite abgewinnen.

Gruß Reinhard
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 13 Oktober 2017, 09:44:08
Das ist die alte Problematik in FHEM mit den IO-Device und Client-Device Konstrukt. Das IO-Device muss vor den Client-Devices definiert werden. Durch das erneute define mit anschließendem Save wurde die Definition am Ende der fhem.cfg angehängt. Damit schlägt jedes Define mit HMCCUDEV oder HMCCUCHN vorher fehl.
Eigentlich bin ich kein Freund vom manuellen Editieren der fhem.cfg. In diesem Fall wäre es aber der richtige Weg gewesen. D.h. einfach waitforccu in der fhem.cfg an das Define anhängen. Hohle dir die alte fhem.cfg zurück und mach das so. Oder Du verschiebst die beiden Zeilen mit HMCCU und HMCCURPC wieder vor das erste Define mit HMCCUDEV und HMCCUCHN.
Wichtig ist auch: HMCCU vor(!) HMCCCURPC, da letzteres ebenfalls ein Client-Device ist, das HMCCU benutzt.
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Beta-User am 13 Oktober 2017, 10:02:40
@zap
https://forum.fhem.de/index.php/topic,62653.msg584897.html#msg584897?
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 13 Oktober 2017, 15:53:16
In der gerade eingecheckten Version 4.1.003 wird nun noch einmal 30 Sekunden gewartet, nachdem die CCU erreicht werden konnte. Außerdem habe ich das Verhalten beim Beenden von Threads in HMCCURPC etwas modifiziert, da es hier manchmal zu seltsamen Meldungen im FHEM Log kam, wenn FHEM bereits beendet war, aber einzelne Threads noch liefen.

In HMCCURPC (externer RPC-Server) gibt es einen automatischen Reconnect-Mechanismus, der aktiviert wird, indem man das Attribut ccuflags auf reconnect setzt. Wenn dann von der CCU für rpcEvtTimeout Sekunden keine Events mehr kamen, wird geprüft, ob der Port der CCU erreichbar ist. Wenn ja, registriert sich der RPC-Server neu bei der CCU. Damit sollte ein CCU Neustart möglich sein, ohne dass der RPC Server komplett den Dienst einstellt. Getestet habe ich das allerdings noch nicht.
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 14 Oktober 2017, 20:48:19
Hallo zap,

habe eben folgenden Test mit HMCCU Vers. 4.1.003 und HMCCURPC Vers. 0.97 beta durchgeführt.

1. Nur Hardware CCU2 "neustart" ungefähr um 18:38 Uhr
Während des gesamten Neustarts der CCU2 werden die Internals von HMCCU wie folgt angezeigt.
ccustate = active
RPCState = running
state = OK

Nachdem die CCU2 wieder erreichbar war, habe ich versucht, innerhalb der ersten Minute bei einem HmIP Wandthermostaten die Temperatur zu verstellen, die Änderung kam ca. 1 Minute verzögert am Wandthermostat an, die Readings wurden aber immer noch mit den alten Werten angezeigt.

Alle Devices werden aber seit dem Neustart der CCU nicht mehr automatisch aktualisiert!
Unerklärlich für mich ist nur, alle Befehle von Fhem in Richtung der Geräte funktionieren, nur die Meldung von den Geräten zu Fhem wird nicht mehr aktualisiert.

Erst nach einem get Update werden die Reading korrekt einmalig aktualisiert, dann stehen diese wieder wie "eingefroren".

Auch beobachte ich auch ein eigenartiges Verhalten, auch nach mehrmaligem "shutdown restart", alle Schaltbefehle Fhem -> Devices werden ausgeführt, jedoch Fehlermeldungen im Log. Die Rückmeldungen Device -> Fhem kommen jedoch nicht an.
Wartezeit bevor ich teste immer > 10 Minuten nach restart.

2017.10.14 19:24:08 0: Server shutdown
2017.10.14 19:24:08 1: HMCCURPC: Found 3 threads. Stopping ...
2017.10.14 19:24:08 1: HMCCURPC: Deregistering RPC server http://192.168.1.33:7420/fh2010 with ID CB2010 at http://192.168.1.32:2010/
2017.10.14 19:24:08 1: HMCCURPC: RPC callback for server CB2010 deregistered
2017.10.14 19:24:08 1: HMCCURPC: Deregistering RPC server http://192.168.1.33:7411/fh2001 with ID CB2001 at http://192.168.1.32:2001/
2017.10.14 19:24:08 1: HMCCURPC: RPC callback for server CB2001 deregistered
2017.10.14 19:24:08 2: HMCCURPC: Sending signal INT to thread CB2010 TID=3
2017.10.14 19:24:08 2: HMCCURPC: Sending signal INT to thread CB2001 TID=2
2017.10.14 19:24:08 2: CCURPC: RPC server CB2001 stopped handling connections. TID=2
2017.10.14 19:24:08 2: CCURPC: RPC server CB2010 stopped handling connections. TID=3
2017.10.14 19:24:09 1: HMCCURPC: Found 1 threads. Stopping ...
2017.10.14 19:24:13 2: Perfmon: ready to watch out for delays greater than one second
2017.10.14 19:24:13 1: Including fhem.cfg
2017.10.14 19:24:13 2: eventTypes: loaded 3247 events from ./log/eventTypes.txt
2017.10.14 19:24:14 2: Switched COC rfmode to HomeMatic
2017.10.14 19:24:45 1: HMCCU: Device CCU2. Initialized version 4.1.003
2017.10.14 19:24:49 1: HMCCU: Read 51 devices with 237 channels from CCU 192.168.1.32
2017.10.14 19:24:51 1: HMCCURPC: Device CCU2_rpc. Initialized version 0.97 beta
2017.10.14 19:24:51 1: Including ./log/fhem.save
2017.10.14 19:24:52 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2017.10.14 19:24:52 1: usb create starting
2017.10.14 19:24:52 1: usb create end
2017.10.14 19:24:52 0: Featurelevel: 5.8
2017.10.14 19:24:52 0: Server started with 271 defined entities (fhem.pl:15182/2017-10-03 perl:5.024001 os:linux user:fhem pid:8903)
2017.10.14 19:24:52 1: Perfmon: possible freeze starting at 19:24:14, delay is 38.665
2017.10.14 19:24:52 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_ModbusTCPServer.pm line 342.
2017.10.14 19:24:52 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [20 10 00 00 00 06] 00 03 20 10 00 05
2017.10.14 19:24:52 1: ModbusTCPServer_Parse: bad frame, received:  [20 10 00 00 00 03] 00 83 02
2017.10.14 19:24:52 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed (peer: 192.168.1.20)
2017.10.14 19:24:53 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed (peer: 192.168.1.20)
2017.10.14 19:25:04 2: HMCCURPC: Starting thread for data processing
2017.10.14 19:25:04 2: HMCCURPC: Started thread for data processing. TID=1
2017.10.14 19:25:04 2: CCURPC: Thread DATA processing RPC events. TID=1
2017.10.14 19:25:04 2: HMCCURPC: RPC server thread started for interface BidCos-RF with TID=2
2017.10.14 19:25:04 2: CCURPC: Initializing RPC server CB2001 for interface BidCos-RF
2017.10.14 19:25:05 2: HMCCURPC: Callback server CB2001 created. Listening on port 7411
2017.10.14 19:25:05 2: CCURPC: CB2001 accepting connections. TID=2
2017.10.14 19:25:05 2: HMCCURPC: RPC server thread started for interface HmIP-RF with TID=3
2017.10.14 19:25:05 2: CCURPC: Initializing RPC server CB2010 for interface HmIP-RF
2017.10.14 19:25:05 2: HMCCURPC: Callback server CB2010 created. Listening on port 7420
2017.10.14 19:25:05 2: CCURPC: CB2010 accepting connections. TID=3
2017.10.14 19:25:06 1: HMCCURPC: RPC server(s) starting
2017.10.14 19:25:06 1: HMCCURPC: Received SL event. RPC server DATA enters server loop
2017.10.14 19:25:06 1: HMCCURPC: Received SL event. RPC server CB2001 enters server loop
2017.10.14 19:25:06 1: HMCCURPC: Received SL event. RPC server CB2010 enters server loop
2017.10.14 19:25:06 1: HMCCURPC: All threads working
2017.10.14 19:25:06 2: HMCCURPC: Registering callback http://192.168.1.33:7411/fh2001 with ID CB2001 at http://192.168.1.32:2001/
2017.10.14 19:25:06 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.10.14 19:25:06 1: HMCCURPC: RPC callback with URL http://192.168.1.33:7411/fh2001 registered
2017.10.14 19:25:06 2: HMCCURPC: Registering callback http://192.168.1.33:7420/fh2010 with ID CB2010 at http://192.168.1.32:2010/
2017.10.14 19:25:06 1: HMCCURPC: RPC callback with URL http://192.168.1.33:7420/fh2010 registered
2017.10.14 19:25:06 1: HMCCURPC: Received IN event. RPC server CB2001 running.
2017.10.14 19:25:06 1: Perfmon: possible freeze starting at 19:25:05, delay is 1.795
2017.10.14 19:25:06 2: CCURPC: CB2001 NewDevice received 69 device and channel specifications
2017.10.14 19:25:56 2: HMCCURPC: Checking if all threads are running
2017.10.14 19:25:56 1: HMCCURPC: Only 2 of 3 threads are running. Cleaning up
2017.10.14 19:25:56 1: HMCCURPC: Housekeeping called. Cleaning up RPC environment
2017.10.14 19:25:56 1: HMCCURPC: Deregistering RPC server http://192.168.1.33:7411/fh2001 with ID CB2001 at http://192.168.1.32:2001/
2017.10.14 19:25:56 1: HMCCURPC: RPC callback for server CB2001 deregistered
2017.10.14 19:25:56 1: HMCCURPC: Deregistering RPC server http://192.168.1.33:7420/fh2010 with ID CB2010 at http://192.168.1.32:2010/
2017.10.14 19:25:56 1: HMCCURPC: RPC callback for server CB2010 deregistered
2017.10.14 19:25:56 2: HMCCURPC: Stop I/O handling
2017.10.14 19:25:56 2: HMCCURPC: Close child socket
2017.10.14 19:25:56 2: HMCCURPC: Close parent socket
2017.10.14 19:25:56 2: HMCCURPC: Sending signal INT to thread CB2001 TID=2
2017.10.14 19:25:56 2: HMCCURPC: Sending signal INT to thread DATA TID=1
2017.10.14 19:25:56 2: HMCCURPC: Sending signal INT to thread CB2010 TID=3
2017.10.14 19:25:56 2: CCURPC: DATA stopped event processing. TID=1
2017.10.14 19:25:56 2: CCURPC: RPC server CB2010 stopped handling connections. TID=3
2017.10.14 19:25:57 2: CCURPC: RPC server CB2001 stopped handling connections. TID=2
2017.10.14 19:25:58 2: HMCCURPC: Thread CB2001 with TID=2 is in state stopping. Can't delete it
2017.10.14 19:25:58 2: HMCCURPC: Thread DATA with TID=1 is in state stopping. Can't delete it
2017.10.14 19:25:58 2: HMCCURPC: Thread CB2010 with TID=3 is in state stopping. Can't delete it
2017.10.14 19:25:58 1: Perfmon: possible freeze starting at 19:25:57, delay is 1.576
2017.10.14 19:31:12 1: HMCCUDEV: HM_OG_SA1_FlurOG Execution of CCU script or command failed
2017.10.14 19:31:12 1: Perfmon: possible freeze starting at 19:31:09, delay is 3.5
2017.10.14 20:10:08 1: HMCCUDEV: HM_OG_RT1_BueroReinhard Execution of CCU script or command failed
2017.10.14 20:10:08 1: Perfmon: possible freeze starting at 20:10:05, delay is 3.487


Habe mal direkt in der Fhem.cfg das Modul HMCCURPC direkt an das Modul HMCCU (vor allen HM-Devices) angehängt, auch das löst das Problem bei mir nach einem restart nicht.

Ich gehe nun wieder auf eine lauffähige HMCCU Version zurück, da ich mir das Fehlverhalten derzeit nicht erklären kann.
Gerne führe ich weitere Tests durch.

Sorry dass ich nichts positives berichten kann, läuft es denn bei allen anderen?
Liegt der Fehler ventuell doch bei mir?
Kann echt nicht sagen, ob es direkt nach dem Update und noch vor dem Test (Neustart CCU2) schon korrekt funktioniert hat.

Gruß Reinhard

Achtung Ergänzung!!!
Irgendwie verstehe ich die Welt nicht mehr, auch mit HMCCU Vers. 4.1.001 bekomme ich den HMCCURPC Vers. 0.96 beta Server nicht zum laufen.
Ich denke meine CCU2 hat sich aufgehängt, nach CCU2 Neustart (bei gestoppten Fhem) läuft alles wieder wie es sein soll.
Frage: Sollte HMCCU mit HMCCURPC "nur" einen Neustart der CCU2 alleine überstehen oder darf so etwas eigentlich niemals vorkommen?
Bei einem tatsächlichen Stromausfall steht ja Fhem und die CCU2 gemeinsam zur gleichen Zeit.
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 14 Oktober 2017, 22:33:29
Hallo zap,

meine CCU2 hatte sich irgendwie aufgehängt (nur die Kommunikation zum RPC Server von Fhem), deshalb kam der RPC-Server nicht zum laufen.

In der neuen Version zunächst was positives.
Fhem läuft nun immer korrekt nach einem "shutdown restart" hoch, ohne dass ich dieses extra nochmals starten muss.

Bin jetzt wieder auf der neuesten Version und habe nun einen Spannungsausfall simuliert.
Auch nach ca. 10 Minuten nach Spannungswiderkehr sind die HM-Devices noch verschwunden und die Weboberfläche reagiert absolut träge.
Im Log sind sehr viele Fehler enthalten:
2017.10.14 22:06:56 2: HMCCURPC: Starting thread for data processing
2017.10.14 22:06:56 2: HMCCURPC: Started thread for data processing. TID=1
2017.10.14 22:06:56 2: CCURPC: Thread DATA processing RPC events. TID=1
2017.10.14 22:06:57 2: HMCCURPC: RPC server thread started for interface BidCos-RF with TID=2
2017.10.14 22:06:57 2: CCURPC: Initializing RPC server CB2001 for interface BidCos-RF
2017.10.14 22:06:57 2: HMCCURPC: Callback server CB2001 created. Listening on port 7411
2017.10.14 22:06:57 2: CCURPC: CB2001 accepting connections. TID=2
2017.10.14 22:06:58 1: HMCCURPC: RPC server(s) starting
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 296) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 297) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 298) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 299) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 300) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 301) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 302) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 303) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 304) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 305) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 306) line 1.
2017.10.14 22:07:06 2: CCURPC: I/O error during data processing (Select found no reader)
2017.10.14 22:07:09 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 322) line 1.


Erst nach einem "shutdown restart" läuft alles wieder prima, ohne jegliche Fehler.

Mir fällt auch folgendes auf, niemals habe ich das Internal "ccustate" anders als active gesehen.
Auch wenn die HM-Devices nach dem "Spannungsausfall" verschwunden sind ist dies nicht anders, auch "rpcstate" steht nach kurzer Zeit auf running und "state" auf OK.

Gruß Reihard

Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 15 Oktober 2017, 09:39:39
Kannst Du mal bitte die Logmeldungen ab define HMCCU posten?

die einzelnen Devices (HMCCUDEV) konnten definiert werden?
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 15 Oktober 2017, 10:19:53
Hallo zap,

anbei das gesamte Log (gekürzt um nahezu gleiche Meldungen) seit dem Update auf die neueste Version, mit dem "Spannunngsausfalltest" in Verbose 2.

2017.10.14 21:49:14 1: fhem
2017.10.14 21:49:15 1: UPD ./CHANGED
2017.10.14 21:49:15 1: UPD ./fhem.cfg.demo
2017.10.14 21:49:15 1: UPD FHEM/10_MYSENSORS_DEVICE.pm
2017.10.14 21:49:15 1: UPD FHEM/26_tahoma.pm
2017.10.14 21:49:15 1: UPD FHEM/31_HUEDevice.pm
2017.10.14 21:49:15 1: UPD FHEM/42_SYSMON.pm
2017.10.14 21:49:15 1: UPD FHEM/57_CALVIEW.pm
2017.10.14 21:49:15 1: UPD FHEM/59_LuftdatenInfo.pm
2017.10.14 21:49:15 1: UPD FHEM/59_WUup.pm
2017.10.14 21:49:15 1: UPD FHEM/73_AMADCommBridge.pm
2017.10.14 21:49:15 1: UPD FHEM/74_AMADDevice.pm
2017.10.14 21:49:15 1: UPD FHEM/75_MSG.pm
2017.10.14 21:49:15 1: UPD FHEM/88_HMCCU.pm
2017.10.14 21:49:15 1: UPD FHEM/88_HMCCURPC.pm
2017.10.14 21:49:15 1: UPD FHEM/98_DOIFtools.pm
2017.10.14 21:49:15 1: UPD FHEM/98_help.pm
2017.10.14 21:49:15 1: UPD FHEM/lib/74_AMADautomagicFlowset_4.0.11.xml
2017.10.14 21:49:15 1: UPD FHEM/lib/openzwave_deviceconfig.xml.gz
2017.10.14 21:49:15 1: UPD FHEM/lib/openzwave_manufacturer_specific.xml
2017.10.14 21:49:15 1: UPD FHEM/lib/zwave_alliancelinks.csv.gz
2017.10.14 21:49:15 1: UPD www/pgm2/defaultCommon.css
2017.10.14 21:49:15 1: UPD www/pgm2/fhemweb.js
2017.10.14 21:49:15 1: UPD www/pgm2/fhemweb_iconLabel.js
2017.10.14 21:49:15 1: UPD www/pgm2/fhemweb_iconRadio.js
2017.10.14 21:49:15 1: UPD www/pgm2/fhemweb_iconSwitch.js
2017.10.14 21:49:15 1: saving fhem.cfg
2017.10.14 21:49:15 1: saving ./log/fhem.save
2017.10.14 21:49:15 1:
2017.10.14 21:49:15 1: New entries in the CHANGED file:
2017.10.14 21:49:15 1:   - feature: 98_DOIFtools: add RGB color values to color table
2017.10.14 21:49:15 1:   - bugfix:  88_HMCCURPC: fixed bug in event timeout handling
2017.10.14 21:49:15 1:   - change:  59_LuftdatenInfo: DEF change (should happen automatically)
2017.10.14 21:49:15 1:   - feature: 98_DOIFtools: add getter linearColorGradient, returns a table of
2017.10.14 21:49:15 1:              value, colornumber, color bar
2017.10.14 21:49:15 1:   - feature: 74_AMADDevice: add set command userFlowRun
2017.10.14 21:49:15 1:   - change:  57_CALVIEW.pm: -new readings weekdayname and weekday
2017.10.14 21:49:15 1:                             -new attr weekdayformat
2017.10.14 21:49:15 1:   - feature: 88_HMCCU: Added parameter waitforccu to define command
2017.10.14 21:49:15 1:   - bugfix:  42_SYSMON: PERL WARNING: Use of uninitialized value
2017.10.14 21:49:15 1:   - bugfix:  59_WUup.pm: fix state and missing attributes (#695364, #696275)
2017.10.14 21:49:15 1:
2017.10.14 21:49:15 1:
2017.10.14 21:49:15 1: fhemabfall
2017.10.14 21:49:16 1: nothing to do...
2017.10.14 21:49:16 1:
2017.10.14 21:49:16 1:
2017.10.14 21:49:16 1: ha_theme
2017.10.14 21:49:16 1: UPD www/hausautomatisierung-com/custom.js
2017.10.14 21:49:16 1: UPD www/images/hausautomatisierung_com/favicon.ico
2017.10.14 21:49:16 1: UPD www/pgm2/hausautomatisierung_comfloorplanstyle.css
2017.10.14 21:49:17 1: UPD www/pgm2/hausautomatisierung_comstyle.css
2017.10.14 21:49:17 1: saving fhem.cfg
2017.10.14 21:49:17 1: saving ./log/fhem.save
2017.10.14 21:49:17 1:
2017.10.14 21:49:17 1: New entries in the CHANGED file:
2017.10.14 21:49:17 1: FHEM haus-automatisierung.com custom theme last changes:
2017.10.14 21:49:17 1: 2017-10-14
2017.10.14 21:49:17 1:  - Kleinere Fixes
2017.10.14 21:49:17 1: Calling /usr/bin/perl ./contrib/commandref_join.pl -noWarnings, this may take a while
2017.10.14 21:49:52 1:
2017.10.14 21:49:52 1: update finished, "shutdown restart" is needed to activate the changes.
2017.10.14 21:49:52 1:
2017.10.14 21:49:52 1: Please consider using the global attribute sendStatistics
2017.10.14 21:50:44 0: Server shutdown
2017.10.14 21:50:44 1: HMCCURPC: Found 3 threads. Stopping ...
2017.10.14 21:50:44 1: HMCCURPC: Deregistering RPC server http://192.168.1.33:7420/fh2010 with ID CB2010 at http://192.168.1.32:2010/
2017.10.14 21:50:44 1: HMCCURPC: RPC callback for server CB2010 deregistered
2017.10.14 21:50:44 1: HMCCURPC: Deregistering RPC server http://192.168.1.33:7411/fh2001 with ID CB2001 at http://192.168.1.32:2001/
2017.10.14 21:50:44 1: HMCCURPC: RPC callback for server CB2001 deregistered
2017.10.14 21:50:44 2: HMCCURPC: Sending signal INT to thread CB2010 TID=3
2017.10.14 21:50:44 2: HMCCURPC: Sending signal INT to thread CB2001 TID=2
2017.10.14 21:50:45 2: CCURPC: RPC server CB2001 stopped handling connections. TID=2
2017.10.14 21:50:45 2: CCURPC: RPC server CB2010 stopped handling connections. TID=3
2017.10.14 21:50:45 1: HMCCURPC: Found 1 threads. Stopping ...
2017.10.14 21:50:49 2: Perfmon: ready to watch out for delays greater than one second
2017.10.14 21:50:49 1: Including fhem.cfg
2017.10.14 21:50:49 2: eventTypes: loaded 3244 events from ./log/eventTypes.txt
2017.10.14 21:50:50 2: Switched COC rfmode to HomeMatic
2017.10.14 21:51:21 1: HMCCU: Device CCU2. Initialized version 4.1.003
2017.10.14 21:51:25 1: HMCCU: Read 51 devices with 237 channels from CCU 192.168.1.32
2017.10.14 21:51:25 1: HMCCURPC: Device CCU2_rpc. Initialized version 0.97 beta
2017.10.14 21:51:27 1: Including ./log/fhem.save
2017.10.14 21:51:27 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2017.10.14 21:51:28 1: usb create starting
2017.10.14 21:51:28 1: usb create end
2017.10.14 21:51:28 0: Featurelevel: 5.8
2017.10.14 21:51:28 0: Server started with 271 defined entities (fhem.pl:15182/2017-10-03 perl:5.024001 os:linux user:fhem pid:1650)
2017.10.14 21:51:28 1: Perfmon: possible freeze starting at 21:50:50, delay is 38.628
2017.10.14 21:51:28 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_ModbusTCPServer.pm line 342.
2017.10.14 21:51:28 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [20 10 00 00 00 06] 00 03 20 10 00 05
2017.10.14 21:51:28 1: ModbusTCPServer_Parse: bad frame, received:  [20 10 00 00 00 03] 00 83 02
2017.10.14 21:51:28 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed (peer: 192.168.1.20)
2017.10.14 21:51:39 2: HMCCURPC: Starting thread for data processing
2017.10.14 21:51:40 2: HMCCURPC: Started thread for data processing. TID=1
2017.10.14 21:51:40 2: CCURPC: Thread DATA processing RPC events. TID=1
2017.10.14 21:51:40 2: HMCCURPC: RPC server thread started for interface BidCos-RF with TID=2
2017.10.14 21:51:40 2: CCURPC: Initializing RPC server CB2001 for interface BidCos-RF
2017.10.14 21:51:41 2: HMCCURPC: Callback server CB2001 created. Listening on port 7411
2017.10.14 21:51:41 2: CCURPC: CB2001 accepting connections. TID=2
2017.10.14 21:51:41 2: HMCCURPC: RPC server thread started for interface HmIP-RF with TID=3
2017.10.14 21:51:41 2: CCURPC: Initializing RPC server CB2010 for interface HmIP-RF
2017.10.14 21:51:41 2: HMCCURPC: Callback server CB2010 created. Listening on port 7420
2017.10.14 21:51:41 2: CCURPC: CB2010 accepting connections. TID=3
2017.10.14 21:51:42 1: HMCCURPC: RPC server(s) starting
2017.10.14 21:51:42 1: Perfmon: possible freeze starting at 21:51:40, delay is 2.461
2017.10.14 21:51:42 1: HMCCURPC: Received SL event. RPC server DATA enters server loop
2017.10.14 21:51:42 1: HMCCURPC: Received SL event. RPC server CB2001 enters server loop
2017.10.14 21:51:42 1: HMCCURPC: Received SL event. RPC server CB2010 enters server loop
2017.10.14 21:51:42 1: HMCCURPC: All threads working
2017.10.14 21:51:42 2: HMCCURPC: Registering callback http://192.168.1.33:7411/fh2001 with ID CB2001 at http://192.168.1.32:2001/
2017.10.14 21:51:42 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.10.14 21:51:42 1: HMCCURPC: RPC callback with URL http://192.168.1.33:7411/fh2001 registered
2017.10.14 21:51:42 2: HMCCURPC: Registering callback http://192.168.1.33:7420/fh2010 with ID CB2010 at http://192.168.1.32:2010/
2017.10.14 21:51:42 1: HMCCURPC: RPC callback with URL http://192.168.1.33:7420/fh2010 registered
2017.10.14 21:51:42 1: HMCCURPC: Received IN event. RPC server CB2001 running.
2017.10.14 21:51:42 2: CCURPC: CB2001 NewDevice received 69 device and channel specifications
2017.10.14 21:51:42 1: CCURPC: CB2010 ListDevices. Sending init to HMCCU
2017.10.14 21:51:43 1: HMCCURPC: Received IN event. RPC server CB2010 running.
2017.10.14 21:51:43 1: HMCCURPC: All RPC servers running
2017.10.14 21:51:45 2: CCURPC: CB2010 NewDevice received 219 device and channel specifications
2017.10.14 21:51:45 2: HMCCURPC: Updated devices. Success=52 Failed=0
2017.10.14 21:51:45 1: Perfmon: possible freeze starting at 21:51:43, delay is 2.949
###### Hier erfolgte der "Spannungsausfall"
2017.10.14 22:06:56 1: Perfmon: possible freeze starting at 18:18:01, delay is 29818135.382
2017.10.14 22:06:56 2: HMCCURPC: Starting thread for data processing
2017.10.14 22:06:56 2: HMCCURPC: Started thread for data processing. TID=1
2017.10.14 22:06:56 2: CCURPC: Thread DATA processing RPC events. TID=1
2017.10.14 22:06:57 2: HMCCURPC: RPC server thread started for interface BidCos-RF with TID=2
2017.10.14 22:06:57 2: CCURPC: Initializing RPC server CB2001 for interface BidCos-RF
2017.10.14 22:06:57 2: HMCCURPC: Callback server CB2001 created. Listening on port 7411
2017.10.14 22:06:57 2: CCURPC: CB2001 accepting connections. TID=2
2017.10.14 22:06:58 1: HMCCURPC: RPC server(s) starting
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 296) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 297) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 298) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 299) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 300) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 301) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 302) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 303) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 304) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 305) line 1.
2017.10.14 22:07:03 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 306) line 1.
2017.10.14 22:07:06 2: CCURPC: I/O error during data processing (Select found no reader)
2017.10.14 22:07:09 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 322) line 1.
2017.10.14 22:07:09 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 323) line 1.
2017.10.14 22:07:09 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 324) line 1.
2017.10.14 22:07:10 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 325) line 1.
2017.10.14 22:07:10 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 326) line 1.
2017.10.14 22:07:10 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 327) line 1.
2017.10.14 22:07:10 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 328) line 1.
2017.10.14 22:07:10 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 329) line 1.
2017.10.14 22:07:10 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 330) line 1.
2017.10.14 22:07:10 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 331) line 1.
2017.10.14 22:07:10 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 332) line 1.
2017.10.14 22:07:10 1: HMCCURPC: Received SL event. RPC server DATA enters server loop
2017.10.14 22:07:10 1: HMCCURPC: Received SL event. RPC server CB2001 enters server loop
2017.10.14 22:07:10 1: HMCCURPC: All threads working
2017.10.14 22:07:10 2: HMCCURPC: Registering callback http://192.168.1.33:7411/fh2001 with ID CB2001 at http://192.168.1.32:2001/
2017.10.14 22:07:10 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.10.14 22:07:11 1: HMCCURPC: RPC callback with URL http://192.168.1.33:7411/fh2001 registered
2017.10.14 22:07:11 1: HMCCURPC: Received IN event. RPC server CB2001 running.
2017.10.14 22:07:11 1: HMCCURPC: All RPC servers running
2017.10.14 22:07:11 2: HMCCU: No client devices matching .*
2017.10.14 22:07:11 2: HMCCURPC: Updated devices. Success=0 Failed=0
2017.10.14 22:07:11 2: CCURPC: CB2001 NewDevice received 69 device and channel specifications
2017.10.14 22:07:25 2: CCURPC: I/O error during data processing (Select found no reader)
2017.10.14 22:07:33 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 347) line 1.
.................... mehrere hundert "gleiche" (eval xxxx) Meldungen
2017.10.14 22:07:33 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 357) line 1.
2017.10.14 22:07:34 1: Perfmon: possible freeze starting at 22:06:57, delay is 37.649
2017.10.14 22:07:44 2: CCURPC: I/O error during data processing (Select found no reader)
2017.10.14 22:08:06 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 362) line 1.
2017.10.14 22:16:56 0: Server shutdown
#### Neustart Fhem "schutdown restart"
2017.10.14 22:16:56 1: HMCCURPC: Found 2 threads. Stopping ...
2017.10.14 22:16:56 1: HMCCURPC: Deregistering RPC server http://192.168.1.33:7411/fh2001 with ID CB2001 at http://192.168.1.32:2001/
2017.10.14 22:16:56 1: HMCCURPC: RPC callback for server CB2001 deregistered
2017.10.14 22:16:56 2: HMCCURPC: Sending signal INT to thread CB2001 TID=2
2017.10.14 22:16:57 2: CCURPC: RPC server CB2001 stopped handling connections. TID=2
2017.10.14 22:16:57 1: HMCCURPC: Found 1 threads. Stopping ...
2017.10.14 22:17:00 2: Perfmon: ready to watch out for delays greater than one second
2017.10.14 22:17:00 1: Including fhem.cfg
2017.10.14 22:17:01 2: eventTypes: loaded 3244 events from ./log/eventTypes.txt
2017.10.14 22:17:01 2: Switched COC rfmode to HomeMatic
2017.10.14 22:17:33 1: HMCCU: Device CCU2. Initialized version 4.1.003
2017.10.14 22:17:38 1: HMCCU: Read 51 devices with 237 channels from CCU 192.168.1.32
2017.10.14 22:17:38 1: HMCCURPC: Device CCU2_rpc. Initialized version 0.97 beta
2017.10.14 22:17:40 1: Including ./log/fhem.save
2017.10.14 22:17:40 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2017.10.14 22:17:40 1: usb create starting
2017.10.14 22:17:41 1: usb create end
2017.10.14 22:17:41 0: Featurelevel: 5.8
2017.10.14 22:17:41 0: Server started with 271 defined entities (fhem.pl:15182/2017-10-03 perl:5.024001 os:linux user:fhem pid:1400)
2017.10.14 22:17:41 1: Perfmon: possible freeze starting at 22:17:01, delay is 40.474
2017.10.14 22:17:41 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_ModbusTCPServer.pm line 342.
2017.10.14 22:17:41 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [20 10 00 00 00 06] 00 03 20 10 00 05
2017.10.14 22:17:41 1: ModbusTCPServer_Parse: bad frame, received:  [20 10 00 00 00 03] 00 83 02
2017.10.14 22:17:41 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed (peer: 192.168.1.20)
2017.10.14 22:17:52 2: HMCCURPC: Starting thread for data processing
2017.10.14 22:17:53 2: HMCCURPC: Started thread for data processing. TID=1
2017.10.14 22:17:53 2: CCURPC: Thread DATA processing RPC events. TID=1
2017.10.14 22:17:53 2: HMCCURPC: RPC server thread started for interface BidCos-RF with TID=2
2017.10.14 22:17:53 2: CCURPC: Initializing RPC server CB2001 for interface BidCos-RF
2017.10.14 22:17:53 2: HMCCURPC: Callback server CB2001 created. Listening on port 7411
2017.10.14 22:17:53 2: CCURPC: CB2001 accepting connections. TID=2
2017.10.14 22:17:54 2: HMCCURPC: RPC server thread started for interface HmIP-RF with TID=3
2017.10.14 22:17:54 2: CCURPC: Initializing RPC server CB2010 for interface HmIP-RF
2017.10.14 22:17:54 2: HMCCURPC: Callback server CB2010 created. Listening on port 7420
2017.10.14 22:17:54 2: CCURPC: CB2010 accepting connections. TID=3
2017.10.14 22:17:55 1: HMCCURPC: RPC server(s) starting
2017.10.14 22:17:55 1: HMCCURPC: Received SL event. RPC server DATA enters server loop
2017.10.14 22:17:55 1: HMCCURPC: Received SL event. RPC server CB2001 enters server loop
2017.10.14 22:17:55 1: HMCCURPC: Received SL event. RPC server CB2010 enters server loop
2017.10.14 22:17:55 1: HMCCURPC: All threads working
2017.10.14 22:17:55 2: HMCCURPC: Registering callback http://192.168.1.33:7411/fh2001 with ID CB2001 at http://192.168.1.32:2001/
2017.10.14 22:17:55 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.10.14 22:17:55 1: HMCCURPC: RPC callback with URL http://192.168.1.33:7411/fh2001 registered
2017.10.14 22:17:55 2: HMCCURPC: Registering callback http://192.168.1.33:7420/fh2010 with ID CB2010 at http://192.168.1.32:2010/
2017.10.14 22:17:55 1: HMCCURPC: RPC callback with URL http://192.168.1.33:7420/fh2010 registered
2017.10.14 22:17:55 1: HMCCURPC: Received IN event. RPC server CB2001 running.
2017.10.14 22:17:55 1: Perfmon: possible freeze starting at 22:17:53, delay is 2.659
2017.10.14 22:17:55 2: CCURPC: CB2001 NewDevice received 69 device and channel specifications
2017.10.14 22:17:55 1: CCURPC: CB2010 ListDevices. Sending init to HMCCU
2017.10.14 22:17:55 1: HMCCURPC: Received IN event. RPC server CB2010 running.
2017.10.14 22:17:55 1: HMCCURPC: All RPC servers running
2017.10.14 22:17:56 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 302) line 1.
2017.10.14 22:17:58 2: CCURPC: CB2010 NewDevice received 219 device and channel specifications
2017.10.14 22:18:02 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 340) line 1.
2017.10.14 22:18:13 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 412) line 1.
2017.10.14 22:18:14 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 419) line 1.
2017.10.14 22:18:32 2: HMCCURPC: Updated devices. Success=52 Failed=0
2017.10.14 22:18:32 1: Perfmon: possible freeze starting at 22:17:56, delay is 36.849


Solltest du noch was benötigenn gib mir bitte Bescheid.

Gruß Reinnhard
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 22 Oktober 2017, 11:59:54
Hallo zap,

konntest du zwischenzeitlich noch irgend welche Rückschlüsse aus dem Log ziehen, weshalb es bei mir nicht geht?
Mache ich da eventuell doch irgend etwas falsch?


Gruß Reinhard
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Steffen am 23 Januar 2018, 16:30:26
Hallo!

Ich habe das jetzt schon ein paar mal beobachtet aber nach einem Neustart von Fhem wenn die CCu2 nicht erreichbar war(stromausfall) sind alle definierten
Einträge weg, gibt es einen Weg das zu ändern?!?


attr global userattr alexaName alexaRoom cmdIcon devStateIcon devStateStyle genericDeviceType:security,ignore,switch,outlet,light,blind,thermometer,thermostat,contact,garage,window,lock homebridgeMapping:textField-long icon sortby webCmd webCmdLabel:textField-long widgetOverride
attr global autoload_undefined_devices 0
attr global autosave 1
attr global exclude_from_update 59_HCS.pm
attr global language DE
attr global latitude 52.4587487
attr global logfile ./log/fhem-%Y-%m.log
attr global longitude 13.4148381
attr global modpath .
attr global motd Messages collected while initializing FHEM:\
configfile: Device Schaltkanal1 not defined. Please add this device first!\
Cannot detect IO device\
Cannot detect IO device\
Cannot detect IO device\
Cannot detect IO device\
Cannot detect IO device\
Cannot detect IO device\
Cannot detect IO device\
Cannot detect IO device\
Cannot detect IO device\
Cannot detect IO device\
Cannot detect IO device\
./log/fhem.save: Please define BW_OfficeBox first\
Please define BW_OfficeBox first\
Please define BW_OfficeBox first\
Please define BW_OfficeBox first\
Please define BW_OfficeBox first\
Please define BW_OfficeBox first\
Please define BW_OfficeBox first\
Please define BW_OfficeBox first\
Please define Deckenlampe first\
Please define Deckenlampe first\
Please define Deckenlampe first\
Please define Deckenlampe first\
Please define Deckenlampe first\
Please define Deckenlampe first\
Please define Deckenlampe first\
Please define FK_Eingang first\
Please define FK_Eingang first\
Please define FK_Eingang first\
Please define FK_Eingang first\
Please define FK_SeitenEingang first\
Please define FK_SeitenEingang first\
Please define FK_SeitenEingang first\
Please define FK_SeitenEingang first\
Please define HCS first\
Please define HCS first\
Please define HCS first\
Please define HCS first\
Please define HCS first\
Please define HCS first\
Please define HCS first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first\
Please define Rauchmelder first\
Please define Rauchmelder first\
Please define Rauchmelder first\
Please define Rauchmelder first\
Please define Rauchmelder first\
Please define Rauchmelder first\
Please define Rauchmelder first\
Please define Rauchmelder first\
Please define Rauchmelder first\
Please define Rauchmelder first\
Please define Rauchmelder first\
Please define Rauchmelder first\
Please define Rauchmelder first\
Please define Rauchmelder first\
Please define Schaltkanal1 first\
Please define Schaltkanal1 first\
Please define Schaltkanal1 first\
Please define Schaltkanal1 first\
Please define Schaltkanal1 first\
Please define Schaltkanal1 first\
Please define Schaltkanal1 first\
Please define Schaltkanal1 first\
Please define Schaltkanal1 first\
Please define Schaltkanal1 first\
Please define Schaltkanal1 first\
Please define Schaltkanal1 first\
Please define Schaltkanal1 first\
Please define Schaltkanal1 first\
Please define Schaltkanal2 first\
Please define Schaltkanal2 first\
Please define Schaltkanal2 first\
Please define Schaltkanal2 first\
Please define Schaltkanal3 first\
Please define Schaltkanal3 first\
Please define Schaltkanal3 first\
Please define Schaltkanal3 first\
Please define Schaltkanal4 first\
Please define Schaltkanal4 first\
Please define Schaltkanal4 first\
Please define Schaltkanal4 first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
Please define Thermostat first\
\
Autosave deactivated
attr global room System
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3


das habe ich jetzt mal getestet und mein HMCCU um 192.168.178.88 waitforccu=180
erweitert aber nach einem Neustart von Fhem dauert der Neustart genau so lange?!

Wird in der Zeit abgefragt ob die CCU2 erreichbar ist oder habe ich das Falsch verstanden?!

Mfg Steffen
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 23 Januar 2018, 19:14:31
Zitat von: Steffen am 23 Januar 2018, 16:30:26
Hallo!

Ich habe das jetzt schon ein paar mal beobachtet aber nach einem Neustart von Fhem wenn die CCu2 nicht erreichbar war(stromausfall) sind alle definierten
Einträge weg, gibt es einen Weg das zu ändern?!?

Die sind nicht weg, sie konnten nur nicht definiert werden, weil vorher das I/O Device nicht definiert werden konnte. Wenn man die FHEM Config nicht abspeichert sondern einfach neu startet mit erreichbarer CCU, sind wieder alle da.

Zitat
das habe ich jetzt mal getestet und mein HMCCU um 192.168.178.88 waitforccu=180
erweitert aber nach einem Neustart von Fhem dauert der Neustart genau so lange?!

Wird in der Zeit abgefragt ob die CCU2 erreichbar ist oder habe ich das Falsch verstanden?!

Was meinst Du mit "genau so lange"? HMCCU prüft für die Dauer des angegebenen Zeitraums (bei Dir 3 Minuten) alle 20 Sekunden, ob die CCU erreichbar ist. Wenn ja, wird nicht gewartet, bis die 3 Minuten um sind sondern das Device initialisiert.

Ein Auszug aus dem FHEM Logfile wäre hilfreich, insbesondere die Stelle, an der das I/O Device mit HMCCU definiert wird.

@Rewe2000: Habe leider keine Idee, wo das Problem liegt. Der Start des RPC Servers sieht für mich ok aus. Woher die Meldung "PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 340) line 1." kommt, weiß ich nicht. Glaube nicht, dass die von HMCCU kommt.
Die Warnung von Perfmon wird durch das Update aller Devices am Ende des RPC Server Starts verursacht. Das dauert eben ein bisschen und blockiert während dieser Zeit FHEM. Ist unkritisch.
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Steffen am 29 Januar 2018, 17:36:57
Hallo!

Also das verzögerte Starten klappt irgenwie nicht, habe mit 192.168.178.88 waitforccu=300 eingestell aber
Fhem startet trotzdem genau so schnell hoch wie ohne die Einstellung?!


Hier mal das Logfile:
2018.01.29 16:18:39 3: telnetPort: port 7072 opened
2018.01.29 16:18:40 3: WEB: port 8083 opened
2018.01.29 16:18:40 3: WEBphone: port 8084 opened
2018.01.29 16:18:40 3: WEBtablet: port 8085 opened
2018.01.29 16:18:40 2: eventTypes: loaded 938 events from ./log/eventTypes.txt
2018.01.29 16:19:12 1: HMCCU: Device d_ccu. Initialized version 4.1.004
2018.01.29 16:19:12 1: HMCCU: No devices read from CCU 192.168.178.88
2018.01.29 16:19:12 3: Opening ZWDongle_0 device /dev/ttyACM0
2018.01.29 16:19:12 3: Setting ZWDongle_0 serial parameters to 115200,8,N,1
2018.01.29 16:19:13 3: ZWDongle_0 device opened
2018.01.29 16:19:16 1: define Schaltkanal1 HMCCUCHN NEQ1693835:1: Cannot detect IO device
2018.01.29 16:19:16 1: define Schaltkanal2 HMCCUCHN NEQ1693835:2 defaults: Cannot detect IO device
2018.01.29 16:19:16 1: define Schaltkanal3 HMCCUCHN NEQ1693835:3 defaults: Cannot detect IO device
2018.01.29 16:19:16 1: define Schaltkanal4 HMCCUCHN NEQ1693835:4 defaults: Cannot detect IO device
2018.01.29 16:19:16 1: define FK_Eingang HMCCUCHN 0000D7099579A0:1: Cannot detect IO device
2018.01.29 16:19:16 1: define FK_SeitenEingang HMCCUCHN 0000D7099555C2:1 defaults: Cannot detect IO device
2018.01.29 16:19:16 1: define Rauchmelder HMCCUCHN 000A570998B072:1 defaults: Cannot detect IO device
2018.01.29 16:19:16 1: define Heizung_Officebox HMCCUDEV 000A97099CE8BA defaults: Cannot detect IO device
2018.01.29 16:19:16 1: define BW_OfficeBox HMCCUDEV 0009156999BBEE: Cannot detect IO device
2018.01.29 16:19:16 1: define HM_HM_LC_Sw4_DR_NEQ1693835 HMCCUDEV NEQ1693835: Cannot detect IO device
2018.01.29 16:19:16 1: define Deckenlampe HMCCUDEV Deckenlampen: Cannot detect IO device
2018.01.29 16:19:16 1: PERL WARNING: "my" variable $host masks earlier declaration in same scope at ./FHEM/30_MilightBridge.pm line 72, <$fh> line 983.
2018.01.29 16:19:17 1: Including ./log/fhem.save
2018.01.29 16:19:17 1: configfile: Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
./log/fhem.save: Please define BW_OfficeBox first
Please define BW_OfficeBox first
Please define BW_OfficeBox first
Please define BW_OfficeBox first
Please define BW_OfficeBox first
Please define BW_OfficeBox first
Please define Deckenlampe first
Please define Deckenlampe first
Please define Deckenlampe first
Please define Deckenlampe first
Please define Deckenlampe first
Please define FK_Eingang first
Please define FK_Eingang first
Please define FK_Eingang first
Please define FK_Eingang first
Please define FK_SeitenEingang first
Please define FK_SeitenEingang first
Please define FK_SeitenEingang first
Please define FK_SeitenEingang first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Schaltkanal1 first
Please define Schaltkanal1 first
Please define Schaltkanal1 first
Please define Schaltkanal1 first
Please define Schaltkanal2 first
Please define Schaltkanal2 first
Please define Schaltkanal2 first
Please define Schaltkanal2 first
Please define Schaltkanal3 first
Please define Schaltkanal3 first
Please define Schaltkanal3 first
Please define Schaltkanal3 first
Please define Schaltkanal4 first
Please define Schaltkanal4 first
Please define Schaltkanal4 first
Please define Schaltkanal4 first

2018.01.29 16:19:17 3: Opening GWhite device 127.0.0.1:5333
2018.01.29 16:19:17 3: GWhite device opened
2018.01.29 16:19:17 3: HCS HeizungControl Found 0 Device(s): 0 FHT, 0 HM-CC-TC, 0 MAX, 0 ZWave, demand: 0, idle: 0, ignored: 0, excluded: 0, unknown: 0, eco: no overdrive: no
2018.01.29 16:19:17 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2018.01.29 16:19:17 1: usb create starting
2018.01.29 16:19:17 3: Probing CUL device /dev/ttyS0
2018.01.29 16:19:17 1: PERL WARNING: can't getattr: Input/output error at FHEM/DevIo.pm line 394.
2018.01.29 16:19:17 3: Can't open /dev/ttyS0: Input/output error
2018.01.29 16:19:17 3: Probing CUL device /dev/ttyS1
2018.01.29 16:19:17 3: Can't open /dev/ttyS1: Input/output error
2018.01.29 16:19:17 3: Probing CUL device /dev/ttyS2
2018.01.29 16:19:17 3: Can't open /dev/ttyS2: Input/output error
2018.01.29 16:19:17 3: Probing CUL device /dev/ttyS3
2018.01.29 16:19:17 3: Can't open /dev/ttyS3: Input/output error
2018.01.29 16:19:17 3: Probing CUL device /dev/ttySAC0
2018.01.29 16:19:17 3: Probing CUL device /dev/ttySAC1
2018.01.29 16:19:18 3: Probing CUL device /dev/ttySAC2
2018.01.29 16:19:18 3: Can't open /dev/ttySAC2: Permission denied
2018.01.29 16:19:18 3: Probing CUL device /dev/ttySAC3
2018.01.29 16:19:18 1: usb create end
2018.01.29 16:19:18 0: Featurelevel: 5.8
2018.01.29 16:19:18 0: Server started with 49 defined entities (fhem.pl:16017/2018-01-27 perl:5.020002 os:linux user:fhem pid:1427)
2018.01.29 16:19:18 3: telnetForBlockingFn_1517239158: port 36101 opened
2018.01.29 16:19:18 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
2018.01.29 16:19:18 3: error while requesting https://www.verkehrsinfo.de/httpsmobil/index.php?c=1&lat=&lon= - https://www.verkehrsinfo.de/httpsmobil/index.php?c=1&lat=&lon=: Can't connect(2) to https://www.verkehrsinfo.de:443:  SSL connect attempt failed because of handshake problems
2018.01.29 16:19:19 3: ZWave got config for polycontrol/doorlockv3.xml from ./FHEM/lib/openzwave_deviceconfig.xml.gz
2018.01.29 16:19:28 3: UWZ Unwetterzentrale: Run.1043 Done fetching data
2018.01.29 16:19:29 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2018.01.29 16:19:29 0: HMCCU: Child process for server CB2001 started with PID 1786
2018.01.29 16:19:29 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001_1
2018.01.29 16:19:29 0: CCURPC: Initializing RPC server CB2001
2018.01.29 16:19:29 0: RPC server(s) starting
2018.01.29 16:19:29 0: CCURPC: Callback server created listening on port 7411
2018.01.29 16:19:29 1: CCURPC: CB2001 Adding callback for events
2018.01.29 16:19:29 1: CCURPC: CB2001 Adding callback for new devices
2018.01.29 16:19:29 1: CCURPC: CB2001 Adding callback for deleted devices
2018.01.29 16:19:29 1: CCURPC: CB2001 Adding callback for modified devices
2018.01.29 16:19:29 1: CCURPC: CB2001 Adding callback for replaced devices
2018.01.29 16:19:29 1: CCURPC: CB2001 Adding callback for readded devices
2018.01.29 16:19:29 1: CCURPC: CB2001 Adding callback for list devices
2018.01.29 16:19:29 0: CCURPC: CB2001 Entering server loop
2018.01.29 16:19:34 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2018.01.29 16:19:41 1: HMCCU: Registering callback http://192.168.178.87:7411/fh2001 with ID CB2001 at http://192.168.178.88:2001/
2018.01.29 16:19:41 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2018.01.29 16:19:41 1: HMCCU: RPC callback with URL http://192.168.178.87:7411/fh2001 initialized
2018.01.29 16:19:42 2: CCURPC: CB2001 NewDevice received 61 device specifications
2018.01.29 16:19:46 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2018.01.29 16:19:46 2: HMCCU: No client devices matching .*
2018.01.29 16:19:46 2: HMCCU: Updated devices. Success=0 Failed=0
2018.01.29 16:19:46 1: HMCCU: All RPC servers running
2018.01.29 16:20:17 3: HCS HeizungControl Found 0 Device(s): 0 FHT, 0 HM-CC-TC, 0 MAX, 0 ZWave, demand: 0, idle: 0, ignored: 0, excluded: 0, unknown: 0, eco: no overdrive: no
2018.01.29 16:21:17 3: HCS HeizungControl Found 0 Device(s): 0 FHT, 0 HM-CC-TC, 0 MAX, 0 ZWave, demand: 0, idle: 0, ignored: 0, excluded: 0, unknown: 0, eco: no overdrive: no
2018.01.29 16:22:09 0: Server shutdown
2018.01.29 16:22:09 1: HMCCU: Deregistering RPC server http://192.168.178.87:7411/fh2001 at http://192.168.178.88:2001/
2018.01.29 16:22:09 0: HMCCU: Stopping RPC server CB2001 with PID 1786
2018.01.29 16:22:09 0: CCURPC: CB2001 Server loop terminated
2018.01.29 16:22:09 2: CCURPC: Eventcount DD = 0
2018.01.29 16:22:09 2: CCURPC: Eventcount EV = 0
2018.01.29 16:22:09 2: CCURPC: Eventcount EX = 1
2018.01.29 16:22:09 2: CCURPC: Eventcount IN = 1
2018.01.29 16:22:09 2: CCURPC: Eventcount ND = 61
2018.01.29 16:22:09 2: CCURPC: Eventcount RA = 0
2018.01.29 16:22:09 2: CCURPC: Eventcount RD = 0
2018.01.29 16:22:09 2: CCURPC: Eventcount SL = 1
2018.01.29 16:22:09 2: CCURPC: Eventcount UD = 0
2018.01.29 16:22:09 2: CCURPC: Eventcount total = 64
2018.01.29 16:22:09 2: CCURPC: Eventcount writeerror =
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 29 Januar 2018, 18:05:48
Aaaaah ja! Dein Problem ist

HMCCU: No devices read from CCU 192.168.178.88

HMCCU erreicht anscheinend die CCU, aber aus irgendwelchen Gründen können die Devices der CCU nicht gelesen werden.

Du kannst mal folgendes versuchen:


set d_ccu hmscript !GetDeviceList dump


Das sollte eine Liste aller CCU Kanäle ausgeben. Das ist die gleiche Funktion, die beim Starten aufgerufen wird.
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Steffen am 29 Januar 2018, 22:13:15
Zitat von: zap am 29 Januar 2018, 18:05:48

Du kannst mal folgendes versuchen:


set d_ccu hmscript !GetDeviceList dump


Das sollte eine Liste aller CCU Kanäle ausgeben. Das ist die gleiche Funktion, die beim Starten aufgerufen wird.

Ok und was kann ich daran erkennen?!?



C;OEQ1012341:0;Deckenlampen:0;0
C;OEQ1012341:1;HM-LC-Sw1-DR OEQ1012341:1;2
D;BidCos-RF;OEQ1012341;Deckenlampen;HM-LC-Sw1-DR;2
C;0000D7099579A0:0;FK_Eingang:0;0
C;0000D7099579A0:1;HMIP-SWDO 0000D7099579A0:1;1
D;HmIP-RF;0000D7099579A0;FK_Eingang;HMIP-SWDO;2
C;0000D7099555C2:0;FK_SeitenEingang:0;0
C;0000D7099555C2:1;HMIP-SWDO 0000D7099555C2:1;1
D;HmIP-RF;0000D7099555C2;FK_SeitenEingang;HMIP-SWDO;2
C;NEQ1693835:0;HM-LC-Sw4-DR NEQ1693835:0;0
C;NEQ1693835:1;HM-LC-Sw4-DR NEQ1693835:1;2
C;NEQ1693835:2;HM-LC-Sw4-DR NEQ1693835:2;2
C;NEQ1693835:3;HM-LC-Sw4-DR NEQ1693835:3;2
C;NEQ1693835:4;HM-LC-Sw4-DR NEQ1693835:4;2
D;BidCos-RF;NEQ1693835;HM-LC-Sw4-DR NEQ1693835;HM-LC-Sw4-DR;5
C;BidCoS-RF:0;HM-RCV-50 BidCoS-RF:0;0
C;BidCoS-RF:1;HM-RCV-50 BidCoS-RF:1;1
C;BidCoS-RF:2;HM-RCV-50 BidCoS-RF:2;1
C;BidCoS-RF:3;HM-RCV-50 BidCoS-RF:3;1
C;BidCoS-RF:4;HM-RCV-50 BidCoS-RF:4;1
C;BidCoS-RF:5;HM-RCV-50 BidCoS-RF:5;1
C;BidCoS-RF:6;HM-RCV-50 BidCoS-RF:6;1
C;BidCoS-RF:7;HM-RCV-50 BidCoS-RF:7;1
C;BidCoS-RF:8;HM-RCV-50 BidCoS-RF:8;1
C;BidCoS-RF:9;HM-RCV-50 BidCoS-RF:9;1
C;BidCoS-RF:10;HM-RCV-50 BidCoS-RF:10;1
C;BidCoS-RF:11;HM-RCV-50 BidCoS-RF:11;1
C;BidCoS-RF:12;HM-RCV-50 BidCoS-RF:12;1
C;BidCoS-RF:13;HM-RCV-50 BidCoS-RF:13;1
C;BidCoS-RF:14;HM-RCV-50 BidCoS-RF:14;1
C;BidCoS-RF:15;HM-RCV-50 BidCoS-RF:15;1
C;BidCoS-RF:16;HM-RCV-50 BidCoS-RF:16;1
C;BidCoS-RF:17;HM-RCV-50 BidCoS-RF:17;1
C;BidCoS-RF:18;HM-RCV-50 BidCoS-RF:18;1
C;BidCoS-RF:19;HM-RCV-50 BidCoS-RF:19;1
C;BidCoS-RF:20;HM-RCV-50 BidCoS-RF:20;1
C;BidCoS-RF:21;HM-RCV-50 BidCoS-RF:21;1
C;BidCoS-RF:22;HM-RCV-50 BidCoS-RF:22;1
C;BidCoS-RF:23;HM-RCV-50 BidCoS-RF:23;1
C;BidCoS-RF:24;HM-RCV-50 BidCoS-RF:24;1
C;BidCoS-RF:25;HM-RCV-50 BidCoS-RF:25;1
C;BidCoS-RF:26;HM-RCV-50 BidCoS-RF:26;1
C;BidCoS-RF:27;HM-RCV-50 BidCoS-RF:27;1
C;BidCoS-RF:28;HM-RCV-50 BidCoS-RF:28;1
C;BidCoS-RF:29;HM-RCV-50 BidCoS-RF:29;1
C;BidCoS-RF:30;HM-RCV-50 BidCoS-RF:30;1
C;BidCoS-RF:31;HM-RCV-50 BidCoS-RF:31;1
C;BidCoS-RF:32;HM-RCV-50 BidCoS-RF:32;1
C;BidCoS-RF:33;HM-RCV-50 BidCoS-RF:33;1
C;BidCoS-RF:34;HM-RCV-50 BidCoS-RF:34;1
C;BidCoS-RF:35;HM-RCV-50 BidCoS-RF:35;1
C;BidCoS-RF:36;HM-RCV-50 BidCoS-RF:36;1
C;BidCoS-RF:37;HM-RCV-50 BidCoS-RF:37;1
C;BidCoS-RF:38;HM-RCV-50 BidCoS-RF:38;1
C;BidCoS-RF:39;HM-RCV-50 BidCoS-RF:39;1
C;BidCoS-RF:40;HM-RCV-50 BidCoS-RF:40;1
C;BidCoS-RF:41;HM-RCV-50 BidCoS-RF:41;1
C;BidCoS-RF:42;HM-RCV-50 BidCoS-RF:42;1
C;BidCoS-RF:43;HM-RCV-50 BidCoS-RF:43;1
C;BidCoS-RF:44;HM-RCV-50 BidCoS-RF:44;1
C;BidCoS-RF:45;HM-RCV-50 BidCoS-RF:45;1
C;BidCoS-RF:46;HM-RCV-50 BidCoS-RF:46;1
C;BidCoS-RF:47;HM-RCV-50 BidCoS-RF:47;1
C;BidCoS-RF:48;HM-RCV-50 BidCoS-RF:48;1
C;BidCoS-RF:49;HM-RCV-50 BidCoS-RF:49;1
C;BidCoS-RF:50;HM-RCV-50 BidCoS-RF:50;1
D;BidCos-RF;BidCoS-RF;HM-RCV-50 BidCoS-RF;HM-RCV-50;51
C;0009156999BBEE:0;HmIP-SMI 0009156999BBEE:0;0
C;0009156999BBEE:1;HmIP-SMI 0009156999BBEE:1;1
D;HmIP-RF;0009156999BBEE;HmIP-SMI 0009156999BBEE;HmIP-SMI;2
C;000A97099CE8BA:0;HmIP-WTH-2 000A97099CE8BA:0;0
C;000A97099CE8BA:1;HmIP-WTH-2 000A97099CE8BA:1;1
C;000A97099CE8BA:2;HmIP-WTH-2 000A97099CE8BA:2;2
C;000A97099CE8BA:3;HmIP-WTH-2 000A97099CE8BA:3;1
C;000A97099CE8BA:4;HmIP-WTH-2 000A97099CE8BA:4;2
C;000A97099CE8BA:5;HmIP-WTH-2 000A97099CE8BA:5;1
C;000A97099CE8BA:6;HmIP-WTH-2 000A97099CE8BA:6;2
C;000A97099CE8BA:7;HmIP-WTH-2 000A97099CE8BA:7;1
D;HmIP-RF;000A97099CE8BA;HmIP-WTH-2 000A97099CE8BA;HmIP-WTH-2;8
C;000A570998B072:0;Rauchmelder:0;0
C;000A570998B072:1;HmIP-SWSD 000A570998B072:1;0
D;HmIP-RF;000A570998B072;Rauchmelder;HmIP-SWSD;2
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 30 Januar 2018, 06:57:21
Daran erkennt man, dass die Abfrage der Geräte funktioniert, nur eben beim Start nicht. Sehr seltsam.

Mach mal bitte das Update auf die 4.2, die es ab heute gibt.
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Steffen am 30 Januar 2018, 16:03:48
Zitat von: zap am 30 Januar 2018, 06:57:21
Daran erkennt man, dass die Abfrage der Geräte funktioniert, nur eben beim Start nicht. Sehr seltsam.

Mach mal bitte das Update auf die 4.2, die es ab heute gibt.

Update habe ich gemacht aber bekomme wieder diese Fehlermeldungen:

2018.01.30 15:29:28 1: Including fhem.cfg
2018.01.30 15:29:28 3: telnetPort: port 7072 opened
2018.01.30 15:29:29 3: WEB: port 8083 opened
2018.01.30 15:29:29 3: WEBphone: port 8084 opened
2018.01.30 15:29:29 3: WEBtablet: port 8085 opened
2018.01.30 15:29:29 2: eventTypes: loaded 1042 events from ./log/eventTypes.txt
2018.01.30 15:29:30 3: error while requesting https://www.verkehrsinfo.de/httpsmobil/index.php?c=1&lat=&lon= - connect to https://www.verkehrsinfo.de:443: Network is unreachable
2018.01.30 15:30:21 1: HMCCU: Device d_ccu. Initialized version 4.2
2018.01.30 15:30:21 1: HMCCU: No devices read from CCU 192.168.178.88
2018.01.30 15:30:21 1: HMCCU: No RPC interfaces found on CCU 192.168.178.88
2018.01.30 15:30:21 3: Illegal RPC interface BidCos-RF
2018.01.30 15:30:21 3: HMCCU: Illegal RPC port 2001
2018.01.30 15:30:21 3: BigBoxBerlin: new ext defined infix:ftui/: dir:./www/tablet:
2018.01.30 15:30:21 3: Registering HTTPSRV BigBoxBerlin for URL /ftui   and assigned link ftui/ ...
2018.01.30 15:30:21 3: Opening ZWDongle_0 device /dev/ttyACM0
2018.01.30 15:30:21 3: Setting ZWDongle_0 serial parameters to 115200,8,N,1
2018.01.30 15:30:22 3: ZWDongle_0 device opened
2018.01.30 15:30:25 1: define Schaltkanal1 HMCCUCHN NEQ1693835:1: Cannot detect IO device
2018.01.30 15:30:25 1: define Schaltkanal2 HMCCUCHN NEQ1693835:2 defaults: Cannot detect IO device
2018.01.30 15:30:25 1: define Schaltkanal3 HMCCUCHN NEQ1693835:3 defaults: Cannot detect IO device
2018.01.30 15:30:25 1: define Schaltkanal4 HMCCUCHN NEQ1693835:4 defaults: Cannot detect IO device
2018.01.30 15:30:25 1: define FK_Eingang HMCCUCHN 0000D7099579A0:1: Cannot detect IO device
2018.01.30 15:30:25 1: define FK_SeitenEingang HMCCUCHN 0000D7099555C2:1 defaults: Cannot detect IO device
2018.01.30 15:30:25 1: define Rauchmelder HMCCUCHN 000A570998B072:1 defaults: Cannot detect IO device
2018.01.30 15:30:25 1: define Heizung_Officebox HMCCUDEV 000A97099CE8BA defaults: Cannot detect IO device
2018.01.30 15:30:25 1: define BW_OfficeBox HMCCUDEV 0009156999BBEE: Cannot detect IO device
2018.01.30 15:30:25 1: define HM_HM_LC_Sw4_DR_NEQ1693835 HMCCUDEV NEQ1693835: Cannot detect IO device
2018.01.30 15:30:25 1: define Deckenlampe HMCCUDEV Deckenlampen: Cannot detect IO device
2018.01.30 15:30:25 1: PERL WARNING: "my" variable $host masks earlier declaration in same scope at ./FHEM/30_MilightBridge.pm line 72, <$fh> line 985.
2018.01.30 15:30:26 1: PERL WARNING: Unquoted string "fh" may clash with future reserved word at ./FHEM/39_Talk2Fhem.pm line 303, <$fh> line 1094.
2018.01.30 15:30:26 1: PERL WARNING: Use of uninitialized value $string in substitution (s///) at ./FHEM/39_Talk2Fhem.pm line 602, <$fh> line 1100.
2018.01.30 15:30:26 3: [HeizungOfficeBoxHC] device <Heizung_Officebox> in fhem not defined, but accepted
2018.01.30 15:30:26 1: define d_rpcBidCos_RF HMCCURPCPROC 192.168.178.88 BidCos-RF: Invalid port or interface BidCos-RF
2018.01.30 15:30:26 1: define d_rpcHmIP_RF HMCCURPCPROC 192.168.178.88 HmIP-RF: Invalid port or interface HmIP-RF
2018.01.30 15:30:26 1: Including ./log/fhem.save
2018.01.30 15:30:26 1: configfile: Illegal RPC interface BidCos-RF
HMCCU: Illegal RPC port 2001
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Invalid port or interface BidCos-RF
Invalid port or interface HmIP-RF
./log/fhem.save: Please define BW_OfficeBox first
Please define BW_OfficeBox first
Please define BW_OfficeBox first
Please define BW_OfficeBox first
Please define BW_OfficeBox first
Please define BW_OfficeBox first
Please define BW_OfficeBox first
Please define Deckenlampe first
Please define Deckenlampe first
Please define Deckenlampe first
Please define Deckenlampe first
Please define Deckenlampe first
Please define FK_Eingang first
Please define FK_Eingang first
Please define FK_Eingang first
Please define FK_Eingang first
Please define FK_Eingang first
Please define FK_SeitenEingang first
Please define FK_SeitenEingang first
Please define FK_SeitenEingang first
Please define FK_SeitenEingang first
Please define FK_SeitenEingang first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define HM_HM_LC_Sw4_DR_NEQ1693835 first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Heizung_Officebox first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Rauchmelder first
Please define Schaltkanal1 first
Please define Schaltkanal1 first
Please define Schaltkanal1 first
Please define Schaltkanal1 first
Please define Schaltkanal1 first
Please define Schaltkanal2 first
Please define Schaltkanal2 first
Please define Schaltkanal2 first
Please define Schaltkanal2 first
Please define Schaltkanal2 first
Please define Schaltkanal3 first
Please define Schaltkanal3 first
Please define Schaltkanal3 first
Please define Schaltkanal3 first
Please define Schaltkanal3 first
Please define Schaltkanal4 first
Please define Schaltkanal4 first
Please define Schaltkanal4 first
Please define Schaltkanal4 first
Please define Schaltkanal4 first
Please define d_rpcBidCos_RF first
Please define d_rpcBidCos_RF first
Please define d_rpcBidCos_RF first
Please define d_rpcHmIP_RF first
Please define d_rpcHmIP_RF first
Please define d_rpcHmIP_RF first
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 05 Februar 2018, 18:20:04
Hallo,

ich muss mich auch nochmals melden da ich nach wie vor noch die Probleme habe, dass die CCU2 nach einem Spannungsausfall nicht mehr durch HMCCU erreicht wird. Ich habe in das DEF bei HMCCU "192.168.1.32 waitforccu=900" eingetragen

Im Log stehen folgende Einträge (gekürzt):
2018.02.05 16:21:37 1: HMCCU: Device CCU2. Initialized version 4.2.001
2018.02.05 16:21:37 1: HMCCU: No devices read from CCU 192.168.1.32
2018.02.05 16:21:38 1: HMCCU: No RPC interfaces found on CCU 192.168.1.32
2018.02.05 16:21:38 3: Illegal RPC interface BidCos-RF
2018.02.05 16:21:38 3: HMCCU: Illegal RPC port 2001
2018.02.05 16:21:40 1: define HM_OG_FKE1_BueroReinhard HMCCUDEV 0000D3C995F8F8: Cannot detect IO device
2018.02.05 16:21:40 1: define HM_OG_FK1_Schlafzimmer HMCCUDEV 0000D3C995F904: Cannot detect IO device
......


Fhem ist nach Spannungswiderkehr bereits nach ca. 1,10 Minuten gestartet, egal was ich unter waitforccu eintrage. Die CCU2 selbst, benötigt bei mir ca. 5,20 Minuten. Auch ich vermute auch die CCU2 wird von HMCCU erreicht und deshalb wird der Parameter waitforccu nicht mehr beachtet.
ZitatAaaaah ja! Dein Problem ist
HMCCU: No devices read from CCU 192.168.178.88
HMCCU erreicht anscheinend die CCU, aber aus irgendwelchen Gründen können die Devices der CCU nicht gelesen werden.

Für mich stellt sich noch die Frage wie ich das Problem lösen kann:
Eventuell gibt es noch eine Lösung innerhalb der HMCCU (zap wäre da gefordert) oder ich prüfe in einem Notify die Readings rpcstate und state (von HMCCU) und führe nach 10 Minuten ein shutdown restart von fhem aus, wenn die Readings nicht running/OK sind.

@zap siehst du noch eine andere Möglichkeit von HMCCU aus zu erkennen ob die Devices korrekt gelesen werden?

Sehr gut funktioniert bei mir das automatisierte starten von HMCCU und der HMCCURPCPROC Server, wenn ich bei laufendem Fhem die CCU2 neu starte. Spätestens 11-15 Minuten sind alle Devicese wieder ansprechbar.

Gruß Reinhard

Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 05 Februar 2018, 18:39:02
Das Problem ist vielschichtig. Wie du richtig erkannt hast, braucht die CCU deutlich länger, bis nach einem Neustart alle Dienste wieder laufen.

Rein netztechnisch ist die CCU relativ schnell wieder da. Dadurch meint HMCCU, dass die CCU verfügbar ist und versucht, die Geräte und Schnittstellen auszulesen. Das schlägt fehl, da noch nicht alle Dienste der CCU laufen.

FHEM müsste in diesem Fall warten ... und warten .... die Frage ist, wie lange? Was ist, wenn die CCU aus irgendwelchen Gründen gar nicht startet. Soll dann FHEM auch nicht starten bzw. ewig warten? Vermutlich keine so gute Idee. Dann läuft gar nichts mehr, nur weil die CCU nicht läuft.

Eine spätere Aktualisierung aller Devices von der CCU macht auch keinen Sinn. Die Definition der HMCCUDEV und HMCCUCHN Devices ist dann schon lange fehlgeschlagen.

Im Moment weiß ich darauf keine Antwort.
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 06 Februar 2018, 20:57:17
Hallo zap,

ich habe mir derzeit mit 2 notifys und einem dummy beholfen, den dummy setze ich immer 15 Minuten nach Neustart von Fhem durch ein notify. Das zweite Notify wird durch den dummy (nach 15 Minuten) getriggert und prüft rpcstate und state vom HMCCU Device, sind diese nicht "running" und "OK" so starte ich fhem mit schutdown restart ohne Rückfrage neu.

Dies ist zwar eine sehr einfache, aber für mich sehr wirkungsvolle Lösung. Ich habe alle meine HmIP und HM Komponenten in meine CCU2 eingebunden und auf dem Raspi in Fhem befindet sich die Logik, abgesehen von wichtigen Direktverknüpfungen von Geräten untereinander. Was nutzt mir da ein laufendes fhem, wenn ich alle meine Geräte nicht mehr "sehen" und steuern kann.

Wie löst denn der Rest der fhem Gemeinde mit CCU2, ohne USV diese Problematik?
Gibt es bei euch niemals Spannungsausfälle?
Habt ihr bessere oder einfachere Lösungen?

Ich habe heute den ganzen Tag versucht, den Neustart in einen einzigen doif abzubilden, nach 10 Stunden und gefühlt 50 Neustarts habe ich aufgegeben (hoffentlich liest Damian dies nicht mit :'().

Gruß Reinhard


Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Steffen am 07 Februar 2018, 05:42:16
Guten Morgen!

@Reinhard...Da ich am selben Problem hänge könnte wir ja vielleicht zusammen Arbeiten und du könntest ja deine Doif mal hier abbilden?!

Denn ich habe das selbe Problem, mir nützt ein laufendes Fhem auch nichts, wenn fast alle HMIP fehlen und nicht ansprechbar sind.

Denn bei mir ist in diesem Fall sogar das Fhem ein wenig Mobil, da kann es öfters mal vorkommen das Fhem ohne Strom ist.

Mfg Steffen
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: zap am 07 Februar 2018, 12:06:08
ich muss darüber nachdenken. eventuell kann man auch die CCU dazu bewegen, eine Info an FHEM zu schicken, sobald alle Dienste laufen.

wohne seit 17 Jahren in meinem Haus und hatte noch nie einen Strohmausfall.
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: Rewe2000 am 07 Februar 2018, 20:01:38
Hallo Steffen,

anbei meine sehr einfache, aber wie ich denke wirkungsvolle Lösung um auch im tiefsten Bayern zukünftig Stromausfälle unbeschadet zu überstehen.

ZitatDenn bei mir ist in diesem Fall sogar das Fhem ein wenig Mobil, da kann es öfters mal vorkommen das Fhem ohne Strom ist.
Hast du dein Fhem im Wohnmobil verbaut?

Sicherlich lässt sich auch alles in einem doif realisieren, ich hatte aber Probleme mit dem attr wait, dieses wird anscheinend während eines Neustarts anders abgearbeitet. Wenn ich mal wieder bessere Nerven habe (oder Hilfe bekomme ;)) mach ich noch einen Versuch, bis dahin kann ich mit der angehängten Lösung leben.

Hier eine kurze Beschreibung zum Ablauf:
Beim Neustart des Raspi wird von Fhem "global:INITIALIZED" in das Log geschrieben, dieser Logeintrag triggert das notify "no_HMCCU_Neustartdummy_setzen".
Durch das enthaltene "sleep 900" wird der dummy "du_HMCCU_Neustart" erst 15 Minuten später gesetzt.

Das setzen dieses dummy wiederum triggert ein weiteres notify "no_HMCCU_Neustart_ausloesen", welches prüft, ob die Readings der CCU2 "rpcstate" = "running" und "state" = "OK" sind. Ist dies nicht der Fall, so wird Fhem ganz bewusst mit "shutdown restart" neu gestartet.

Die 10 Sekunden Wartezeit im notify "no_HMCCU_Neustart_ausloesen" vor dem "shutdown restart" sollen Fhem ermöglichen, noch vor den Neustart eine Meldung über Pushover zu senden.

In diesen 15 Minuten müsste die CCU2 in jeden Fall nach einem Stromausfall wieder bereit sein. Sollte dennoch einmal die CCU2 nicht mehr bereit sein, so startet Fhem maximal 4 x pro Stunde.

Diese Vorgehensweise mach natürlich nur Sinn, wenn Fhem ohne die CCU2 nicht betrieben werden soll. Wenn jemand wert darauf legt, dass Fhem auch ggf. auch ohne CCU2 noch weiterlaufen soll, für den ist diese Lösung nicht brauchbar.

Eine kurze Funktionsbeschreibung ist im comment der Devices direkt enthalten, sollten noch Fragen bestehen, bitte einfach melden.

Dummy:
defmod du_HMCCU_Neustart dummy
attr du_HMCCU_Neustart DbLogExclude .*
attr du_HMCCU_Neustart comment 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.
attr du_HMCCU_Neustart group Hardware
attr du_HMCCU_Neustart room Homematic
attr du_HMCCU_Neustart webCmd on:off

setstate du_HMCCU_Neustart off
setstate du_HMCCU_Neustart 2018-02-07 19:15:17 state off


notify Neustart ausführen:
defmod no_HMCCU_Neustart_ausloesen notify (du_HMCCU_Neustart:on-for-timer.*) {\
my $r1 = ReadingsVal("CCU2", "rpcstate", "undefined");;;;\
my $r2 = ReadingsVal("CCU2", "state", "undefined");;;;\
if ($r1 ne "running" or $r2 ne "OK") {   \
Log 3, "HMCCU Kommunikation läuft nicht - $r1/$r2, Fhem wurde soeben neu gestartet!";;;;\
fhem("set Postmaster msg title=Systemmeldung! sound=persistent Fhem Neustart ausgeführt, wegen fehlerhafter Kommunikation HMCCU");;;;\
fhem("sleep 10 ;; shutdown restart")\
} else {\
Log 3, "HMCCU läuft - $r1/$r2, ein Neustart von Fhem ist nicht notwendig!"\
}\
}
attr no_HMCCU_Neustart_ausloesen DbLogExclude .*
attr no_HMCCU_Neustart_ausloesen comment Dieses notify prüft über ein dummy, ob die HMCCU korrekt läuft.\
Ist dies nicht der Fall, so wird über Pushover eine Nachricht versendet und fhem nach einer kurzen Wartezeit mit schutdown restart neu gestartet.
attr no_HMCCU_Neustart_ausloesen group Hardware
attr no_HMCCU_Neustart_ausloesen room Homematic

setstate no_HMCCU_Neustart_ausloesen 2018-02-07 19:15:07
setstate no_HMCCU_Neustart_ausloesen 2018-02-07 19:00:06 state active


notify dummy verzögert setzen:
defmod no_HMCCU_Neustartdummy_setzen notify global:INITIALIZED sleep 900;;\
set du_HMCCU_Neustart on-for-timer 10
attr no_HMCCU_Neustartdummy_setzen DbLogExclude .*
attr no_HMCCU_Neustartdummy_setzen comment Dieses notify erkennt einen erfolgten Systemstart von fhem über "global:INITIALIZED" und setzt einen dummy. Der Trigger des dummy löst die Prüfung der Kommunikation der HMCCU über ein weiteres notify aus.
attr no_HMCCU_Neustartdummy_setzen group Hardware
attr no_HMCCU_Neustartdummy_setzen room Homematic

setstate no_HMCCU_Neustartdummy_setzen 2018-02-07 19:00:06
setstate no_HMCCU_Neustartdummy_setzen 2018-02-07 19:00:06 state active



Hinweis:
Zum testen sollte aus Sicherheitsgründen Fhem und der Raspi mit shutdown kontrolliert gestoppt werden. Andere User hatten schon mal Probleme mit einer defekten Speicherkarte und/oder SQL-Datenbank, nachdem das Netzteil (für Fhem) unerwartet gezogen wurde.

Gruß Reinhard
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: ptr201711 am 08 Juli 2018, 20:28:13
 :)
Hatte das gleiche Problem. Obiges von    Rewe2000 hat geholfen. Danke!
Titel: Antw:Korrekter Start CCU2 und Fhem (auf Raspi) nach Stromausfall
Beitrag von: dadoc am 15 Juli 2018, 10:12:14
Auch ich wurde mit diesem Workaround geholfen ;)
Vielen Dank
Martin