Merten Connect 505xxx/506xxx - Parameter Values

gschwanm · Post by **gschwanm** » 30 Dec 2015 21:59

Hi!

I assoiated a Merten Connect 5051xx Battery Powered Wall Controllers to a Fibaro Roller Shutter 2.
It is now possible to fully open and close the blinds, but not to stop them.

I tried to change the parameters of the Wall Controller, but had no luck so far with the values 1, 127 or 255.
It seems to be a easy problem, as I did not find anything helping.

There is a parameter list in the manuel, but no value:

Code: Select all

List of functions                                                Parameter number
Switching/dimming/shutters dual-surface:                        0
Switching single-surface:                                       4
Retrieve/save scene                                             60
Doorbell function                                               44
Move shutter single-surface (direction of 
movement changes after each switching 
process)                                                        54
LOWER shutter as long as button
is pressed                                                      52
RAISE shutter as long as button
is pressed                                                      55

Please give me a hint.

BR
Martin

CrazyFin · Post by **CrazyFin** » 10 Jan 2016 00:04

Hi Martin

I have been playing around with Z-Wave for the last 3-4 years and have tested almost every platform and software around.

None of them have been able to successfully include and use the Merten Connect 505xxx/506xxx battery operated wall switches. As far as I have been able to read through MANY Google-searches is that the Merten switches has some kind of proprietary classes the messes up the whole inclusion process?

If I use the Merten switch and any other Z-Wave device that I want to control, like the Fibaro Roller Shutter (first version or the version 2 that you have), then I have to do a direct association between those two devices.

I have been able to do that successfully in Indigo but Indigo is bad on other things with these switches such as the fact that a 2-way switch shows up as a 1-way switch...

I recently found out about the Z-Way program and I ordered the Z-Wave.ME USBZ stick together with the license and have now been able to use the Z-Way web gui to do the inclusion, exclusion, parameter configs and so on MUCH better than ANY other software I have tested.

However, while I am able to do direct associations between a Merten 505xxx switch and for example a roller shutter I am not able to control a simple on/off wall plug when trying to do the associations via Z-Way.

I have been able to do that with the Z-Wave.ME WALLC-S2 (the new Gen5 version) successfully though so I think there is an issue with Merten Connect wall controllers in Z-Way?

Funny thing is that I am able to see all 4 paddles nice and clean in the Z-Way log:

Left paddle - Uppe
[2016-01-09 16:59:11.076] [D] [zway] RECEIVED: ( 01 0C 00 04 00 0A 06 60 06 01 20 01 FF 42 )
[2016-01-09 16:59:11.076] [D] [zway] SENT ACK
[2016-01-09 16:59:11.076] [D] [zway] SETDATA devices.10.data.lastReceived = 0 (0x00000000)
[2016-01-09 16:59:11.076] [D] [zway] SETDATA devices.1.instances.1.commandClasses.32.data.srcNodeId = 10 (0x0000000a)
[2016-01-09 16:59:11.076] [D] [zway] SETDATA devices.1.instances.1.commandClasses.32.data.srcInstanceId = 1 (0x00000001)
[2016-01-09 16:59:11.076] [D] [zway] SETDATA devices.1.instances.1.commandClasses.32.data.level = 255 (0x000000ff)

Left paddle - lower
[2016-01-09 16:59:35.380] [D] [zway] RECEIVED: ( 01 0C 00 04 00 0A 06 60 06 01 20 01 00 BD )
[2016-01-09 16:59:35.380] [D] [zway] SENT ACK
[2016-01-09 16:59:35.380] [D] [zway] SETDATA devices.10.data.lastReceived = 0 (0x00000000)
[2016-01-09 16:59:35.380] [D] [zway] SETDATA devices.1.instances.1.commandClasses.32.data.srcNodeId = 10 (0x0000000a)
[2016-01-09 16:59:35.380] [D] [zway] SETDATA devices.1.instances.1.commandClasses.32.data.srcInstanceId = 1 (0x00000001)
[2016-01-09 16:59:35.380] [D] [zway] SETDATA devices.1.instances.1.commandClasses.32.data.level = 0 (0x00000000)

Right paddle - upper
[2016-01-09 17:00:29.364] [D] [zway] RECEIVED: ( 01 0C 00 04 00 0A 06 60 06 03 20 01 FF 40 )
[2016-01-09 17:00:29.365] [D] [zway] SENT ACK
[2016-01-09 17:00:29.365] [D] [zway] SETDATA devices.10.data.lastReceived = 0 (0x00000000)
[2016-01-09 17:00:29.365] [D] [zway] SETDATA devices.1.instances.3.commandClasses.32.data.srcNodeId = 10 (0x0000000a)
[2016-01-09 17:00:29.365] [D] [zway] SETDATA devices.1.instances.3.commandClasses.32.data.srcInstanceId = 3 (0x00000003)
[2016-01-09 17:00:29.365] [D] [zway] SETDATA devices.1.instances.3.commandClasses.32.data.level = 255 (0x000000ff)

Right paddle - Lower
[2016-01-09 17:01:32.367] [D] [zway] RECEIVED: ( 01 0C 00 04 00 0A 06 60 06 03 20 01 00 BF )
[2016-01-09 17:01:32.367] [D] [zway] SENT ACK
[2016-01-09 17:01:32.367] [D] [zway] SETDATA devices.10.data.lastReceived = 0 (0x00000000)
[2016-01-09 17:01:32.367] [D] [zway] SETDATA devices.1.instances.3.commandClasses.32.data.srcNodeId = 10 (0x0000000a)
[2016-01-09 17:01:32.367] [D] [zway] SETDATA devices.1.instances.3.commandClasses.32.data.srcInstanceId = 3 (0x00000003)
[2016-01-09 17:01:32.367] [D] [zway] SETDATA devices.1.instances.3.commandClasses.32.data.level = 0 (0x00000000)

However, when I do direct association to for example a wall plug then nothing happens...

The WALLC-S2 works fine though.

Post by **PoltoS** » 10 Jan 2016 04:27

Indeed this Merten battery device is very problematic and old one.

First make sure to use simple associations (don' select any channel in your target switch). This is because Merten uses a very old and deprecated MultiInstance Command Class substituted 10 years ago by MultiChannel Command Class.

Second solution is to use Trap Events app to and Bind Devices (or If-Then) to make associations via Z-Way

CrazyFin · Post by **CrazyFin** » 10 Jan 2016 13:06

Ok I will have more questions (

) and post more screenshots of my association attempts with these switches.
I´ll create a separate thread for that since this one is about parameter values.

CrazyFin · Post by **CrazyFin** » 02 Sep 2016 10:33

Testing has continued since January...

With the latest versions of Z-Way server for Windows things has become quite good with these problematic switches from Merten.

Inclusion/exclusion works quite smooth and I am able to get events for both the left and right paddle in Z-Way server software! Really cool!

However, this is so strange:

If I have a button/transmitter, for example 5072xx, associated with my Z-Wave controller and also do a direct association with a Z-Wave dimmer then the dimmer only works as an on/off switch. Dimming becomes disabled for some reason and this is so strange. If I instead remove the association of the 5072xx from my Z-Wave controller but keep the direct association with the Z-Wave dimmer then dimmer works fine to dim lights. This causes problems since I now do not get any more updates from the 5072xx into my Z-Wave controller since it is no longer associated with the controller.

What is happening here? If I do the same thing but use USB Z-Wave stick from Merten and their own software then this part works just fine.
Is this caused by the fact that these devices also acts as a Z-Wave controller?

Post by **PoltoS** » 11 Sep 2016 14:35

May be Merten device is checking for target device capabilities? May be controller is not answering some specific command from Merten device? Check log to see this.

Hard to say exactly what happens

CrazyFin · Post by **CrazyFin** » 12 Sep 2016 21:35

Ok I am attaching some logs and data from a fresh inclusion process (the Merten reset to factory defaults and the Z-Wave stick reset as well).

First, the log from the inclusion process of Merten Connect 505xxx/506xxx/507xxx) (my model is the one paddle version 5071xx where xx is color of the paddle)

Code: Select all

[2016-09-12 19:19:27.999] [I] [zway] Adding job: Add/re-include node to network
[2016-09-12 19:19:28.028] [I] [zway] Job 0x4a (Add/re-include node to network): Ready to add - push button on the device to be added
[2016-09-12 19:19:32.769] [I] [zway] Job 0x4a (Add/re-include node to network): Node found: #0
[2016-09-12 19:19:32.957] [I] [zway] Job 0x4a (Add/re-include node to network): Adding controller: #19
[2016-09-12 19:19:32.957] [I] [zway] Adding job: Get node protocol information
[2016-09-12 19:19:32.957] [I] [zway] Adding job: Get routing table line
[2016-09-12 19:19:32.957] [I] [zway] Adding job: Check if node is failed
[2016-09-12 19:19:32.957] [I] [zway] Adding job: Get routing table line
[2016-09-12 19:19:32.972] [I] [zway] Job 0x62 (Check if node is failed): Node 19 is operating
[2016-09-12 19:19:32.972] [I] [zway] Removing job: Check if node is failed
[2016-09-12 19:19:33.160] [I] [zway] Job 0x4a (Add/re-include node to network): Protocol done
[2016-09-12 19:19:33.160] [I] [zway] Loading Command Classes for device 19
[2016-09-12 19:19:33.160] [I] [zway] Node 19:0 supports CC Basic
[2016-09-12 19:19:33.160] [I] [zway] Node 19:0 supports CC Configuration
[2016-09-12 19:19:33.160] [I] [zway] Node 19:0 supports CC ManufacturerSpecific
[2016-09-12 19:19:33.160] [I] [zway] Node 19:0 supports CC Association
[2016-09-12 19:19:33.160] [I] [zway] Node 19:0 supports CC Version
[2016-09-12 19:19:33.160] [I] [zway] Node 19:0 supports CC MultiChannelAssociation
[2016-09-12 19:19:33.160] [I] [zway] Interview step 1 skipped due to absence of Security CC
[2016-09-12 19:19:33.160] [I] [zway] Interview step 2
[2016-09-12 19:19:33.160] [I] [zway] Node 19:0 CC Version Interview started
[2016-09-12 19:19:33.160] [I] [zway] Adding job: Basic Version Get
[2016-09-12 19:19:33.160] [I] [zway] Adding job: Configuration Version Get
[2016-09-12 19:19:33.160] [I] [zway] Adding job: ManufacturerSpecific Version Get
[2016-09-12 19:19:33.160] [I] [zway] Adding job: Association Version Get
[2016-09-12 19:19:33.160] [I] [zway] Adding job: Version Version Get
[2016-09-12 19:19:33.160] [I] [zway] Adding job: MultiChannelAssociation Version Get
[2016-09-12 19:19:33.160] [I] [zway] Adding job: Add/re-include node to network
[2016-09-12 19:19:33.175] [I] [zway] Removing job: Add/re-include node to network
[2016-09-12 19:19:33.438] [I] [zway] Job 0x4a (Add/re-include node to network): Done
[2016-09-12 19:19:33.438] [I] [zway] Removing job: Add/re-include node to network
[2016-09-12 19:19:33.438] [I] [zway] Adding job: Add/re-include node to network
[2016-09-12 19:19:33.548] [W] [zway] Received SOF, while awaiting ACK
[2016-09-12 19:19:33.548] [I] [zway] Node info received: 19
[2016-09-12 19:19:33.845] [I] [zway] Job 0x4a (Add/re-include node to network): No ACK received before timeout
[2016-09-12 19:19:33.860] [I] [zway] Job 0x4a (Add/re-include node to network): Stop done
[2016-09-12 19:19:33.860] [I] [zway] Removing job: Add/re-include node to network
[2016-09-12 19:19:33.891] [I] [zway] Removing job: Get node protocol information
[2016-09-12 19:19:33.907] [I] [zway] Job 0x80 (Get routing table line): List of neighbours for node 1: [ ]
[2016-09-12 19:19:33.907] [I] [zway] Removing job: Get routing table line
[2016-09-12 19:19:33.923] [I] [zway] Job 0x80 (Get routing table line): List of neighbours for node 19: [ ]
[2016-09-12 19:19:33.923] [I] [zway] Removing job: Get routing table line
[2016-09-12 19:19:34.001] [I] [zway] Job 0x13 (Basic Version Get): Delivered
[2016-09-12 19:19:34.001] [I] [zway] Removing job: Basic Version Get
[2016-09-12 19:19:34.016] [I] [zway] Node 19:0 CC Version: Basic is v1
[2016-09-12 19:19:34.188] [I] [zway] Job 0x13 (Configuration Version Get): Delivered
[2016-09-12 19:19:34.188] [I] [zway] Removing job: Configuration Version Get
[2016-09-12 19:19:34.204] [I] [zway] Node 19:0 CC Version: Configuration is v1
[2016-09-12 19:19:34.355] [I] [zway] Job 0x13 (ManufacturerSpecific Version Get): Delivered
[2016-09-12 19:19:34.355] [I] [zway] Removing job: ManufacturerSpecific Version Get
[2016-09-12 19:19:34.387] [I] [zway] Node 19:0 CC Version: ManufacturerSpecific is v1
[2016-09-12 19:19:34.526] [I] [zway] Job 0x13 (Association Version Get): Delivered
[2016-09-12 19:19:34.526] [I] [zway] Removing job: Association Version Get
[2016-09-12 19:19:34.557] [I] [zway] Node 19:0 CC Version: Association is v1
[2016-09-12 19:19:34.713] [I] [zway] Job 0x13 (Version Version Get): Delivered
[2016-09-12 19:19:34.713] [I] [zway] Removing job: Version Version Get
[2016-09-12 19:19:34.729] [I] [zway] Adding job: Version Get
[2016-09-12 19:19:34.729] [I] [zway] Node 19:0 CC Version: Version is v1
[2016-09-12 19:19:34.901] [I] [zway] Job 0x13 (MultiChannelAssociation Version Get): Delivered
[2016-09-12 19:19:34.901] [I] [zway] Removing job: MultiChannelAssociation Version Get
[2016-09-12 19:19:34.916] [I] [zway] Node 19:0 CC Version: MultiChannelAssociation is v1
[2016-09-12 19:19:35.073] [I] [zway] Job 0x13 (Version Get): Delivered
[2016-09-12 19:19:35.073] [I] [zway] Removing job: Version Get
[2016-09-12 19:19:35.104] [I] [zway] Node 19:0 CC Version Interview done
[2016-09-12 19:19:35.104] [I] [zway] Saving configuration data to config/zddx/cc518d51-DevicesData.xml
[2016-09-12 19:19:35.104] [I] [zway] Interview step 3
[2016-09-12 19:19:35.104] [I] [zway] Node 19:0 CC ManufacturerSpecific Interview started
[2016-09-12 19:19:35.104] [I] [zway] Adding job: ManufacturerSpecific Get
[2016-09-12 19:19:35.229] [I] [zway] Job 0x13 (ManufacturerSpecific Get): Delivered
[2016-09-12 19:19:35.229] [I] [zway] Removing job: ManufacturerSpecific Get
[2016-09-12 19:19:35.260] [I] [zway] Node 19:0 CC ManufacturerSpecific Interview done
[2016-09-12 19:19:35.260] [I] [zway] Saving configuration data to config/zddx/cc518d51-DevicesData.xml
[2016-09-12 19:19:35.260] [I] [zway] Loading ZDDX index from ZDDX/ZDDX.indxml
[2016-09-12 19:19:35.276] [I] [zway] Found multiple partial matches, choose manually
[2016-09-12 19:19:35.276] [I] [zway] Interview step 4 skipped due to absence of MultiInstance CC
[2016-09-12 19:19:35.276] [I] [zway] Interview step 5
[2016-09-12 19:19:35.276] [I] [zway] Node 19:0 CC Basic Interview started
[2016-09-12 19:19:35.276] [I] [zway] Node 19:0 CC Basic Interview done
[2016-09-12 19:19:35.276] [I] [zway] Adding job: Basic Get
[2016-09-12 19:19:35.276] [I] [zway] Node 19:0 CC Configuration Interview started
[2016-09-12 19:19:35.276] [I] [zway] Node 19:0 CC Configuration Interview done
[2016-09-12 19:19:35.276] [I] [zway] Node 19:0 CC Association Interview started
[2016-09-12 19:19:35.276] [I] [zway] Adding job: Association Groupings Get
[2016-09-12 19:19:35.276] [I] [zway] Node 19:0 CC MultiChannelAssociation Interview started
[2016-09-12 19:19:35.276] [I] [zway] Adding job: MultiChannelAssociation Groupings Get
[2016-09-12 19:19:35.401] [I] [zway] Job 0x13 (Basic Get): Delivered
[2016-09-12 19:19:35.401] [I] [zway] Removing job: Basic Get
[2016-09-12 19:19:35.573] [I] [zway] Job 0x13 (Association Groupings Get): Delivered
[2016-09-12 19:19:35.573] [I] [zway] Removing job: Association Groupings Get
[2016-09-12 19:19:35.604] [I] [zway] Adding job: Association Get
[2016-09-12 19:19:35.604] [I] [zway] Adding job: Association Get
[2016-09-12 19:19:35.760] [I] [zway] Job 0x13 (MultiChannelAssociation Groupings Get): Delivered
[2016-09-12 19:19:35.760] [I] [zway] Removing job: MultiChannelAssociation Groupings Get
[2016-09-12 19:19:35.776] [I] [zway] Adding job: MultiChannelAssociation Get
[2016-09-12 19:19:35.776] [I] [zway] Adding job: MultiChannelAssociation Get
[2016-09-12 19:19:35.948] [I] [zway] Job 0x13 (Association Get): Delivered
[2016-09-12 19:19:35.948] [I] [zway] Removing job: Association Get
[2016-09-12 19:19:35.979] [I] [zway] Node 19:0 CC Association: Group 1 report
[2016-09-12 19:19:36.151] [I] [zway] Job 0x13 (Association Get): Delivered
[2016-09-12 19:19:36.151] [I] [zway] Removing job: Association Get
[2016-09-12 19:19:36.182] [I] [zway] Node 19:0 CC Association: Group 2 report
[2016-09-12 19:19:36.182] [I] [zway] Node 19:0 CC Association Interview done
[2016-09-12 19:19:36.182] [I] [zway] Node 19:0 CC Association: Auto Configuration done
[2016-09-12 19:19:36.370] [I] [zway] Job 0x13 (MultiChannelAssociation Get): Delivered
[2016-09-12 19:19:36.370] [I] [zway] Removing job: MultiChannelAssociation Get
[2016-09-12 19:19:36.385] [I] [zway] Node 19:0 CC MultiChannelAssociation: Group 1 report
[2016-09-12 19:19:36.541] [I] [zway] Job 0x13 (MultiChannelAssociation Get): Delivered
[2016-09-12 19:19:36.541] [I] [zway] Removing job: MultiChannelAssociation Get
[2016-09-12 19:19:36.573] [I] [zway] Node 19:0 CC MultiChannelAssociation: Group 2 report
[2016-09-12 19:19:36.573] [I] [zway] Node 19:0 CC MultiChannelAssociation Interview done
[2016-09-12 19:19:36.573] [I] [zway] Saving configuration data to config/zddx/cc518d51-DevicesData.xml
[2016-09-12 19:19:36.573] [I] [zway] Interview for Node #19 finished.
[2016-09-12 19:19:36.573] [I] [zway] Adding job: MultiChannelAssociation Set
[2016-09-12 19:19:36.573] [I] [zway] Adding job: MultiChannelAssociation Get
[2016-09-12 19:19:36.573] [I] [zway] Adding job: MultiChannelAssociation Set
[2016-09-12 19:19:36.573] [I] [zway] Adding job: MultiChannelAssociation Get
[2016-09-12 19:19:36.573] [I] [zway] Node 19:0 CC MultiChannelAssociation: Auto Configuration done
[2016-09-12 19:19:36.745] [I] [zway] Job 0x13 (MultiChannelAssociation Set): Delivered
[2016-09-12 19:19:36.745] [I] [zway] Removing job: MultiChannelAssociation Set
[2016-09-12 19:19:36.916] [I] [zway] Job 0x13 (MultiChannelAssociation Get): Delivered
[2016-09-12 19:19:36.916] [I] [zway] Removing job: MultiChannelAssociation Get
[2016-09-12 19:19:37.104] [I] [zway] Job 0x13 (MultiChannelAssociation Set): Delivered
[2016-09-12 19:19:37.104] [I] [zway] Removing job: MultiChannelAssociation Set
[2016-09-12 19:19:37.277] [I] [zway] Job 0x13 (MultiChannelAssociation Get): Delivered
[2016-09-12 19:19:37.277] [I] [zway] Removing job: MultiChannelAssociation Get

This is interesting! When I press for example the upper (ON) part of the paddle for the FIRST time after a completed inclusion process I see the following in the log.
Note the error message of not supporting command class 0x60, i.e. the multi channel v2 / multi instance class?
Same error on the next log row for the 0x20 command class?

Code: Select all

[2016-09-12 20:00:00.806] [I] [zway] Got frame from device 19 to controller, but command class 0x60 for device is not registered - instantiating it as not supported
[2016-09-12 20:00:00.806] [I] [zway] Node 19:0 CC MultiChannel: Received CC 0x20 command from instance 1, but it is not registered, creating it as unsupported
[2016-09-12 20:00:00.822] [I] [core] Creating device switchControl ZWayVDev_zway_Remote_19-1-1-B
[2016-09-12 20:00:00.822] [I] [core] Notification: device-info (device-OnOff): {"dev":"Merten (19.1.1) Button","l":"on"}
[2016-09-12 20:00:03.658] [I] [core] Notification: device-info (device-OnOff): {"dev":"Merten (19.1.1) Button","l":"off"}
[2016-09-12 20:00:11.307] [I] [core] Notification: device-info (device-OnOff): {"dev":"Merten (19.1.1) Button","l":"on"}

I have selected the device description "CONNECT 5051xx" and looking in the XML file I see:

Code: Select all

<ZWaveDevice xmlns="http://www.pepper1.net/zwavedb/xml-schemata/z-wave" schemaVersion="2">
<descriptorVersion>1</descriptorVersion>
<deviceData>
<manufacturerId value="007a"/>
<productType value="0001"/>
<productId value="0002"/>
<libType value="02"/>
<protoVersion value="02"/>
<protoSubVersion value="07"/>
<appVersion value="01"/>
<appSubVersion value="05"/>
<basicClass value="01"/>
<genericClass value="12"/>
<specificClass value="01"/>
<optional value="false"/>
<listening value="false"/>
<routing value="false"/>
<beamSensor>0</beamSensor>
</deviceData>
<deviceDescription>
<description>
<lang xml:lang="en"/>
</description>
<wakeupNote>
<lang xml:lang="en"/>
</wakeupNote>
<inclusionNote>
<lang xml:lang="en"/>
</inclusionNote>
<productName/>
<brandName/>
<productVersion>1.5</productVersion>
</deviceDescription>
<commandClasses>
<commandClass id="0020" version="1" supported="true" controlled="true" secure="false" inNIF="false"/>
<commandClass id="0070" version="1" supported="true" controlled="false" secure="false" inNIF="true"/>
<commandClass id="0072" version="1" supported="true" controlled="false" secure="false" inNIF="true"/>
<commandClass id="0085" version="1" supported="true" controlled="true" secure="false" inNIF="true"/>
<commandClass id="0086" version="1" supported="true" controlled="false" secure="false" inNIF="true"/>
<commandClass id="008e" version="1" supported="true" controlled="false" secure="false" inNIF="true"/>
<commandClass id="0060" version="1" supported="false" controlled="true" secure="false" inNIF="false"/>
<commandClass id="0026" version="1" supported="false" controlled="true" secure="false" inNIF="true"/>
<commandClass id="0050" version="1" supported="false" controlled="true" secure="false" inNIF="true"/>
</commandClasses>
<assocGroups>
<assocGroup number="1" maxNodes="12">
<description>
<lang xml:lang="en">Group 1</lang>
</description>
</assocGroup>
<assocGroup number="2" maxNodes="12">
<description>
<lang xml:lang="en">Group 2</lang>
</description>
</assocGroup>
</assocGroups>
</ZWaveDevice>

Shouldn´t the row with "<commandClass id="0060" version="1" supported="false" controlled="true" secure="false" inNIF="false"" have "supported = true"?
And shouldn´t the row with "<commandClass id="0026" version="1" supported="false" controlled="true" secure="false" inNIF="true"" have "supported = true"?

Looking at the interview result I see the following:

: Z-Way server - Interview result for Merten Connect 5071xx radio button.png (21.16 KiB) Viewed 18930 times

Here is the command class data I see

Basic:

Code: Select all

/: None (19:19)
    supported: true (19:19)
    version: 1 (19:19)
    security: false (19:19)
    interviewDone: true (19:19)
    interviewCounter: 9 (19:19)
    level: None (19:19)

Configuration:

Code: Select all

/: None (19:19)
    0: None (20:07)
        val: 0 (20:07)
        size: 1 (20:07)
    4: None (20:09)
        val: 0 (20:09)
        size: 1 (20:09)
    44: None (20:09)
        val: 0 (20:09)
        size: 1 (20:09)
    52: None (20:09)
        val: 0 (20:09)
        size: 1 (20:09)
    54: None (20:09)
        val: 0 (20:09)
        size: 1 (20:09)
    55: None (20:09)
        val: 0 (20:09)
        size: 1 (20:09)
    supported: true (19:19)
    version: 1 (19:19)
    security: false (19:19)
    interviewDone: true (19:19)
    interviewCounter: 9 (19:19)

Manufacturer Specific

Code: Select all

/: None (19:19)
    supported: true (19:19)
    version: 1 (19:19)
    security: false (19:19)
    interviewDone: true (19:19)
    interviewCounter: 9 (19:19)
    vendorId: 122 (19:19)
    vendor: Merten (19:19)
    productId: 2 (19:19)
    productType: 1 (19:19)
    serialNumber: None (19:19)

Association

Code: Select all

/: None (19:19)
    1: None (20:02)
        max: 12 (20:02)
        nodes: (20:02)
    2: None (20:02)
        max: 12 (20:02)
        nodes: (20:02)
    supported: true (19:19)
    version: 1 (19:19)
    security: false (19:19)
    interviewDone: true (19:19)
    interviewCounter: 9 (19:19)
    groups: 2 (19:19)
    specificGroup: None (19:19)

Version

Code: Select all

/: None (19:19)
    supported: true (19:19)
    version: 1 (19:19)
    security: false (19:19)
    interviewDone: true (19:19)
    interviewCounter: 9 (19:19)
    ZWLib: 2 (19:19)
    ZWProtocolMajor: 2 (19:19)
    ZWProtocolMinor: 7 (19:19)
    SDK: 4.05 (19:19)
    applicationMajor: 1 (19:19)
    applicationMinor: 5 (19:19)
    hardwareVersion: None (19:19)
    firmwareCount: 0 (19:19)

Multi Channel Association

Code: Select all

/: None (19:19)
    1: None (20:02)
        max: 12 (20:02)
        nodesInstances: 1,1 (20:02)
    2: None (20:02)
        max: 12 (20:02)
        nodesInstances: 1,2 (20:02)
    supported: true (19:19)
    version: 1 (19:19)
    security: false (19:19)
    interviewDone: true (19:19)
    interviewCounter: 9 (19:19)
    groups: 2 (19:19)

I hope this can make some help in trying to understand why the dimming functionality is lost when these devices are associated both to the Z-Wave controller and the device to be controlled.

CrazyFin · Post by **CrazyFin** » 13 Sep 2016 00:07

This is interesting! Using Aeon Labs new generation Z-Wave USB stick called "Z-Stick GEN5" together with their small tool "Zensys Tool" I can see command class 0x26 (multilevel switch) for the Merten device:

: Z-Way server - Interview result for Merten Connect 5071xx radio button vith Aeon Labs Zensys tool.png (23.91 KiB) Viewed 18929 times

So the question is why none of the Z-Wave based software platforms I have tested are able to see that this device supports multi level switch command class 0x26.

I found this interesting thread (in German though) https://forum.fhem.de/index.php/topic,4 ... #msg381232

And when they include the device as a new node they do also see the command class 0x26:
Readings:
2015-12-29 14:59:54 CMD ZW_APPLICATION_UPDATE
2015-12-29 17:06:47 basicSet ff
2015-12-29 14:58:48 model Merten Transmitter 2-Gang Switch
2015-12-29 14:58:48 modelId 007a-0001-0004
2015-12-29 17:04:11 transmit NO_ACK
Versionhash:
ASSOCIATION, BASIC, BASIC_WINDOW_COVERING, CONFIGURATION,MANUFACTURER_SPECIFIC, MULTI_CHANNEL_ASSOCIATION, SWITCH_MULTILEVEL
VERSION
Attributes:
IODev ZWDongle_0
classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MARK ASSOCIATION BASIC SWITCH_MULTILEVEL BASIC_WINDOW_COVERING

So could this be the issue that command class 0x26 is not being properly picked up when syncing in the device into Z-Way?

Post by **PoltoS** » 14 Sep 2016 00:24

Becasue it is after CC_MARK. Everything after MARK is "controlled" versus those before (supported). MEans device can send Switch Multilevel, but can not accept it.

Z-Way on it's side will always trap Switch Multilevel commands and create "supported=false" CC to handle events from the device. But only if device sends such commands.

As I've mentioned previously, may be the device do not send them because it expects something from the controller to configure it? Please compare log of Merten commands with log of Z-Way (I know, it is hard!) or ask Merten

CrazyFin · Post by **CrazyFin** » 14 Sep 2016 14:19

I am not sure that I really understand what the CC_MARK means. Does it mean that the device is capable of those command classes (for example 0x26) but does not show it to the controller due to the controller not asking/showing proper requests to the device during the inclusion process?
Ah! Found this explanation on the web:

"The command classes that come before 0xEF COMMAND_CLASS_MARK are the supported classes – what the device accepts, more or less – and the ones after the mark are the controlled classes – what the device sends to others."
So to me it sounds like the Merten device is capable of SENDING the 0x26 TO the controller but not accepting the 0x26 commands FROM the controller?

You mention that I should compare the log of Merten commands against the Z-Way log (which I can see). I am not sure what Merten commands log you mean?

I have been in contact with Schneider Electric (who owns Merten since few years back). I started the communications with Schneider Electric here in Sweden and have now been able to find a person in Denmark that seems to have more technical knowledge of their devices but so far no luck with solving this mystery.

Z-Way is really good though compared to other software and hardware based plattforms since it is the ONLY one that I have tested so far that is capable of handling the old and depreciated "Multi Instance" class properly. I am now able to see BOTH paddles for the 4-channel models in the log. Really good!

I just wish we could solve this non-dimming versus dimming mystery and I will be flying high...

forum

Merten Connect 505xxx/506xxx - Parameter Values

Merten Connect 505xxx/506xxx - Parameter Values

Re: Merten Connect 505xxx/506xxx - Parameter Values

Re: Merten Connect 505xxx/506xxx - Parameter Values

Re: Merten Connect 505xxx/506xxx - Parameter Values

Re: Merten Connect 505xxx/506xxx - Parameter Values

Re: Merten Connect 505xxx/506xxx - Parameter Values

Re: Merten Connect 505xxx/506xxx - Parameter Values

Re: Merten Connect 505xxx/506xxx - Parameter Values

Re: Merten Connect 505xxx/506xxx - Parameter Values

Re: Merten Connect 505xxx/506xxx - Parameter Values