HMCCU 5.0 Beta verfügbar

[Dek]

Hallo zusammen,

Ich habe den Umstieg gewagt, und es hat auch alles funktioniert. Ich habe aus jeder Menge HMCCUDEV jetzt HMCCUCHN gemacht. Dabei ist mir eine "Inkonsistenz" aufgefallen.

kurzer Ausflug in meinen Use-Case:
Ich nutze Heizkörper-Thermostate als dumme Stellglieder, indem ich sie voll-aufdrehe, und den Öfflungsgrad über die config "VALVE_MAXIMUM_POSITION" regle.

Um hier den aktuellen Stand im Reading zu haben, muss ich nach einem

Code Auswählen Erweitern


set MyDevice config VALVE_MAXIMUM_POSITION=0.33:DOUBLE

ein

Code Auswählen Erweitern


get MyDevice  config VALVE_MAXIMUM_POSITION


ausführen, und hier steckt der Teufel:
Das HMCCUDEV hat beim get config noch einen Filter, ("get <name> config [<filter-expr>]" das HMCCUCHN kennt diese Option ("get <name> config") nicht.

das führt dazu, dass immer alle (!) configs abgeholt werden und bei einem programmatischen Aufruf (notify) im logfile landen. Was das mit den RF credits macht, weis ich nicht.

Frage: kann man an der Stelle die Funktionalität angleichen?
Dek

PS: Ich nutze die Version aus dem git repository

[zap]

@Dek: In beiden Fällen (bei HMCCUDEV und bei HMCCUCHN) wird jeweils das komplette Paramterset gelesen (also alle Parameter eines Kanals). Das ist lediglich ein Befehl in Richtung CCU und Gerät. Man spart also nichts beim Duty Cycle, wenn man nur einen Parameter abfragt (was möglich wäre).

Aber ich verstehe den Hintergrund und werde das bei HMCCUCHN entsprechend abpassen.

[zap]

Hi Zap,

der RC7 funktioniert bei mir wunderbar.
Beim Resetten meiner Devices ist mir aufgefallen, dass die beiden Devices noch nicht komplett hinterlegt sind.
   
HmIP-SWD Wassersensor  >>"HMCCUDEV: HmIP_SWD_Keller_Wassersensor No default attributes found"
HmIP-SAM Neigungssensor  >> kein reset aber auch keine Fehlermeldung

Wie kann ich Dir helfen, die Geräte einzubinden ?

Gruß
Christoph

Die Typbezeichnungen genügen mir. Aber: HmIP-SWD ist ein "SensorWindowDoor" = SWD, also kein Wassersensor (?)

[kjmEjfu]

Die Typbezeichnungen genügen mir. Aber: HmIP-SWD ist ein "SensorWindowDoor" = SWD, also kein Wassersensor (?)

Wassersensor: https://de.elv.com/homematic-ip-wassersensor-hmip-swd-ip44-151694

[zap]

Wassersensor: https://de.elv.com/homematic-ip-wassersensor-hmip-swd-ip44-151694

Und wieder einmal ist es Zeit, Danke zu sagen. Danke EQ-3 für verwirrende / falsche / geänderte oder auch nicht geänderte Gerätebezeichnungen.

In der Homematic IP Device Doku steht der Wasser-Sensor als "HmIP-SW" drin. Man beachte das nicht vorhandene "D"

Im ELV-Webshop sind entsprechend die Fenstersensoren als "SWDO" (Optisch) und "SWDM" (Magnetisch) aufgeführt.

Da hat wohl jemand vergessen, die Device Doku zu aktualisieren.

[Dek]

@Dek: In beiden Fällen (bei HMCCUDEV und bei HMCCUCHN) wird jeweils das komplette Paramterset gelesen (also alle Parameter eines Kanals). Das ist lediglich ein Befehl in Richtung CCU und Gerät. Man spart also nichts beim Duty Cycle, wenn man nur einen Parameter abfragt (was möglich wäre).

Habe ich das richtig verstanden: eine Einzel-Wert Abfrage wäre möglich, ist aber aktuell nicht implementiert? Auch wenn das den duty-cycle nix kostet, ist immerhin für die Antwort das shared-Medium Funk belegt. Ich kenne aber das Protokoll nicht/zu wenig, um hier mögliche Kollisionen zu erkennen. In der Heiz-Saison wird der Befehl im Schnitt (über alle Aktoren hinweg summiert) bei mir durchaus 1/Minute geschickt. Da kommt was zusammen.

Aber ich verstehe den Hintergrund und werde das bei HMCCUCHN entsprechend abpassen.

Das klingt gut. Dann auch die Ausgabe ins Log unterbinden, solange muss ich auf verbose 2 stellen.

Dek

[Dek]

Wobei ich gerade merke, dass ich gar nicht weiß, welches verbose ich runterdrehen müsste, da das ja eine umgeleitete GUI-Ausgabe ist....

[zap]

Wobei ich gerade merke, dass ich gar nicht weiß, welches verbose ich runterdrehen müsste, da das ja eine umgeleitete GUI-Ausgabe ist....

In der 4.4 dürfte auch bei HMCCUDEV "get config" keinen Filter erlauben. Das habe ich wohl "wegoptimiert". Kommt wieder ... oder vielleicht ein eigener get Befehl.

[Dek]

Wobei ich gerade merke, dass ich gar nicht weiß, welches verbose ich runterdrehen müsste, da das ja eine umgeleitete GUI-Ausgabe ist....

Problem gelöst:
Ich hatte den Befehl in einem Perl-Block über

Code Auswählen Erweitern


fhem("get MyDevice config VALVE_MAXIMUM_POSITION");

ausgeführt, habe dann aber inzwischen gelesen, dass der fhem() Befehl noch ein Argument (=1) kennt, um die Ausgabe zu unterdrücken:

Code Auswählen Erweitern


fhem("get MyDevice config VALVE_MAXIMUM_POSITION",1);


Damit läuft alles wie gewünscht, es dauert (gefühlt) länger als mit der alten Lösung. Aber das ist nur eine Randnotiz ohne Relevanz

Dek

[Rosti]

Hi,

Nachdem mein HMLAN langsam am sterben war, habe Ich auf ccu3 und auf die 4.4 Beta umgestellt.
Soweit funktioniert alles gut, folgendes aber aufgefallen:

- Schaltvorgang über FHEM und events dauert gefühlt 1 Sekunde, mit dem HMLAN war die Verzögerung deutlich kleiner, aber Ich nehme an es ist halt so.
- Wenn ccu3 rebootet wird, dann wird die Verbindung nicht automatisch wieder aufgebaut vom Modul. Im GUI steht verbunden/OK, aber es funktioniert nichts, erst nach "set off"/"set on" geht es.

lg

[zap]

@Rosti: Setze mal im I/O Device im Attribut "ccuflags" das Flag "reconnect".

[zap]

Nicht unterstützte HM-Geräte

Man kann mit HMCCU 4.4 natürlich auch Geräte steuern / nutzen, die von "get create" und "get createDev" nicht erkannt werden. Dazu geht man wie folgt vor:

• Man definiert für jeden Kanal des Gerätes, den man nutzen möchte, ein HMCCUCHN Device oder für das Gerät insgesamt ein HMCCUDEV Device
• Man legt mit dem Attribut statedatapoint den Datenpunkt fest, der in STATE erscheinen soll
• Wenn man Werte in den Readings ersetzen möchte (z.B. false oder 0 durch "closed"), verwendet man das Attribut substitute

Lässt sich das Gerät auch steuern, setzt man zusätzlich das Attribut controldatapoint auf den Datenpunkt, mit dem sich das Gerät steuern lässt (z.B. LEVEL bzw. x.LEVEL für HMCCUDEV).
Nun kann man noch zusätzlich mit dem Attribut statevals Befehle definieren, die sich auf den controldatapoint beziehen.

Ein Beispiel für einen BidCos-RF Dimmer, Status und Steuerung über Kanal 1 => HMCCUCHN:

Code Auswählen Erweitern


define myDimmer HMCCUCHN abcdefgh:1
attr myDimmer statedatapoint LEVEL
attr myDimmer controldatapoint LEVEL
attr statevals on:100,off:0


Danach stehen die Befehle "set myDimmer on" und "set myDimmer off" zur Verfügung. Sie setzten den controldatapoint 1.LEVEL auf 100 oder 0.

Bei einem HmIP-Dimmer liegen statedatapoint und controldatapoint gerne in unterschiedlichen Kanälen => HMCCUDEV:

Code Auswählen Erweitern


define myDimmer HMCCUDEV abcdefgh
attr myDimmer statedatapoint 3.LEVEL
attr myDimmer controldatapoint 4.LEVEL
attr statevals on:100,off:0


Grundsätzlich werden die Readings eines Gerätes auch dann ausgelesen und aktualisiert, wenn HMCCU die Geräte nicht "kennt".
Jedes steuerbare Gerät kann mit "set datapoint" gesteuert werden. Man muss natürlich Namen, Funktion und Werte der Datenpunkte kennen.

[Maista]

@zap

Moin,

heute endlich mal wieder Zeit gehabt....

Das anlegen der Wetterstation HmIP-SWO-PR hat soweit funktioniert!

Wurden die "1." bei den Readings-Namen wegoptimiert?

get HM.OG.bk.WE.Sensor config

erzeugt im Event Monitor Fehlermeldungen.

Code Auswählen Erweitern

2021.08.22 19:42:27 1 : HMCCURPCPROC [d_rpc178040HmIP_RF] Error in request getParamset 00185BE9A57631 SERVICE: Generic error (UNREACH)
2021.08.22 19:42:28 1 : HMCCURPCPROC [d_rpc178040HmIP_RF] Error in request getParamset 00185BE9A57631:0 SERVICE: Generic error (UNREACH)
2021.08.22 19:42:29 1 : HMCCURPCPROC [d_rpc178040HmIP_RF] Error in request getParamset 00185BE9A57631:1 SERVICE: Generic error (UNREACH)
Ist das ok?

Im Fenster des Devices bekomme ich aber eine Ausgabe angezeigt:

Code Auswählen Erweitern

Device 00185BE9A57631
  Channel 0 [MASTER]
    ARR_TIMEOUT = 10
    CYCLIC_INFO_MSG = 1
    CYCLIC_INFO_MSG_DIS = 0
    CYCLIC_INFO_MSG_DIS_UNCHANGED = 0
    CYCLIC_INFO_MSG_OVERDUE_THRESHOLD = 2
    DUTYCYCLE_LIMIT = 180
    ENABLE_ROUTING = false
    LOCAL_RESET_DISABLED = false
    LOW_BAT_LIMIT = 3.2

get HM.OG.bk.WE.Sensor datapoint svHmIPRainCounterToday_1609

zeigt das im Web an :

Code Auswählen Erweitern

HMCCUCHN: HM.OG.bk.WE.Sensor Execution of CCU script or command failed
und erzeugt im Event Monitor diese Fehlermeldung:

Code Auswählen Erweitern

2021.08.22 19:45:39 1 : HMCCUCHN [HM.OG.bk.WE.Sensor] Error CMD = Write((datapoints.Get("HmIP-RF.00185BE9A57631:1.svHmIPRainCounterToday_1609")).Value())
2021.08.22 19:45:39 1 : HMCCUCHN [HM.OG.bk.WE.Sensor] HMCCUCHN: HM.OG.bk.WE.Sensor Execution of CCU script or command failed

Wann diese ".svHmIP"-Variablen automatisch aktualisiert werden habe ich noch nicht verstanden.

Danke und noch schönen Sonntag

Gerd

[zap]

Die Kanalnummer im Reading gibt es nur bei HMCCUDEV. Ändern kann man die Darstellung mit dem Attribut "ccureadingformat".

Die Fehler "Error in request getParamset 00185BE9A57631 SERVICE: Generic error (UNREACH)" lässt sich leider nicht vermeiden. Ursache: Die CCU liefert für einige Geräte eine falsche Parameterbeschreibung. Diese Beschreibung gibt fälschlicherweise an, dass es ein Parameterset SERVICE gibt, das tatsächlich jedoch nicht existiert. Daher der Fehler. Also ignorieren.

Die verknüpften Systemvariablen sind ein Problem. Die CCU aktualisiert diese nicht automatisch. Wie verhält es sich bei "get values"? Werden die Readings dann aktualisiert.

[Maista]

Die Kanalnummer im Reading gibt es nur bei HMCCUDEV. Ändern kann man die Darstellung mit dem Attribut "ccureadingformat".

Ah, das war mir bisher nicht bewusst, komme immer nur sporadisch dazu etwas zu machen :=(

Die verknüpften Systemvariablen sind ein Problem. Die CCU aktualisiert diese nicht automatisch. Wie verhält es sich bei "get values"? Werden die Readings dann aktualisiert.

Das Funktioniert, gibt ein Fenster mit den Daten. Im Event-Monitor sehe ich auch keine Fehlermeldung.