HMCCU: Version 4.3 verfügbar

[zap]

Muss ich nochmal prüfen. Delayedinit hat eben den Nachteil, dass immer die angegebene Zeit gewartet wird, auch wenn die CCU errichbar ist. Gab es denn bei ccudelay irgendwelche Log Einträge?

[warp10]

Gab es denn bei ccudelay irgendwelche Log Einträge?

Der Log in meinem Post ist der mit ccudelay. Meinst Du noch einen anderen Log?

[Simon74]

1. Danke für das HMCCU Modul ! :-)

2.
Ich habe soeben alles von HMLAN auf CCU3 umgestellt, um zukünftig HM-IP Geräte nutzen zu können.
Die 2 vorhandenen LAN-Gateways habe ich der CCU3 untergeordnet, wobei mir hier noch nicht klar ist ob sich die Geräte den besten Gateway selbstständig suchen.
HM_CUL ist aus der FHEM Konfiguration verschwunden.

3.
Ich habe bis dato für Bewegungsmelder <> Licht Aktionen "TIMED_ON" verwendet, Beispiel:

Code: [Auswählen]

IF ([HM_bm_ku:2.BRIGHTNESS] < 37 and [HM_sd_ku_led] eq "off" or [HM_sd_ku_led:timedOn] eq "running")
 ({Log 3, "Notify(nfy.bm.ku_led): LED Timer Küche (5min)"},set HM_sd_ku_led on-for-timer 300)Wird dies so schon unterstützt, Reading sehe ich nicht obwohl ich im Device folgendes gesetzt habe:

Code: [Auswählen]

ccureadingfilter (STATE|CURRENT|ENERGY_COUNTER|POWER|TIMED_ON)Bin ich richtig in der Annahme das hier "ccudef-substitute" in der HMCCU noch angepasst werden muss ?
DEFMOD sieht bei mir so aus:

Code: [Auswählen]

defmod ccu31 HMCCU 192.168.0.224
attr ccu31 ccudef-readingfilter ^(LOW_?BAT|UNREACH)$
attr ccu31 ccudef-readingname ^(.+\.)?LOW_?BAT$:battery;;^(.+\.)?UNREACH$:activity
attr ccu31 ccudef-substitute AES_KEY!(0|false):off,(1|true):on;;LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;;UNREACH!(0|false):alive,(1|true):dead;;MOTION!(0|false):noMotion,(1|true):motion;;DIRECTION!0:stop,1:up,2:down,3:undefined;;WORKING!0:false,1:true;;INHIBIT!(0|false):unlocked,(1|true):locked
attr ccu31 cmdIcon on:general_an off:general_aus
attr ccu31 eventMap /rpcserver on:on/rpcserver off:off/
attr ccu31 room Homematic
attr ccu31 rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
attr ccu31 rpcport 2001,2010,9292
attr ccu31 rpcserver on
attr ccu31 stateFormat rpcstate/state
4.
Geschwindigkeit Unterschied HMLAN <-> HMCCU.
Da ich im Moment aus Neugierde gerade auch andere Lösungen teste (Symcon und ioBroker) fällt mir auf das hier FHEM am langsamsten mit der CCU kommuniziert.
Gefüllt sind die 2 genannten Lösungen bei Motion gleich schnell wie FHEM mit HMLAN direkt.
Unter FHEM sind gefüllt 2 Sekunden dazu gekommen, wäre schön wenn das an meiner Konfiguration liegt ? 

[zap]

@warp10: ist ein Bug, der nur in bestimmten Fällen auftritt. Morgen gibt es ein Update dafür.

@Simon74: Du solltest im Device ccu31 das Attribut ccuflags auf procrpc setzen. Derzeit verwendest du den internen RPC Server, der ist langsam und fliegt demnächst raus.

ccudef-sjbstitute beziehf sich auf alle Devices, das solltest Du so lassen. Jedes Device hat ein Attrinut substitute, das du ggf setzen solltest. Wenb du Glück hast, gibt es für deine Devices Defaults. Einfach mal set defaults bei einem Device ausführen.

wenn es weiterhin nicht geht, mach mal ein get deviceinfo.

[Simon74]

ich meinte gelesen zu haben das procrpc schon die Default Einstellung ist :-) habe ich nun eingetragen.
Bzl. der Devices gibt es hier noch keine Defaults werde hier aber wenn nötig in den richtigen Beitrag schreiben,
vielen Dank !

[warp10]

@warp10: ist ein Bug, der nur in bestimmten Fällen auftritt. Morgen gibt es ein Update dafür.

Ok danke fürs bugfixing! Es funktioniert jetzt auch mit "ccudelay".

Ich hätte zwei Fragen und zwar hab ich zwei Homematic IP Wassermelder gekauft und in piVCCU angemeldet.
Dann hab ich diese als neue HMCCUDEVs in fhem angelegt, aber vergessen vorher das HMCCU-Attribut "rpcinterfaces" um HmIP-RF zu erweitern.
Was mich wundert ist, dass die Wassermelder trotzdem in fhem funktioniert, obwohl kein rpcinterface dazu exisitiert. Woran liegt das?
(Mittlerweile habe ich das Attribut um HmIP-RF erweitert und habe jetzt entsprechend zwei rpc Devices)

Die andere Frage: nachdem ich die Wassermelder als HMCCUDEVs in fhem angelegt hatte war deren readings "hmstate = unreachable" und "Activity = dead" und in piVCCU hatte ich bei den Servicemeldungen "Gerätekommunikation gestört". Das passiert auch nach jedem Neustart meines RPi, aber erst seitdem ich die Devices bei fhem angelegt habe. Irgendwie scheint das Herstellen einer Verbindung mit fhem den Zustand in piVCCU zu verändern. Ist das normal?

Danke und viele Grüße,
Thorsten

[zap]

Was mich wundert ist, dass die Wassermelder trotzdem in fhem funktioniert, obwohl kein rpcinterface dazu exisitiert. Woran liegt das?

rpcinterfaces und die HMCCURPCPROC Devices werden nur für den Empfang der Events von der CCU benötigt, also die Aktualisierung der Readings. Die Steuerung von FHEM aus läuft per Homematic Script. Das ist die Logikschicht der CCU.

Die andere Frage: nachdem ich die Wassermelder als HMCCUDEVs in fhem angelegt hatte war deren readings "hmstate = unreachable" und "Activity = dead" und in piVCCU hatte ich bei den Servicemeldungen "Gerätekommunikation gestört". Das passiert auch nach jedem Neustart meines RPi, aber erst seitdem ich die Devices bei fhem angelegt habe. Irgendwie scheint das Herstellen einer Verbindung mit fhem den Zustand in piVCCU zu verändern. Ist das normal?

Beim Start von FHEM wird der Status aller Devices von der CCU abgefragt. Wenn die CCU schon eine Weile läuft, ist das kein Problem. In Deinem Fall wird sie aber mit dem Pi gestartet. Daher muss sie selbst erst bei den Geräten die Daten abfragen. Dabei wird das Sende Limit anscheinend überschritten.
Wenn Du nur FHEM neu startest,  sollte das eigentlich nicht passieren.

[Ban]

Bräuchte auch etwas Hilfe.

Heute ist mir aufgefallen, dass der HmIP-RF nicht mehr richtig startet.
Er bleibt immer auf Initialized und dementsprechend bekomme ich auch keinen Status der HMIP-Geräte z.b. von einem HmIP-BSM.
Dessen Status bleibt auch auf Initialized.
Ich verwende mit der CCU2 noch normal HM, dieser RPC startet normal und von den normalen HM-Geräten bekomme ich auch die Statusänderungen.

So sieht der jeweilige Status aus:

CCU RPC BidCos-RF running/OK
CCU RPC HmIP-RF Initialized
HM_CCU2 running/OK

192.168.10.14 ccudelay=200 habe ich in der HM_CCU2 zum Test gesetzt.
Reboot des Pi und/oder der CCU2 bringen keinen Erfolg.

Hat evtl. jemand eine Idee? Fhem ist aktuell.
Ich habe zwischenzeitlich neue Geräte an der CCU2 angemeldet.
Kann es damit zusammen hängen?

Vielen Dank,
Ban

Edit:
Habe den Fehler gefunden.
Das Attribut rpcinterfaces war plötzlich nicht mehr gesetzt.
Habe es wieder auf den Wert "BidCos-RF,HmIP-RF" gesetzt und jetzt läuft es wieder.

[Familienpapi]

Hallo,
bei mir startet der RPC Server nach einem Start von FHEM nicht.
Meine Konfig:
RPi3 mit piVCCU, deaktiviertem Bluetooth und aktiviertem WLAN. Daher auch überall die angegebenen IP-Adressen. WLAN ist auf 192.168.188.0/24 zu finden. Alles aktuell gepachtet, Stand heute Abend.

fhem.cfg:

Code: [Auswählen]

define HomeMatic HMCCU 192.168.237.241
attr HomeMatic ccuflags procrpc
attr HomeMatic event-on-change-reading .*
attr HomeMatic group HomeMatic
attr HomeMatic room zzConfig
attr HomeMatic rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
attr HomeMatic rpcinterval 5
attr HomeMatic rpcport 2001,2010,9292
attr HomeMatic rpcqueue /opt/fhem/ccutemp
attr HomeMatic rpcserver on
attr HomeMatic rpcserveraddr 192.168.237.240
attr HomeMatic stateFormat rpcstate/state

define d_rpcBidCos_RF HMCCURPCPROC iodev=HomeMatic BidCos-RF
attr d_rpcBidCos_RF ccuflags ccuInit,reconnect
attr d_rpcBidCos_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpcBidCos_RF group HomeMatic
attr d_rpcBidCos_RF room zzConfig
attr d_rpcBidCos_RF stateFormat rpcstate/state
attr d_rpcBidCos_RF rpcServerAddr 192.168.237.240

define d_rpcHmIP_RF HMCCURPCPROC iodev=HomeMatic HmIP-RF
attr d_rpcHmIP_RF ccuflags ccuInit,reconnect
attr d_rpcHmIP_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpcHmIP_RF group HomeMatic
attr d_rpcHmIP_RF room zzConfig
attr d_rpcHmIP_RF stateFormat rpcstate/state
attr d_rpcHmIP_RF rpcServerAddr 192.168.237.240

define d_rpcVirtualDevices HMCCURPCPROC iodev=HomeMatic VirtualDevices
attr d_rpcVirtualDevices ccuflags ccuInit,reconnect
attr d_rpcVirtualDevices eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpcVirtualDevices group HomeMatic
attr d_rpcVirtualDevices room zzConfig
attr d_rpcVirtualDevices stateFormat rpcstate/state
attr d_rpcVirtualDevices rpcServerAddr 192.168.237.240
Im Log steht dann:

Code: [Auswählen]

2018.09.20 20:48:57 1: HMCCU: [HomeMatic] Initialized version 4.3.001
2018.09.20 20:48:57 1: HMCCU: [HomeMatic] HMCCU: Initializing device
2018.09.20 20:48:57 1: HMCCU: [HomeMatic] HMCCU: Read 2 devices with 59 channels from CCU 192.168.237.241
2018.09.20 20:48:57 1: HMCCU: [HomeMatic] HMCCU: Read 3 interfaces from CCU 192.168.237.241
2018.09.20 20:48:57 1: HMCCU: [HomeMatic] HMCCU: Read 0 programs from CCU 192.168.237.241
2018.09.20 20:48:57 1: HMCCU: [HomeMatic] HMCCU: Read 0 virtual groups from CCU 192.168.237.241
2018.09.20 20:48:57 1: HMCCURPCPROC: [d_rpcBidCos_RF] Initialized version 1.0.007 for interface BidCos-RF with I/O device HomeMatic
2018.09.20 20:48:57 1: HMCCURPCPROC: [d_rpcHmIP_RF] Initialized version 1.0.007 for interface HmIP-RF with I/O device HomeMatic
2018.09.20 20:48:57 1: HMCCURPCPROC: [d_rpcVirtualDevices] Initialized version 1.0.007 for interface VirtualDevices with I/O device HomeMatic
Die Internals:

Code: [Auswählen]

CCUNum 1
Clients :HMCCUDEV:HMCCUCHN:HMCCURPC:HMCCURPCPROC:
DEF 192.168.237.241
NAME HomeMatic
NOTIFYDEV global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
NR 90
NTFY_ORDER 50-HomeMatic
RPCState inactive
STATE inactive/OK
TYPE HMCCU
ccuaddr BidCoS-RF
ccuchannels 59
ccudevices 2
ccuif BidCos-RF
ccuinterfaces BidCos-RF,HmIP-RF,VirtualDevices
ccuip 192.168.237.241
ccuname HM-RCV-50 BidCoS-RF
ccustate active
ccutype CCU2/3
host 192.168.237.241
version 4.3.001
Ich kann nun direkt

Code: [Auswählen]

set HomeMatic rpcserver on eingeben und der RPC Server läuft auf Anhieb und die Temperaturen von einem Wandthermostat werden auch aktualisiert.
Aber ich muss eben manuell starten. Das funktioniert sogar wenige Sekunden nach einem FHEM Neustart.

Mir gehen die Ideen aus, stehe jedoch für weitere Infos / Anregungen gerne zur Verfügung.

[zap]

@Ban: Logfile Einträge?

[Ban]

Hallo Zap,

hat sich gerade überschnitten. Habe den Fehler gefunden.
Das Attribut rpcinterface war nicht mehr gesetzt.
Habe es wieder auf  "BidCos-RF,HmIP-RF" gesetzt und jetzt läuft wieder alles wunderbar:-)
Habe es aber nicht wissentlich gelöscht...

Dank dir für dein tolles Modul!!!

Grüße,
Ban

[zap]

Vielleicht nicht gespeichert nach dem Attribut setzen?

[zap]

@Familienpapi:

Sowas steht nicht im Log, vielleicht etwas weiter unten:

HMCCU: Start of RPC server after FHEM initialization in xx seconds

Die Attribute rpcinterval und rpcqueue im HMCCU DEvice kannst Du löschen. Werden nicht mehr benötigt. Haben aber nichts mit Deinem Problem zu tun.

[Ban]

@zap:

Das nicht Speichern kann ich ausschließen.
Habe erst seit 3 Wochen die CCU2 wegen mehreren HMIP Geräten und habe Fhem in der Zeit sehr oft neu gestartet.
Das Attribut habe ich ganz am Anfang gesetzt.
Da ging danach immer alles. Ich werde es beobachten und bescheid sagen, falls es wieder auftritt.

[warp10]

Danke für Deine Antwort.

rpcinterfaces und die HMCCURPCPROC Devices werden nur für den Empfang der Events von der CCU benötigt, also die Aktualisierung der Readings. Die Steuerung von FHEM aus läuft per Homematic Script. Das ist die Logikschicht der CCU.

Seltsamerweise hatte ich aber trotzdem korrekte Readings obwohl es da für HMIP zuständige HMCCURPCPROC Device noch nicht gab.

Beim Start von FHEM wird der Status aller Devices von der CCU abgefragt. Wenn die CCU schon eine Weile läuft, ist das kein Problem. In Deinem Fall wird sie aber mit dem Pi gestartet. Daher muss sie selbst erst bei den Geräten die Daten abfragen. Dabei wird das Sende Limit anscheinend überschritten.
Wenn Du nur FHEM neu startest,  sollte das eigentlich nicht passieren.

Das Problem bestand aber auch beim ersten Anlegen der Devices in fhem, und da lief die CCU schon sehr lange. Der Duty Cycle ist mit Sicherheit kein Problem, den logge ich mit und der ist bei mir immer unter 5%, auch nach einem Neustart. Ich hab noch nicht viele Homematic-Geräte...

Viele Grüße,
Thorsten