Z-Wave 7.043

[alvy]

Do u mean setting the remote to replicate information to the ucm again? ie. Pressing \"learn\" in configurator and follw by pressing \"exc\" and \"asc\" on the lrc14? Did that many times..not helping..please advise if we can manually correct this mode assignment? Changing the basic to multichannel assignment in the clx file and writing into eprom doesnt work.

[alvy]

[user=86]ident[/user] wrote:

Can you do another learn with the network, no need to reset

You should be able to see the nodes as multichannel.

During each learn, the UCM/Zwave polls all the nodes to see if they are multichannel

You have not erased any information even though the last learn detected as basic

Hi when u say that the ucm will poll the nodes for node type, does it mean that the remote controller does not contain information about the node type when include the nodes. So during a replication of the information between the controller and ucm, only node id and address is exchanged? Node type is determined and interpretted by the ucm when it polls the actual device?? Then what is stopping us from manually assigning the node type to the switches assuming that we hit such problems as ive encountered.
The reason why i reset the whole network is because ive experimented and discovered that the response problem ive mentioned earlier only affect basic nodes. I can configure multiple channel ids in the response when the node is multichannel. In basic node only channel \"blank\" works.

[alvy]

[user=86]ident[/user] wrote:

If you still have many nodes as basic after a learn, it may be the last node which is a dimmer which is causing a problem on the zwave network
Exclude it and see if there is any problem

The last node which is a DIN module dimmer is also directly associated to a satelite switch via the same remote so that it can be controlled by that switch. I did a series of other association with other switches to establish some 2 way switching before i let the ucm learn the network again which included the last node addition. Can this cause the problem mentioned? But then, before i attempted the reset earlier, during the 1st round after i upgraded the firmware, i used the remote to incl all switches in one go before i replicate to the ucm. Already without setting associations all nodes are detected as basic. Very puzzling..

[ident]

please advise if we can manually correct this mode assignment?

Being a Zwave-enabled manufacturer, Z-wave does not allow manual assignment of multichannel switches if it is not detected. This is why you cannot manually send a multichannel command

does it mean that the remote controller does not contain information about the node type when include the nodes. So during a replication of the information between the controller and ucm, only node id and address is exchanged? Node type is determined and interpretted by the ucm when it polls the actual device??

Correct, the UCM/Zwave has to poll each device to fnd out if it is a multichannel switch. If there is no reply from the device, then it is taken as a Basic switch

Then what is stopping us from manually assigning the node type to the switches assuming that we hit such problems as ive encountered.

Zwave Association does not allow this


Before you reset the network and after you reset the network it seems that only with the dimmer in the network, the nodes became basic. So it may be that puttiing the dimmer in the network caused a problem. That is why I suggest to remove and confirm if the nodes can be detected as Multichannel switches

[alvy]

Ok..so in other words the remote is not faulty? 
I totally understand that zwave association has its concern..but besides using a learn which requires the remote to replicate..can u program a button or function just to do node validation instead or the learn which requires the remote. Is there also a debug mode to see the zwave exchanges so that we can troubleshoot this problem or identify malfunctioning nodes?

[ident]

I think the first thing to confirm is whether removing the last node fixes this problem, before we can consider other actiions

[alvy]

Hi,

i did more tests now. I\'ve confirmed that the last DIN node is not causing the problems. As you\'ve mentioned that each learn process polls all nodes for their type, I did a few more rounds of learning by doing the replication procedure. I get mixed results everytime after a learn. Sometimes I get randomly more than 10 multichannel nodes showing as basic, sometimes less. The best i\'ve managed is only 2 units of 2 channel switches returning as basic nodes. And you mentioned that if the nodes do not reply in due time they are automatically classify as basic nodes. I\'ve did a few rounds of network rediscovery with the LRC14 and re-learn again, but again, best result is 2 random nodes labeled as basic when they should be multichannel. and when they are registered as basic nodes, response wizard does not work when i declare the 2nd channel under basic set command. Only channel 0 works.

is there a way to have guaranteed msg send and receipt when the ucm is polling for node information relating to types? Is there a configurable timeout setting to lengthen the wait period for node replies? Obviously, I would appreciate if a new patch can be made to the configurator to solve the Response multichannel bug.

thanks

[ident]

I\'ve confirmed that the last DIN node is not causing the problems

How did you confirm that?

and when they are registered as basic nodes, response wizard does not work when i declare the 2nd channel under basic set command. Only channel 0 works.

That is correct, according to the rules set by Zwave

Is there a configurable timeout setting to lengthen the wait period for node replies?

This is not within our control. The time-out is in the Z-Wave module and cannot be changed

i was having very delayed actions from associated switches. I can have 2 associated switches side by side which takes more than 5 secs to trigger each other\'s button. Seemed like some form of zwave storm or loop that is occuring. On top of that some switches do not even trigger its associated peer anymore. Reassociating resolve the problem for less than a few hrs and it reverted back to the problematic stage.

are you saying the Zwave switches associated wth other switches have a big delay.


It appears like this may be a Z-wave network problem and may not be a bug
Perhaps your house is too large if it has 3 or 4 floors


You have not sent your cclx file to support@cytech.biz That would help us to understand your setup better

[alvy]

Hi,

Sent you the cclx (the only one i can find) which was having issue with the zwave network.

I did not exclude the DIN module because after a few re-learn i managed to get most back to multichannel except any random 2 switches. But those switches are located either in the basement or 1 floor (in a room) above the UCM. I am starting to believe that it may be a issue with lost communication at the point of relearning. Unless you are sure that the DIN node really the culprit I will do the exclude. It is challenging and the reason why i\'m reluctant to exclude it because it is sited in the ceiling!

As for the bug i mentioned about assigning channels other than 0 or 1 to the basic node, I always have the impression you can do that regardless of whether the node is identified as basic or multi. My bad. So i do have to resolve the node type issue else I won\'t be able to control some switches.

[ident]

There is no problem with your file and the setup for zwave

It looks like the din rail dimmer may be the cause of the problem. Prior to adding the din rail dimmer, you were always able to detect the multichannel switch  but when you added the dimmer then each time you do a learn, you have random switches detected as basic (ie there is no reply to a query). We suspect this could be because the din rail dimmer is interfering with the other devices replies to the query when UCM/zwave is polling them. But we cannot be sure without trying it out.
In zwave, many things are going on in the wireless network which are not known

If you do remove the dimmer from the network and everything works then you should do a reset to default for the dimmer so that any data that is left can be erased, as that may be causing problems