matt (support) wrote:The sendRaw commands currently do not provide access to hop fields. Can you describe exactly how iHealth uses those? I'll consider adding them based on what it needs and how it uses them...
First of all, even without the ability to restrict the max hops, this is not a show stopper. All it does is increase the uncertainty in an diagnosis this tool can make.
I'm not quite sure if iHealth is actually writing the packet to constrain the number of hops, but being able to do so can be an important diagnostic tool.
Correction - iHealth is not using the actual hops, the *'s are based on the mean average of the response time.
- Code: Select all
$mean = $sum / $num; # The average response time
printf REPORT "%42s\t%3d\t%1.3f\t%1.3f\t%1.3f\t%1.3f\t%s\n", $report->{$address}->{devicename}, $num_success, $min, $mean, $max, $sd, ('*' x ($mean*20));
The issue is that I can generate a estimated response time for the device(s), but some devices are generating numbers that are significantly too high. From what I see in the developers guide, 633 ms should be the highest possible for an extended message with 3 hops, and an ack.
Method 1 -
I can take the actual time the signal took, and then using the guidelines that smart home gives us in the developers guide try to match it to the rough time that 3 hops would take. But I'm seeing a few signals in the 700+ ms time frame. That's above 3 hops. So obviously some resends are being factored in for that device. So time isn't a reliable indicator of the number of hops.
The timing for each hop varies depending on the Extended / Standard message length, and if an Ack is requested. I don't see any way in the indigo device database to tell if a device uses extended or standard message lengths, so I don't have a reliable method to decide on which set of timings I should be basing the hop timing on.
The main issue is that we can make estimations, but we can't verify the data behind the estimation.
If a device is taking 326 ms, is it because it's a Standard message with 2 hops, and an ACK (~300 ms)? Or is it an Extended message with 1 hop, an Ack, and 1 retry? Does this really matter? Well, maybe? The question is do we want this to be able to potentially diagnose potential signal path issues?
Method 2 -
The other way is to send a command, and set it to 0 hops max. If the signal is ack'd, then we know it's reaching a dual band RF device, or a extremely close device. If it's not ack'd, we increment the max hops, until the device ack's. Then we know how many hops away it is. Once we know how many hops away it is, we can compare the actual ack time, to the guidelines that Smarthome gives us.
If it is significantly higher, than we can say that there is something funny with that signal path (e.g. multiple retries in addition to additional hops).In addition, I don't see anyway to tell if a device uses extended or standard message sizes, so it's very hard to tell what timing I should be using for an hop.
Now while we still have the issue of the standard vs extended message length, the issue is fairly moot since we know the actual number of hops the signal took. Let's take the 326 ms example above.
We know it was 2 hops, and took 326 ms, we know that we requested ACKs. So is it Greater than 300 ms, but less than 400ms? Then it fits the profile for a standard message w/ack. Does it fit within 316ms and 475 ms? It also fit's the Extended cycle times.
But if we know it was 2 hops, and is 615 ms? We know there some signal interference, and/or issues with the signal path.