HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:

[Ban]

Hallo Reinhard,

freut mich, dass es bei dir auch funktioniert!
Ist aktuell ein Workaround, aber ein praktikabler.

Ich verstehe aber auch noch nicht, warum es nur bei uns auftritt.
Das möchte ich eigentlich noch rausbekommen. Gestern war aber zu lang, deswegen habe ich mit dem Ergebnis erstmal aufgehört.
Morgen kommt ein RPI-RF-MOD Funk-Modul. Ich will mal schauen, wie sich das ganze mit RaspberryMatic verhält.
Wahrscheinlich nicht anders, aber ist auch Spieltrieb dabei:-)

Viele Grüße,
Ban

[Rewe2000]

Hallo Ban,

ich will auch noch Ersatz für meine CCU3, hab mir auch überlegt einen Raspi 3 B und ein Funkmodul RPI-RF-MOD zu kaufen, mit Raspimatic wäre das ja eine vollwertige CCU3, nur ohne Gehäuse. Berichte biite mal wie es bei dir läuft und ob da der Fehler in gleicher Weise auftritt.

Ich wollte gestern nochmals meine CCU2 mit alter Firmware und altem Restore und gleichzeitig mit altem RASPI Image gleichzeitig testen, ob da der Fehler auch noch auftritt. Bekam aber meine HmIP Geräte mit der CCU2 nicht mehr zum laufen, weshalb auch immer, musste dann abbrechen, da ich noch weg musste.

Bist du mit deinen Geräten nach dem Umstieg auf CCU3 nochmals auf die CCU2 zurückgegangen, ev. klappt ja das auch nicht mehr. Werde es ev. heute nochmals versuchen.

Gruß Reinhard

[Ban]

Nein, bin nicht wieder auf die CCU2 zurückgegangen.

Für den Raspi mit Funkmodul gibt es ein Gehäuse von ELV: Gehäuse RP-Case für Raspberry Pi und RPI-RF-MOD Funk-Modulplatine
Gibt auch ein Komplettset, heißt dort Charly.

Ich sag bescheid, wie es ausgegangen ist. Versandbestätigung ist gerade reingekommen.

Nachtrag:
Habe heute noch einmal getestet. Habe die CCU seit 2 Tagen nicht neu gestartet. Keine Fehlermeldung im Log der CCU. Dann habe ich fhem neu gestartet und habe die RPC Server beim Start angelassen, damit HMCCU ein Update auf alle Devices macht. Direkt wieder das ganze Log voll mit Fehlermeldungen und die CCU lässt sich nicht bedienen.
Merkwürdig.

Grüße,
Ban

[Ban]

Hallo zap,

ich habe deinen Vorschlag ausprobiert und das Update der Devices beim Start von HMCCU unterbunden.
Ich habe zum Test das komplette if in der Methode HMCCU_UpdateClients auskommentiert.
Das bringt das für mich gewünschte Verhalten.
Nach dem Start von fhem inkl. der RPC Server geht keine Anfrage an die CCU.
HMCCU und die RPC Server starten korrekt.
Alle Devices stehen zuerst auf Initialized und der Status kommt nach und nach rein.
Wenn ein Gerät seinen Status ändert, bekommt das fhem mit und zeigt den Status an.

Ich denke, dass Update sollte auch nur beim Start ausgeschaltet sein und nicht komplett abgehängt werden.

Aktuell habe ich viel (siehe unten:-) zuwenig Ahnung von deinem Modul, von Perl und der Parameterübergabe von der fhem-GUI, als dass ich mir eine Umsetzung zutrauen würde,
welche du übernehmen könntest. Wahrscheinlich ist das auch schlicht zuviel, was ich da raus genommen habe:-)

Evtl. könntest du das Update der Devices beim Start von fhem bzw. der HMCCU per Parameter steuerbar machen.


Nachtrag: Habe mir schon gedacht, dass das zu kurz gedacht ist und da noch mehr gemacht wird:-)
Kann die Geräte nur noch einmal über fhem steuern, bekomme: "HMCCUDEV: HM_Licht_Wohnzimmer Invalid datapoint"
Aber war auch nur ein Test...

Vielen Dank und viele Grüße,
Ban



Noch ein Nachtrag: Ich habe heute testweise ioBroker installiert, um zu schauen, wie sich meine CCU damit verhält. Wenn ich die beiden Adapter rega und rpc anschalte und die Geräte abfrage, bekomme ich im Log der CCU3 dieselben Fehlermeldungen, wie beim Start der PRC-Server in fhem. Nur die CCU3 ist weiterhin bedienbar. Die Fehlermeldungen der nicht erreichbaren Geräte sind wohl nicht der Auslöser für das Fehlverhalten der CCU. Scheinbar macht HMCCU hier bei der Abfrage noch etwas mehr. Mehr Datenpunkte abfragen? Kann man das evtl. herausfinden? Ich helfe auch gerne weiterhin mit!

Beim zweiten Test, CCU3 Neustart und ioBroker Neustart, danach die beiden Adapter neu angelegt und die IP Geräte synchronisiert, kamen die Fehlermeldungen in der CCU3 nicht mehr. Evtl. weil vorher noch gleichzeitig fhem zugegriffen hat. Auch beim zweiten Test ist die CCU weiterhin normal bedienbar. Der State der IP Geräte wird bei Änderung auch im ioBroker aktualisiert. Die Events kommen also an.

[Ban]

Hallo zusammen,

noch abschließend hier die Info zum Stand meiner Tests.

Ich habe zusätzlich einen Charly gekauft. Alle Geräte resettet und auf dem Charly neu angelernt. Auf dem Charly verwende ich das aktuelle RaspberryMatic.
Habe als weiteren Test eine externe Antenne angeschlossen.
Auch mit dieser Kombination habe ich dasselbe Problem.

Folgendes habe ich insgesamt versucht:

- fhem neu aufgesetzt und nur HMCCU eingebunden. Alle Geräte in fhem neu erzeugen lassen
- 2 unterschiedliche CCU3 ausprobiert. Jeweils das Backup eingespielt
- Unterschiedliche Positionen der CCU3 getestet
- neuer Charly mit Neuanlernen aller Geräte, ohne Backup
- externe Antenne am Charly

Immer ohne zusätzliche Module in der CCU.

Jedesmal gibt es das beschriebene Verhalten.
 
Viele Grüße,
Ban

[Rewe2000]

Hallo,

ich habe heute das kalte Wetter nochmals genutzt, um den gleichen Versuch wie Ban schon gemacht hat, nochmals nachzustellen.

• Raspi komplett neu mit Linux Debian lite Kernel 4.14 neu aufgesetzt
• Fhem aktuellste Version fhem-5.9 nur mit im WIKI empfohlenen Paketen installiert
• Nur die Perl Module RPC::XML::Server und RPC::XML::Client für HMCCU installiert
• Als einziges Modul HMCCU mit den dazugehörigen RPC Servern (BidCos-RF,HmIP-RF,VirtualDevices) installiert

Auch nur mit dieser Minimalkonfiguration, treten die gleichen Fehler wie immer beim Neustart (wie bei Ban auch) auf.

Als ich die einzelnen Geräte noch nicht in Fhem angelegt hatte (RPC Server sind schon gelaufen) war alles noch OK und Fhem konnte problemlos neu gestartet werden.
Erst als ich meine Geräte aus der CCU3 mit dem Befehl

Code Auswählen Erweitern

get d_ccu devicelist create ^.* t=dev f=HM_%n defattr save room=Homematic

in Fhem angelegt hatte, ging die CCU3 nach einem shutdown restart wieder in die Knie.

Alle meine Gerätenamen habe ich in der CCU nach folgendem Muster angelegt:
Z.B.: EG_FKE1_Kueche (Geschoss_Funktion_Raum) alles konsequent ohne Umlaute und Sonderzeichen und doppeltes Vorkommen, nur mit Unterstrichen.
Wenn die Gerätenamen so passen, kann von Seiten Fhem nach menschlichem Ermessen kein Userfehler mehr in Betracht kommen, denn es gibt ja keine Programmierung und keinerlei weitere Module in Fhem .

Gibt es von irgend jemande von euch noch irgend welche Ideen welche ich versuchen könnte um Fhem in Verbindung mit der CCU3 wieder "normal" zu nutzen?

Derzeit könnte ich nahezu jeden Versuch durchführen (schon aus Gründen der Verzweiflung), da ich dafür meinen Test-Raspi verwende. Neu angelernt habe ich auch schon alle Geräte auf der CCU2 in der Vergangenheit, auch daran kann es nicht liegen, da dies den Fehler nicht beseitigt hatte.

@Ban: Hast du den Versuch mit nur einigen Geräten auf der CCU3 schon durchgeführt?

Gruß Reinhard

[zap]

Wir hatten ja schon das Update aller Geräte nach dem Start der RPC Server und der damit einhergehenden Überlastung der CCU als Ursache identifiziert.

Insofern: Was hast Du Dir von der Neuinstallation versprochen?

Aus irgendwelchen ominösen Gründen können einige CCUs die Vielzahl der Anfragen nicht ab, während andere CCUs damit kein Problem haben.

[PatrickR]

Hi!

Da wir immer noch nicht den Grund für das Problem kennen, wäre eine Idee, die Updates auszubremsen:

88_HMCCU.pm ab Zeile 6646 (also vor my $nam = '';) Folgendes einfügen:

Code Auswählen Erweitern


Log3 $hmccu_hash->{NAME}, 5, "HMCCU: [$hmccu_hash->{NAME}] GetUpdate: Updating $addr.";


und
88_HMCCU.pm ab Zeile 2899 Folgendes einfügen:

Code Auswählen Erweitern


sleep(1);


sowie in FHEM:

Code Auswählen Erweitern


attr d_ccu verbose 5


Das Timing lässt sich dann im FHEM-Log beobachten:

Code Auswählen Erweitern


2019.04.14 19:47:29.706 5: HMCCU: [hmccu2] GetUpdate: Updating 0007D70B9CF569.
2019.04.14 19:47:30.732 5: HMCCU: [hmccu2] GetUpdate: Updating 001858AF8C18E3.
2019.04.14 19:47:31.831 5: HMCCU: [hmccu2] GetUpdate: Updating 0010970DA3C443.
2019.04.14 19:47:32.860 5: HMCCU: [hmccu2] GetUpdate: Updating 0007D7049CF38C.


Bitte beachtet: Durch die langen Sleeps gibt es auf jeden Fall ein riesiges Freeze in FHEM, daher bitte nur auf Testsystemen ausprobieren.

Patrick

[zap]

Für Tests bestimmt nicht schlecht. Als einigermaßen nachhaltiger Workaround denke ich eher an sowas:

- Update abschaltbar machen
- Update mit sleep zwischen den einzelnen Devices im Hintergrund, d.h. Non blocking ausführen

[PatrickR]

Für Tests bestimmt nicht schlecht. Als einigermaßen nachhaltiger Workaround denke ich eher an sowas:

- Update abschaltbar machen
- Update mit sleep zwischen den einzelnen Devices im Hintergrund, d.h. Non blocking ausführen

So war es gedacht. Die Sleepzeit müsste natürlich in ein Attribut. Jetzt müssen wir aber erstmal verifizieren, dass es überhaupt was bringt.


Von unterwegs gesendet.

[Rewe2000]

Hallo,

bei mir passieren wieder seltsame Dinge!

Ich habe den Test wie von Patrick vorgeschlagen durchgeführt und 88_HMCCU.pm entsprechend modifiziert.
Mit diesen Änderungen hängt sich die CCU3 nicht mehr auf und Fhem steht bei mir für ca. 2 Minuten, es wurden aber alle Geräte sauber eingelesen.

Ich dachte mir, nun mache ich mal den Test mit Verbose 5 und nur der Zeile für den Logeintrag, um zu sehen, wo die timeout Fehler, bei welchem Gerät genau auftreten.

Code Auswählen Erweitern

Log3 $hmccu_hash->{NAME}, 5, "HMCCU: [$hmccu_hash->{NAME}] GetUpdate: Updating $addr.";

Bei mir reicht genau diese eine Zeile in Verbindung mit Verbose 5 aus, damit die RPC-Server wieder "normal" gestartet werden können. Alle 59 Geräte werden bei mir nun in weniger als 2 Sekunden fehlerfrei gelesen.

Es würde wahrscheinlich schon ausreichen das Modul durch ein wenig Schreibarbeit ins Log zu "beschäftigen", bei mir muss es definitiv kein sleep(1) sein. Somit wäre es für uns zumindes ein kurzfristiger Workaround, bis zap irgendwann mal eine professionelle Lösung einbaut.

Ich habe dies nun mehr als 8 Mal auf dem Testsystem getestet durch "shutdown restart" mit anschließendem "set d_ccu rpcserver on"
Ich bin nun so mutig und werde dies am Dienstag auf meinem Produktivsystem testen, denn irgendwann müssen ja die RPC-Server mal neu gestartet werden.

Edit:
Kommando zurück!
Es ist doch nicht so einfach wie gedacht, bei den Tests hat irgendwie meine CCU3 gehangen, es gab keinerlei Fehler auf der WEB Oberfläche, gemerkt hatte ich es erst, als sich meine HmIP-BSM nicht mehr über RaspiMatic selbst schalten liesen.
Nach einem Neustart der CCU3 ist nun alles so wie in der Vergangenheit auch.
Auch die Wartezeit von einer Sekunde bringt bei mir nicht den gewünschten Erfolg.

Code Auswählen Erweitern

2019.04.08 15:29:29 5: HMCCU: [d_ccu] GetUpdate: Updating 0000D3C995F919.
2019.04.08 15:29:29 4: HMCCU: [d_ccu] Build URL = http://192.168.1.32:8181/tclrega.exe
2019.04.08 15:29:33 2: HMCCU: [d_ccu] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.04.08 15:29:33 2: HMCCU: Update of device 0000D3C995F919 failed
2019.04.08 15:29:34 5: HMCCU: [d_ccu] GetUpdate: Updating 000A97099C16F3.
2019.04.08 15:29:34 4: HMCCU: [d_ccu] Build URL = http://192.168.1.32:8181/tclrega.exe
2019.04.08 15:29:38 2: HMCCU: [d_ccu] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.04.08 15:29:38 2: HMCCU: Update of device 000A97099C16F3 failed
2019.04.08 15:29:39 5: HMCCU: [d_ccu] GetUpdate: Updating 000A970994F8D1.
2019.04.08 15:29:39 4: HMCCU: [d_ccu] Build URL = http://192.168.1.32:8181/tclrega.exe
2019.04.08 15:29:43 2: HMCCU: [d_ccu] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.04.08 15:29:43 2: HMCCU: Update of device 000A970994F8D1 failed

Da hab ich mich zu früh gefreut.
Gruß Reinhard

[Ban]

@Ban: Hast du den Versuch mit nur einigen Geräten auf der CCU3 schon durchgeführt?

Das habe ich nicht mehr versucht, aber bei mir hat sich das Verhalten auch geändert.
@Reinhard: evtl. ist es das bei dir auch das aktuelle Verhalten.

Ich kann im Moment mein fhem neustarten wie ich will, solange ich die CCU nicht neustarte, habe ich keinerlei Problem.
Testweise habe ich die CCU neugestartet und danach auch fhem. Dann tritt das Problem wieder auf.
Mit der aktuellen RaspberrymaticFirmware (3.45.5.20190330) ist ein Watchdog eingebaut worden. Da sehe ich dann auch, dass, sobald sich die CCU "aufhängt", der Wathchdog versucht ReGaHss mehrfach neu zu starten.
Sobald ich einmalig einen lauffähigen Zustand mit "rpcregister all" herstelle, kann ich danach mein fhem wieder ohne Hänger der CCU durchstarten.

Im Moment bin ich auch dabei die "Last" in der CCU zu erhöhen, da ich meine Homematic Komponenten sukzessive von VCCU nach HMCCU umziehe.

Grüße,
Ban

[PatrickR]

Mahlzeit!

Gerade ist es wieder soweit. Nach dem Raspberrymatic-Update in der vergangenen Woche lief es nach rpcregister ohne Probleme weiter. Offenbar habe ich das Problem dann nur bis zum FHEM-Neustart gerade vertagt. Dafür hat die Raspberrymatic gerade von selbst neu gestartet, offenbar wegen des Watchdogs.

Patrick

[Rewe2000]

Hallo Patrick,

auch ich habe eben ein Fhem Update durchgeführt und musste dadurch zwangsweise ein "shutdown restart" durchführen.
Grundsätzich bekomme ich meine Systeme nur wieder, wie folgt zum laufen:

- Nachdem Neustart von Fhem (ca. 5-10 Minuten) iegt grundsätzlich mein RaspberryMatic am Boden (zu erkennen an mehreren Kommunikationsstörungen zu IP-Geräten"
- Grundsätzlich führe ich danach auch einen auch Neustrart der RaspberryMatic durch, auch wenn sich diese anscheinend wieder erholt hat.
- Im Anschluß dann noch, beim HMCCU Modul ein set rpcregister all, nach 10 Sekunden ist Fhem wieder bereit.

Ohne diese Vorgehensweise bekomme ich meine Systeme überhaupt nicht mehr zum laufen.

Alles total unbefriedigend, besonders auch deswegen, weil ich selbst keinerlei Ideen mehr habe um das Problem noch ein wenig einzugrenzen.

Ich habe schon echt mit dem Gedanken gespielt, einige IP-Sensoren testweise aus meiner CCU3 zu löschen, denn mir geht es absolut nicht ins Hirn, was bei uns dreien anders ist als bei den vielen anderen HMiP und Fhem Usern.

Gruß Reinhard

[PatrickR]

Hallo Reinhard!

- Nachdem Neustart von Fhem (ca. 5-10 Minuten) iegt grundsätzlich mein RaspberryMatic am Boden (zu erkennen an mehreren Kommunikationsstörungen zu IP-Geräten"
- Grundsätzlich führe ich danach auch einen auch Neustrart der RaspberryMatic durch, auch wenn sich diese anscheinend wieder erholt hat.
- Im Anschluß dann noch, beim HMCCU Modul ein set rpcregister all, nach 10 Sekunden ist Fhem wieder bereit.

Alles klar, kommt auf die Verzweiflungsliste. Ich habe es gerade so gelöst, dass ich die Sub HMCCU_UpdateClients () außer Gefecht gesetzt habe.

Alles total unbefriedigend, besonders auch deswegen, weil ich selbst keinerlei Ideen mehr habe um das Problem noch ein wenig einzugrenzen.

Wo kommt Ihr her? Wir könnten uns bspw. mal in Berlin treffen und ein Bier trinken Ich bringe auch ein HmIP-Gerät und einen Hammer mit.

@Zap:
Könntest Du evtl ein Attribut oder ccuflag spendieren, das HMCCU_UpdateClients() außer Gefecht setzt?

Patrick