HMCCU: Version 4.3 verfügbar

[Ralli]

Ich nehme an, Du hast das "noInitialUpdate" Flag nicht gesetzt (in den HMCCURPCPROC Devices oder dem HMCCU Device)?

Natürlich nicht .

[Tardar]

Hey zap,

ich hatte ein Problem, welches durch 2 Optionen hervorgerufen wurde.
Zum einen, wenn die Reihenfolge der Devices sich in der Config ändert (z.B. die CCU steht unter HMCCUDEV Einträgen oder den Fehler mit Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 125..

Beschrieben mit Lösungsansatz von rudolfkoenig und CoolTux in folgemden Thread:


PS: Nach Anpassung der Reihenfolge (ccu vor erstem ccudev) in der Config startet FHEM wieder.
Vielleicht lässt sich der "Fehler" noch anders abfangen, kannst Du dir ja mal ansehen

https://forum.fhem.de/index.php/topic,104106.msg979066.html

Einen schönen Feiertag und WOchenende gewünscht
Tardar

[zap]

Hallo Zap,

bei meinen HM-Devices, die noch über CUL_HM laufen erscheint bei Schaltvorgängen ein Log 3 Eintrag im global Logfile. Daran hab ich mir ehrlich gesagt etwas gewöhnt und finde es schade, dass dies bei den HM-Devices, die über HMCCU laufen nicht der Fall ist.

Wie sehen denn die Log Meldungen von CUL_HM in diesem Fall aus?

[Wolle02]

Wie sehen denn die Log Meldungen von CUL_HM in diesem Fall aus?

z.B. so:

Code Auswählen Erweitern

2019.10.03 10:50:57 3: CUL_HM set WZ_Heizung_Balkon_ClimRT_tr desired-temp 10.0
2019.10.03 10:50:57 3: CUL_HM set WZ_Heizung_Balkon_ClimRT_tr burstXmit
2019.10.03 10:50:57 3: CUL_HM set WZ_Heizung_Fenster_ClimRT_tr desired-temp 10.0
2019.10.03 10:50:57 3: CUL_HM set WZ_Heizung_Fenster_ClimRT_tr burstXmit
2019.10.03 10:52:59 3: CUL_HM set WZ_Heizung_Balkon_ClimRT_tr controlMode auto
2019.10.03 10:52:59 3: CUL_HM set WZ_Heizung_Balkon_ClimRT_tr burstXmit
2019.10.03 10:52:59 3: CUL_HM set WZ_Heizung_Fenster_ClimRT_tr controlMode auto
2019.10.03 10:52:59 3: CUL_HM set WZ_Heizung_Fenster_ClimRT_tr burstXmit
2019.10.03 12:16:33 3: CUL_HM set SZ_Decke on
2019.10.03 12:16:34 3: CUL_HM set SZ_Decke off


Im Prinzip einfach nur der Schaltvorgang wiedergegeben, aber man kann so im Zusammenspiel mit anderen Logeinträgen schön nachvollziehen, was wann wie geschaltet hat oder halt auch nicht.

[zap]

Kommt mit dem nächsten Release.

[Wolle02]

Kommt mit dem nächsten Release.

Bei der Gelegenheit noch eine Bitte   

Zitat aus der CommanRef von HMCCU:

get <name> ccumsg {service|alarm}
Query active service or alarm messages from CCU. Generate FHEM event for each message.

Könntest du für solch ein Event auch einen Logeintrag generieren, damit man sich daraus dann ein notify basteln könnte?

Danke und Gruß
Wolle

[Ralli]

Das Problem ist, dass die CCU keinen RPC-Event erzeugt, wenn eine Service- oder Alarmmeldung vorliegt.

Du kannst das anders lösen: definiere dir in der CCU ein Programm, welches bei Vorliegen von Servicemeldungen bspw. einen virtuellen Taster betätigt (Fernbedienung). Du definierst in fhem ein Device für die virtuellen Taster (def CCU_FB HMCCUDEV BidCoS-RF) und kannst nun für die entsprechenden Readings dein notify bzw. DOIF bauen.

Ich habe bspw. im Ausführungsteil eines DOIF folgendes definiert:

Code Auswählen Erweitern


({my $smsg=fhem("get CCU2 ccumsg service"); $smsg =~ s/;/,/g; fhem("set Telegram message \@Empfaenger ".$smsg)})


[Wolle02]

Moin Ralli,

vielen Dank für deine Erklärung und deinen Tip zur Umsetzung.

Das ist natürlich doof wenn die CCU selber schon kein Event erzeugt. Hmmm, jetzt muss ich erstmal schauen, wie man in der CCU Programme und virtuelle Taster anlegt; von der Syntax ganz zu schweigen. Damit habe ich mich bislang noch nie beschäftigt. Meine gesamte Logik läuft in Fhem. Die CCU brauch ich nur als I/O.

Gruß
Wolle

[Ralli]

Hallo Wolle,

ich mache das ähnlich. Ich nutze die CCU grds. als reines IO-Gateway zu Sensoren und Aktoren. Außer für manche rudimentäre Programme, wie solche, um Einschränkungen der CCU zu kompensieren.

Die virtuellen Taster sind in der CCU standardmäßig bereits drin. Und ein entsprechendes Programm bekommst du recht einfach über die WebUI konfiguriert. Einfach mal probieren!

[Wolle02]

Ja, ich hab jetzt gesehen, dass ich in der CCU zwei Geräte habe, die HM-RCV-50 und HmIP-RCV-50 heißen. Das sind scheinbar jeweils 50 virtuelle Taster. Bevor ich da jetzt irgendwas mache nur nochmal kurz die Rückversicherung 
Ich kann diese virtuellen Taster frei verwenden und mit irgendwas belegen? Die werden nicht für irgendwelche systeminternen Dinge der CCU gebraucht?

[Ralli]

Ich kann diese virtuellen Taster frei verwenden und mit irgendwas belegen?

Ja.

Die werden nicht für irgendwelche systeminternen Dinge der CCU gebraucht?

Nein.

[Wolle02]

Funktioniert gut. Vielen Dank nochmal.

[Simon74]

Es gibt mittlerweile einen set datapoint Befehl im IO Device, mit dem man mehrere Devices vom Typ HMCCUCHN und HMCCUDEV in einem CCU Request schalten kann. Wenn also beide Schaltbefehle aus dem gleichen DOIF resultieren, solltest du das mal probieren.

Außerdem habe ich in HMCCUCHN und HMCCUDEV den Befehl set rpcparameter eingebaut. Der setzt Datenpunkte über die RPC Schnittstelle unter Umgehung der CCU Rega. Das kann auch bei Timeout Problemen helfen.

Gibt es hierzu genaueres (Wiki) ?
(Wie schon mal geschrieben habe ich keine Netzwerkprobleme, einzelne Befehle laufen ansonsten auch zügig ab)
Ich habe nun das notify zum alle Lichter aus(schalten) umgebaut, anstatt einzelne Devices anzugeben einfach mit Filter.

Hier ein "list group=Licht" um zu sehen wieviele Devices geschaltet werden (wenn on)

Code Auswählen Erweitern

HM_di_bz
HM_di_eg
HM_di_fl
HM_di_ku
HM_di_sz
HM_di_wz
HM_sd_bo1
HM_sd_ku_led
HM_sd_wz_led
HM_ws_bz_spiegel
HM_ws_ku_herdlicht
HM_ws_tr
HmIP_di_bo
HmIP_di_ez

notify: (nfy.auto_bm.alle) sieht so aus

Code Auswählen Erweitern

bm.alle:.*
{Log 2,"$NAME: $EVENT ($SELF)"};
IF (Value("$NAME.enable") ne "") (delete $NAME.enable);
IF ([$NAME] eq "off") (
  set HmIP_pr_wz detection-off,
  set HmIP_pr_bz detection-off,
  attr nfy.bm.eg_timer disable 1,
  attr nfy.bm.fl_timer disable 1,
  define $NAME.enable at +00:30 set $NAME on,
  set group=Licht:FILTER=STATE!=off off,
  {Log 1,"Bewegunsmelder Aus: Alle ($SELF)"}
)
ELSE (
  set HmIP_pr_wz detection-on,
  set HmIP_pr_bz detection-on,
  attr nfy.bm.eg_timer disable 0,
  attr nfy.bm.fl_timer disable 0,
    {Log 1,"Bewegunsmelder Ein: Alle ($SELF)"}
)

Alle Lichter mal eingeschaltet und Testlauf:
FHEM Log:

Code Auswählen Erweitern

2019.10.05 21:41:12 1: Bewegunsmelder Aus: Alle (nfy.auto_bm.alle)
2019.10.05 21:41:16 2: HMCCUDEV: [HmIP_pr_bz] Error during CCU request. read from http://10.8.5.224:8181 timed out
2019.10.05 21:41:16 2: HMCCUDEV: [HmIP_pr_wz] Error during CCU request. read from http://10.8.5.224:8181 timed out
2019.10.05 21:41:16 2: HMCCUDEV: [HM_ws_ku_herdlicht] Error during CCU request. read from http://10.8.5.224:8181 timed out
2019.10.05 21:41:16 2: HMCCUDEV: [HmIP_di_ez] Error during CCU request. read from http://10.8.5.224:8181 timed out
2019.10.05 21:41:16 2: HMCCUDEV: [HmIP_di_bo] Error during CCU request. read from http://10.8.5.224:8181 timed out
2019.10.05 21:41:16 2: HMCCUDEV: [HM_sd_bo1] Error during CCU request. read from http://10.8.5.224:8181 timed out

Geschaltet (off) wurde nun jedoch alles, hat halt ein paar Sekunden gedauert.
Bin ich der einzige mit dem Problem ?

[kotaro]

Ja, ich hab jetzt gesehen, dass ich in der CCU zwei Geräte habe, die HM-RCV-50 und HmIP-RCV-50 heißen. Das sind scheinbar jeweils 50 virtuelle Taster. Bevor ich da jetzt irgendwas mache nur nochmal kurz die Rückversicherung 
Ich kann diese virtuellen Taster frei verwenden und mit irgendwas belegen? Die werden nicht für irgendwelche systeminternen Dinge der CCU gebraucht?

so wie ich das verstanden habe, ist es für eine bessere Steuerung der Geräte gedacht. Aus Programmen soll man die Virtuellen Taster drücken. Diese Virtuellen Taster kannst du aber direkt mit dem Gerät peeren, und hast eine bessere Latenz und so...
zumindest, habe ich das so verstanden mal..

[zap]

Die Beschreibung der Befehle findest Du in der commandref.

Gruppen bzw. Devicefilter werden derzeit noch nicht unterstützt. Grundsätzlich aber eine sehr gute Idee für eine Erweiterung.

In Deinem Fall wäre z.B. folgende Vereinfachung möglich. Statt:

Code Auswählen Erweitern


  set HmIP_pr_wz detection-off
  set HmIP_pr_bz detection-off


könntest Du folgendes schreiben (angenommen, das IO Device heißt d_ccu und der Datenpunkt hinter detection-off wäre 1.DETECTION mit zulässigen Werten 0 und 1):

Code Auswählen Erweitern

set d_ccu datapoint HmIP_pr_wz.1.DETECTION=0 HmIP_pr_bz.1.DETECTION=0

Die beiden Set-Befehle werden dann in einem Request an die CCU geschickt.

Wenn HmIP_pr_wz ein HMCCUCHN Devices sind, lässt Du die Kanalnummer vor dem Datenpunkt weg, also:

Code Auswählen Erweitern

set d_ccu datapoint HmIP_pr_wz.DETECTION=0 HmIP_pr_bz.DETECTION=0