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
Die Antwort auf "get model" hat eine ungewöhnliche Länge und scheitert daher. Kurzfristige Notlösung:
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
Habe die Laengenpruefung entfernt.
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
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
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:
modelId:0159-0003-0052
modelConfig:qubino/ZMNHCDx.xml
model:Qubino (Goap) ZMNHCDx Flush Shutter
bzw. im Eventmonitor:
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?
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:
Lib 3 Prot 4.38 App 7.0 HW 2 FWCounter 1 FW 7.0
Gruß
Michael
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
Zitatda 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.
ZitatSeit 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.
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:
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
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.
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.
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.
Zitat von: rudolfkoenig am 17 September 2019, 09:00:50
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
@krikan:
Nachdem ich die Emails von goap nochmal durchgelesen habe, habe ich festgestellt, dass was anderes implementiert ist.
Goap schreibt:
Zitat- 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.
Zitat von: rudolfkoenig am 17 September 2019, 12:07:59
Sollen wir es mit dieser Logik versuchen
Die "Qubino-Logik" funktioniert nach meiner Erinnerung nicht mit (allen?) Geräten anderer Hersteller. Hatte ich "damals" bei meinem Gerätepark nachgeschaut; falls Details interessant sind, könnte ich die erst in einer Woche liefern.
Frage mich auch, ob das nur für die getesteten Qubino-ZWavePlus-Geräte oder für alle -auch die alten ohnePlus- so ist.
Zitat.oder lieber direkt zur alten Version zurueckkehren.?
Noch keine endgültige Meinung. Tendenz eher ja, da ich Sorge vor zu vielen Spezialfällen habe.
Man könnte auch nur eine Qubino-Sonderlösung einbauen.
Gruß, Christian
Ist die Aussage von Goap aus #14 nicht einfach nur verdreht? Oder bin ich gerade total verwirrt!?
Der Aktor von mdescher hat keine CC_MULTI_CHANNEL im NIF gemeldet und FHEM hat gemäß dem Zitat aus #14 eine MCA gesetzt. Das funktionierte nicht; vielmehr musste eine SCA gesetzt werden.
Das gibt nur Sinn, wenn ich die Aussage ändere in:
Zitat- if the device lists CC_MULTI_CHANNEL in the NIF, configure MCA with MC_ASSOCIATION_SET(groupId=1, multichannelnodeId=1, endpointid=0)
- if the device doesn't list the mentioned CC_MULTI_CHANNEL, then configure SCA with ASSOCIATION_SET(groupId=1, nodeId=1)
Insgesamt finde ich das auch verständlicher. Zudem passt es der Erinnerung nach bei den anderen Geräten. Ausnahmen wird es aber sicherlich wieder geben; insbesondere bei den ohnePlus-Geräten.
Wie goap es bestaetigt hat, ist die Logik verdreht, so wie krikan es vermutet.
Ab sofort wird fuer mcaAdd bei der Inklusion zusaetzlich auf MULTI_CHANNEL geprueft, sonst wird das "alte" Verfahren mit associationAdd verwendet.
Hat jetzt nicht direkt mit dem bisher diskutierten zu tun, aber doch mit dem Qubino Shutter. Bisher hatte ich Fibaro Shutter 2 verbaut. Jetzt habe ich den Qubino genommen nachdem der Fibaro Shutter 3 gar nicht richtig funktioniert hat und ich auch viel über Probleme gelesen hatte.
Nun habe ich das nächste Qubino-Problem mit einem Z-Wave.Me ZME_WALLC-S Secure Wall Controller. Der Qubino reagiert bei direkter Assoziation wie gewünscht auf basicSet 0 (runterfahren), die dimup/down Kommandos (fahren während der Knopf gedrückt wird und stop bei loslassen), aber er zeigt keine Reaktion auf basicSet 255 (hochfahren). Der Button ist okay (gedrückt halten/dimup geht und wenn ich den Controller zusätzlich zum Qubinio assoziiere, dann sehe ich auch das "basicSet 255" bei Knopfdrück.
Kennt jemand das Problem, dass der Qubino anscheinend nicht auf "basicSet 255" reagiert?
Gruß
Michael
Ich kann es wohl selber beantworten. Ich habe jetzt mal probeweise einen FIBARO System FGPB101 Button mit dem Qubino assoziiert. Wenn der Button basicSet 255 sendet passiert nicht, wenn er basicSet 99 sendet, dann geht der Rolladen hoch. Im Gegensatz zu den Fibaro Shuttern kann der Qubino Shutter also wohl tatsächlich nichts mit basicSet 255 anfangen. Leider kann man dem Z-Wave.Me ZME_WALLC-S Secure Wall Controller soweit ich sehe aber nicht den basicSet-Wert konfigurieren und damit arbeitet er wohl nicht mit dem Qubino zusammen. Ist doch alles Käse wieder. ::)
Zitat von: mdescher am 21 September 2019, 14:57:33
"basicSet 255"
Durch manuelle Ergänzung von BASIC im Attribut classes stellt FHEM auch die Befehle der CC BASIC zur Verfügung. Damit könnte man dann direkt von FHEM testen.
Der FF Wert bei CC Basic bedeutet "setze auf letzten Wert". Qubino dokumentiert das in https://qubino.com/manuals/Flush_Shutter.pdf auf Seite 55 entsprechend.
Leider ist "letzter Wert" nicht sonderlich selbsterklärend und ich würde bei einem Rolladenaktor erwarten, dass das auf oder zu bzw. dem Gegenteil von 0 entspricht. Was jetzt bei Qubino "letzer Wert" (FF) sein soll verstehe ich so nicht. Irgendeine Reaktion sollte der Befehl doch wohl auslösen...
Eventuell schreibst Du mal Qubino an, was denn "basicSet 255"/"letzter Wert" ist und beschreibst das Problem mit der direkten Assoziierung.
Gruß, Christian
ich hänge mich hier mal mit ran und bitte um eure um Hilfe.
ich habe 3x Qubino (Goap) ZMNHSDx Din Dimmer an zwei unterschiedlichen Fhem Instanzen (jeweils Raspi)
beide senden null komme null Return States über die lifeline wenn ich z.b. am Wandschalter das Licht anschalte.
keinerlei Referenz im Log. es kommt nix an.
ich kann die Schalter im FHEM problemlos schalten. der State ändert sich dann auch im Fhem.
ich habe die Schritte hier im Threat probiert und versucht die MCA group 1 zu löschen und die Lifeline neu mit dem Dongle zu verbinden. keine Änderung.
habt ihr eine Idee was ich tun kann.
ich kann mich erinnern, dass das in der Vergangenheit funktioniert hat. kann aber bewusst nicht sagen, seit wann das nicht mehr geht.
(Deswegen habe ich ein zweites, jungfräuliches Fhem System aufgesetzt, nur mit dem ZWave Dongle und 2 der DIN Schalter.
danke euch Vorab.
Grüße
Chris
Kannst Du bitte die Ausgabe von "list <device>" eines nicht funktionierenden Dimmers wie hier https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F beschrieben posten.
Hast Du zusätzlich einen Temperatursensor und/oder zusätzliche Inputs (Switch binary mode) installiert?
Gruß, Christian
Hallo Christian und danke für deine schnelle Antwort.
es funktioniert jetzt. habe gestern noch sowohl dimmer als auch dongle factory resettet, neu eingebunden, mcaDel 1 0 1 0 und associationAdd 1 1 brachten dann den Erfolg.
danke und Grüße
Chris
Kannst Du bitte trotzdem ein "list" posten und meine Frage zu den zusätzlichen Anschlüssen beantworten.
Das ist für FHEM bzw. die automatisch gesetzten Assoziationen während der Inklusion wichtig.
Deine gezeigten Befehle (Löchen mca und Neuanlage sca) widersprechen mMn der hier mit Qubino herausgearbeiteten Lösung und wir müssen ggfs. Nachbessern, damit nicht der Nächste darüber stolpert.
Gruß, Christian
Hallo Christian, sehr gerne.
Kein Sensor angeschlossen.
ein Physikalischer Schalter am Dimmer- Wandtaster.
hier ein Beispiel List.
Internals:
CFGFN
DEF c86dd55a 37
FUUID 5d8daa12-f33f-7bb3-88f4-41f773cab9c88f86
IODev ZWave1
LASTInputDev ZWave1
MSGCNT 55
NAME ZWave_KuecheLicht
NR 322855
STATE off
TYPE ZWave
ZWave1_MSGCNT 55
ZWave1_RAWMSG 000400250a32022134000000000000
ZWave1_TIME 2019-09-27 09:07:43
ZWaveSubDevice no
cmdsPending 0
homeId c86dd55a
isWakeUp
lastMsgSent 1569568061.05464
nodeIdHex 25
READINGS:
2019-09-27 08:26:57 configActivateDeactivateFunctionsALLON10 ALLONActiveALLOFFActive
2019-09-27 08:26:57 configAutomaticTurningOffOutputAfter11 0
2019-09-27 08:26:57 configAutomaticTurningOnOutputAfterSet12 0
2019-09-27 08:26:58 configDigitalTemperatureSensor120 5
2019-09-27 08:26:58 configDimmingTimeWhenKeyPressed 3
2019-09-27 08:26:58 configEnableDisableDoubleClickFunction Disabled
2019-09-27 08:26:58 configIgnoreStartLevel respectStartLevel
2019-09-27 08:26:58 configInput1SwitchType MonoStablePushButton
2019-09-27 08:26:58 configMaximumDimmingValue 99
2019-09-27 08:26:58 configMinimumDimmingValue 1
2019-09-27 08:26:58 configPowerReportingInWattsByTime42 0
2019-09-27 08:26:58 configPowerReportingInWattsOnPower40 5
2019-09-27 08:26:58 configSavingTheStateOfTheRelayAfterA30 FlushDimmerModuleSavesItsState0
2019-09-27 08:26:58 configTemperatureSensorOffsetSettings 32536
2019-09-27 08:26:58 configWorkingMode Dimmer
2019-09-27 08:32:01 model Qubino (Goap) ZMNHSDx Din Dimmer
2019-09-27 08:32:01 modelConfig qubino/ZMNHSDx.xml
2019-09-27 08:32:01 modelId 0159-0001-0052
2019-09-27 09:07:43 power 0 W
2019-09-27 08:36:25 reportedState off
2019-09-27 09:07:41 state off
2019-09-27 09:07:41 timeToAck 0.027
2019-09-27 09:07:41 transmit OK
2019-09-27 08:32:16 version Lib 3 Prot 4.05 App 1.1 HW 1 FWCounter 0
Attributes:
IODev ZWave1
alias ZWave_KuecheLicht
classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY POWERLEVEL BASIC SWITCH_ALL SWITCH_BINARY SWITCH_MULTILEVEL METER ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO CONFIGURATION MARK BASIC SWITCH_MULTILEVEL
room ZWave
vclasses ASSOCIATION:2 ASSOCIATION_GRP_INFO:2 BASIC:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 MANUFACTURER_SPECIFIC:2 METER:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SWITCH_ALL:1 SWITCH_BINARY:1 SWITCH_MULTILEVEL:3 ZWAVEPLUS_INFO:2
Grüße
Chris
Vielen Dank.
Da keine Class MULTI_CHANNEL im Attribut classes vorhanden ist, muss associationAdd (SCA) genutzt werden. Ab 10_ZWave.pm vom 20.09.2019 sollte FHEM das automatisch bei der Inklusion richtig machen. Also entweder hast Du eine Version von vorher, die das noch falsch macht, genutzt oder der Code ist noch nicht optimal (unwahrscheinlich). Kannst Du etwas zur genutzten Version schreiben?
Gruß, Christian
auf dem Live System von dem das 'List' oben stammt ist die 10_ZWave.pm vom 17.09.
auf dem Test System ist sie am 22.09. aktualisiert wurden
beide Systeme haben sich gleich verhalten.
wenn es hilft kann ich einen Dimmer nochmal auf dem Test System inkludieren und dir zwei lists erstellen? eins direkt nach dem Inkludieren, eines nach mcaDel 1 0 1 0 und associationAdd 1 1 ?
Grüße
Chris
Zitatauf dem Live System von dem das 'List' oben stammt ist die 10_ZWave.pm vom 17.09.
Die macht es noch falsch und erfordert in Deinem Fall mcaDel 1 0 1 0 und associationAdd 1 1.
Zitatauf dem Test System ist sie am 22.09. aktualisiert wurden
Dann sollte die Neue darauf sein, die es richtig macht.
Zitatwenn es hilft kann ich einen Dimmer nochmal auf dem Test System inkludieren und dir zwei lists erstellen?
Wenn Du Zeit und Lust hast, dann kannst Du gerne einen Dimmer mit der neuen Version inkludieren. "get associationAll" bzw. "get <device> mcaAll" sollten dann nur den Controller (ohne Endpointnummer 0) in Assoziationgruppe 1 listen. Die Befehle mcaDel 1 0 1 0 und associationAdd 1 1 sind dann überflüssig und brauchen nicht mehr ausgeführt werden. Momentan gehe ich davon aus, dass die neue Fassung alles richtig macht.
Gruß, Christian
ok, ähm, du hast recht, es ging auf Anhieb. aber warum... :) lol ::) wahrscheinlich Layer 9...
also, Update fhem/10_ZWave.pm -> nothing to do
update all - kein 10_ZWave.pm
Dongle und Dimmer factory resettet. Dongle eingebunden - node list war leer.
Dimmer eingebunden. auf anhieb alle Readings da.
hier das list
Internals:
CFGFN
DEF f7139680 2
FUUID 5d8dc77f-f33f-ba45-4f1d-fbe767705f3225f4
IODev ZWave1
LASTInputDev ZWave1
MSGCNT 40
NAME ZWave_SWITCH_MULTILEVEL_2
NR 27
STATE dim 99
TYPE ZWave
ZWave1_MSGCNT 40
ZWave1_RAWMSG 00040002058e03051000
ZWave1_TIME 2019-09-27 09:52:37
ZWaveSubDevice no
cmdsPending 0
homeId f7139680
isWakeUp
lastMsgSent 1569574356.40143
nodeIdHex 02
READINGS:
2019-09-27 09:26:51 assocGroup_1 Max 1 Nodes ZWave1
2019-09-27 09:26:51 assocGroup_2 Max 16 Nodes
2019-09-27 09:26:51 assocGroup_3 Max 16 Nodes
2019-09-27 09:26:51 assocGroup_4 Max 16 Nodes
2019-09-27 09:26:51 assocGroup_5 Max 16 Nodes
2019-09-27 09:26:50 assocGroups 5
2019-09-27 09:27:16 configActivateDeactivateFunctionsALLON10 ALLONActiveALLOFFActive
2019-09-27 09:27:16 configAutomaticTurningOffOutputAfter11 0
2019-09-27 09:27:16 configAutomaticTurningOnOutputAfterSet12 0
2019-09-27 09:27:16 configDigitalTemperatureSensor120 5
2019-09-27 09:27:16 configDimmingDuration RespectStartLevel
2019-09-27 09:27:16 configDimmingTimeSoftOnOff 100
2019-09-27 09:27:16 configDimmingTimeWhenKeyPressed 3
2019-09-27 09:27:16 configEnableDisableDoubleClickFunction Disabled
2019-09-27 09:27:16 configIgnoreStartLevel respectStartLevel
2019-09-27 09:27:17 configInput1SwitchType MonoStablePushButton
2019-09-27 09:27:17 configMaximumDimmingValue 99
2019-09-27 09:27:17 configMinimumDimmingValue 1
2019-09-27 09:27:17 configPowerReportingInWattsByTime42 0
2019-09-27 09:27:17 configPowerReportingInWattsOnPower40 5
2019-09-27 09:27:17 configSavingTheStateOfTheRelayAfterA30 FlushDimmerModuleSavesItsState0
2019-09-27 09:27:17 configTemperatureSensorOffsetSettings 32536
2019-09-27 09:27:17 configWorkingMode Dimmer
2019-09-27 09:52:33 mcaGroups 5
2019-09-27 09:52:34 mca_1 Max 1 Nodes ZWave1
2019-09-27 09:52:34 mca_2 Max 16
2019-09-27 09:52:35 mca_3 Max 16
2019-09-27 09:52:36 mca_4 Max 16
2019-09-27 09:52:37 mca_5 Max 16
2019-09-27 09:25:37 model Qubino (Goap) ZMNHSDx Din Dimmer
2019-09-27 09:25:37 modelConfig qubino/ZMNHSDx.xml
2019-09-27 09:25:37 modelId 0159-0001-0052
2019-09-27 09:26:11 power 14.9 W
2019-09-27 09:26:10 reportedState dim 99
2019-09-27 09:26:10 state dim 99
2019-09-27 09:52:37 timeToAck 1.087
2019-09-27 09:52:37 transmit OK
2019-09-27 09:25:38 zwavePlusInfo version:01 role:AlwaysOnSlave node:Z-Wave+Node installerIcon:1c00 userIcon:1c00
Attributes:
IODev ZWave1
classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY POWERLEVEL BASIC SWITCH_ALL SWITCH_BINARY SWITCH_MULTILEVEL METER ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO CONFIGURATION MARK BASIC SWITCH_MULTILEVEL
room ZWave
vclasses ASSOCIATION:2 ASSOCIATION_GRP_INFO:2 BASIC:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 MANUFACTURER_SPECIFIC:2 METER:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SWITCH_ALL:1 SWITCH_BINARY:1 SWITCH_MULTILEVEL:3 VERSION:2 ZWAVEPLUS_INFO:2
nochmal Danke für deine Zeit und Hilfe!
Grüße
Chris
Zitatauf dem Live System von dem das 'List' oben stammt ist die 10_ZWave.pm vom 17.09.
auf dem Test System ist sie am 22.09. aktualisiert wurden
Aber evtl. nicht neu gestartet: update fuehrt nicht automatisch zum Verwenden der neuen Module.
Zitat von: rudolfkoenig am 27 September 2019, 11:22:00
Aber evtl. nicht neu gestartet: update fuehrt nicht automatisch zum Verwenden der neuen Module.
das könnte durchaus sein, ja.
wie auch immer, funzt jetzt auf beiden Systemen. ich bin sehr dankbar ;)