Problem mit HMCCU und virtuellen CUXD Device

[Garbsen]

Hallo

Ich habe ein Problem mit meinen Somfy-Devices.

Ich habe vor ein paar Tagen von CCU2 auf Raspimatic umgerüstet. Zunächst liefen meine Somfy-Rolläden in FHEM, die ich mit HMCCU in die ccu eingebunden hatte problemlos. Heute ging plötzlich nichts mehr.
Kein einziges cCU device tauchte mehr in FHEM auf.
Ich habe dann ein Backup eingespielt und konnte die Devices mit Crete wieder einbinden.
Neben den Somfy-Devices, für die ich in Homematic virtuelle CUxD Devices angelegt hatte habe ich mehrere Homematic Devices in FHEM angelegt.
Die Homematic Devices zeigen in FHEM auch alle Veränderungen und ich kann sie von FHEM aus steuern.
Anders die Somfy/virtuellen Devices. Hier kommen weder die Änderungen die ich in FHEM vornehme in der ccu an, noch umgekehrt. Bzw. Änderungen in der ccu sind in FHEM nur zu sehen, wenn ich get Update auslöse. Änderungen in FHEM z.B. Rollo auf Pos 100 statt 0 werden schon in FHEM ignoriert, dh. Nach einem Seiten refresh steht dort wieder 0.

Das Peer mit dem ,,echten" Somfy-Device in FHEM geht auch nicht, weder in die eine noch andere Richtung.

Hat jemand eine Idee, wo der Fehler liegen kann?

Hier ein List sowohl vom ccu device als auch vom FHEM device:

<sup>List HM_Rollo_DLO

DEF        CUX4000004:1
   IODev      d_ccu
   NAME       HM_Rollo_DLO
   NR         693
   STATE      closed
   TYPE       HMCCUCHN
   ccuaddr    CUX4000004:1
   ccudevstate active
   ccuif      CUxD
   ccuname    Rollo Dach Links oben Somfy:1
   ccutype    CUX-HM-LC-Bl1PBU-FM
   channels   1
   statevals  devstate
   READINGS:
     2018-06-17 22:20:37   1.LEVEL         closed
     2018-06-17 22:20:37   1.STATE         true
     2018-06-17 22:20:37   control         0
     2018-06-17 22:20:37   hmstate         closed
     2018-06-17 22:20:37   state           closed
   hmccu:
     dp:
       1.CONTROL:
         OVAL       0
         VAL        0
       1.INSTALL_TEST:
         OVAL       false
         VAL        false
       1.LEVEL:
         OSVAL      open
         OVAL       1.000000
         SVAL       closed
         VAL        0.000000
       1.MOTION:
         OVAL       true
         VAL        true
       1.RCVL:
         OVAL       0
         VAL        0
       1.RCVS:
         OVAL       0
         VAL        0
       1.STATE:
         OSVAL      true
         OVAL       true
         SVAL       true
         VAL        true
Attributes:
   IODev      d_ccu
   ccureadingfilter (LEVEL|WORKING|STATE|PRESS|STOP)
   ccuscaleval LEVEL:0:1:0:100
   cmdIcon    up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down
   controldatapoint LEVEL
   event-on-update-reading .*
   eventMap   /datapoint STOP true:stop/datapoint LEVEL 0:down/datapoint LEVEL 100:up/
   group      Allgemein
   peer       LEVEL:$LEVEL <= 100:fhem:set RolloD1_3 pos $value;;
   room       CCU2,Dach
   statedatapoint LEVEL
   substexcl  control
   substitute LEVEL!#0-0:closed,#100-100:open;WORKING,STOP!(0|false):no,(1|true):yes
   webCmd     up:down:stop:control
   widgetOverride control:slider,0,10,100


List Rollo_D1_3

Internals:
   ADDRESS    000018
   DEF        000018 AE 4EAE
   IODev      CUL_433
   NAME       RolloD1_3
   NR         131
   STATE      oben
   TYPE       SOMFY
   move       stop
   CODE:
     1          000018
   READINGS:
     2016-12-26 13:21:43   Automatik       1
     2018-06-17 20:25:49   enc_key         AE
     2018-06-17 20:26:09   exact           100
     2018-06-17 20:26:09   position        100
     2018-06-17 20:25:49   rolling_code    4EAE
     2018-06-17 20:26:09   state           open
Attributes:
   IODev      CUL_433
   alias      Rollo Giebel oben links
   devStateIcon .*oben:fts_shutter_12 .*unten:fts_shutter_90
   drive-down-time-to-100 17
   drive-down-time-to-close 20
   drive-up-time-to-100 3
   drive-up-time-to-open 20
   eventMap   /open:oben/closed:unten/on:runter/off:hoch/Pos 30:Sonnenschutz
   genericDeviceType blind
   group      Rollaeden Giebel
   homebridgeMapping CurrentPosition=position,minValue=0,maxValue=100 TargetPosition=position,minStep=10,cmd=
   icon       fts_shutter_updown
   model      somfyblinds
   positionInverse 1
   room       Dach,Homekit,Lena Wohnen,Somfy,Sueden
   webCmd     runter:hoch:stop:Sonnenschutz
   widgetOverride eventMap:textField-long</sup>

[Garbsen]

Kleine Korrektur, wenn ich das HMCCU device in FHEM ändere wird die Änderung doch zur CCU weitergeleitet, erscheint in FHEM aber auch erst, wenn ich get Update auslöse.
Es scheint somit wirklich ein Problem mit dem Peer zu sein, aber wo genau liegt es?

[Garbsen]

Keine einer Idee?

Habe jetzt verschiedene Syntax für das Peer attr ausprobiert, keine Chance das FHEM Device über das HMCCU device zu steuern.
Das Problem ist, dass ich meine alten Einstellungen nicht mehr sehen kann. Egal welches Update ich einspiele, die Devices bleiben immer verschwunden. Ich vermute durch den Wechsel von Ccu2 auf raspimatic.
Ich muss also alles neu anlegen und die ganzen attr. Neu definieren.
Irgendwo habe ich wohl einen Knoten drin und finde ihn nicht.
Folgende Probleme:

Änderungen am HMCCU device sind in FHEM erst zu sehen, wenn ich im device ein get Update mache
Peer zum FHEM device funzt nicht

Wer kann helfen?
Danke
(lists stehen im ersten Post)

[zap]

Hast du im IO Device rpcInterfaces um CUxD ergänzt und FHEM neu gestartet?
Welche RPC Server benutzt Du (ccuflags)?

[Garbsen]

Moin zap

Zunächst Danke, dass Du Dich kümmerst.

Habe den procrpc , und ja CUxD ist drin und neu gestartet bereits mehrfach.

[Garbsen]

Ok, ich probiere ja weiter rum

Folgendes funktioniert:

1.LEVEL:'$1.LEVEL' eq 'closed':fhem:set RolloD1_3 pos 0;;

Es scheint also ein Syntax Problem zu sein, was das peer-Problem betrifft.
Wünschenswert wäre natürlich, wenn ich es irgendwie mit der Übergabe des konkreten Wertes ginge.

Unabhängig davon bleibt das Problem, dass sich der Wert des HMCCU Devices  in FHEM nicht von selber aktualisiert, sondern nur nach get Update.
Ich habe sowohl bei Event-on-change-reading, wie auch bei Event-on-Update-reading es mit .* und mit 1 ausprobiert, beides bringt keine Änderung

[Garbsen]

Ok, das mit dem Peer attr bekomme ich stückweise geregelt.
Ich hatte u.a. Das substitute attr mit: LEVEL!#0-0:closed,#100-100:open
Bestückt, das vertrug sich nicht mit dem Peer: 1.LEVEL:$1.LEVEL <= 100:fhem:set RolloD1_2 pos $value;;
auch nichts wenn in Level ein Wert zwischen 0 und 100 stand.
Nachdem ich das Substitute gelöscht habe funktioniert der Peer Befehl mit Value grundsätzlich.

Ich werde auch alle anderen attr. einmal unterschiedlich ausprobieren und dann die (für mich) optimale Einstellung für Somfy-RTS Rolläden einmal hier posten (dann finde ich es vielleicht auch mal wieder)

Was ich weiterhin nicht hinbekomme, ist das automatische aktualisieren. Ich muss immer erst ein manuelles get Update im Hmccu device machen, damit der Peer Befehl greift.

Unabhängig davon, ob ich das Hmccu device in FHEM oder in der WebUI ändere. Seltsamerweise werden Änderungen am device in FHEM sofort nach ccu übertragen aber in FHEM selber nicht aktualisiert.
D.h. Wenn ich die Rolladenstellung des Hmccu Devices in FHEM von 100 auf 40 ändere bleibt es in FHEM bei 100, (nach Seitenrefresh) in der WebUI steht korrekt 40. wenn ich dann in FHEM im device get Update Anstoße ändert sich der Wert auch in FHEM sofort und wird per Peer an das Somfy-device übergeben.

Was muss in Event-on-Update-reading bzw. Event-on-change-reading stehen? Was genau bewirken diese Einträge, könnte dazu nichts finden
Gruß
K-H

[Garbsen]

Hast du im IO Device rpcInterfaces um CUxD ergänzt und FHEM neu gestartet?
Welche RPC Server benutzt Du (ccuflags)?

Heureka!

Das Problem mit der fehlenden Aktualisierung bei Änderung könnte ich lösen.
Ich habe das Attribut rcpinterfaces gelöscht, Neustart FHEM, Attribut wieder gesetzt, Neustart FHEM und es geht. Kann es sein, dass hier durch das einspielen des Backups irgendein Fehler passiert war?

Bleibt aber meine Frage, was die Event-on-change / Update Attribute innerhalb von Hmccu auslösen?