forum

Hello

I've been using the Z-Cloud for a while now and I've had a few problems with it and my whole zwave-network:

I have a few ACT wall plugs, merten connect binary power switches, duwi dimmers and zwave.me dimmers. I control them all with a zwave.me usb stick which is connected to a windows machine which is on almost 24/7.

I have all of my merten modules (3) associated with two of my zwave.me dimmers second association group. This has been working all right for a while, until today the other dimmer won't control the mertens. When I request current stored values from the association part of the zwave.me dimmer it tells me the mertens are indeed associated with the second group. I tried re-interviewing the zwave.me dimmer but for some reason the interview won't finish. The queue shows the node responding ok but the values in the description record won't update. The other dimmer controls the mertens just fine.

Also, sometimes one of my original duwi dimmers shows as dead but comes to life when I ask it for some current stored values. One was doing the same thing until it died completely (local control works, though).

Any ideas to what's going on?

EDIT: I just noticed that the description record shows as Flush-Mountable Dimmer v1.3 for the non-working dimmer and the working dimmer shows only Flush-Mountable Dimmer. The double click part for configuration is also missing from the dimmer that won't control the mertens.

Unfortunately this version (1.3) had a bug with parameter 14 (double click bahevior). The bug is that parameter 14 is saved in place of 13th parameter after powercycle. So, after configuration and until you power off the device, everything is ok. After power off, param 14 is reverted to factory default (double click is disabled). That's why we have removed this param from description of version 1.3 (the one you have). The description without version number (that you still have for your second dimmer) is older and still have description of the buggy parameter. In more recent version of our devices (starting from 1.4) this problem was fixed (it was in august or september 2011).

If you use param 13 and 14 (single and double click actions) both equal to 1 (Switch On/Off and dim by Basic Set), we can popose you simple workaround: make a schedule that sends Configuration.Set(14, 1, 1) commands each 10 minutes. Thus, after a powercycle your config will be restored in less than 10 minutes.

To get the description having the parameter 14 in the list of configurations just select the description record manually (version 1.4) by pressing a button on the top of Device Configuration page (the furst button under first cut link).

Hope this will help.

We apologize for the inconvenience.

Thanks for the reply.

Unfortunately that didn't work. I set the parameters 13 and 14 to 1 (1byte) and they were successfully sent (checked the queue).

I even tried to associate the mertens with group 1 of the dimmer so they would be controlled by single click but that didn't work, either. This dimmer has worked in the past and it responds to everything I send from Z-Cloud immediately. The local attached load switching/dimming also works flawlessly. Only the associated switching doesn't work (I tried associating with other nodes, too.) Is it broken?

Disconnect the power and connect back. Will the problem go out?

I tried that yesterday and it worked. I just had to set parameter 14 again.

This morning, neither of the dimmers were controlling the mertens. I had to cut power to both of them again to get them to work (they are behind the same fuse). This won't do. Is this something that is fixed in later software versions?

This was fixed in November 2011. This happened only in big networks where routed commands were sent out.

A workaround (to tricky, but should work): If it worked for you before, you might want to update neighbours for ZME devices (in hope they will see Merten devices and controller in direct range) and powercycle them once. They will work until first routed packet is sent out. Unfortunately only we are able to fix the device.

We apologize again for the inconvenience you have.