[ANSWERED]: Merten dimmer error syncing/including

I have now one of the ZME_WALLC-S from ZWAVE.ME here at my home for testing.
Can someone please move my post above to a new thread "New (?) dual paddle battery operated switch ZME_WALLC-S" (viewtopic.php?f=77&t=13415)? I have started a new thread there were I report from my tests with that switch.


An update on my issue with the 2-paddle/2-channel Merten / Schneider Electric battery operated Radio CONNECT switch:
I reported earlier in this thread that the device I was controlling via direct association with the 2nd paddle (right paddle) did not report status updates in Indigo (in my case a Fibaro roller shutter). Anyway during some testing with my newly arrived Merten USB Z-Wave interface I have resetted my device to factory defaults a couple of times and then reconfigured with my wanted parameters again and voilaaaa! Now BOTH devices that I control with this switch updates their statuses in Indigo. Coooool!

Still having the problem though that the switch itself only shows up as a single device in Indigo (this actually worked fine in HomeSeer where I could see 2 devices even though status updates only worked for the left paddle).

I have read some very interesting info about multi-class devices and problems with them being not properly Z-Wave constructed at http://wiki.zwaveeurope.com/index.php?t ... _in_Z-Wave (more good info at the top level of that Wiki: http://wiki.zwaveeurope.com):

Assigned Association of Multi Channel Devices by Remote Controls and Wall Controller fails
Most remote controls and wall controllers can be used to set associations either to their own buttons or even to other sources. In order to identify the association target - the device a command is supposed to be sent to – this device needs to send out a Node Information Frame to announce the Node ID to be set into the association group. The NIF however only identifies the device itself and can not differentiate between different channels. Hence the association will not be set to a specific channel but to the device only. The fall back of the device will make sure that in most cases the first channel will receive the command sent.

[matt (support)]

I have now one of the ZME_WALLC-S from ZWAVE.ME here at my home for testing.
Can someone please move my post above to a new thread "New (?) dual paddle battery operated switch ZME_WALLC-S" (viewtopic.php?f=77&t=13415)? I have started a new thread there were I report from my tests with that switch.

I think leaving it on this thread is a good idea, as it is useful information (knowing an alternative exists) for users that either have the Merten module or are thinking about getting one.

A small update on the syncing process that I have discovered during my 3-4 months of testing:

If I want to re-associate any of the two paddles to another Z-Wave device it just wont work without resetting the Merten switch back to factory defaults and then re-included it into my Z-Wave USB stick and then resync it back into Indigo where I can do my new associations.

What I have discovered is that if I SKIP/UNTICK the "Sync neighbors" function when I am syncing in the device in to Indigo for the first time, then I am able to re-associate (if needed)without having to do the full factory-reset procedure of the switch and then re-sync it back to Indigo again.. Nice indeed!

I have also noticed the following:

1. As always when you want to make an association for these switches, triple-click on any paddle and calculate until the red led has flashed the sixth time. Directly after (max 1 second later) press either click "The include" button in the Indigo association window or the "Remove association" button. You should now see in the log that the association goes through. If not, just repeat the procewss.

2. I have seen that most of the time that even if I am setting a new association and that the log actually states that association worked I can still not see it in the list of associations for the device BUT the association actually works! Just repeat the process as described in step 1 above and the new association will show up in the list.

Gentlemen I know you are really busy with Indigo 7 but I got so excited with my new discovery for these problematic battery operated push button devices from Merten that I just had to write the info here.

I really love these devices since they are so beautifully designed and really look sleek in my house with frames in brushed steel and the buttons in antracite colour.
I have also learned that these buttons are called 5051xx, 5061xx and 5071xx for the one button devices where the xx is the three different color options (white, metallic and antracite). The two-paddle versions are called 5052xx, 5062xx, and 5072xx. The three main different numbers indicate what series. For example 5051xx is the System M series and 5071xx (as well as the 5072xx) which I have are called "System Design".

Anyway, I have always wondered why these buttons only acts as an on/off device when they are associated to both the Z-Wave controller and for example a dimmer plugin at the same time. It is as if Indigo does not know that this device has the command class 0x26 multi level switch.
As soon as I remove the association between the Merten-device and the Z-Wave controller and only keep a direct association between the Merten-device and the dimmer plugin then dimming functionality of the Merten-device comes back!? The drawback with this is that Indigo has no info about when I press the Merten device since it is no longer associated with Indigo and its Z-Wave USB stick.

After years of testing and many hours of "googling", reading docs, logs etc I just today realised that when I used the Aeon Labs Zensys tool for testing my new Aeon Labs Gen5 USB Z-Wave stick that the Zensys tool actually displays these command classes:

Include Node result for Merten Connect 5071xx radio button vith Aeon Labs Zensys tool.png (103.32 KiB) Viewed 2447 times

As you can see above this Merten device has the command class 0x26, i.e. "Multilevel Switch". HOWEVER, every time I sync in the device into Indigo (or ANY other Z-Wave software) this command class is omitted/not included for some strange reason?!

The device info in Indigo is completely missing that command class:
==========
Indigo Z-Wave Version: 1.0.301
Node ID: 26
Model: Transmitter Module
Model ID: 00010004
Manufacturer: Merten
Manufacturer ID: 007A
Protocol Version: 2.27
Application Version: 1.08
Model Definition Version: 0
Library Type: 2
Class Name: Remote Switch
Class Hierarchy: 01 : 12 : 00
Command Class Base: 00
Command Versions: 20v1 85v1 86v1 8Ev1 70v1 72v1 ************** Where is the command class 26v1?!
Multi-Endpoint Types: - none -
Multi-Endpoint Classes: - none -
Multi-Instance Counts: - none - *********** (This should be 2, Merten is using the old depreciated version Multi_Instance instead of Multi_Channel)
Associations: 1:[4] 2:[] 3:[3] 4:[]
Config Values: - none -

==========

and selected parts from debug sync log when syncing in the device shows the same issue where the command class 0x26 is totally ignored:
==========
Z-Wave Syncing - started for device "026 - SchneiderElectric / Merten CONNECT 2-channel push"
Z-Wave Debug RCVD requestNodeInfo: 01 13 00 49 84 1A 0D 01 12 00 72 86 70 85 8E EF 85 20 26 50 96
Z-Wave Debug RCVD requestManufactureInfo: 01 0E 00 04 00 1A 08 72 05 00 7A 00 01 00 04 EF
Z-Wave Debug . . requestManufactureInfo: node 026, manufacturerId 007A, productId 00010004
Z-Wave Syncing - retrieved manufacture and model names: Merten - 007A, Transmitter Module - 00010004
Z-Wave Debug . . requestVersInfoGen: node 026, protoVers 2.27, appVers 1.08
Z-Wave Syncing - retrieved protocol version 2.27, app version 1.08
Z-Wave Syncing - retrieved class hierarchy: Controller : Remote Switch : -- (01 : 12 : 00, base 00)
Z-Wave Syncing - retrieved command classes: 20v1 85v1 86v1 8Ev1 70v1 72v1
Z-Wave Debug . . requestAssociationGroupCount: node 026, group count: 4
Z-Wave Debug . . requestAssociations: node 026, group: 1, num associations: 1, max associations: 12, replies left: 0
Z-Wave Debug . . requestAssociations: node 026, group: 1, associations: [4]
Z-Wave Syncing - retrieved group 1 associations: [4]
Z-Wave Debug . . requestAssociations: node 026, group: 2, num associations: 0, max associations: 12, replies left: 0
Z-Wave Debug . . requestAssociations: node 026, group: 2, associations: []
Z-Wave Syncing - retrieved group 2 associations: []
Z-Wave Debug . . requestAssociations: node 026, group: 3, num associations: 1, max associations: 12, replies left: 0
Z-Wave Debug . . requestAssociations: node 026, group: 3, associations: [3]
Z-Wave Syncing - retrieved group 3 associations: [3]
Z-Wave Debug . . requestAssociations: node 026, group: 4, num associations: 0, max associations: 12, replies left: 0
Z-Wave Debug . . requestAssociations: node 026, group: 4, associations: []
Z-Wave Syncing - retrieved group 4 associations: []
Z-Wave Debug SENT addInterfaceAssociation: 01 0B 00 13 1A 04 85 01 01 01 05 64 1C
Z-Wave Syncing - added group 1 association to interface
Z-Wave Debug . . addInterfaceAssociation: node 026, group: 1, associations: [4, 1]
Z-Wave Syncing - complete
Z-Wave Debug terminatingSyncUI
===========

Is there anyone with any clue why the sync is omitting the 0x26 command class completely even though the device is supporting it (as far as I can see in the Zensys node inclusion log)?
I see the same problem in all other HA software platforms so this is nothing unique to Indigo.

[matt (support)]

The 0x26 is coming after the mark byte (0xEF), which means the module only supports sending/commanding modules with that command class type but that the module doesn't support responding to or receiving those commands. Some battery operated modules like this report command classes this way, which technically is correct but confuses Indigo into thinking the module isn't that type (dimmer) of device.

Can you describe in more detail the specific problem you are having with Indigo's compatibility of the module. I realize in the UI it likely shows as a relay module instead of a dimmer module. We should be able to correct that by adding a device definition for the module to force Indigo into realizing the module type, but I'm not positive that will solve your issue since I'm a bit unclear as to what isn't working correctly.

Can you describe in more detail the specific problem you are having with Indigo's compatibility of the module. I realize in the UI it likely shows as a relay module instead of a dimmer module. We should be able to correct that by adding a device definition for the module to force Indigo into realizing the module type, but I'm not positive that will solve your issue since I'm a bit unclear as to what isn't working correctly.

Ok the device is a battery operated wall transmitter and is available in 2 versions, one with a single paddle (i.e. 2 channel version normally operated in one pair to control one device) and the other one with 2 paddles (i.e. 4 channels which are normally operated in pairs to control 2 devices).

There are 2 main issues:

1. When syncing in the device to Indigo and its Z-Wave USB controller stick it gets automatically associated with the Indigo controller (which is normal). I then also associate it directly with for example the dimmer that I want to control with the wall transmitter. Now the problem begins, I can now ONLY turn the dimmer ON and OFF, I can not dim it anymore.
If I remove the association between the wall transmitter and the Indigo Z-Wave USB controller stick and ONLY keep the direct association between the wall transmitter and the dimmer unit then I can control the dimming of the dimmer unit.
So the only way to be able to dim Z-Wave devices with this wall transmitter I can not have the wall transmitter associated with the Indigo Z-Wave controller stick.
A consequence of this is that I will not be able to see status of the wall transmitter in Indigo.
So the question is what is happening when I remove the association between the wall transmitter and Indigo and only keep the direct association between the wall transmitter and the device to be controlled since the dimming of the device to be controlled only works in this situation.


2. The other issue is that these devices use an old and depreciated command class called Multi_Instance instead of Multi_Channel. Indigo (and many other Z-Wave software based platforms) will not realise this and when syncing/interviewing the device Indigo is not aware of the 4 instances that the device has (this is for the 2 paddle version). The device also has the problem that it stays awake quite short time so most Z-Wave software platforms are not able complete the sync/interview process completely before the device goes into sleep again. I have tested quite many software platforms and I´ve found only one that is able to handle Multi_Instance command class and that can see/distinguish which one of the 2 paddles has been pressed and it is Z-Way Server from ZWave.ME.
So it seems to be possible to handle this wake up time issue and the depreciated Multi_Instance command class in some way. Maybe Z-Way server remembers where the first interview ends so that when I wake up the device again Z-Way continues the interview from where it ended the first time?
Z-Way Server has the same problem though as mentioned in issue number 1 above, i.e. when associated with both the controller and the device to be controlled the Merten wall transmitter only works as an on/off switch without dimming capability.

[matt (support)]

Okay, I understand now (and refreshed my memory by reading previous posts in this thread).

Unfortunately, I'm not sure how to address issue #1. It appears the module changes how it functions based on the type of device it is associated against. When it is associated with a dimmer module (that support 0x26 command) it sends out the dimming command class, but when it is associated with a module that doesn't claim to support dimming (Indigo's Z-Wave Controller in this case) it changes how it functions and no longer sends out the 0x26 commands even to other modules that do support that 0x26 command (a direct association to a dimmer). If the module is associated with a dimmer then it should send out dimming commands to that module, regardless of other modules it is associated with.

Regarding issue #2, you are correct that Indigo doesn't support the older MultiInstance command class (but does support the newer endpoint MultiChannel class). Is there anything logged (in regards to multiinstance) if you have debug logging turned on and you press a secondary button? There might be some new functionality coming in Indigo that will let you Trigger off of arbitrary incoming packets, in which case there might be a (future) way to catch those button presses if they are sending out unique packets to Indigo.

#1
Yepp this is somewhat inline with I have started to suspect as well.
I think I can verify this by NOT doing a direct association with the controller BUT instead do a direct association with a dimmer plugin device AND a on/off plug-in device. Then I should see the same erroneous behaviour. If this is true then I guess we (or no other Z-Wave software) can do nothing about it since it is an erroneous implementation by Merten / Schneider Electric of the firmware on the Merten devices.
I can live with that if this happens to be true.

#2
I'll test this when Indigo 7 is released. I don´t feel that I want to spend too much time debugging this now on my Indigo 6 installation (with about 150 devices) since I will most likely bite the bullet and start all over again with a fresh Indigo 7 install when I am also planning to replace my current Aeon Labs UZB Stick 2E with the new Aeon Labs Z-Wave Gen5 USB stick ZW090.

I´ve had some strange behaviour lately when syncing in these devices where I always have had to FIRST sync in the device to be controlled and THEN the Merten devices that will control in order to be able to complete direct associations in Indigo. I cant recall that this was the issue in the beginning of my Indigo setup so I am starting to think that something has gone bad when my installation had become +150 devices. This is the reason why I will try out with a fresh installation when Indigo 7 is released.
I´ve also seen some really difficulties to sync in new devices like the newer Fibaro and Qubino dimmers and relay switches as well as when I do a re-sync of previous synced in devices.

I might do a test install on another Mac Mini when Indigo 7 is released so that I can test it first with the Aeon Labs Gen5 USB stick ZW090.