I was deploying a simple light sensor-threshold-light actuator app. Node 2 has a light sensor and a threshold wuclass, node 3 has a light actuator.

When I deploy for the first time, the mapper somehow decides to deploy a virtual threshold class to node 2? But there's a native one available, so it should just use that one. The funny thing is that when I deploy the app a second time, so there's already a threshold instance on node 2 present, then it will use the native class and no virtual class is deployed.

This is due to the line 144 of mapper.py

        elif has_wuclass:
            # create a new wuobject from existing wuclasses published

from node (could be virtual) sensorNode = locTree.sensor_dict[node.id] sensorNode.initPortList(forceInit = False) port_number = sensorNode.reserveNextPort() _wuobject = WuObjectFactory.createWuObject(wuclassdef, node, portnumber,True) print "appending vitual for", node.id component.instances.append(wuobject) pass # pass on to the next candidates elif node.type != 'native' and node.type != 'picokong' and wuclassdef.virtual==True:

create a new virtual wuobject where the node

            # doesn't have the wuclass for it
            # TODO: should check for existance of virtual impl
            # as indicated by the virtual attribute
            # (will be changed to a more appropriate name later)
            sensorNode = locTree.sensor_dict[node.id]
            sensorNode.initPortList(forceInit = False)
            port_number = sensorNode.reserveNextPort()
            _wuobject = WuObjectFactory.createWuObject(wuclassdef,

node, portnumber, True)

The last argument of the foirst createWuObject should be false since it is nor virtual.

2014-03-05 17:08 GMT+08:00 Niels Reijers notifications@github.com:

I was deploying a simple light sensor-threshold-light actuator app. Node 2 has a light sensor and a threshold wuclass, node 3 has a light actuator.

When I deploy for the first time, the mapper somehow decides to deploy a virtual threshold class to node 2? But there's a native one available, so it should just use that one. The funny thing is that when I deploy the app a second time, so there's already a threshold instance on node 2 present, then it will use the native class and no virtual class is deployed.

Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/140 .

Phone: 886-2-23516989 Mobile: 0919816155

Does that solve it? (if so, why not just fix it instead of describing how to fix it?) I'm not familiar with the mapper, but it seems to loop over the devices. If you change this to False, that does seem to make it not virtual. But what if the first node considered doesn't have the native Threshold, but the second does? It would still create a virtual one on the first node instead of using the native one on the second, or am I reading it wrong?

On Wed, Mar 5, 2014 at 9:31 PM, Yu-Chung Wang notifications@github.comwrote:

This is due to the line 144 of mapper.py

elif has_wuclass:

create a new wuobject from existing wuclasses published

from node (could be virtual) sensorNode = locTree.sensor_dict[node.id] sensorNode.initPortList(forceInit = False) port_number = sensorNode.reserveNextPort() _wuobject = WuObjectFactory.createWuObject(wuclassdef, node, portnumber,True) print "appending vitual for", node.id component.instances.append(wuobject) pass # pass on to the next candidates elif node.type != 'native' and node.type != 'picokong' and wuclassdef.virtual==True:

create a new virtual wuobject where the node

doesn't have the wuclass for it

TODO: should check for existance of virtual impl

as indicated by the virtual attribute

(will be changed to a more appropriate name later)

sensorNode = locTree.sensor_dict[node.id] sensorNode.initPortList(forceInit = False) port_number = sensorNode.reserveNextPort() _wuobject = WuObjectFactory.createWuObject(wuclassdef, node, portnumber, True)

The last argument of the foirst createWuObject should be false since it is nor virtual.

2014-03-05 17:08 GMT+08:00 Niels Reijers notifications@github.com:

I was deploying a simple light sensor-threshold-light actuator app. Node 2 has a light sensor and a threshold wuclass, node 3 has a light actuator.

When I deploy for the first time, the mapper somehow decides to deploy a virtual threshold class to node 2? But there's a native one available, so it should just use that one. The funny thing is that when I deploy the app a second time, so there's already a threshold instance on node 2 present, then it will use the native class and no virtual class is deployed.

Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/140> .

YC

Phone: 886-2-23516989 Mobile: 0919816155

Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/140#issuecomment-36741844 .

I do not know the answer and have no time to check it now. This is why I post it. You may try it or ask Sen to check it.

2014-03-05 23:42 GMT+08:00 Niels Reijers notifications@github.com:

Does that solve it? (if so, why not just fix it instead of describing how to fix it?) I'm not familiar with the mapper, but it seems to loop over the devices. If you change this to False, that does seem to make it not virtual. But what if the first node considered doesn't have the native Threshold, but the second does? It would still create a virtual one on the first node instead of using the native one on the second, or am I reading it wrong?

On Wed, Mar 5, 2014 at 9:31 PM, Yu-Chung Wang <notifications@github.com

wrote:

This is due to the line 144 of mapper.py

elif has_wuclass:

create a new wuobject from existing wuclasses published

from node (could be virtual) sensorNode = locTree.sensor_dict[node.id] sensorNode.initPortList(forceInit = False) port_number = sensorNode.reserveNextPort() _wuobject = WuObjectFactory.createWuObject(wuclassdef, node, portnumber,True)

print "appending vitual for", node.id component.instances.append(wuobject) pass # pass on to the next candidates elif node.type != 'native' and node.type != 'picokong' and wuclassdef.virtual==True:

create a new virtual wuobject where the node

doesn't have the wuclass for it

TODO: should check for existance of virtual impl

as indicated by the virtual attribute

(will be changed to a more appropriate name later)

sensorNode = locTree.sensor_dict[node.id] sensorNode.initPortList(forceInit = False) port_number = sensorNode.reserveNextPort() _wuobject = WuObjectFactory.createWuObject(wuclassdef, node, portnumber, True)

The last argument of the foirst createWuObject should be false since it is nor virtual.

2014-03-05 17:08 GMT+08:00 Niels Reijers notifications@github.com:

I was deploying a simple light sensor-threshold-light actuator app. Node 2 has a light sensor and a threshold wuclass, node 3 has a light actuator.

When I deploy for the first time, the mapper somehow decides to deploy a virtual threshold class to node 2? But there's a native one available, so it should just use that one. The funny thing is that when I deploy the app a second time, so there's already a threshold instance on node 2 present, then it will use the native class and no virtual class is deployed.

Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/140>

.

YC

Phone: 886-2-23516989 Mobile: 0919816155

Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/140#issuecomment-36741844

.

_

Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/140#issuecomment-36755227 .

2014-03-05 23:42 GMT+08:00 Niels Reijers notifications@github.com:

Does that solve it? (if so, why not just fix it instead of describing how to fix it?) I'm not familiar with the mapper, but it seems to loop over the devices. If you change this to False, that does seem to make it not virtual. But what if the first node considered doesn't have the native Threshold, but the second does? It would still create a virtual one on the first node instead

In this case, the mapper should prefer the native one over the virtual one.

Actually, there is another issue in the current mapper. It should not give the wuobjects created by the wuclasses higher priority. For now, it's higher since we will see the wuobjects and skip the wudevices with Threshold wuclasses. However, this is smaller issue since it does not hurt. However, if we implement more optimization in the future, we should implement this correctly so that the result of the optimization will be consistent in every mapping.

of using the native one on the second, or am I reading it wrong?

On Wed, Mar 5, 2014 at 9:31 PM, Yu-Chung Wang <notifications@github.com

wrote:

This is due to the line 144 of mapper.py

elif has_wuclass:

create a new wuobject from existing wuclasses published

from node (could be virtual) sensorNode = locTree.sensor_dict[node.id] sensorNode.initPortList(forceInit = False) port_number = sensorNode.reserveNextPort() _wuobject = WuObjectFactory.createWuObject(wuclassdef, node, portnumber,True)

print "appending vitual for", node.id component.instances.append(wuobject) pass # pass on to the next candidates elif node.type != 'native' and node.type != 'picokong' and wuclassdef.virtual==True:

create a new virtual wuobject where the node

doesn't have the wuclass for it

TODO: should check for existance of virtual impl

as indicated by the virtual attribute

(will be changed to a more appropriate name later)

sensorNode = locTree.sensor_dict[node.id] sensorNode.initPortList(forceInit = False) port_number = sensorNode.reserveNextPort() _wuobject = WuObjectFactory.createWuObject(wuclassdef, node, portnumber, True)

The last argument of the foirst createWuObject should be false since it is nor virtual.

2014-03-05 17:08 GMT+08:00 Niels Reijers notifications@github.com:

I was deploying a simple light sensor-threshold-light actuator app. Node 2 has a light sensor and a threshold wuclass, node 3 has a light actuator.

When I deploy for the first time, the mapper somehow decides to deploy a virtual threshold class to node 2? But there's a native one available, so it should just use that one. The funny thing is that when I deploy the app a second time, so there's already a threshold instance on node 2 present, then it will use the native class and no virtual class is deployed.

Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/140>

.

YC

Phone: 886-2-23516989 Mobile: 0919816155

Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/140#issuecomment-36741844

.

_

Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/140#issuecomment-36755227 .

I have TA sessions all day today since 8am. I'll look into it this evening.

Sen

On Wed, Mar 5, 2014 at 3:45 PM, Yu-Chung Wang notifications@github.comwrote:

2014-03-05 23:42 GMT+08:00 Niels Reijers notifications@github.com:

Does that solve it? (if so, why not just fix it instead of describing how to fix it?) I'm not familiar with the mapper, but it seems to loop over the devices. If you change this to False, that does seem to make it not virtual. But what if the first node considered doesn't have the native Threshold, but the second does? It would still create a virtual one on the first node instead

In this case, the mapper should prefer the native one over the virtual one.

Actually, there is another issue in the current mapper. It should not give the wuobjects created by the wuclasses higher priority. For now, it's higher since we will see the wuobjects and skip the wudevices with Threshold wuclasses. However, this is smaller issue since it does not hurt. However, if we implement more optimization in the future, we should implement this correctly so that the result of the optimization will be consistent in every mapping.

of using the native one on the second, or am I reading it wrong?

On Wed, Mar 5, 2014 at 9:31 PM, Yu-Chung Wang <notifications@github.com

wrote:

This is due to the line 144 of mapper.py

elif has_wuclass:

create a new wuobject from existing wuclasses published

from node (could be virtual) sensorNode = locTree.sensor_dict[node.id] sensorNode.initPortList(forceInit = False) port_number = sensorNode.reserveNextPort() _wuobject = WuObjectFactory.createWuObject(wuclassdef, node, portnumber,True)

print "appending vitual for", node.id component.instances.append(wuobject) pass # pass on to the next candidates elif node.type != 'native' and node.type != 'picokong' and wuclassdef.virtual==True:

create a new virtual wuobject where the node

doesn't have the wuclass for it

TODO: should check for existance of virtual impl

as indicated by the virtual attribute

(will be changed to a more appropriate name later)

sensorNode = locTree.sensor_dict[node.id] sensorNode.initPortList(forceInit = False) port_number = sensorNode.reserveNextPort() _wuobject = WuObjectFactory.createWuObject(wuclassdef, node, portnumber, True)

The last argument of the foirst createWuObject should be false since it is nor virtual.

2014-03-05 17:08 GMT+08:00 Niels Reijers notifications@github.com:

I was deploying a simple light sensor-threshold-light actuator app. Node 2 has a light sensor and a threshold wuclass, node 3 has a light actuator.

When I deploy for the first time, the mapper somehow decides to deploy a virtual threshold class to node 2? But there's a native one available, so it should just use that one. The funny thing is that when I deploy the app a second time, so there's already a threshold instance on node 2 present, then it will use the native class and no virtual class is deployed.

Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/140>

.

YC

Phone: 886-2-23516989 Mobile: 0919816155

Reply to this email directly or view it on GitHub<

https://github.com/wukong-m2m/wukong-darjeeling/issues/140#issuecomment-36741844

.

_

Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/140#issuecomment-36755227

.

Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/140#issuecomment-36809150 .

Behaviour is back after b93eebe1d588d94facb57f9a4da270e77dec7fe4

This is my understanding of the error. Actually, there is a confusion in display about what is virtual wuclass. In the current display, any wuobject created by wuclass (virtual, native) will be called virtual wuclass. Let me see whether this will fix the bug here.

I don't get what does it mean by blue color. So I use blue for virtual wuobjs, green for native wuobjs. Yellow is no longer used.

wukong-m2m / wukong-darjeeling

Mapper uses virtual class when a native one is available #140

create a new virtual wuobject where the node

create a new wuobject from existing wuclasses published

create a new virtual wuobject where the node

doesn't have the wuclass for it

TODO: should check for existance of virtual impl

as indicated by the virtual attribute

(will be changed to a more appropriate name later)

create a new wuobject from existing wuclasses published

create a new virtual wuobject where the node

doesn't have the wuclass for it

TODO: should check for existance of virtual impl

as indicated by the virtual attribute

(will be changed to a more appropriate name later)

create a new wuobject from existing wuclasses published

create a new virtual wuobject where the node

doesn't have the wuclass for it

TODO: should check for existance of virtual impl

as indicated by the virtual attribute

(will be changed to a more appropriate name later)

create a new wuobject from existing wuclasses published

create a new virtual wuobject where the node

doesn't have the wuclass for it

TODO: should check for existance of virtual impl

as indicated by the virtual attribute

(will be changed to a more appropriate name later)