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

[PatrickR]

Hi!

Kann es sein, dass noInitialUpdate immer noch Probleme macht?

Bekam gerade nach dem Restart eine Armada von tclrega-Zugriffen obwohl das Flag auf beiden RPCs gesetzt ist.

Patrick

[Rewe2000]

Hallo Patrick,

so wie ich es verstanden habe hat zap da noch einen Fehler im Modul. https://forum.fhem.de/index.php/topic,98287.msg940304.html#msg940304

Ich habe bisher keine Versuche mehr gemacht und warte lieber auf die korrekte Version des Moduls, bis zap dies bereitstellt.
Nachdem alle "Leidensgenossen" geschwiegen haben, dachte ich echt, ich bin wieder der einzige mit dem Problem.

Gruß Reinhard

[zap]

Das Flag funktioniert derzeit nur, wenn es bei mindestens einem RPC Server nicht gesetzt ist.

[Rewe2000]

Hallo zap,

vielen Dank für das gestrige Update des Moduls HMCCU.
Nun klappt das ausblenden mit noInitialUpdate bei allen RPC-Servern, beim Neustart von Fhem.
Bisher läuft alles bestens und so wie in der Vergangenheit auch gewohnt.

Ich kann gut damit leben, wenn sich die Geräte innerhalb der nächten Stunden mit dem aktuellen Zustand melden, wenn ich diesen sofort brauche, so betätige ich eben das Gerät und der aktuelle Zustand wird sofort gesendet.

Gruß Reinhard

[zap]

Freut mich. Demnächst gibt es noch einen Versuch mit dem initialen Update. Muss aber erst noch etwas testen.

[Dirk070]

Kurze Statusmeldung zu den Time Outs bei mir:
Ich habe ab und zu weiterhin das Problem mit den "timed out" Meldungen. Die Aktoren reagieren aber eigentlich immer.

Beispiel:
Eine Schaltung über einen DOIF löst um 20:00 Uhr mehrere SET CONTROL für meine Rolladen aus und schaltet 2 Lampen an.
Die Rolladen sind HMIP-Aktoren, die Lampen noch die alten HM.
Vielleicht ein oder zweimal im Monat gehen die Lampen um 20:00 Uhr an und die Rolladen fahren aber 1 Minute oder so später.
In Summe sind also immer nur die IP-Aktoren betroffen. Im Log finden sich dann die "timed out" Meldungen.

In der HMCCU steht der ccuReqTimeout bereits auf 8.

[zap]

D.h. die set Befehle werden für unterschiedliche Devices ausgeführt?

[Dirk070]

Ja genau, ein separater SET pro Rollade und pro Licht.
Über den Daumen 2 Aktoren Licht (keine IP) und 7 Rolladen (IP).

[zap]

Du könntest Dir ein Homematic Script schreiben das all diese Aufgaben erledigt. Der Vorteil: ein solches Script wird mit einem einzigen Request an die CCU geschickt und ausgeführt. Parameter können auch übergeben werden.

[zap]

Alternativ kannst Du auch ein Gruppendevice für die Rollläden und eins für die Lichter anlegen. Wichtig dabei ist, dass alle Geräte in einer Gruppe den Datenpunkt, den Du setzen willst, im gleichen Kanal verfügbar haben.

Also: Wenn Du 3 Rollläden hast und alle werden über den Datenpunkt 1.LEVEL gesteuert, kannst Du folgendes tun:

Code Auswählen Erweitern

define  allBlinds HMCCUDEV virtual group=Adr1,Adr2,Adr3

Wenn Du nun folgenden Befehl absetzt, werden alle 3 Datapoint Set Befehle in nur einem Request an die CCU geschickt, z.B.

Code Auswählen Erweitern

set allBlinds datapoint 1.LEVEL 100

Außerdem wird es voraussichtlich mit der nächsten Version eine Möglichkeit geben, beliebige CCU Geräte in einem einzigen Request zu schalten.

[Dirk070]

Außerdem wird es voraussichtlich mit der nächsten Version eine Möglichkeit geben, beliebige CCU Geräte in einem einzigen Request zu schalten.

Vielen Dank für die Tipps und Infos, die Funktion im nächsten Release wäre natürlich perfekt. 

Laut Log setzt FHEM die Befehle aller in der selben Sekunde ab, ich vermute, dass die CCU für die Verzögerungen verantwortlich ist.
DutyCycle kann ich ausschließen (wird geloggt). Die Verzögerungen ergeben sich max. in 10% der Fälle, dann sind die Non-IP Geräte immer schneller.

Ich bin mal gespannt, ob die Problematik mit dem Senden in einem Request erledigt ist, oder es wirklich die CCU ist.

Eine Info war ich noch schuldig: die Aktoren werden zwar alle geschaltet, aber durchaus mit jeweils individuellen Werten.
Also einige Rolladen auf 80%, andere auf 50% etc.

[zap]

Ok, bei unterschiedlichen Werten macht eine Gruppe keinen Sinn.

In dem Fall wird es die kommende Erweiterung lösen.

[Dirk070]

Ich bin dem Thema auch noch mal nachgegangen. Aufgrund von vergangenen Test hatte ich bei den Rolladenaktoren die Eventverzögerung und den Zufallsanteil auf "Nicht aktiv" in der CCU.
Dies habe ich gestern auf 1Sek. und 3.Sek. geändert. Der erste Lauf am gestrigen Abend war dann tatsächlich zügiger und mit dem Schalten des Lichts parallel.

Eventuell hatten sich durch die Einstellungen tatsächlich Funk-Kollisionen ergeben. Ich beobachte den Verlauf über die nächsten Tage und Wochen, dann lässt sich eine verlässliche Aussage formulieren.
Die Ergänzung im Modul ist natürlich trotzdem eine willkommene Neuerung 

[zap]

Jetzt verfügbar.