XML-RPC init / Neustart der CCU

[cirion]

Hallo,

es scheint ja so, dass sich die CCU per init übermittelte Kommunikationspartner nicht über einen Neustart hinaus merkt. Gibt es eine Möglichkeit, den Neustart irgendwie sinnvoll festzustellen (ohne Ping-Pong-Orgien oder gleich ein init() jede Minute)?

Gruß,
cirion

[thkl]

Naja wenn Du Dich als Consumer via Init auf dem BidCos Interface anmeldest und über einen Zeitraum x keine Events mehr bekommst, dann ist es Zeit für einen (re)Init. Wie lange x ist hängt von den Geräten ab. zb Thermostate sind recht gesprächig.
Ich würde meinen, aller Minute muss mindestens ein Event kommen.

[hobbyquaker]

Ich verfahre bei rfd/hs485d so dass ich alle 30 sekunde prüfe wie lang der letzte Event her ist. Wenn 30sek kein Event kam versuche ich einen per Ping zu erzeugen, wenn 60sek kein Event reinkam führ ich den Init erneut durch. Beim hmipserver funktioniert der Ping leider (noch?) nicht, hier wird dann halt grundsätzlich nach 60sek ohne Event ein erneuter Init durchgeführt.

(ohne Ping-Pong-Orgien oder gleich ein init() jede Minute)?

Was hast da dagegen? Funktioniert und schmerzt doch nicht

[cirion]

Was ich dagegen habe: Solche Polling-Geschichten mit größeren Perioden haben für mich als Informatiker sowieso immer einen üblen Beigeschmack - ist halt nicht sonderlich elegant und verursacht unnötigen Netzwerk-Traffic. Hauptgrund ist allerdings, dass man potenziell ein Event zwischen Neustart und erneutem init() verpasst. Da die komplette Logik über meine Software läuft und die CCU nur als Hardwareschnittstelle dient, wäre das in bestimmten Situationen lästig bis ärgerlich. Deshalb hätte ich gerne die Wahrscheinlichkeit dafür so niedrig wie möglich.

Werde mich wohl bei Gelegenheit mal mit Scripting auf der CCU beschäftigen müssen, und dann bei jedem Start meine Software explizit benachrichtigen.

[hobbyquaker]

Hauptgrund ist allerdings, dass man potenziell ein Event zwischen Neustart und erneutem init() verpasst. Da die komplette Logik über meine Software läuft und die CCU nur als Hardwareschnittstelle dient, wäre das in bestimmten Situationen lästig bis ärgerlich. Deshalb hätte ich gerne die Wahrscheinlichkeit dafür so niedrig wie möglich.

Werde mich wohl bei Gelegenheit mal mit Scripting auf der CCU beschäftigen müssen, und dann bei jedem Start meine Software explizit benachrichtigen.

Selbst wenn die CCU Deine Software direkt nach dem Start der Rega benachrichtigen würde wären schon 2-3 Minuten vergangen in denen potentiell Events verloren gehen können. In Anbetracht dieser sehr langen Bootzeit der CCU würd ich da eher noch über einen anderen Ansatz nachdenken: gar keine CCU sondern nur die Schnittstellenprozesse (rfd/hs485d/hmserver oder vielleicht auch Homegear falls Du kein HmIP einsetzt) verwenden, idealerweise auf dem selben Host auf dem auch Deine Software läuft - dann hättest Du auch die Möglichkeit diese Prozesse direkt zu kontrollieren, der Traffic bleibt auf dem Loopback und man hat noch ein Sicherheits-Plus weil man nicht die unverschlüsselten und ohne Auth erreichbaren RPC Server im Netzwerk lauschen lassen muss.

[cirion]

Selbst wenn die CCU Deine Software direkt nach dem Start der Rega benachrichtigen würde wären schon 2-3 Minuten vergangen in denen potentiell Events verloren gehen können.

Da ich einen RPi 3 mit RaspberryMatic nutze, muss ich Gott sei dank nicht mit solchen Reboot-Zeiten kämpfen. Aber ja, klar können dann auch Events verloren gehen, es geht mir halt ums Minimieren dessen. Ganz verhindern kann ich es sowieso nicht.

gar keine CCU sondern nur die Schnittstellenprozesse (rfd/hs485d/hmserver oder vielleicht auch Homegear falls Du kein HmIP einsetzt) verwenden, idealerweise auf dem selben Host auf dem auch Deine Software läuft - dann hättest Du auch die Möglichkeit diese Prozesse direkt zu kontrollieren, der Traffic bleibt auf dem Loopback und man hat noch ein Sicherheits-Plus weil man nicht die unverschlüsselten und ohne Auth erreichbaren RPC Server im Netzwerk lauschen lassen muss.

Das Auslagern der Schnittstellen- und Logikschichten meiner Software auf den RPi habe ich durchaus schon in Betracht gezogen - das wird (wenn überhaupt) aber noch eine ganze Weile dauern. Ändert aber sowieso nicht viel an der Event-Situation (verschlechtert sie sogar minimal, da dann ja auch meine Software erstmal starten muss, was den gesamten Reboot etwas verzögert). Den Sicherheitsbonus finde ich allerdings vernachlässigbar - wenn jemand Zugriff auf mein lokales Netzwerk erhält, habe ich deutlich größere Probleme als die mangelnde Authentifizierung am XML-RPC-Server. Insofern ist mein Netz hinreichend gut geschützt - da wäre ein 868-MHz-Jammer der deutlich einfachere Weg für einen potenziellen Störenfried.

Da meine Software sowieso schon eine eigene HTTP-Schnittstelle besitzt, werde ich also wohl erstmal den Weg über ein Script gehen, das beim Neustart per wget einen Request absetzt...

[Familienvater]

Hi,

also bei mir wäre es relativ einfach zu erkennen, wenn der hs485d/rfd/die CCU "stirbt", im Schnitt habe ich 3,5 Events pro Sekunde. Da ich meine CCU aber das letzte mal vor über 300 Tagen neu gestartet habe, und ich nur Daten zum Loggen verarbeite, habe ich mir dafür keine ausgefeilten Mechanismen ausgedacht.

Wenn die Zentrale autark neu startet, dann ist eh irgendwas schiefgelaufen.

Ich find die Methode von hobbyquaker aber smart, wenn eine gewisse Zeit nichts kommt mal PING/PONG zu machen.

Der Familienvater

[zap]

Nur schade, dass der PONG seit dem letzten CCU Firmware Update nicht mehr funktioniert. Wenn man ein PING schickt, erhält man statt eines PONG folgende Fehlermeldung im Log der CCU:

Code: Alles auswählen

May 26 19:01:14 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= CENTRAL [../Platform/DOM/iseXmlRpc.cpp (2166)]
May 26 19:01:14 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","CENTRAL","PONG","LALA"}]}) on http://192.168.1.7:7411/fh2001:
May 26 19:01:14 homematic-ccu2 user.err rfd: XmlRpc transport error

Witzigerweise scheint das ein alter Fehler zu sein, den EQ-3 "reaktiviert" hat.

[hobbyquaker]

Ping/Pong funktioniert mit rfd und hs485d schon. Der Fehler den Du gepostet hast kommt von der Rega, die beschwert sich weil Sie das Gerät "CENTRAL" (von dem der Pong event kommt) nicht kennt. Macht aber nichts, subscribers die ein Init ausgeführt haben erhalten den Pong ja trotzdem. Der Fehler in der Rega ist auch harmlos, das einzig nervige ist der überflüssige Log-Eintrag. Hat Jens-Maus in seiner Beta aber bereits gefixed, bleibt zu hoffen dass der Fix Einzug in die offizielle Firmware findet.
Wo er allerdings nicht funktioniert (und auch noch nie funktioniert hat) ist mit dem hm(ip)server, der generiert kein Pong wenn man ihm ein Ping schickt.
Siehe auch: https://github.com/eq-3/occu/issues/44 und https://github.com/eq-3/occu/issues/42

[cirion]

Nur für's Protokoll, falls mal jemand das gleiche Problem haben sollte:

Ich habe das ganze nun mit einer Benachrichtigung mittels wget in /usr/local/etc/rc.local gelöst, nachdem ein HomeMatic-Script mit system.Exec("wget...") beim Systemstart (noch) nicht zu funktionieren scheint (später kein Problem).

Prinzipiell könnte man mittels wget auch einen XML-RPC-Request absetzen, falls einem kein anderes HTTP-API zur Verfügung steht. Halte ich für insgesamt simpler, als bedingt auf Pongs zu warten.

Gruß,
cirion


P.S.:
Ist vi tatsächlich der einzige (vorinstallierte) Editor auf der (O)CCU? Meine Linuxzeiten liegen fast 20 Jahre zurück, und selbst da hat sich kaum noch jemand vi angetan...