HMCCU: Version 4.3 verfügbar

[PatrickR]

Hi!

[Dass das Nicht-Vorliegen der Werte in der CCU zum Problem führt] kann eigentlich nicht sein. Ich habe diese Woche ein CCU Update mit anschließendem Reboot gemacht. Direkt nach dem CCU Neustart habe ich die RPC Server auf FHEM neu gestartet, ohne Probleme. Ich habe mehr als 80 Homematic Geräte in der CCU (BidCos und HmIP).

Ich kenne leider das Innenleben der CCU nicht, aber es liegt nahe, dass mehrere Faktoren zusammenkommen. Denkbar wäre z. B. dass verschiedene Dienste/Queues/etc. in der CCU die verschiedenen Technologien bedienen und dass sich durch Deine Mischung das Problem auf HmIP, Homematic verteilt. Das würde zumindest erklären, warum meine HmIP-Monokultur explodiert.

nonBlocking verhindert bestenfalls, dass FHEM blockiert. Sonst unterscheidet sich da nichts (wobei ich erst mal nachschauen muss, ob beim globalen Update überhaupt nonBlocking berücksichtigt wird).

Ok. Dann ist zumindest ausgeschlossen, dass die get-update-jobs schneller die CCU befeuern weil sie vor dem Schließen der Verbindung gebackgroundet werden.

Wenn die CCU die Werte nicht kennt, fragt sie vermutlich das Gerät. Zumindest deuten die Fehlermeldung "GetValue error" im CCU Log darauf hin.

D. h. der Ablauf und damit das Timing in der CCU ist entscheidend anders, wenn sie die Werte nicht kennt. Es wird sogar zusätzlich "gefunkt".

Patrick

[Ban]

Ich habe dasselbe Problem und folge Beobachtung.

Das würde zumindest erklären, warum meine HmIP-Monokultur explodiert.

Ich habe sowohl HMIP, als auch HM Geräte. Aktuell sind es 51 Stück.

D. h. der Ablauf und damit das Timing in der CCU ist entscheidend anders, wenn sie die Werte nicht kennt. Es wird sogar zusätzlich "gefunkt".

Es wird zwar zusätzlich gefunkt. Scheint aber das Problem, zumindest bei mir, nicht auszulösen. Hierzu hatten wir/ich auch schon Tests durchgeführt siehe diesen Thread: https://forum.fhem.de/index.php/topic,98287.0.html
Wir haben die CCU3 mind. 24 Stunden laufen lassen, damit diese alle Werte kennt. Danach einen Neustart von fhem durchgeführt.
Dadurch hat sich die CCU3 auch aufgehängt.

Grüße,
Ban

[PatrickR]

Ich habe dasselbe Problem und folge Beobachtung.
Ich habe sowohl HMIP, als auch HM Geräte. Aktuell sind es 51 Stück.
Es wird zwar zusätzlich gefunkt. Scheint aber das Problem, zumindest bei mir, nicht auszulösen. Hierzu hatten wir/ich auch schon Tests durchgeführt siehe diesen Thread: https://forum.fhem.de/index.php/topic,98287.0.html
Wir haben die CCU3 mind. 24 Stunden laufen lassen, damit diese alle Werte kennt. Danach einen Neustart von fhem durchgeführt.
Dadurch hat sich die CCU3 auch aufgehängt.

Ok, den Teil hatte ich überlesen. Langsam gehen mir die Theorien aus...
Interessant für einen Test wäre ein konfigurierbares Delay beim Updaten der Geräte durch hmccu. "Praktischerweise" lässt sich das Problem beliebig oft herbeiführen wenn es einmal auftritt.

Patrick

[zap]

Das Delay kannst du simulieren. Das Update kann jederzeit mit dem Befehl

get <iodev> update

durchgeführt werden.

[PatrickR]

@zap:
Mir geht es um das Delay zwischen den Devices/Channels, d. h. in etwa:

get update dev1
sleep x
get update dev2
sleep x
get update dev3
etc.

Von unterwegs gesendet.

[Maista]

@zap

Hallo Zap, kleine Info

Danke erst ein mal für deine CCU-Module.

Bisher hatte ich nur kleinere Probleme mit den Modulen.
Sporadisch lief der RPC nicht an nach einem Update.
Dieser startete aber bisher immer wieder wenn man ihn Manuell an schubste.

Heute, nach diversen Tests & Neustarts von FHEM wollte dann plötzlich der RPC nicht mehr starten.
Nach einem Update von FHEM kam dann diese Meldung  (keine Updates zu HMCCU o.ä. dabei!):

HMCCURPCPROC: [d_rpc178042BidCos_RF] Can't create RPC callback server CB2001178051178042 on port 7411. Port in use?

Danach habe ich mehrfach FHEM per shutdown neu gestartet und auch in der Shell, FHEM beendet und neu gestartet.
Aber der RPC wollte nicht starten.

Erst nach dem ich den Raspberry komplett neu gestartet hat funktioniert das nun wieder.

Falls es Dir etwas bringt, kann ich dir das Log zu kommen lassen.
Anfangs mit Verbose 1, danach bis zum Neustart des Rpi mit Verbose 5.


Bei der Gelegenheit,
gibt es Datenpunkte für die Taste ECO/Comfort (Tag/Nacht-Temperatur) am HM-CC-RT-DN Thermostat?
Hab schon ein paar Ansätze gelesen aber mangels Zeit noch nicht versucht umzusetzen.

Danke und Gruss
Gerd

[zap]

Das Problem beim RPC Server Start liegt daran, dass beim FHEM shutdown restart der alte RPC Server noch nicht richtig beendet war und deshalb den Port blockiert hat. Lässt sich nur schwer vermeiden, da das ein separater Prozess ist.
HMCCU unterstützt zwar das delayed Shutdown Verfahren von FHEM, das wartet aber auch nur einige Sekunden auf das Beenden der Prozesse. Wenn das länger dauert, kommt es zu dem Effekt.

[Maista]

Danke für die Info.
Wenn man es weis ist das weniger ein Problem

Gruss Gerd

[Raymund]

gibt es Datenpunkte für die Taste ECO/Comfort (Tag/Nacht-Temperatur) am HM-CC-RT-DN Thermostat?

Vielleicht ist das Folgende das, wonach Du suchst:

Code Auswählen Erweitern

attr <name> eventMap /datapoint 4.AUTO_MODE 1:auto/datapoint 4.MANU_MODE 19.0:manual/datapoint 4.COMFORT_MODE 1:on/datapoint 4.LOWERING_MODE 1:off/

Damit bekommst Du die Set-Befehle on/off sowie auto/manual.

[Maista]

@Raymund

Klasse. Werd ich ausprobieren. Hab die bisher nicht Orten können 
Im Forum habe ich vorhin auch was gefunden aber wegen Arbeit noch nicht dazu gekommen.

Edit:
Hat geklappt. 

Bekomme die zwei Datenpunkte aber nicht als Reading angezeigt. Ist das nicht lesbar?

Danke und Gruß
Gerd

[zap]

Das Setzen der Default Attribute für das Thermostat wäre ein guter Ansatz.

Mit get deviceinfo bekommst du eine Liste der Datenpunkte inkl. Info über Read, Write, Event.

Und dann gibt es noch die Geräte Doku von EQ3. Dort sind für jeden Gerätetyp alle Datenpunkte mit Funktion beschrieben. Download im EQ3 Support Portal.

[Maista]

Hallo zap,

Das Setzen der Default Attribute für das Thermostat wäre ein guter Ansatz.

Mit get deviceinfo bekommst du eine Liste der Datenpunkte inkl. Info über Read, Write, Event.

Und dann gibt es noch die Geräte Doku von EQ3. Dort sind für jeden Gerätetyp alle Datenpunkte mit Funktion beschrieben. Download im EQ3 Support Portal.

Ich hatte irgend wann irgendwo gelesen das es eine Liste gibt, aber das die bei EQ3 liegt hatte ich nicht vermutet
Danke für den stups.

In dem PDF https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/hm_devices_Endkunden.pdf
sieht man dann auch das z.B.  COMFORT_MODE nur geschrieben werden kann. Dann ist natürlich auch klar das es kein Reading geben kann 

Gruss Gerd

[ext23]

Hi,

ich habe nach wie vor das Problem, dass ein

set HM_PMSW_02 on-for-timer 1200

nicht zuverlässig arbeitet! Die Steckdose bleibt leider an und damit auch der Heizstrahler
Kannst du hier nochmal schauen? Ich meine das darf nicht passieren. Das ist mir Jahre mit FHEM+HMLAN nicht passiert und mit dem CCU und HmIP macht das ständig Probleme. Wenn es Protokoll-technisch ein Problem ist, kann man in die HMCCU Module vielleicht ein Workaround einbauen der Prüft ob die Dose wirklich im on-for-timer Modus ist?

HMCCU Version 4.3.014
Steckdose: HM-ES-PMSw1-Pl-DN-R1

/Daniel

[zap]

Ein on-for-timer löst das gleichzeitige Setzen von 2 Datenpunkten aus: ON_TIME und STATE. Das passiert in einem einzigen CCU Request. Entweder gehen also beide Befehle oder keiner. Von daher für mich nicht nachvollziehbar, zumindest für den Weg FHEM -> CCU.

Was dann zwischen CCU und Device passiert, kann ich nicht beeinflussen. Du könntest Dir aber mal den CCU Log anschauen. Vielleicht gibt es dort Fehlermeldungen, die weiterhelfen.

[ext23]

Welches Log soll ich mir da speziell anschauen? Weil das Log was man über die CCU WebGUI runterladen kann ist ohne Befund zu der Zeit wo ich die Steckdose eingeschaltet habe.

Wenn das ein Problem zwischen CCU und Steckdose ist, mhh wäre blöd, kann mir aber nicht vorstellen, dass ich der Einzige bin. Und das tritt schon recht häufig auf, also ich sage mal so ca. bei 100 Schaltvorgängen 1x.

/Daniel