Sollte Qubino ZMNHCD1 Flush Shutter in FHEM funktionieren?

[mdescher]

Auch nach Suche hier im Forum ist mir nicht klar was an dem Teil funktionieren sollte und was nicht. Ich habe ihn eingebunden und kann nach Kalibrierung mit on/off/stop/dim auch Positionen anfahren. Aber erstens bekomme ich keine automatischen Meldungen über die angefahrene Zielposition, sondern nur über manuelles "get swmStatus" eine Änderung am "reportedState". Beim Fibaro Shutter 2 bekomme ich automatische Updates des "position" Readings. Weiterhin liefert "get model" nur "UNPARSED:MANUFACTURER_SPECIFIC 0e7205015900030052000000000000", d.h. ich kann Konfigurationen nur über die generischen "get/setConfigXXX" verwalten.

Ist das beides derzeit so oder sollte da mehr funktionieren?

Danke + Gruß
Michael

[krikan]

Die Antwort auf "get model" hat eine ungewöhnliche Länge und scheitert daher. Kurzfristige Notlösung:

Code Auswählen Erweitern

setreading <device> modelConfig qubino/ZMNHCDx.xml

Automatische Meldungen sollten bei korrekt gesetzten Assoziationen kommen. Jedoch nicht als "position" wie bei Fibaro, sondern als "dim".

@Rudi: Bei parse für "get model"-Antwort die Längenprüfung eventuell komplett weglassen?

Gruß, Christian

[rudolfkoenig]

Habe die Laengenpruefung entfernt.

[mdescher]

Hi Christian,

danke für die Notlösung.

Mit der Positionsmeldung habe ich aber bisher trotzdem kein Glück. Ich bekomme nichts. Ungewöhnlich ist, dass bei "assocGroup_1" (wo sonst immer der Controller steht) beim Qubino nichts steht (außer "Max 1 Nodes").

Ein "set <device> associationAdd 1 1" nützt nichts, oder geht das grundsätzlich nicht? (hatte bisher noch nie die Notwendigkeit an Group 1 etwas zu ändern)

Gruß
Michael

[mdescher]

Ich hatte es auch mit assocGroup 7 versucht, da kam aber in FHEM immer nur sowas wie "UNPARSED: SWITCH_MULTILEVEL 04260160ff". Das vorletzte Byte entspricht dem erwarteten Dim-Wert. Evtl. liegt hier auch nur wieder eine kleine Inkompatibilität vor?

Gruß
Michael

[harald654]

Hallo Michael,

ich nutze die Qubino ZMNHCD1 seit über einem Jahr im ganzen Haus mit FHEM.
Dein beschrieben Probleme hatte ich bis jetzt noch nicht. Bei mir funktioniert soweit alles, auch wird "reportedState" automatisch aktualisiert (on/off/dim xx).
get model leifert bei mir:

Code Auswählen Erweitern

modelId:0159-0003-0052
modelConfig:qubino/ZMNHCDx.xml
model:Qubino (Goap) ZMNHCDx Flush Shutter
bzw. im Eventmonitor:

Code Auswählen Erweitern

2019-09-17 00:57:36 ZWave ZWave_SWITCH_MULTILEVEL_22 modelId: 0159-0003-0052
2019-09-17 00:57:36 ZWave ZWave_SWITCH_MULTILEVEL_22 modelConfig: qubino/ZMNHCDx.xml
2019-09-17 00:57:36 ZWave ZWave_SWITCH_MULTILEVEL_22 model: Qubino (Goap) ZMNHCDx Flush Shutter
Somit eher keine inkompatibilität von FHEM mit den Qubinos.

@krikan und @rudolfkoenig sollten wir daher die Längenprüfung wieder aktivieren?

[mdescher]

Hallo Harald,

wie du schreibst hast du deine Qubinos ja schon länger, vielleicht wurde da zwischenzeitlich etwas an der Firmware gedreht. Bei mir liefert "get version" folgendes:

Code Auswählen Erweitern

Lib 3 Prot 4.38 App 7.0 HW 2 FWCounter 1 FW 7.0

Gruß
Michael

[krikan]

Der ZMBHCD1 funktioniert grds. mit FHEM. Qubino(Goab)  hat das vergangenen Monat selbst getestet (https://forum.fhem.de/index.php/topic,103243.0.html). Mein eigener Test ist ca. 1 Jahr her.

Welche Firmware bei Qubino und mir genutzt wurde ist mir unbekannt. Der Ausbau der Längenbegrenzung für model-parse sollte aber (bis zum Beweis des Gegenteils  ) unkritisch sein.

Die UNPARSED Meldung bei Assogroup 7 ist ok. Der Befehl ist ein Ansteuerungsbefehl für andere Aktoren und ist für FHEM normalerweise uninteressant. Einbaunotwendigkeit sehe ich nicht.

Zum eigentlichen Problem:
Entscheidend sollte aussschließlich die Assogroup 1 ein. Dort hinein muss der Controller; alles andere bitte löschen. Unklar ist aber, ob als "nomale" Assoziation oder als MULTI_CHANNEL_ASSOZIATION. Das liegt unter anderem an der Konfiguration des Aktors. Ohne angeschlossenen Temperatursensor und ohne Aktivierung von VEntian-Blind Mode müsste eine "normale" Assoziation genügen; wenn die nicht sogar zwingend ist, dabei bin ich mir unsicher.

Seit Kurzem setzt FHEM bei Geräten mit CC MULTI_CHANNEL_ASSOCIATION automatisch eine Multi-Channel-Assoziation statt einer normalen Assoziation. Das könnte hier das Problem sein; ich vermute, das diese MULTI_CHANNEL_ASSOCIATION mit Assogroup 1 gesetzt ist.

Bitte rufe folgendes ab:
"get <device> mcaAll"
Was sind die Rückgabewerte? Am bestens bitte die Ausgabe von "list" des kompletten Devices, damit ich konkreter etwas erkenne.

Hast Du per Eventmonitor kontrolliert, ob die Events nicht auf dem Endpoints statt dem Root-Device gemeldet werden? Hast Du überhaupt Endpoints?

Gruß, Christian

[rudolfkoenig]

da kam aber in FHEM immer nur sowas wie "UNPARSED: SWITCH_MULTILEVEL 04260160ff"

Das Geraet meldet "set XX dim 96". Ueblicherweise sendet FHEM sowas an das Geraet, und nicht andersherum.
Ich habe ZWave.pm erweitert, damit diese Nachricht als "state:setDim 96" verarbeitet wird.

Seit Kurzem setzt FHEM bei Geräten mit CC MULTI_CHANNEL_ASSOCIATION automatisch eine Multi-Channel-Assoziation statt einer normalen Assoziation.

Die Empfehlung dazu kam von goap, auch wenn sie danach durch weitere Beispiele verwaessert wurde.
Mich wuerde interessieren, ob es hilft Beides zu setzen.

[mdescher]

In der mca_1 ist der Controller drin. In der assocGroup_1 nicht, zumindest wird nichts angezeigt. Da hatte ich auch die ganze Zeit das Problem vermutet, nur wie schon gesagt hilft auch ein "set <device> associationAdd 1 1" nicht. Es kommt kein Fehler, nur bleibt die assocGroup_1 leer. Endpoints habe ich in der Tat auch keine.

Hier noch der list-Output:

Code Auswählen Erweitern


Internals:
   DEF        e4b4cb01 79
   EG.wz.ZWDongle.Aeotec_MSGCNT 221
   EG.wz.ZWDongle.Aeotec_RAWMSG 0004004f03260363
   EG.wz.ZWDongle.Aeotec_TIME 2019-09-17 08:17:13
   FUUID      5d7f9847-f33f-b333-dd91-0e7d448f176f2cba
   IODev      EG.wz.ZWDongle.Aeotec
   LASTInputDev EG.wz.ZWDongle.Aeotec
   MSGCNT     221
   NAME       EG.ku.RS
   NR         302
   STATE      99
   TYPE       ZWave
   ZWaveSubDevice no
   cmdsPending 0
   homeId     e4b4cb01
   isWakeUp   
   lastMsgSent 1568701031.77481
   nodeIdHex  4f
   OLDREADINGS:
   READINGS:
     2019-09-16 19:37:02   alarmTypeSupported PowerManagement
     2019-09-16 19:36:18   assocGroupCmdList_1 DEVICE_RESET_LOCALLY:01 SWITCH_MULTILEVEL:03 SENSOR_MULTILEVEL:05 METER:02
     2019-09-16 19:36:36   assocGroupName_1 lifeline
     2019-09-16 19:50:32   assocGroup_1    Max 1 Nodes
     2019-09-16 19:50:33   assocGroup_2    Max 16 Nodes
     2019-09-16 19:50:33   assocGroup_3    Max 16 Nodes
     2019-09-16 19:50:33   assocGroup_4    Max 16 Nodes
     2019-09-16 19:50:34   assocGroup_5    Max 16 Nodes
     2019-09-16 19:50:34   assocGroup_6    Max 16 Nodes
     2019-09-16 19:50:34   assocGroup_7    Max 16 Nodes
     2019-09-16 19:50:35   assocGroup_8    Max 16 Nodes
     2019-09-16 19:50:35   assocGroup_9    Max 16 Nodes
     2019-09-16 19:50:32   assocGroups     9
     2019-09-16 19:27:20   configActivateDeactivateFunctionsALLON10 ALLONActiveALLOFFActive
     2019-09-16 19:27:20   configDigitalTemperatureSensor120 5
     2019-09-16 19:27:20   configForcedShutterCalibration Default
     2019-09-16 19:27:20   configMotorMovingUpDownTime 0
     2019-09-16 19:27:20   configMotorOperationDetection 30
     2019-09-16 19:27:21   configOperatingModes ShutterMode
     2019-09-16 19:27:21   configPowerConsumptionMaxDelayTime 30
     2019-09-16 19:27:21   configPowerReportingInWattsByTime42 0
     2019-09-16 19:27:22   configPowerReportingInWattsOnPower40 10
     2019-09-16 19:27:22   configSlatsPosition ZWaveControlPushButtonOperation1
     2019-09-16 19:27:22   configSlatsTiltingFullTurnTime 150
     2019-09-16 19:27:22   configTemperatureSensorOffsetSettings 32536
     2019-09-16 19:27:22   configTimeDelayForNextMotorMovement 5
     2019-09-16 17:34:18   energy          0 kWh
     2019-09-16 19:50:38   mcaGroups       9
     2019-09-16 19:50:39   mca_1           Max 1 Nodes EG.wz.ZWDongle.Aeotec:0
     2019-09-16 19:50:39   mca_2           Max 16
     2019-09-16 19:50:39   mca_3           Max 16
     2019-09-16 19:50:40   mca_4           Max 16
     2019-09-16 19:50:40   mca_5           Max 16
     2019-09-16 19:50:40   mca_6           Max 16
     2019-09-16 19:50:41   mca_7           Max 16
     2019-09-16 19:50:41   mca_8           Max 16
     2019-09-16 19:50:41   mca_9           Max 16
     2019-09-16 17:34:03   meterSupported  type:energy, import only (consumed), resetable:yes, scales: 0:kWh 2:W
     2019-09-16 19:27:02   modelConfig     qubino/ZMNHCDx.xml
     2019-09-16 19:52:16   power           0 W
     2019-09-17 08:17:13   reportedState   dim 99
     2019-09-17 08:17:13   state           dim 99
     2019-09-16 19:38:11   swa             on off
     2019-09-17 08:17:13   timeToAck       1.634
     2019-09-17 08:17:13   transmit        OK
     2019-09-17 07:42:21   version         Lib 3 Prot 4.38 App 7.0 HW 2 FWCounter 1 FW 7.0
     2019-09-16 16:12:54   zwavePlusInfo   version:01 role:AlwaysOnSlave node:Z-Wave+Node installerIcon:1a00 userIcon:1a00
Attributes:
   IODev      EG.wz.ZWDongle.Aeotec
   classes    ZWAVEPLUS_INFO DEVICE_RESET_LOCALLY POWERLEVEL SECURITY VERSION MANUFACTURER_SPECIFIC SWITCH_ALL SWITCH_BINARY SWITCH_MULTILEVEL METER ALARM ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO CONFIGURATION MARK SWITCH_MULTILEVEL
   vclasses   ALARM:5 ASSOCIATION:2 ASSOCIATION_GRP_INFO:2 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 MANUFACTURER_SPECIFIC:2 METER:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SECURITY:0 SWITCH_ALL:1 SWITCH_BINARY:1 SWITCH_MULTILEVEL:3 VERSION:2 ZWAVEPLUS_INFO:2


[mdescher]

Ich habe ein paar Zeilen aus dem list-Output entfernt um euch nicht weiter zu verwirren. Derzeit habe ich den Controller auf assocGroup_6. Dort bekomme ich dann am Device ein Update auf das basicSet Reading sobald die Endposition erreicht ist. Darauf habe ich wiederum ein Notify um manuell via get swmStatus den reportedState zu bekommen. Das ganze als Workaround. Daher ist der reportedState zeitlich auch aktuell im list-Output oben.

[rudolfkoenig]

Ich wuerde als naechstes "set EG.ku.RS mcaDel 1 0 X 0" probieren (X ist nodeId des Controllers, vmtl. 1), und "set EG.ku.RS associationAdd 1 X" dahinter.

[mdescher]

Genau das habe ich gerade gemacht und tatsächlich steht der Controller jetzt in assocGroup_1 und mca_1 drin. Vorher stand er in mca_1 mit ":0" am Ende, jetzt ohne. Und jetzt bekomme ich auch das Reading reportedState mit "dim xx" upgedated.

[krikan]

Mich wuerde interessieren, ob es hilft Beides zu setzen.

Das darf nicht funktionieren, da in die Assogroup nur ein Ziel hinein kann. Passt auch zum Ergebnis von mdescher.
In Kombination mit der Erkenntnis von mdescher "MULTI_CHANNEL geht nicht, aber normale ASSOCIATION schon", sind wir wohl wieder fast bei der alten Automatik/Code. Mir gefällt das zwar nicht, aber wenn es keine sinnvolle herstelller-/geräteübergreifende Lösung gibt (erkenne ich nicht), ist das vermutlich aus Supportsicht die einfachste Lösung.

Wenn bei der einfachen Assoziation etwas an Rückmeldungen fehlt (und ggfs. mehrere Endpoints beim Device existieren), muss man auf MULTI_CHANNEL_ASSOCIATION (mcaAdd) manuell umsteigen.

Alternativ kann ich mich in die Vorgaben der ozw-XMLs bei dem Thema Assoziationen einarbeiten und wir übernehmen das bei FHEM. Gefällt mir aber auch nicht. Das bleibt mMn "Gefrickel".

Gruß, Christian

[rudolfkoenig]

@krikan:
Nachdem ich die Emails von goap nochmal durchgelesen habe, habe ich festgestellt, dass was anderes implementiert ist.
Goap schreibt:

- if the device lists CC_MULTI_CHANNEL in the NIF, then configure SCA with ASSOCIATION_SET(groupId=1, nodeId=1)
- if the device doesn't list the mentioned CC_MULTI_CHANNEL, configure MCA with MC_ASSOCIATION_SET(groupId=1, multichannelnodeId=1, endpointid=0)

Allerdings wird im naechsten Absatz diese Aussage eingeschraenkt, und eine Begruendung faellt mir auch nicht ein.
Sollen wir es mit dieser Logik versuchen, oder lieber direkt zur alten Version zurueckkehren.?

@mdescher: das ist nur eine Ueberlegung fuer die Zukunft, in deinem Fall sollte das Problem geloest sein.