Slychiu, may I ask to you consider as matter of urgency to make changes (which as a Software Engineer I think are low risk and on the small side but yield more than the simpleness of the change itself - so from the users point of view makes life easier and better. When I consider other Zwave Primary controllers that must have a complex web front end to represent the device to do stuff, your implementation can stand ahead the competition in terms of reliability and speed. It does what it says without hassle. Hardware ZWave devices work and conform to the Zwave standard, and as Comfort sticks to core Zwave Messages rather than complex Web device representation it is not tangled up to the point device is not fully working as happens so frequently in primary controllers.
May I ask others who read this to lend their support if necessary to make changes described below. Just a recap for others users benefit and has important information if not familiar
Step 2 - ZWAve Tips - Install and Management - ZWave Sensors
Note that just because the sensor reading is not displayed or works correctly in the Primary Controller, it does not mean it can not be used by Comfort to get the sensor reading. In other words Comfort can still use the device and sensor readings like temperature. The issue is that the device works but Vera or other primary controller does not fully support it yet properly. Because the device is fully functional and fulfill the ZWave standard, Comfort only needs the device registered in the Primary Controller.
Now to the point - - the node type must change from Basic to Multilevel Sensor.
In Comfort the node type changes during the Learn phase. However this is a two step process.
Learn step 1 get ID of the device from Primary Controller (actually the Alt ID) that Primary Controller only can create.
Learn Step 2 after all the devices are found and with their IDs Comfort goes into a second loop and speaks to the device directly (not via the primary controller) to get its device type so that the node can change to Mutlilevel Sensor.
ProblemIf you have many devices loaded and identified as Multilevel Sensor - and you want to add a new device, a new Learn process will reset the device as Basic. You can loose all the nodes that are Multilevel Senor and are set back to Basic. If you have many as I have, I have spend days and weeks, months on different Learns to get the node back to Multilevel Sensor.
Due to uncertainties in when and how the device respond with the device type, Comfort may not be able get the right information from the device on any and every Learn.
This means the Learn is a Hit and Miss affair for setting the node type. As Vera only gives a 1 minutes - there are also timing issues. You can do a Comfort Learn without putting the Primary Controller in Learn Mode when Comfort in Vera has already been Learned and this can make it easier but because Comfort resets the node type back to Basic if the device does does not give the right information - this can happen for various reasons - then you can still loose all your existing Multivlevel Senors being reset to Basic.
I have still got devices loaded as Multilevel Sensor, but I can not go further the more loaded - the more difficult it is. I plead with you to change this.
What is needed - change request - for Comfort Learn Option 1
Split out from Learn - getting and Setting Device type and add a new button for this to Just make sure the device is NOT reset to Basic on subsequent requests. Only go out to devices that are Basic node and not Node like Multilevel Senors or the Other Types. Once set this way do not change it. Only allow the user to change back to Basic.
When second/new button is pressed, then for each Basic node found in Comfort only and not Multilevel Senors or the Other Types go to the node to query the device to set the node type.
This will make Learniong from the primrary controller quicker and more robust. The Second Learn to Set the node type will be easier to manage.
Split out from Learn - getting and Setting Device type.
Make the node type a drop down box.
Allow the user to set the Node Type to Multilevel Sensor or the other Node Types. If necessary only - Comfort goes to Node to confirm the Node type but because there issues beyond Comfort control - this may or should be avoided perhaps, but if there are details the device responds with that is needed by Comfort to make things work - then you may have no choice - but if you do not need it to make it work - why bother just let the user set the Node type via Drop down.
Please may I ask you to make this change
Last edited on Thursday Nov 24th, 2016 03:57 pm by MDKKEN
MDKKEN, you have a good knowledge of the working of Zwave
We have discussed your suggestions
You are right that the learning process in UCM/Zwave is a 2 step process. First the UCM gets the node information from the primary, and 2nd the uCM addresses each node directly to find out what they are, eg Basic, Multilevel switch etc. If there is no reply from the node, the UCM/Zwave will set the node to Basic.
The first suggestion is that in the 2nd phase, the UCM/zwave does not check the multilevel switch nodes and instead, go only to the basic nodes and find out their info.
However the problem is that the Controller may have already deleted some nodes and made other changes, so a limited learn like this may miss out these changes and get left with the wrong node information
Actually the reason that the learning process fails and causes some nodes to revert to basic is due to a problem with the Zwave network itself. Not getting a reply means the UCM is unable to communicate with the node. This may mean that controlling the device may not work correctly or may be intermittent, and that even if the device remains as Multilevel it may not work correctly. The Zwave network problem may be due to the node being ourt of reach or there may be blind spots in the network.
Perhaps adding more nodes to the mesh may improve the situation.
This is similar to the problem faced by Lwillerton. after using a zniffer, it was found that one of the nodes was blocked, which caused the network problems.
The 2nd suggestion is using a drop-down list to select a node type for each device. However this practice is not allowed by Zwave, and it will refuse to certify any device which behaves this way
A possible option is to be able to select a particular node and be able to query it individually. This needs changes in Comfigurator and UCM/Zwave firmware
The performance of the zwave network especially when it is large and in a large house may still be an issue. Does anyone have any experience to share? Are there problems controlling devices intermittently?
I realise this is an old thread, but it seems closest to an issue I am trying to understand.
I have a zwave network with a number of devices. The primary controller is Homeseer, I have zwave 3 as a secondary controller.
Some of my devices are 'Sensative' window sensors. They appear in Homeseer and I can see if they are open or closed.
I would like to see their state (open or closed) in Comfort.
When I learn the network from Homeseer to Comfort the sensors appear as Basic node types, not sensors.
I think the problem is, that as described above the learning process is a two stage process, but the sensor strips are battery devices and go back to sleep before the UCM has read them as stage 2 of the process.
Is there any way I get them to appear in Comfort as sensors and therby see their state?
You have to wave a magnet over them and they wake up but it seems only for a short time.
If they are polled immediately you can connect to them but by the time the first part of the sequence has completed, they are back asleep.
I will experiment and see if I can time to wake up after I've started the learn sequence.