HMCCU 5.0 im SVN verfügbar

[Nighthawk]

Schwerpunkt ist immer noch Bugfixing. Aber wie schon geschrieben: jedes Gerät lässt sich per define anlegen und nutzen. Zur Steuerung muss man halt "set datapoint" verwenden (und ggf vorher in der Doku die Funktion der Datenpunkte nachschlagen).

Hallo Zap,

danke für den Wink, hat auf Anhieb geklappt (durch den Service des Moduls Devices automatisch anzulegen, vergisst man doch glatt den normalen Weg ) und alle Readings waren von alleine vorhanden, top.


Gruß
Alex

[Ryker]

Es gibt das Flag "reconnect" für das Attribut ccuflags...

Das habe ich probiert, aber nach einem Restart der CCU reconnected es sich iwie nicht.

@xeeenon:
Ich hab mir dafür einen Watchdog erstellt, damit klappt das relativ zuverlässig.

Code Auswählen Erweitern


defmod ReConnect_CCU watchdog CCU3_Presence:present 00:01:00 Presence:absent set HM_CCU rpcregister all
attr ReConnect_CCU autoRestart 1
attr ReConnect_CCU icon hm_ccu


Ryker

[Ryker]

@zap: Kurze Frage zur Funktionsweise von HMCCU.
Kann es sein, dass es set-Events nicht gleichzeitig verarbeiten kann.
Weil wenn ich irgendwas per set gleichzeitig an alle meine Thermostate schicke, dann bekomme ich nur beim ersten keinen Fehler, aber bei den anderen allen kommt sowas hier:

Code Auswählen Erweitern


2022.01.05 10:27:48 2: HMCCUCHN [HMIP_Thermostat1_Wohnzimmer] Error during CCU request. read from http://ccu3.fritz.box:8181 timed out

Es funkionieren zwar alle set's trotzdem, aber es kommt halt der Fehler.

Weil, wenn das so normal ist, dann muss ich meine Mechanismen im FHEM etwas serialisieren.

Ryker

[zap]

@zap: Kurze Frage zur Funktionsweise von HMCCU.
Kann es sein, dass es set-Events nicht gleichzeitig verarbeiten kann.
Weil wenn ich irgendwas per set gleichzeitig an alle meine Thermostate schicke, dann bekomme ich nur beim ersten keinen Fehler, aber bei den anderen allen kommt sowas hier:

Code Auswählen Erweitern


2022.01.05 10:27:48 2: HMCCUCHN [HMIP_Thermostat1_Wohnzimmer] Error during CCU request. read from http://ccu3.fritz.box:8181 timed out

Es funkionieren zwar alle set's trotzdem, aber es kommt halt der Fehler.

Weil, wenn das so normal ist, dann muss ich meine Mechanismen im FHEM etwas serialisieren.

Ryker

Wie schickst Du die set Befehle ab? Per "set <devspec>"? Das ist sehr ineffizient, da für jedes Device dann ein separater Request an die CCU geschickt wird. In diesem Fall ist es besser, Du verwendest den "set datapoint" Befehl vom I/O Device. Mit dem Kannst Du Befehle an mehrere Devices in einem einzigen CCU-Request schicken.

Beispiel:

Code Auswählen Erweitern

set ccu datapoint ccutype=HM-CC-RT-DN SET_TEMPERATURE 21.0

Wenn die Thermostate HMCCUDEVs sind, noch die Kanalnummer vor den Datenpunkt packen:

Code Auswählen Erweitern

set ccu datapoint ccutype=HM-CC-RT-DN 4.SET_TEMPERATURE 21.0

[Ryker]

Ich hab einen Watchdog, der prüft ob draußen jetzt Sommer ist oder nicht (wenn Temp länger als 15h nicht unter Wert X sinkt). Das gleiche dann natürlich auch umgekehrt.
In dem Fall dass Sommer geworden ist, setzt er dann sowas hier ab:

Code Auswählen Erweitern


   fhem("set HMIP_Thermostat1_Wohnzimmer off");
   fhem("set HMIP_Thermostat2_Wohnzimmer off");
   fhem("set HMIP_Thermostat_Kinderzimmer off");

Dabei kommt dann der Fehler bei 2 von den 3en über HMCCU.

In Zukunft wollte ich das aber dynamisch machen.
@zap du meinst man kann über HMCCU auch einfach das Gerät weglassen und einfach nur über den GeräteType was losschicken.
Das würde ja meinen Konstrukt dann noch besser verinfachen. Probier ich aus.

Ryker

[Ryker]

Hm, Wenn ich das hier sende:
set HM_CCU datapoint ccutype=HmIP-eTRV-2 SET_POINT_TEMPERATURE 21.0

bekomme ich:
HMCCU: HM_CCU FHEM device SET_POINT_TEMPERATURE has illegal type

Mache ich das gleiche direkt am Thermostat im FHEM, dann klappt das.
Das gleiche auch wenn ich den datapoint CONTROL_MODE mit 0 oder 1 oder 2 ansteuere.

Die Thermostate sind als HMCCUCHN definiert.

Ryker

[justme1968]

ich bekomme mit der neuesten version bei fast jedem set datapoint timeouts. manchmal gehen ein paar hintereinander durch, dann fängt es aber wieder an mit den timeouts. events von der ccu scheinen problemlos anzukommen.

da mir auch das ccu3 web interface heute ein paar mal hägen geblieben ist bin ich mir aber nicht sicher ob es modul liegt. ganz nebenbei hatte ich auch noch einen mehrstündige internet ausfall, die aktivierung einer backup dsl verbindung, den letzten ccu3 update und pihole probleme. aber vielleicht hat noch jemand die timeouts beobachtet?

[zap]

Hm, Wenn ich das hier sende:
set HM_CCU datapoint ccutype=HmIP-eTRV-2 SET_POINT_TEMPERATURE 21.0

bekomme ich:
HMCCU: HM_CCU FHEM device SET_POINT_TEMPERATURE has illegal type

Versuch mal:

Code Auswählen Erweitern

set HM_CCU datapoint ccutype=HmIP-eTRV-2 SET_POINT_TEMPERATURE=21.0

Oder:

Code Auswählen Erweitern

set HM_CCU datapoint FHEMDEV1,FHEMDEV2.SET_POINT_TEMPERATURE=21.0

FHEMDEVx durch Deine FHEM DEvicenames ersetzen

[zap]

ich bekomme mit der neuesten version bei fast jedem set datapoint timeouts. manchmal gehen ein paar hintereinander durch, dann fängt es aber wieder an mit den timeouts. events von der ccu scheinen problemlos anzukommen.

da mir auch das ccu3 web interface heute ein paar mal hägen geblieben ist bin ich mir aber nicht sicher ob es modul liegt. ganz nebenbei hatte ich auch noch einen mehrstündige internet ausfall, die aktivierung einer backup dsl verbindung, den letzten ccu3 update und pihole probleme. aber vielleicht hat noch jemand die timeouts beobachtet?

Wenn die set Befehle in Timeouts laufen, hat wahrscheinlich der Rega Prozess der CCU ein Problem. Du kannst auf der CCU mal in /var/log/messages nach Fehlermeldungen schauen.

Man kann die CCU Prozesse auch neu starten. Die Scripts liegen wie üblich in /etc/init.d

[Ryker]

Das hier funktioniert einwandfrei

Code Auswählen Erweitern


set HM_CCU datapoint HMIP_Thermostat1_Wohnzimmer,HMIP_Thermostat2_Wohnzimmer SET_POINT_TEMPERATURE=21.0


Aber,

Code Auswählen Erweitern


set HM_CCU datapoint ccutype=HmIP-eTRV-2 SET_POINT_TEMPERATURE=21.0

oder

Code Auswählen Erweitern


set HM_CCU datapoint ccusubtype=TRV SET_POINT_TEMPERATURE=21.0

oder

Code Auswählen Erweitern


set HM_CCU datapoint ccutype=HmIP-eTRV-2 CONTROL_MODE=0

wird zwar ohne Fehler geschluckt, aber es gibt kein Reaktion darauf.


Aber auch bei der Variante, wo ich die Geräte mit Komma separiert angebe, kommt der Timeout-Fehler im FHEM-Log.
Wie @justme1968 schon schreibt ist mir das auch erst aufgefallen seit dem letzten Update vom HMCCU. Ich bin der Meinung die Timeout-Fehler waren vorher nicht da.
/var/log/messages auf der CCU3 zeigt keine Fehler und auch die CPU darin langweilt sich zu tode.


Ryker

[rageltus]

Hallo zusammen,

ist es möglich mit dem HMCCU Modul in Verbindung mit der CCU2 die Servicemeldungen bspw. für Updates oder Batteriemeldungen (das kriegt man allerdings auch ohne HMCCU hin), zu erhalten damit man bspw. ein notify auslösen kann? Hat hier jemand eine Idee?

Vielen Dank!

Viele Grüße,
Benjamin

[l-j-silver]

Hallo Zusammen,

nachdem ich heute auch das Update auf HMCCU 5.0 durchgeführt habe, startet fhem nicht mehr und im log ist folgendes ersichtlich.

Code Auswählen Erweitern

2022.01.06 13:38:33 1: PERL WARNING: Prototype mismatch: sub HMCCU_GetRPCInterfaceList ($) vs ($;$) at ./FHEM/88_HMCCU.pm line 211, <$fh> line 1103.
2022.01.06 13:38:33 1: reload: Error:Modul 88_HMCCU deactivated:
Too many arguments for main::HMCCU_GetRPCInterfaceList at ./FHEM/88_HMCCU.pm line 1410, near "0)"
Too many arguments for main::HMCCU_GetRPCInterfaceList at ./FHEM/88_HMCCU.pm line 1775, near "0)"
Too many arguments for main::HMCCU_GetRPCInterfaceList at ./FHEM/88_HMCCU.pm line 2824, near "0)"
Too many arguments for main::HMCCU_GetRPCInterfaceList at ./FHEM/88_HMCCU.pm line 3885, near "0)"
Too many arguments for main::HMCCU_GetRPCInterfaceList at ./FHEM/88_HMCCU.pm line 5091, near "0)"
Too many arguments for main::HMCCU_GetRPCInterfaceList at ./FHEM/88_HMCCU.pm line 5207, near "0)"
Too many arguments for main::HMCCU_GetRPCInterfaceList at ./FHEM/88_HMCCU.pm line 5265, near "0)"
Too many arguments for main::HMCCU_GetRPCInterfaceList at ./FHEM/88_HMCCU.pm line 5312, near "0)"
BEGIN not safe after errors--compilation aborted at ./FHEM/88_HMCCU.pm line 7473, <$fh> line 1103.


Wenn ich alle Zeilen (88_HMCCU.pm) mit    

Code Auswählen Erweitern

my $interfaces = HMCCU_GetRPCInterfaceList ($hash, 0);


in

Code Auswählen Erweitern

my $interfaces = HMCCU_GetRPCInterfaceList ($hash);


änder, dann startet auch fhem normal und HMCCU ist aktuell.

Was mache ich falsch?

Vielen Dank.

Grüße Toni

[zap]

Hallo zusammen,

ist es möglich mit dem HMCCU Modul in Verbindung mit der CCU2 die Servicemeldungen bspw. für Updates oder Batteriemeldungen (das kriegt man allerdings auch ohne HMCCU hin), zu erhalten damit man bspw. ein notify auslösen kann? Hat hier jemand eine Idee?

Vielen Dank!

Viele Grüße,
Benjamin

get ccuMsg

Kann man für Alarme und Servicemeldungen aufrufen. Für jede Meldung wird ein Event in FHEM generiert.

[zap]

Kleines Update morgen. Änderungen siehe

https://github.com/zapccu/HMCCU/blob/master/VERSIONS.md

[zap]

@r-j-silver

Du verwendest nicht die aktuelle Version von 88_HMCCU.pm.

Am besten führst Du das Update morgen nochmal aus.