Closed cheweiliang closed 10 years ago
I just trace the code a little bit. In function getNodeInfo(self, destination) in wkpfcomm.py: I think it should enter the first if statement to get the node location, wuclass list, wuobject list. Is that correct? But I am not sure what the "basic", "generic", and "specific" represent for.
It looks like you have a native ZWave device in the node list. They will be treated as Light Actuator even through that it is not active since we use the (basic,generic,specific) to decide the device type. We can send a SWITCH_BINARY_GET to check if the device is available or not in the future. However, for now, if any zwave switch is added, we will treat it as Light_Actuator.
2013/10/29 catlikethief notifications@github.com
I just trace the code a little bit. In function getNodeInfo(self, destination) in wkpfcomm.py: I think it should enter the first if statement to get the node location, wuclass list, wuobject list. Is that correct? But I am not sure what the "basic", "generic", and "specific" represent for.
— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/71#issuecomment-27279095 .
Hello @wycc
When I use my wedevice in discover process, it only shows light_actuator in the detail dialog.
Currently My enable_wuclasses.xml file is,
<WuClass name="Threshold" appCanCreateInstances="true"/>
<WuClass name="Light_Sensor" appCanCreateInstances="true" createInstancesAtStartup="1" />
<WuClass name="Light_Actuator" appCanCreateInstances="true" createInstancesAtStartup="1" />
<WuClass name="Numeric_Controller" appCanCreateInstances="true" createInstancesAtStartup="1" />
<WuClass name="LED" appCanCreateInstances="true" createInstancesAtStartup="1" />
I can not get it, why the discover result only show light_actuator.
I am still tracing .. , please provide any help !
I am in the same situation as Louis and also tried 3 cases, no component, one component and 3 stage components. It always turned out to be like this:
The four wuobjects are always all light actuators no matter what the FBP is drawn in my tests.
Please make sure that your wudevice is loaded with the latest VM. In the end of the function radio_zwave_init(), there is a call to
radio_zwave_set_node_info(0,0xff,0)
This function will set the (generic,specific) to be (0xff,0). Therefore, in the Master, it will be treated as WUDevice instead of native zwave device. Please make sure this function is called.
2013/10/29 catlikethief notifications@github.com
I just trace the code a little bit. In function getNodeInfo(self, destination) in wkpfcomm.py: I think it should enter the first if statement to get the node location, wuclass list, wuobject list. Is that correct? But I am not sure what the "basic", "generic", and "specific" represent for.
— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/71#issuecomment-27279095 .
"radio_zwave_set_node_info()" function is called after I reset the Zwave module and re-match the device node ID.
The issue of mine as mentioned is resolved but it still cannot discover the components.
it seems that the radio_zwave_set_node_info() has been call since in the code.
void radio_zwave_set_node_info(uint8_t devmask,uint8_t generic, uint8_t specific) {
unsigned char b[10];
int k;
b[0] = 1;
b[1] = 8;
b[2] = 0;
b[3] = 3;
b[4] = devmask;
b[5] = generic;
b[6] = specific;
b[7] = 0;
b[8] = seq;
b[9] = 0xff^7^0^0x3^devmask^generic^specific^0^seq;
seq++;
for(k=0;k<10;k++)
{
uart_write_byte(ZWAVE_UART, b[k]);
}
zwave_mode=0;
DEBUG_LOG(true,"set node info!!!!!!!!!!");
}
we have print "set node info!!!!!!" in the end. and i did see that on the arduino serial monitor
Does this debug message indicate that radio_zwave_set_node_info has been exucuted ? Or did uart_write_byte function fail at this point ... ?
I just reopened issue #51 reversed my previous change and put some more comment on it. I am not sure if the issue is related to this one since both of them relates to discovery problem. But I just reference it here FYI.
Sen,
Please spend some time to check if this issue is related to discovery issue posted lately.
Daniel On 2013/11/01, at 上午6:05, senatorjo notifications@github.com wrote:
I just reopened issue #51 reversed my previous change and put some more comment on it. I am not sure if the issue is related to this one since both of them relates to discovery problem. But I just reference it here FYI.
— Reply to this email directly or view it on GitHub.
Chi-Sheng (Daniel) Shih NEWS Lab, National Taiwan University E-Mail: cshih@csie.ntu.edu.tw
@chishengshih I already changed the code back to its previous version. So if people download the recent version, discovery for more than 1 time will use database instead real nodes... I don't think the problem talked here is mainly because of the problem I fixed since the symptom of the problem I previously caused, would be "discovery for a second time would only discover offline nodes." People here are talking about online nodes.
Anyway, since I already pushed the commit to rebut my previous change. @louisccc could you download my latest change, and if the problem still persist, it would mean these two problems are unrelated to each other. But since my recent found in the database( see issue #51) , you may want to check if nodes are discovered correctly(print the content of "node_infos"). If nodes are discovered correctly , you may also need to make sure they are in the database as well (check "wuclasses()", "wuobjects()", "identity"). I am trying to think of a way to fix #51 in the mean time.
Seems it's not fixed.
@senatorjo I asked Chen-Hsuan to diff the discovery on two different versions of master and see what may be the causes of the failure.
Please use the latest VM to verify it again. It works at my environment.
What's the testing status of this problem now? I cannot see any problem here in simulation, thus I suspect it's due to problems in communication between devices.
This is because we use the new way to distinguish the wudevice from the native device. It will works after we use the latest VM. Please refer to the following design document.
https://docs.google.com/document/d/18Fal-dLsYY8KOvuDPJ_3XezirOCgK4Vvt2P1gkBHPho/edit#
2013/11/5 senatorjo notifications@github.com
What's the testing status of this problem now? I cannot see any problem here in simulation, thus I suspect it's due to problems in communication between devices.
— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/71#issuecomment-27727019 .
This problems seems to be fixed now for non-native devices. For those who still has this problem, be sure to update your pyzwave package installation to include the newest update.
When I try to discover (click node editor), the result is always three "online" wunodes at location "WuKong" with 0 wuclass and 1 wuobject(Light actuator). However, I don't have any "online" wunode, even if I have a online wunode, the wuclass list and wuobject list is incorrect.
Here's the log from the console:
my zwave address: 1 [wkpfcomm] getNodeInfo of node id 2 calling GetRoutingInformation! Send request Node information listening client BASIC_TYPE: Static controller GENERIC_TYPE: Static Controller SPECIFIC_TYPE: Static remote cotnroller [wkpfcomm] getNodeInfo of node id 3 calling GetRoutingInformation! Send request Node information listening client BASIC_TYPE: Static controller GENERIC_TYPE: Static Controller SPECIFIC_TYPE: Static remote cotnroller [wkpfcomm] getNodeInfo of node id 4 calling GetRoutingInformation! Send request Node information listening client BASIC_TYPE: Static controller GENERIC_TYPE: Static Controller SPECIFIC_TYPE: Static remote cotnroller 2 3 4 WuKong#2(0, 0, 0), 3(0, 0, 0), 4(0, 0, 0),