Closed nielsreijers closed 10 years ago
chishengshih
commented
10 years ago Niels,
When does the VM need to pull the properties from remote nodes?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 11:51, Niels Reijers notifications@github.com wrote:
Now I understand why I never see the request property init messages, but I don't get why this didn't cause more problems before...
— Reply to this email directly or view it on GitHub.
nielsreijers
commented
10 years ago When it boots and has an incoming link. The remote node won't propagate until the value changes, so the node that just started needs to ask for it. It still doesn't seem to work well though, so I'll need to look at it again. But at least it doesn't crash anymore.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.com> wrote:
Niels,
When does the VM need to pull the properties from remote nodes?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 11:51, Niels Reijers notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
Now I understand why I never see the request property init messages, but I don't get why this didn't cause more problems before...
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35227868 .
_
chishengshih
commented
10 years ago The data acquisition model is questionable.
Does the receiver needs to ack after it receives the message?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 12:23, Niels Reijers notifications@github.com wrote:
When it boots and has an incoming link. The remote node won't propagate until the value changes, so the node that just started needs to ask for it. It still doesn't seem to work well though, so I'll need to look at it again. But at least it doesn't crash anymore.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.com> wrote:
Niels,
When does the VM need to pull the properties from remote nodes?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 11:51, Niels Reijers notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
Now I understand why I never see the request property init messages, but I don't get why this didn't cause more problems before...
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35227868 .
_ — Reply to this email directly or view it on GitHub.
nielsreijers
commented
10 years ago Questionable?
Take the bedroom scenario. Node 2 has all the sensors, but node 3 has the actuator. If 3 reboots it needs to know if the actuator should be on or off. Only node 2 knows this. But if the state of the actuator doesn't change, node 2 has no reason to propagate the value. This is why after a reboot, node 3 will ask for the value from node 2.
If node 2 can't be reached, node 3 will retry asking for the value until it either succeeds or until it gets a normal propagation message from node 2. This may happen if we boot the whole network, and node 3 boots up earlier than 2.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.com> wrote:
The data acquisition model is questionable.
- If the node does not exist, the sender should not send the data to the node. I think it only happens that one node leaves and rejoin later. It will happen a lot when the network is not reliable.
- If the new node does pull the data from source, it is not sure if the original component is still active.
Does the receiver needs to ack after it receives the message?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 12:23, Niels Reijers notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
When it boots and has an incoming link. The remote node won't propagate until the value changes, so the node that just started needs to ask for it. It still doesn't seem to work well though, so I'll need to look at it again. But at least it doesn't crash anymore.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.comjavascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
Niels,
When does the VM need to pull the properties from remote nodes?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 11:51, Niels Reijers notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com'); javascript:_e(%7B%7D,'cvml','notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');');>>
wrote:
Now I understand why I never see the request property init messages, but I don't get why this didn't cause more problems before...
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35227868>
.
_
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35228609 .
_
chishengshih
commented
10 years ago Node 3 only needs to pull the data when the threshold component on node 2 changes its output and node 3 is not reachable or down. Since nodes 3 does not know if node 2 changes its output, node 3 pulls the data when it boots.
The scenario I like is the following.
If the sender (Node 2) knows that node 3 is down and does not receive the changed data, it should notify the master or gateway this error. (Z-Wave will send several times on different paths if there is any, and should report that the destination is not reachable after the trials.) The sender can ask for remapping the actuator to another node and re-transmit the data.
What's the difference?
In current model, the sender does not react when the destination is down and, hence, the destination needs to pull the data. The advantage of this approach is that we can ignore transient failure. The disadvantage of this approach is that the destination needs to know who will send data to it, i.e., the reverse links. In addition, the reverse links could be removed or remapped during its down time.
In my opinions, the transient failure on network should be handled by communication protocol, not the application. (Z-wave does handle it by trying different paths.) The application only handles long-term failure. In addition, asking the destination node to keep the reverse links is a work around, not a good solution.
Daniel
On 2014/2/17, at 下午12:54, Niels Reijers notifications@github.com wrote:
Questionable?
Take the bedroom scenario. Node 2 has all the sensors, but node 3 has the actuator. If 3 reboots it needs to know if the actuator should be on or off. Only node 2 knows this. But if the state of the actuator doesn't change, node 2 has no reason to propagate the value. This is why after a reboot, node 3 will ask for the value from node 2.
If node 2 can't be reached, node 3 will retry asking for the value until it either succeeds or until it gets a normal propagation message from node 2. This may happen if we boot the whole network, and node 3 boots up earlier than 2.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.com> wrote:
The data acquisition model is questionable.
- If the node does not exist, the sender should not send the data to the node. I think it only happens that one node leaves and rejoin later. It will happen a lot when the network is not reliable.
- If the new node does pull the data from source, it is not sure if the original component is still active.
Does the receiver needs to ack after it receives the message?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 12:23, Niels Reijers notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
When it boots and has an incoming link. The remote node won't propagate until the value changes, so the node that just started needs to ask for it. It still doesn't seem to work well though, so I'll need to look at it again. But at least it doesn't crash anymore.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.comjavascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
Niels,
When does the VM need to pull the properties from remote nodes?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 11:51, Niels Reijers notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com'); javascript:_e(%7B%7D,'cvml','notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');');>>
wrote:
Now I understand why I never see the request property init messages, but I don't get why this didn't cause more problems before...
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35227868>
.
_
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35228609 .
_ — 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
nielsreijers
commented
10 years ago What if the network has been running for a while, then at some point node 3 reboots for whatever reason. Maybe I had to replace the batteries, maybe there's another reason.
Node 2 won't know, since it doesn't need to send any messages to 3 as long as nothing changes. No propagation failed, since there's nothing to propagate. But node 3 won't know whether the light should be on or off until it asks node 2.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.com> wrote:
Node 3 only needs to pull the data when the threshold component on node 2 changes its output and node 3 is not reachable or down. Since nodes 3 does not know if node 2 changes its output, node 3 pulls the data when it boots.
The scenario I like is the following.
If the sender (Node 2) knows that node 3 is down and does not receive the changed data, it should notify the master or gateway this error. (Z-Wave will send several times on different paths if there is any, and should report that the destination is not reachable after the trials.) The sender can ask for remapping the actuator to another node and re-transmit the data.
What's the difference?
In current model, the sender does not react when the destination is down and, hence, the destination needs to pull the data. The advantage of this approach is that we can ignore transient failure. The disadvantage of this approach is that the destination needs to know who will send data to it, i.e., the reverse links. In addition, the reverse links could be removed or remapped during its down time.
In my opinions, the transient failure on network should be handled by communication protocol, not the application. (Z-wave does handle it by trying different paths.) The application only handles long-term failure. In addition, asking the destination node to keep the reverse links is a work around, not a good solution.
Daniel
On 2014/2/17, at 下午12:54, Niels Reijers notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
Questionable?
Take the bedroom scenario. Node 2 has all the sensors, but node 3 has the actuator. If 3 reboots it needs to know if the actuator should be on or off. Only node 2 knows this. But if the state of the actuator doesn't change, node 2 has no reason to propagate the value. This is why after a reboot, node 3 will ask for the value from node 2.
If node 2 can't be reached, node 3 will retry asking for the value until it either succeeds or until it gets a normal propagation message from node 2. This may happen if we boot the whole network, and node 3 boots up earlier than 2.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.comjavascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
The data acquisition model is questionable.
- If the node does not exist, the sender should not send the data to the node. I think it only happens that one node leaves and rejoin later. It will happen a lot when the network is not reliable.
- If the new node does pull the data from source, it is not sure if the original component is still active.
Does the receiver needs to ack after it receives the message?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 12:23, Niels Reijers notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com'); javascript:_e(%7B%7D,'cvml','notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');');>>
wrote:
When it boots and has an incoming link. The remote node won't propagate until the value changes, so the node that just started needs to ask for it. It still doesn't seem to work well though, so I'll need to look at it again. But at least it doesn't crash anymore.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.comjavascript:_e(%7B%7D,'cvml','notifications@github.com'); javascript:_e(%7B%7D,'cvml','notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');');>>
wrote:
Niels,
When does the VM need to pull the properties from remote nodes?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 11:51, Niels Reijers notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com'); javascript:_e(%7B%7D,'cvml','notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');');>
javascript:_e(%7B%7D,'cvml','notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com'); javascript:_e(%7B%7D,'cvml','notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');');>');>>
wrote:
Now I understand why I never see the request property init messages, but I don't get why this didn't cause more problems before...
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub<
https://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35227868>
.
_
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35228609>
.
_ — 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.twjavascript:_e(%7B%7D,'cvml','cshih@csie.ntu.edu.tw');
Phone: +886-2-33664927 Fax: +886-2-33663778
— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35229684 .
_
chishengshih
commented
10 years ago If there is no state change on node 2, node 3 should not need to pull data from node 2. Why should Node 2 keep the data for any one?
If node 3 needs this value to keep the light on or off, it should store in its local storage when it receives the data.
Daniel
On 2014/2/17, at 下午1:34, Niels Reijers notifications@github.com wrote:
What if the network has been running for a while, then at some point node 3 reboots for whatever reason. Maybe I had to replace the batteries, maybe there's another reason.
Node 2 won't know, since it doesn't need to send any messages to 3 as long as nothing changes. No propagation failed, since there's nothing to propagate. But node 3 won't know whether the light should be on or off until it asks node 2.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.com> wrote:
Node 3 only needs to pull the data when the threshold component on node 2 changes its output and node 3 is not reachable or down. Since nodes 3 does not know if node 2 changes its output, node 3 pulls the data when it boots.
The scenario I like is the following.
If the sender (Node 2) knows that node 3 is down and does not receive the changed data, it should notify the master or gateway this error. (Z-Wave will send several times on different paths if there is any, and should report that the destination is not reachable after the trials.) The sender can ask for remapping the actuator to another node and re-transmit the data.
What's the difference?
In current model, the sender does not react when the destination is down and, hence, the destination needs to pull the data. The advantage of this approach is that we can ignore transient failure. The disadvantage of this approach is that the destination needs to know who will send data to it, i.e., the reverse links. In addition, the reverse links could be removed or remapped during its down time.
In my opinions, the transient failure on network should be handled by communication protocol, not the application. (Z-wave does handle it by trying different paths.) The application only handles long-term failure. In addition, asking the destination node to keep the reverse links is a work around, not a good solution.
Daniel
On 2014/2/17, at 下午12:54, Niels Reijers notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
Questionable?
Take the bedroom scenario. Node 2 has all the sensors, but node 3 has the actuator. If 3 reboots it needs to know if the actuator should be on or off. Only node 2 knows this. But if the state of the actuator doesn't change, node 2 has no reason to propagate the value. This is why after a reboot, node 3 will ask for the value from node 2.
If node 2 can't be reached, node 3 will retry asking for the value until it either succeeds or until it gets a normal propagation message from node
This may happen if we boot the whole network, and node 3 boots up earlier than 2.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.comjavascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
The data acquisition model is questionable.
- If the node does not exist, the sender should not send the data to the node. I think it only happens that one node leaves and rejoin later. It will happen a lot when the network is not reliable.
- If the new node does pull the data from source, it is not sure if the original component is still active.
Does the receiver needs to ack after it receives the message?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 12:23, Niels Reijers notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com'); javascript:_e(%7B%7D,'cvml','notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');');>>
wrote:
When it boots and has an incoming link. The remote node won't propagate until the value changes, so the node that just started needs to ask for it. It still doesn't seem to work well though, so I'll need to look at it again. But at least it doesn't crash anymore.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.comjavascript:_e(%7B%7D,'cvml','notifications@github.com'); javascript:_e(%7B%7D,'cvml','notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');');>>
wrote:
Niels,
When does the VM need to pull the properties from remote nodes?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 11:51, Niels Reijers notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com'); javascript:_e(%7B%7D,'cvml','notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');');>
javascript:_e(%7B%7D,'cvml','notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com'); javascript:_e(%7B%7D,'cvml','notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');');>');>>
wrote:
Now I understand why I never see the request property init messages, but I don't get why this didn't cause more problems before...
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub<
https://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35227868>
.
_
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35228609>
.
_ — 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.twjavascript:_e(%7B%7D,'cvml','cshih@csie.ntu.edu.tw');
Phone: +886-2-33664927 Fax: +886-2-33663778
— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35229684 .
_ — 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
nielsreijers
commented
10 years ago Node 2 (sensor and threshold) has a number of wuobjects that have state, so it's not storing data for any one, but just storing the state of it's local properties.
Node 3 (actuator) has a light actuator object that needs to know if it's on_off property is true or false. So when it boots it needs to get his value from whatever component is connected to the light_actuator's on_off property. This may be a remote component. If it is, it could wait for the next value, but it doesn't know if node 2 has also just started, so it's going to send the value, or if node 2 has been running for a long time, and has already propagated the value to node 3 before node 3 rebooted. If that's the case, node 2 has no reason to propagate the value again until it changes. This is why node 3 will ask node 2 to get the value.
However, it didn't work well until just now for two reasons. One was a bug in the VM that I've just fixed. The other is that the master will generate an initial values table that contains values for properties that are also the destination of a link. I'm not sure if that's desirable. It seems strange to me to define an initial value for a property who's value is supposed to be determined by an external link. I would prefer to remove these initial values from the table.
On Mon, Feb 17, 2014 at 4:50 PM, Chi-Sheng (Daniel) Shih < notifications@github.com> wrote:
If there is no state change on node 2, node 3 should not need to pull data from node 2. Why should Node 2 keep the data for any one?
If node 3 needs this value to keep the light on or off, it should store in its local storage when it receives the data.
Daniel
On 2014/2/17, at 下午1:34, Niels Reijers notifications@github.com wrote:
What if the network has been running for a while, then at some point node 3 reboots for whatever reason. Maybe I had to replace the batteries, maybe there's another reason.
Node 2 won't know, since it doesn't need to send any messages to 3 as long as nothing changes. No propagation failed, since there's nothing to propagate. But node 3 won't know whether the light should be on or off until it asks node 2.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.com> wrote:
Node 3 only needs to pull the data when the threshold component on node 2 changes its output and node 3 is not reachable or down. Since nodes 3 does not know if node 2 changes its output, node 3 pulls the data when it boots.
The scenario I like is the following.
If the sender (Node 2) knows that node 3 is down and does not receive the changed data, it should notify the master or gateway this error. (Z-Wave will send several times on different paths if there is any, and should report that the destination is not reachable after the trials.) The sender can ask for remapping the actuator to another node and re-transmit the data.
What's the difference?
In current model, the sender does not react when the destination is down and, hence, the destination needs to pull the data. The advantage of this approach is that we can ignore transient failure. The disadvantage of this approach is that the destination needs to know who will send data to it, i.e., the reverse links. In addition, the reverse links could be removed or remapped during its down time.
In my opinions, the transient failure on network should be handled by communication protocol, not the application. (Z-wave does handle it by trying different paths.) The application only handles long-term failure. In addition, asking the destination node to keep the reverse links is a work around, not a good solution.
Daniel
On 2014/2/17, at 下午12:54, Niels Reijers <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
Questionable?
Take the bedroom scenario. Node 2 has all the sensors, but node 3 has the actuator. If 3 reboots it needs to know if the actuator should be on or off. Only node 2 knows this. But if the state of the actuator doesn't change, node 2 has no reason to propagate the value. This is why after a reboot, node 3 will ask for the value from node 2.
If node 2 can't be reached, node 3 will retry asking for the value until it either succeeds or until it gets a normal propagation message from node 2. This may happen if we boot the whole network, and node 3 boots up earlier than 2.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.com<javascript:_e(%7B%7D,'cvml',' notifications@github.com');>> wrote:
The data acquisition model is questionable.
- If the node does not exist, the sender should not send the data to the node. I think it only happens that one node leaves and rejoin later. It will happen a lot when the network is not reliable.
- If the new node does pull the data from source, it is not sure if the original component is still active.
Does the receiver needs to ack after it receives the message?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 12:23, Niels Reijers <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com'); <javascript:_e(%7B%7D,'cvml','notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');');>>
wrote:
When it boots and has an incoming link. The remote node won't propagate until the value changes, so the node that just started needs to ask for it. It still doesn't seem to work well though, so I'll need to look at it again. But at least it doesn't crash anymore.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.com<javascript:_e(%7B%7D,'cvml',' notifications@github.com');> <javascript:_e(%7B%7D,'cvml','notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');');>>
wrote:
Niels,
When does the VM need to pull the properties from remote nodes?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 11:51, Niels Reijers < notifications@github.com<javascript:_e(%7B%7D,'cvml',' notifications@github.com');> <javascript:_e(%7B%7D,'cvml','notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');');>
<javascript:_e(%7B%7D,'cvml','notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com'); <javascript:_e(%7B%7D,'cvml','notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');');>');>>
wrote:
Now I understand why I never see the request property init messages, but I don't get why this didn't cause more problems before...
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub<
https://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35227868>
.
_
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub<
https://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35228609>
.
_ — 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<javascript:_e(%7B%7D,'cvml',' cshih@csie.ntu.edu.tw');>
Phone: +886-2-33664927 Fax: +886-2-33663778
— Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35229684>
.
_ — 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
— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35238250 .
_
nielsreijers
commented
10 years ago Here's a simple scenario to illustrate the point. If you unpack simple.zip in the simulator_scenarios directory and run java -jar network_ui.jar -c ../../simulator_scenarios/simple/networkconfig.xml from the wukong/tools/network_ui directory, it should start the network with an application already deployed.
The application is simple, just a PIR sensor on node 2, connected to a light actuator on node 3. When the network starts, node 2 will sense a value of 1 and propagate this to node 3. Now, if we restart node 3 by double clicking on it twice (kill/start), it will process it's initial value list, which somehow contains a value for the light actuator (0). So it will turn off the light actuator, and our network is in an inconsistent state where the sensor output is true, but the actuator is off. If we remove the initial value for the light actuator from the table, then node 3 will ask node 2 what the value should be (the property pull)
You can see this by running the network in the other archive, where I've manually removed the initial value from the table. When you restart node 3 there, you can see it ask node 2 for the right value.
Best, Niels
On Mon, Feb 17, 2014 at 5:12 PM, Niels Reijers nielsreijers@gmail.comwrote:
Node 2 (sensor and threshold) has a number of wuobjects that have state, so it's not storing data for any one, but just storing the state of it's local properties.
Node 3 (actuator) has a light actuator object that needs to know if it's on_off property is true or false. So when it boots it needs to get his value from whatever component is connected to the light_actuator's on_off property. This may be a remote component. If it is, it could wait for the next value, but it doesn't know if node 2 has also just started, so it's going to send the value, or if node 2 has been running for a long time, and has already propagated the value to node 3 before node 3 rebooted. If that's the case, node 2 has no reason to propagate the value again until it changes. This is why node 3 will ask node 2 to get the value.
However, it didn't work well until just now for two reasons. One was a bug in the VM that I've just fixed. The other is that the master will generate an initial values table that contains values for properties that are also the destination of a link. I'm not sure if that's desirable. It seems strange to me to define an initial value for a property who's value is supposed to be determined by an external link. I would prefer to remove these initial values from the table.
On Mon, Feb 17, 2014 at 4:50 PM, Chi-Sheng (Daniel) Shih < notifications@github.com> wrote:
If there is no state change on node 2, node 3 should not need to pull data from node 2. Why should Node 2 keep the data for any one?
If node 3 needs this value to keep the light on or off, it should store in its local storage when it receives the data.
Daniel
On 2014/2/17, at 下午1:34, Niels Reijers notifications@github.com wrote:
What if the network has been running for a while, then at some point node 3 reboots for whatever reason. Maybe I had to replace the batteries, maybe there's another reason.
Node 2 won't know, since it doesn't need to send any messages to 3 as long as nothing changes. No propagation failed, since there's nothing to propagate. But node 3 won't know whether the light should be on or off until it asks node 2.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.com> wrote:
Node 3 only needs to pull the data when the threshold component on node 2 changes its output and node 3 is not reachable or down. Since nodes 3 does not know if node 2 changes its output, node 3 pulls the data when it boots.
The scenario I like is the following.
If the sender (Node 2) knows that node 3 is down and does not receive the changed data, it should notify the master or gateway this error. (Z-Wave will send several times on different paths if there is any, and should report that the destination is not reachable after the trials.) The sender can ask for remapping the actuator to another node and re-transmit the data.
What's the difference?
In current model, the sender does not react when the destination is down and, hence, the destination needs to pull the data. The advantage of this approach is that we can ignore transient failure. The disadvantage of this approach is that the destination needs to know who will send data to it, i.e., the reverse links. In addition, the reverse links could be removed or remapped during its down time.
In my opinions, the transient failure on network should be handled by communication protocol, not the application. (Z-wave does handle it by trying different paths.) The application only handles long-term failure. In addition, asking the destination node to keep the reverse links is a work around, not a good solution.
Daniel
On 2014/2/17, at 下午12:54, Niels Reijers <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
Questionable?
Take the bedroom scenario. Node 2 has all the sensors, but node 3 has the actuator. If 3 reboots it needs to know if the actuator should be on or off. Only node 2 knows this. But if the state of the actuator doesn't change, node 2 has no reason to propagate the value. This is why after a reboot, node 3 will ask for the value from node 2.
If node 2 can't be reached, node 3 will retry asking for the value until it either succeeds or until it gets a normal propagation message from node 2. This may happen if we boot the whole network, and node 3 boots up earlier than 2.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.com<javascript:_e(%7B%7D,'cvml',' notifications@github.com');>> wrote:
The data acquisition model is questionable.
- If the node does not exist, the sender should not send the data to the node. I think it only happens that one node leaves and rejoin later. It will happen a lot when the network is not reliable.
- If the new node does pull the data from source, it is not sure if the original component is still active.
Does the receiver needs to ack after it receives the message?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 12:23, Niels Reijers <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com'); <javascript:_e(%7B%7D,'cvml','notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');');>>
wrote:
When it boots and has an incoming link. The remote node won't propagate until the value changes, so the node that just started needs to ask for it. It still doesn't seem to work well though, so I'll need to look at it again. But at least it doesn't crash anymore.
On Monday, 17 February 2014, Chi-Sheng (Daniel) Shih < notifications@github.com<javascript:_e(%7B%7D,'cvml',' notifications@github.com');> <javascript:_e(%7B%7D,'cvml','notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');');>>
wrote:
Niels,
When does the VM need to pull the properties from remote nodes?
Chi-Sheng Shih National Taiwan University
On 2014/2/17, at 11:51, Niels Reijers < notifications@github.com<javascript:_e(%7B%7D,'cvml',' notifications@github.com');> <javascript:_e(%7B%7D,'cvml','notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');');>
<javascript:_e(%7B%7D,'cvml','notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com'); <javascript:_e(%7B%7D,'cvml','notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');');>');>>
wrote:
Now I understand why I never see the request property init messages, but I don't get why this didn't cause more problems before...
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub<
https://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35227868>
.
_
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub<
https://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35228609>
.
_ — 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<javascript:_e(%7B%7D,'cvml',' cshih@csie.ntu.edu.tw');>
Phone: +886-2-33664927 Fax: +886-2-33663778
— Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35229684>
.
_ — 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
— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/133#issuecomment-35238250 .
_
_
Now I understand why I never see the request property init messages, but I don't get why this didn't cause more problems before...