[OpenTRV-dev] Good communications generally except NO binary stats from leaf for 2 weeks

[gary.gladman at talktalk.net]

Hi,

My Setup:
@2532: hub in living room on mantelpiece adjacent to TV controlling FHT8V valve
@1F2A: leaf in dining room next to stereo speaker controlling FHT8V valve (only internal brick wall and ~3m between leaf and hub)

I have been analysing the output from my hub for a continuous period just over three weeks. By and large communications on all fronts (OpenTRV-FHT8V, Leaf-Hub, Hub-Pi(home grown)) was good and very reliable.

However, two weeks ago the Leaf-Hub binary stats and only the binary stats abruptly stopped occurring except for 2 one off stats examples and some one off stats on Leaf resets. I performed increasingly long power downs (up to a day) then power on resets at the Leaf in an attempt to jar the system out of this syndrome but all with no success.

I have tried everything I can think of without resetting the hub to resolve the issue. I have not reset the hub so far to establish to some degree how long this scenario might persist without interference, plus given the lack of success of resetting the leaf I doubt whether a hub reset will work in any case.

My Hub and Leaf share the last three bits of their FHT8V identity meaning they run on the same duration timing cycles (116s). As I have speculated before, and since my radio comms is essentially good, I can only assume that somehow Hub and Leaf FHT8V transmissions have alligned and overlapped preventing the hub from perceiving the leaf though each respective FHT8V seems to continue to have good communication with its respective OpenTRV. I have little if any hard evidence to support this assumption but I cannot think of any other explanation.

I suspect that this problem will arise in 1/8 of Hub(FHT8V)-Leaf(FHT8V)(*1) systems or n/8 of Hub(FHT8V)-Leaf(FHT8V)(*n) systems where the hub and any leaf "share" id's. This is a significant proportion increasing rapidly as the population of leaves increases. I am surprised that more systems are not seeing or suffering from this problem. I suspect in n>1 systems the problem can typically be solved/mitigated by swapping the Hub's FHT8V with a leaf that does not share id's so that only leaves "share" id's though they may occlude one another from the Hub's perspective which may of course still be a significant problem.

Given that my system is largely out of commission and has been for two weeks with no forseeable resolution this seems pretty serious. In the wild this issue is going to be a fairly common experience at some time especially in small starter systems which users are going to expect to just work. Can anyone think of a simple reliable external fix or workaround, otherwise can anyone think of (and make?) an internal fix that I can trial?

Regards

Hub Pi Analysis (covers three week period):
$ ./opentrv.awk /tmp/opentrv
00: 19 2
01: 35 2
02: 20
03: 22
04: 19
05: 19 2
06: 34 4
07: 22 5
08: 21
09: 21
10: 19
11: 14
12: 22 2
13: 19
14: 21 2
15: 20 2
16: 25 2
17: 17 2
18: 22
19: 21 2
20: 26 2
21: 14
22: 23
23: 18
1: 469 - 23;03:42
2: 16 - 22;20:03
3: 1 - 9;06:49
4: 1 - 9;06:01
5: 1 - 9;07:43
23;07:10 41 488 (469 16 1 1 1  ) :23;07:20 12925 13429 127174 0.305309% 3.75307% 3.49244% 3.41151% =23;07:21 F23;07:20 16737 @22;12:41 4678 72.0499%

- In first week number of local stats loss was ~3% (however now 72.0499% - due to "total" loss since end of first week (("one off") last seen on day 22 at 12:41)).- JSON stats loss similar at 3.75307% (however unchanged throughout) (demonstrating an independent distribution).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20151024/954d343e/attachment.html>