HMCCU: Version 4.3 verfügbar

[zap]

Hallo zap,

ich habe vor ein paar Tagen ein FHEM Update gemacht, dabei wurde auch HMCCU aktualisiert. Seitdem kommt es alle 1-2 Tage vor, dass FHEM schlagartig so langsam ist, dass ich den PI neu starten muss. Danach läuft es wieder. Kann HMCCU dafür verantwortlich sein? Ich habe versäumt den RPC Server zu stoppen, weiß aber auch nicht, ob es für mich relevant ist.

Dies Fehlermeldung steht häufig im Log:

HMCCU: Can't open file queue /tmp/ccuqueue_2001_1

Danke und viele Grüße

Offensichtlich hat fhem keine Schreibrechte auf das /tmp Verzeichnis oder die Datei existiert und darf von fhem nicht überschrieben werden.

Aber ich würde dir sowieso empfehlen, auf procrpc umzustellen. Dazu im IO Device ccuflags auf procrpc stellen, speichern und fhem neu starten. Dabei wird mindestens 1 neues Device vom Typ HMCCURPCPROC anglegt. Nochmal speichern und Rpc Server starten.

[zap]

Kleines Update auf 4.3.008. Einige kleinere Bugs behoben.

Funktionale Änderungen:

• HMCCURPCPROC: Neues Attribut rpcPingCCU und ccuflag logPong für periodischen CCU alive check
• HMCCURPCPROC: Events bzw. Datenpunkte können nun auch senkrechte Striche enthalten
• HMCCU: Auslesen von CCU Systemvariablen angepasst
• HMCCUConf: Scripts zum Auslesen von Service- und Alarmmeldungen
• HMCCUConf: Script GetVariables überarbeitet
• HMCCUConf: Script GetVariablesExt zum Auslesen aller Variableninformationen
• HMCCUConf: Einige HmIP Gerätekonfigurationen hinzugefügt

[BadenPower]

Hallo zap,

ich habe gerade einmal ganz kurz in Dein Projekt hineingeschnüffelt und gleich einen mehrfach vorkommenden Fehler in den CCU-Skripten entdeckt, welchen Du beseitigen solltest.

dom.RTUpdate() erwartet als Parameter einen Integer und kein Boolean.

Wobei für die Reinitialisierung folgende Werte gelten:

Code Auswählen Erweitern


IRT-Auswahl
0 – alle
1 - ValueChange
2 - TimerChange
3 - ProgramChange
4 - HistoryChange
5 - ComTestChange
6 - SchedulerChange
7 - TimerChangeManual


Des Weiteren arbeitest Du mit dom.GetObject(), zum Beispiel in Deinen Methoden "GetDeviceInfo" oder "GetDevice" in Verbindung mit der Suche nach Objekten per Name.

Das kann gut gehen, muss es aber nicht, wenn zum Beispiel 2 Objekte den gleichen Namen haben.

Daher solltest Du immer zuerst auf die entsprechende List zugreifen und dann per .Get() das Objekt auslesen.

Für Geräte wäre dies dann zum Beispiel so:

Code Auswählen Erweitern


oDev = (dom.GetObject(ID_DEVICES)).Get("hier_den_namen_verwenden");

oder direkt mit dem vorhandenen Devices-Objekt

Code Auswählen Erweitern


oDev = devices.Get("hier_den_namen_verwenden");

oder über das Root-Object:

Code Auswählen Erweitern


oDev = (root.Devices()).Get("hier_den_namen_verwenden");



BadenPower
.

[zap]

Danke für die Hinweise!

Und gleich ein paar Folgefragen:

Zu:

Code Auswählen Erweitern

oDev = (dom.GetObject(ID_DEVICES)).Get("hier_den_namen_verwenden");

Viele meiner Scripte akzeptieren als Input sowohl ein Device als auch einen Channel. Müsste ich das dann so machen:

Code Auswählen Erweitern

oDev = (dom.GetObject(ID_DEVICES)).Get("hier_den_namen_verwenden");
if(!oDev) {
   oChn = (dom.GetObject(ID_CHANNELS)).Get("hier_den_namen_verwenden");
}

Gibt es diese Möglichkeit auch für Programme, also ein

Code Auswählen Erweitern

dom.GetObject(ID_PROGRAMS)

[BadenPower]

Hallo zap,

Viele meiner Scripte akzeptieren als Input sowohl ein Device als auch einen Channel. Müsste ich das dann so machen:

Das wäre eine Möglichkeit.

Allerdings wird es so sein, dass wenn ein Kanal und ein Gerät den gleichen Namen haben, dann immer das Gerät gefunden wird, da es zuerst abgefragt wird.

Dies ist ein Problem, wenn man für 2 verschiedene Objekttypen nur eine Eingabemöglichkeit geschaffen hat. Das Skript kann nicht selbst entscheiden, ob das Gerät, oder der Kanal gewünscht ist. Da solltestDu eventuell das Design überdenken.

Gibt es diese Möglichkeit auch für Programme, also ein

Ja:

ID_PROGRAMS = Programmliste
ID_FUNCTIONS = Gewerkeliste
ID_FAVORITES = Favoritenliste
usw...

Schau Dir einfach einmal die HM-Skript-Übersicht (siehe Bild im Anhang) Deiner HM-Internals an, dort findest Du alle IDs unter dem Reiter "ReGaSkript-Konstanten"


BadenPower
...

[stefan-dd]

Hallo,
Ich habe ein Problem mit dem Status der RPCServer. Er läuft und es wird ein Error ausgegeben, Signale gehen rein und kommen raus. Irgendwie klappt die Aktualisierung des state nicht richtig. Der Fehler ist nicht immer vorhanden. Wo liegt die Ursache?

Code Auswählen Erweitern

defmod d_ccu HMCCU 192.168.1.33 ccudelay=2
attr d_ccu alias CCU2
attr d_ccu ccuflags procrpc
attr d_ccu eventMap /rpcserver on:on/rpcserver off:off/
attr d_ccu group System
attr d_ccu room Home
attr d_ccu rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
attr d_ccu rpcport 2001,2010,9292
attr d_ccu rpcserver on
attr d_ccu stateFormat rpcstate/state
attr d_ccu webCmd on:off

setstate d_ccu error/error
setstate d_ccu 2018-12-03 16:23:14 count_channels 111
setstate d_ccu 2018-12-03 16:23:14 count_devices 13
setstate d_ccu 2018-12-03 16:23:14 count_groups 0
setstate d_ccu 2018-12-03 16:23:14 count_interfaces 3
setstate d_ccu 2018-12-03 16:23:14 count_programs 3
setstate d_ccu 2018-12-03 16:24:09 rpcstate error
setstate d_ccu 2018-12-03 16:24:09 state error

[zap]

Welcher error wird denn ausgegeben? Kannst Du mal die Logeinträge von HMCCURPCPROC und CCURPC posten?
Bzw am besten alles was "CCU" enthält.

[Chaos]

 Ahoi,

ich bin gerade dabei von vccu mit HMLAN auf hmccu (raspmatic mit HMLAN) zu wechseln. Soweit so gut, aber sequence gelingt mir nicht wie vorher.

Konkret möchte ich nen HM-PBI-4-FM mit ne sequence aus kurzen Tastendrücken machen, aber ich bekomm nicht mehr als einen "Doppelklick" hin.

Code Auswählen Erweitern

2018.12.03 23:12:34 5: sequence Taster_Eltern_4_seq matched 2
2018.12.03 23:12:35 5: sequence Taster_Eltern_4_seq timeout on 1 (partial_1)
2018.12.03 23:12:43 5: sequence Taster_Eltern_4_seq matched 2
2018.12.03 23:12:44 5: sequence Taster_Eltern_4_seq timeout on 1 (partial_1)
2018.12.03 23:13:22 5: sequence Taster_Eltern_4_seq matched 2
2018.12.03 23:13:23 5: sequence Taster_Eltern_4_seq timeout on 1 (partial_1)
2018.12.03 23:13:24 5: sequence Taster_Eltern_4_seq matched 2
2018.12.03 23:13:25 5: sequence Taster_Eltern_4_seq timeout on 1 (partial_1)

Kann mir jemand sagen ob das überhaupt mit HMCCU möglich ist?

MfG
Manuel

[zap]

sequence?
hat jetzt eigentlich nichts mit HMCCU zu tun. wie sehem denn die Definitionen aus?

[OiledAmoeba]

Ahoi,

ich bin gerade dabei von vccu mit HMLAN auf hmccu (raspmatic mit HMLAN) zu wechseln. Soweit so gut, aber sequence gelingt mir nicht wie vorher.

Konkret möchte ich nen HM-PBI-4-FM mit ne sequence aus kurzen Tastendrücken machen, aber ich bekomm nicht mehr als einen "Doppelklick" hin.
(...)
Kann mir jemand sagen ob das überhaupt mit HMCCU möglich ist?

MfG
Manuel

Klar, warum nicht. HMCCU ist aus FHEM-Sicht auch "nur" ein I/O-Device.
Ich denke eher, dass das ein Timing-Problem ist. Schalte mal mit

Code Auswählen Erweitern

attr global mseclog 1die Millisekunden im Logfile an und setze den Schalter und/oder sequence auf Verbose 5. Dann führe die Sequenz aus und schau dir das Log an, ob die Events evtl zu spät ankommen.
Wenn ja, kannst Du an zwei Schrauben drehen: Entweder Du findest und eliminierst den Verursacher für das lag oder du erhöhst das Timeout für die Sequenz.

[Chaos]

Ahoi,

danke für die Hinweise.
Mittlerweile kommen überhaupt keine *.pressed rein

Gerade gedrückt und kein aktuelles reading drin

Lt. CCU ist der Taster um 04.12.2018 17:20:00 betätigt worden.

Lt FHEM irgendwann gestern Abend.

ein list vom Device:

Code Auswählen Erweitern

Internals:
   DEF        LEQ0252863
   IODev      d_ccu
   NAME       HM_Taster_Eltern
   NR         555
   STATE      Initialized
   TYPE       HMCCUDEV
   ccuaddr    LEQ0252863
   ccudevstate active
   ccuif      BidCos-RF
   ccuname    Taster_Eltern
   ccutype    HM-PBI-4-FM
   channels   5
   firmware   1.5
   statevals  devstate
   READINGS:
     2018-12-03 23:06:01   3.PRESS_LONG    pressed
     2018-12-03 23:06:01   3.PRESS_LONG_RELEASE yes
     2018-12-03 23:05:22   3.PRESS_SHORT   pressed
     2018-12-03 23:20:40   4.PRESS_LONG    pressed
     2018-12-03 23:20:40   4.PRESS_LONG_RELEASE yes
     2018-12-03 23:13:24   4.PRESS_SHORT   pressed
     2018-12-04 17:24:39   hmstate         Initialized
     2018-12-04 17:19:22   state           Initialized
   hmccu:
     devspec    LEQ0252863
     dp:
       0.AES_KEY:
         OVAL       0
         VAL        0
       0.CONFIG_PENDING:
         OVAL       false
         VAL        false
       0.LOWBAT:
         OVAL       false
         VAL        false
       0.RSSI_DEVICE:
         OVAL       1
         VAL        1
       0.RSSI_PEER:
         OVAL       180
         VAL        180
       0.STICKY_UNREACH:
         OVAL       false
         VAL        false
       0.UNREACH:
         OVAL       false
         VAL        false
       4.INSTALL_TEST:
         OVAL       1
         VAL        1
Attributes:
   IODev      d_ccu
   ccureadingfilter PRESS
   event-on-update-reading .*
   room       Homematic
   substitute PRESS_SHORT,PRESS_LONG,PRESS_CONT!(1|true):pressed,(0|false):released;PRESS_LONG_RELEASE!(0|false):no,(1|true):yes
   verbose    5

FHEM neugestartet. RPCServer off/on. CCU neugestartet.

Noch einer ne Idee?

MfG
Manuel

[OiledAmoeba]

Zeig bitte mal die Attribute des device.
Zb unter dem device sollte Raw-Definition stehen, dann kannst du da die Attribute einfach rauskopieren

[zap]

Werden denn die Readings anderer HMCCUCHN oder HMCCUDEV Devices aktualisiert?

Gibt es Fehlermeldungen von HMCCU oder HMCCURPCPROC im FHEM Logfile?

Hast Du die Tasten der Fernbedienung in der CCU mit einem Dummy Programm verknüpft oder werden sie in einem Dummy Programm abgefragt? (bei vielen Fernbedienungen notwendig, damit PRESSxxx Events geschickt werden).

[Chaos]

Hi,

Ich habe den Taster nochmals gelöscht und in fhem neu erstellen lassen. Jetzt kommen die Events bzw. Readings wieder an.

Im log erscheint nach viermal Short press allerdings nur

Code Auswählen Erweitern

2018.12.04 22:47:30.695 5: sequence Taster_Eltern_4_seq matched 2
2018.12.04 22:47:31.196 5: sequence Taster_Eltern_4_seq timeout on 1 (partial_1)
2018.12.04 22:48:39.442 5: sequence Taster_Eltern_4_seq matched 2
2018.12.04 22:48:39.943 5: sequence Taster_Eltern_4_seq timeout on 1 (partial_1)
2018.12.04 22:49:09.079 5: sequence Taster_Eltern_4_seq matched 2
2018.12.04 22:49:09.581 5: sequence Taster_Eltern_4_seq timeout on 1 (partial_1)


Das raw device:

Code Auswählen Erweitern

defmod HM_Taster_Eltern HMCCUDEV LEQ0252863
attr HM_Taster_Eltern IODev d_ccu
attr HM_Taster_Eltern ccureadingfilter PRESS
attr HM_Taster_Eltern room Homematic
attr HM_Taster_Eltern substitute PRESS_SHORT,PRESS_LONG,PRESS_CONT!(1|true):pressed,(0|false):released;;PRESS_LONG_RELEASE!(0|false):no,(1|true):yes

setstate HM_Taster_Eltern 2018-12-04 22:42:58 3.PRESS_SHORT pressed
setstate HM_Taster_Eltern 2018-12-04 22:44:34 4.PRESS_LONG pressed
setstate HM_Taster_Eltern 2018-12-04 22:44:34 4.PRESS_LONG_RELEASE yes
setstate HM_Taster_Eltern 2018-12-04 22:49:09 4.PRESS_SHORT pressed
setstate HM_Taster_Eltern 2018-12-04 22:49:09 hmstate Initialized
setstate HM_Taster_Eltern 2018-12-04 22:42:01 state Initialized


Das raw für das sequence device fall das hilft:

Code Auswählen Erweitern


defmod Taster_Eltern_4_seq sequence HM_Taster_Eltern.4.PRESS_SHORT:.* 0.5 HM_Taster_Eltern.4.PRESS_SHORT:.* 0.5 HM_Taster_Eltern.4.PRESS_SHORT:.* 0.5 HM_Taster_Eltern.4.PRESS_SHORT:.* 0.5 HM_Taster_Eltern.4.PRESS_SHORT:.*
attr Taster_Eltern_4_seq room Elternzimmer
attr Taster_Eltern_4_seq triggerPartial 1
attr Taster_Eltern_4_seq verbose 5

setstate Taster_Eltern_4_seq active


@zap:
Ich habe den Taster in der ccu mit nem Dummy verknüpft.
Andernfalls bekam ich zuvor gar keine readings

Die anderen HM Geräte sind meistens Rollladen. Die funktionieren, allerdings sind da ja weniger "zeitkritisch".

Fehler im Log bzgl. HMCCU* seh ich keine.

Vielen Dank
Manuel

[zap]

Es gibt ein Update für alle Module im SVN. Steht morgen dann für FHEM update zur Verfügung.

Neue Funktionen:

• Beim Starten eines RPC-Servers für das Interface BidCos-RF wird automatisch auch ein regelmäßiger RPC Ping an die CCU gestartet. Gesteuert werden kann das über das Attribut rpcPingCCU im I/O Device. So ist sicher gestellt, dass in Zusammenhang mit dem ccuflag reconnect die RPC Server nicht unnötig neu registriert werden. Wichtig: Der Wert im Attribut rpcevtimeout muss größer sein als der bei rpcPingCCU. Die Voreinstellungen sind so gewählt, dass das passt. Für einen automatischen Reconnect nach Ausfall der CCU Verbindung muss also lediglich im Attribut ccuflags das Flag reconnect gesetzt werden.
• Es gibt nun auch im I/O Device ein ccuflag trace. Wenn das gesetzt ist, werden auch zu einigen I/O Device Befehlen zusätzliche Informationen ausgegeben
• Wenn ein Gerät einen Datenpunkt LEVEL hat, stehen nun die Set-Befehle "set up <Wert>" und "set down <Wert>" für die Änderung des Levels relativ zum aktuellen Wert zur Verfügung

Folgende Fehler wurden behoben:

• Fehler in Schreibweise des Befehls set rpcregister
• Diverse Fehler beim Befehl set execute
• Fehler beim Auftreten von Event Timeouts

Folgende Fehler wurden noch nicht behoben:

• Falsches Präfix bei Readings in Zusammenhang mit Aggregationsfunktion im I/O Device
• RPC Server starten nicht, wenn CCU Interface BidCos-RF nicht vorhanden ist