HMCCU 5.0 im SVN verfügbar

[a_quadrat]

Die CCU ist ein separater Raspi mit RaspberryMatic, Version 3.59.6.20210703.

Das Problem "PERL WARNING: Argument "" isn't numeric in addition (+) at (eval 457798) line 1." war die Ursache, dass ich ein Update von FHEM gemacht habe und suche aktuell noch die Ursache.

Ich bin mir auch noch nicht sicher, ob HMCCU das Problem ist, weil die andren Geräte auch Kommunikationsprobleme haben, z.B deconz, MQTT... Vielleicht sind die Log-Einträge nur die Folge, dass FHEM langsam wurde.

Ich habe jetzt erstmal Version 4.3 wieder hergestellt, um zu sehen, ob es am HMCCU Modul liegt.

VG Andreas

[tomcat.x]

Das Attribut rpcinterfaces verschwindet immer beim FHEM Neustart. Ich brauche aber nur HmIP-RF und nicht alle 3 RPC Interfaces. Kann das sonst noch jemand bei sich beobachten?

Siehe
https://forum.fhem.de/index.php/topic,123686.msg1182994.html#msg1182994
und
https://forum.fhem.de/index.php/topic,123686.msg1183665.html#msg1183665

Also leider nur als Bestätigung, ohne Lösung.

[Wolfpunk]

Siehe
...
Also leider nur als Bestätigung, ohne Lösung.

Danke dir, aber ich kann das Attribut rpcinterfaces setzen, ist hier kein Problem. Ich bekomme also keine Fehlermeldung bzgl. unknown attribute. Beim FHEM Neustart verschwindet es nur immer wieder von selbst. (config war gespeichert.)

[tomcat.x]

Ja, das ist das gleiche bei mir. Ich kann es setzen, es kommt kein Fehler und es verschwindet. Die Meldung steht auf der Startseite nach dem Neustart. Dabei verschwindet das Attribut auch.

[Depechem]

ich habe an meinen Rollläden nach dem Update auf HMCCU 5.0 ein "defaults reset" gemacht.

Folgendes musste ich bei den attr. wieder ändern da ansonsten das ASC-Modul nicht mehr ging:

HmIPW-DRBL4 (IP-Wired)
attr: substexcl: control|pct
attr: controldatapoint 14.LEVEL (Nummer von von 14.ACTIVITY_STATE nehmen)
attr: statedatapoint 13.LEVEL (Nummer von von 13.LEVEL_STATUS nehmen)

HM-LC-Bl1PBU-FM (normales HM)
attr: substexcl: control|pct

vieleicht hilft dies ja jemanden.

Kann zap dies evtl. gleich in die "defaults" der jeweiligen Geräte übernehmen?

viele Grüße Thomas

[darthi]

Hallo zusammen,

anscheinend funktionieren mit der neuen Version die genericDeviceType-Werte für z.B. eine Alexasteuerung nicht mehr.

Ich bekomme folgende Fehlermeldung bei meinen HM-CC-RT-DN Heizungsthermostaten:

Code Auswählen Erweitern

[2021-11-4 12:41:12] [FHEM] HeizungKueche is thermostat
[2021-11-4 12:41:12] [FHEM] HeizungKueche is NOT a thermostat. set command for target temperature missing: control
[2021-11-4 12:41:12] [FHEM] HeizungKueche has
[2021-11-4 12:41:12] [FHEM]   StatusLowBattery [battery]
[2021-11-4 12:41:12] [FHEM]   CurrentTemperature [4.ACTUAL_TEMPERATURE]
[2021-11-4 12:41:12] [FHEM]   CurrentHeatingCoolingState [undefined]
[2021-11-4 12:41:12] [FHEM] HeizungKueche will not send proactive events
[2021-11-4 12:41:12] [FHEM] HeizungKueche uses ID: OEQ1706077
  2021-11-04 12:41:12 caching: HeizungKueche-battery: ok
  2021-11-04 12:41:12 caching: HeizungKueche-4.ACTUAL_TEMPERATURE: 20.4

Muss ich nun ein händisches homebridgeMapping anlegen oder sollte das theoretisch weiterhin funktionieren?

edit: Konnte das Problem lösen... Hatte anscheinend doch noch ein altes homebridgeMapping eingestellt. Nachdem ich es gelöscht hatte, Alexa neu geladen, wurden die Geräte laut FHEM Log wieder korrekt erkannt. Allerdings haben sie erstmal in Alexa weiterhin nicht korrekt funktioniert. Es kam nur "Warten auf HMCCUDEV". Dann habe ich in der Alexa App noch einmal eine Suche durchgeführt und obwohl er nichts neues gefunden hat, funktionieren nun die Thermostate wieder...

[michaelw]

Ich versuche im Moment mit dem Modul Weekprofile ein Profil für ein HM-CC-RT-DN zu setzen. Das Modul sollte grundsätzlich wohl mit HMCCUDEV zusammenarbeiten können. Der Befehl, der über Weekprofile für das Gerät erzeugt wird, rechnet die Uhrzeit aus dem Profil in Minuten um und setzt daraus dann den set Befehl zusammen. set <device> device config TEMPERATUR_FRIDAY_1=18.0 ENDTIME_FRIDAY_1=1145 sollte zum Beispiel für den ersten Wert für Freitag bis 19:05 18°C einstellen. Wenn ich diesen Befehl manuell an das Thermostat sende, kommt aber nicht das erwartete Ergebnis dabei raus. Hat sich in Version 5.0 etwas an der Syntax verändert?
Ich habe zum Beispiel festgestellt, dass ENDTIME_FRIDAY_1=19 die Uhrzeit auf 19:00 Uhr gesetzt wird und ENDTIME_FRIDAY_1=19.5 die Uhrzeit auf 19:30 gesetzt wird. Ist das so beabsichtigt?
Führe ich ein get paramsetDesc aus, ist hier noch die Zeit in Minuten referenziert (Beispiel: ENDTIME_FRIDAY_1: INTEGER [R,W] [Visible,Sticky] RANGE=5...1440 DFLT=360 UNIT=minutes)

[Dirk070]

Hallo zap,

gestern hatte ich aufgrund einer Änderung (Allerheiligen und Zeitumstellung) ein Update gemacht.
Dabei kam dann offenbar auch HMCCU5 mit. Als ich abends nach hause kam, war keine der Rolladen gefahren.
Panik.....Kurzanalyse.....Backup eingespielt.

Heute folgendes Test-Doif aufgesetzt:

Code Auswählen Erweitern

my $LED_CCU="";;
$LED_CCU = "CCU_DG_STR_HMIP_PDT.4.LEVEL=100";;
fhem ("set ccu3 datapoint $LED_CCU") if ($LED_CCU ne "");;

Unter der alten Version alles gut (so habe ich 10 Rolladen und diverse Lampen mit Bewegungsmeldern und einer Logik im Einsatz).

Unter 5.0 gibt die folgende Fehlermeldung im Log:

Code Auswählen Erweitern

2021.11.05 10:37:24 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/88_HMCCU.pm line 1513.
2021.11.05 10:37:24 3: eval: { Log 1, "--> Test-Start <--";  my $LED_CCU="";; $LED_CCU = "CCU_DG_STR_HMIP_PDT.4.LEVEL=100";; fhem ("set ccu3 datapoint $LED_CCU") if ($LED_CCU ne "");;  Log 1, "--> Test-Ende <--"; }
2021.11.05 10:37:24 1: HMCCU [ccu3] HMCCU: ccu3 Invalid channel number specified for device CCU_DG_STR_HMIP_PDT
2021.11.05 10:37:24 3: set ccu3 datapoint CCU_DG_STR_HMIP_PDT.4.LEVEL=100 : HMCCU: ccu3 Invalid channel number specified for device CCU_DG_STR_HMIP_PDT

Danach laut Wiki

Code Auswählen Erweitern

CCU_DG_STR_HMIP_PDT mit set defaults reset

Ändert nichts, die Lampe lässt sich zwar über die UI schalten, aber nicht mehr über den Datapoint.
Das Beispiel ist simplifiziert, bei den Rolladen sammel ich so bis zu 10 Befehle und sende diese in einem Rutsch an die CCU.

Laut Wiki sollten doch die Funktionen erhalten geblieben sein "Nachdem FHEM auf HMCCU Version 5.0 aktualisiert und neu gestartet wurde, sollten die definierten Geräte (HMCCUCHN und HMCCUDEV Devices) wie unter Version 4.3 funktionieren"

Hier bräuchte ich bitte mal Deine Hilfe. Zum Glück laufen die beiden Versionen jeweils in einem Docker-Image, sodass ich recht schnell umschalten und testen kann.

Danke vorab und viele Grüße
Dirk

[Sirmike]

Hallo zusammen,

anscheinend funktionieren mit der neuen Version die genericDeviceType-Werte für z.B. eine Alexasteuerung nicht mehr.

Ich bekomme folgende Fehlermeldung bei meinen HM-CC-RT-DN Heizungsthermostaten:

Code Auswählen Erweitern

[2021-11-4 12:41:12] [FHEM] HeizungKueche is thermostat
[2021-11-4 12:41:12] [FHEM] HeizungKueche is NOT a thermostat. set command for target temperature missing: control
[2021-11-4 12:41:12] [FHEM] HeizungKueche has
[2021-11-4 12:41:12] [FHEM]   StatusLowBattery [battery]
[2021-11-4 12:41:12] [FHEM]   CurrentTemperature [4.ACTUAL_TEMPERATURE]
[2021-11-4 12:41:12] [FHEM]   CurrentHeatingCoolingState [undefined]
[2021-11-4 12:41:12] [FHEM] HeizungKueche will not send proactive events
[2021-11-4 12:41:12] [FHEM] HeizungKueche uses ID: OEQ1706077
  2021-11-04 12:41:12 caching: HeizungKueche-battery: ok
  2021-11-04 12:41:12 caching: HeizungKueche-4.ACTUAL_TEMPERATURE: 20.4

Muss ich nun ein händisches homebridgeMapping anlegen oder sollte das theoretisch weiterhin funktionieren?

edit: Konnte das Problem lösen... Hatte anscheinend doch noch ein altes homebridgeMapping eingestellt. Nachdem ich es gelöscht hatte, Alexa neu geladen, wurden die Geräte laut FHEM Log wieder korrekt erkannt. Allerdings haben sie erstmal in Alexa weiterhin nicht korrekt funktioniert. Es kam nur "Warten auf HMCCUDEV". Dann habe ich in der Alexa App noch einmal eine Suche durchgeführt und obwohl er nichts neues gefunden hat, funktionieren nun die Thermostate wieder...

Hallo darthi,

ich habe das selbe Problem. Kannst du mir sagen was du genau gelöscht hast, das Attribute homebridgeMapping? Danach ein ALEXA reload ?

VG

Mike

[simonsky]

Hallo zusammen für alle die das Batterie Problem mit der Voltanzeige haben hat mir folgendes weitergeholfen.

Code Auswählen Erweitern

attr ccuflags showDeviceReadings

[zap]

Hallo zap,

gestern hatte ich aufgrund einer Änderung (Allerheiligen und Zeitumstellung) ein Update gemacht.
Dabei kam dann offenbar auch HMCCU5 mit. Als ich abends nach hause kam, war keine der Rolladen gefahren.
Panik.....Kurzanalyse.....Backup eingespielt.

Heute folgendes Test-Doif aufgesetzt:

Code Auswählen Erweitern

my $LED_CCU="";;
$LED_CCU = "CCU_DG_STR_HMIP_PDT.4.LEVEL=100";;
fhem ("set ccu3 datapoint $LED_CCU") if ($LED_CCU ne "");;

Ein Bug.

Ist CCU_DG_STR_HMIP_PDT ein FHEM Device? Warum machst Du dann nicht folgendes:

set CCU_DG_STR_HMIP_PDT datapoint 4.LEVEL 100 # Bei einem HMCCUDEV Device

oder

set CCU_DG_STR_HMIP_PDT datapoint LEVEL 100 # Bei einem HMCCUCHN Device

oder noch einfacher:

set CCU_DG_STR_HMIP_PDT open
set CCU_DG_STR_HMIP_PDT close

[zap]

Nach dem Update hatte ich ein paar Fehler mit unbekannten Attributen beim HMCCU Device. Habe dann geschaut, was da vorher gesetzt war, dann ohne die Attribute gespeichert und neu gestartet. Für ein Attribut bekomme ich den Fehler damit aber nicht weg: "unknown attribute rpcinterfaces". Das wird doch aber noch gebraucht und gibt es daher auch noch. Ich habe dann neu auf "HmIP-RF" gesetzt, gespeichert und neu gestartet. Leider ohne Erfolg. Momentan muss ich also nach dem Start erst das Attribut setzen und dann manuell den RPC-Server starten.

Dabei habe ich über folgendes gestolpert: Wenn ich im Gerät bei"Set" erst "rpcserver" und dann "on" auswähle, bekomme ich als Fehler "HMCCU: <MeinGerätename> Usage: set <MeinGerätename> [rpcserver] {'on'|'off'} " angezeigt, also genau die gewählte Syntax. Auch manuell eingegeben funktioniert das nicht, nur ohne das optionale "rpcserver".

Sind im I/O device noch irgendwelche Attribute wie z.B. eventMap gesetzt?

[simonsky]

Hallo zusammen ich habe folgendes Problem mit dem ccu update und meiner Wetterstation von Homematic. Seit neustens kann ich nicht mehr mit get update die Regen Menge ermitteln
Vorher hatte ich sie mit HMCCUDEV eingebunden das ist leider jetzt auch nicht möglich.
Gibt es eine Möglichkeit die readings wieder zu bekommen. Angezeigt werden sie, aber nicht aktualisiert. Nur bei komplett neuem fhem Start.

Vorher

Code Auswählen Erweitern

define Wetterstation HMCCUDEV 00181A499****
attr Wetterstation IODev ccu
attr Wetterstation event-on-update-reading .*
attr Wetterstation room Wetter
attr Wetterstation stateFormat Temperatur: 1.ACTUAL_TEMPERATURE °C, Feuchtigkeit: 1.HUMIDITY %, Helligkeit: 1.ILLUMINATION, Regen: 1.svHmIPRainCounterYesterday_3440  mm/qm, Wind: 1.WIND_SPEED km/h


Code Auswählen Erweitern

define Wetterstation_update at +*00:30:00 get Wetterstation update
attr Wetterstation_update room Wetter


und jetzt ist es so

Code Auswählen Erweitern

define Wetterstation HMCCUCHN 00181A49*****:1
attr Wetterstation IODev ccu
attr Wetterstation room Wetter

zur info es geht um folgende readings

Code Auswählen Erweitern

svHmIPRainCounterToday und

Code Auswählen Erweitern

svHmIPRainCounterYesterday


danke schon mal für weiter hilfe

[Sommerfeld]

Hallo,
kann es sein, dass Heizungsgruppen nicht mehr unterstützt werden?
V G

[Maista]

@simonsky
Ich hatte das gleiche Problem.
Bin derzeit nicht am PC.
Suche hier im Thread.

Ich hab dazu Variablen in der ccu3 gesetzt welche mir im d_ccu Readings setzt welche ich dann mit einem AT zyklisch in das Wetterstations-Device als Reading schreibe.
Hat mit einem get nie sinnvoll funktioniert.

Zap hatte mir dazu auch geantwortet warum das so ist.

Läuft derzeit auf einem eigenen Raspberry.
Komme auch nicht groß dazu weiter zu werkeln.

Gruß Gerd