wukong-m2m / wukong-darjeeling

Darjeeling for WuKong
Other
20 stars 17 forks source link

Discover result is incorrect #71

Closed cheweiliang closed 10 years ago

cheweiliang commented 10 years ago

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),

cheweiliang commented 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.

wycc commented 10 years ago

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 .

louisccc commented 10 years ago

Hello @wycc

When I use my wedevice in discover process, it only shows light_actuator in the detail dialog.

2013-10-30 9 46 52

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 !

hanboa commented 10 years ago

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: image

The four wuobjects are always all light actuators no matter what the FBP is drawn in my tests.

wycc commented 10 years ago

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 .

hanboa commented 10 years ago

"radio_zwave_set_node_info()" function is called after I reset the Zwave module and re-match the device node ID.

hanboa commented 10 years ago

The issue of mine as mentioned is resolved but it still cannot discover the components.

louisccc commented 10 years ago

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

2013-11-01 1 49 08

Does this debug message indicate that radio_zwave_set_node_info has been exucuted ? Or did uart_write_byte function fail at this point ... ?

senatorjo commented 10 years ago

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.

chishengshih commented 10 years ago

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

Phone: +886-2-33664927 Fax: +886-2-33663778

senatorjo commented 10 years ago

@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.

louisccc commented 10 years ago

Seems it's not fixed.

chishengshih commented 10 years ago

@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.

wycc commented 10 years ago

Please use the latest VM to verify it again. It works at my environment.

senatorjo commented 10 years ago

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.

wycc commented 10 years ago

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/presentation/d/1wouvyAd3rYhLVVAAEtjkarp26QuFdQvH5ewDYiZ-gDM/edit#slide=id.g1072670f8_055

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 .

senatorjo commented 10 years ago

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.