[OpenTRV-interest] Stats from remote units

Wed Nov 12 20:45:35 GMT 2014

Hi Damon

Thanks for the info and sorry for no reply the past 24 hours. I've not
had time to absorb all the information that you provided (but I'll be
working on it), and for this message I'll stick mostly to questions
about House Codes.

I don't know how I didn't figure out that the first values after the
"@" are the hex representation of the device house code ...

Regardless, I now have enough information to amend my fhem code to the
two-stage model, so that I have:

* A stage-one definition for the board that I am connected to
* One or more stage-two definitions for remote devices from which I
may receive data.

I'm already logging data from the remote devices, but currently it's
associated with the stage-one board. I just need some time to work on
the code, hopefully tomorrow.

I have forgotten what House Code that my Conrad Valve has. I think I
wrote it down somewhere, fingers crossed I can find it. I might have
misunderstood the relationship that is supposed to exist between my
devices (so that, for instance, they don't clash with any belonging to
my neighbour).

I had *assumed* that there should be some common element between
devices within the same house; perhaps I'm completely wrong about
that? This write-up suggests that the (FHT) House Codes are arbitrary
and different for every device:

http://russellallen.info/post/2010/10/28/FHEM-Setup-on-Windows-Home-Server-Part-2-of-2.aspx

With definitions like:
define bathroom FHT 1122
define bedroom FHT 3344

So, my definitions will be something like:

define OpenTRVboiler OpenTRV 9375
define OpenTRVboard2 OpenTRV_FHT 9376

Where:

"OpenTRVboiler" is my arbitrary name for my board #1, connected to my
PC and acting as if it were controlling my boiler
"OpenTRV" is my definition type for directly connected OpenTRV devices
"OpenTRVboard2" is my arbitrary name for my board #2, battery powered
and not connected to the PC.
"OpenTRV_FHT" is my definition type for remote devices that I may
receive data from *via* an "OpenTRV" device (see above)
And "9375" and "9376" are the unique House Codes reported by the two
devices in question (or, I could use the hex representations)

Question 1:

Is it true to say that the data that I might receive from remote
devices is FHT-type data ... not exactly sure how to express that; I
suppose that the FHT-ness is the RF protocol (and this is the only
protocol that the openTRV devices understand currently)?

Question 2:

I think I may have set one of my boards to have the same House Code as
my Conrad Valve. Hence, if there is any data that I might be receiving
from it, it may be that I'm not aware of it because I am assuming that
it is data from the board.

So: should all my devices have different House Codes?

Question 3:

What is the nature of the data that is exchanged between the OpenTRV
board and the Conrad Valve? Is it only one-directional, with the valve
acting on commands to open or close? Or does the valve also return
data such as the open percentage?

On 11 November 2014 09:23, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:
> Hi again!
>
> On 10 Nov 2014, at 19:43, Alasdair Macdonald <EMAIL ADDRESS HIDDEN> wrote:
>
>> Hi Damon
>>
>> I typed "X 0" into both boards.
>>
>> Now, in my locally connected "boiler" board, I get "X0" in my
>> semicolon separated data:
>>
>>> X 0
>> =F0%@17C2;ID3EB;V3315;X0;L463;T16 8 W255 0 F255 0 W255 0 F255 0;S12 12
>> 24 cff;O3;C2;HC93 74 s
>>
>> Later:
>>
>> 1138:10:88 FHT8V TX
>> Bare stats TX
>> RCfH0
>> @5D4A;T20C1;L115;O2
>> 1140:6:76 FHT8V TX
>> @5D4B;T20C0;L19;O2
>> 1140:40:10 CfH 93 75
>> RCfH1
>> Boiler on, s left: 106
>> =F0%@20C1;ID3EB;V3315;X0;L472;T19 0 W255 0 F255 0 W255 0 F255 0;S12 12
>> 24 cff;O2;C2;HC93 74
>>
>>>
>> @5D4B;T20C1;L19;O2
>> Boiler on, s left: 46
>> =F0%@20C2;ID3EB;V3315;X0;L476;T19 1 W255 0 F255 0 W255 0 F255 0;S12 12
>> 24 cff;O2;C2;HC93 74
>>
>>>
>> 1142:2:88 FHT8V TX
>> Bare stats TX
>> RCfH0
>> @5D4A;T20C2;L119;O2
>> 1143:58:76 FHT8V TX
>> @5D4B;T20C1;L19;O2
>> 1144:34:11 CfH 93 75
>> RCfH1
>> Boiler on, s left: 100
>> =F0%@20C2;ID3EB;V3315;X0;L475;T19 4 W255 0 F255 0 W255 0 F255 0;S12 12
>> 24 cff;O2;C2;HC93 74
>>
>>>
>> @5D4B;T20C1;L20;O2
>> 1145:54:88 FHT8V TX
>> Boiler on, s left: 40
>> =F0%@20C3;ID3EB;V3315;X0;L460;T19 5 W255 0 F255 0 W255 0 F255 0;S12 12
>> 24 cff;O2;C2;HC93 74
>>
>>>
>> Bare stats TX
>> RCfH0
>> @5D4A;T20C3;L115;O2
>> Bare stats TX
>> 1147:50:76 FHT8V TX
>> !RXerr F3
>> 1149:46:76 FHT8V TX
>> =F0%@20C1;ID3EB;V3315;X0;L459;T19 9 W255 0 F255 0 W255 0 F255 0;S12 12
>> 24 cff;C2;HC93 74
>>
>> So there are lots of new line formats here; I know how to read some of
>> them, but not all.
>>
>> I figured out (Control.cpp) that "RCfH" is "Remote Call for Heat", and
>> I may see "RCfH1" or "RCfH0". When there is call for heat, I assume
>> that "Boiler on, s left:" is reporting the (minimum) number of
>> *seconds* that the boiler should remain on?
>
> Yes.
>
> Now some of those are just in the current version and with the DEBUG flag set, so you should not rely on those.
>
> Only lines beginning with ‘=‘, ‘@‘ and ‘{‘ are likely to be supported in production.
>
> Note also that to reduce load at the listener in Java I may well add a batched/queued mode where the ‘@‘ and ‘{‘ lines are not issued asynchronously, but are queued and only released when requested by the server/listener explicitly.  I might get to that today if I’m very lucky.
>
> But I think that the default will be to spit out the ‘=‘, ‘@‘ and ‘{‘ lines unprompted as now.
>
>> I was already receiving the lines that reference "FHT8V" explicitly,
>> and I believe that they come from the Conrad Valve. I also believe
>> that the first two numbers are a time, but I'm starting to be
>> uncertain.
>>
>> In:
>>> 970:14:73 FHT8V SYNC FINAL
>>
>> I believe that 970:14 is a time reported by the FHT8V, and I thought
>> that 73 was part of its house code.
>
> That 970:14:73 is simply a debug-mode timestamp.
>
>>
>> Here are the FHT8V lines (above) all in one block:
>>
>> 1138:10:88 FHT8V TX
>> 1140:6:76 FHT8V TX
>> 1142:2:88 FHT8V TX
>> 1143:58:76 FHT8V TX
>> 1145:54:88 FHT8V TX
>> 1147:50:76 FHT8V TX
>> 1149:46:76 FHT8V TX
>>
>> So the first two number are minutes and seconds? ... what's the third
>> number - part of the device's house code? And what does it mean, that
>> we have received a message from the device? I see that this data is
>> output on line 689 in FHT8V_Wireless_Rad_Valve.cpp, but I can't tell
>> if there’s useful data that has been received but not shown, or what.
>
>
> The relevant code that generates these timestamps is in Serial.cpp and is:
>
>
> #ifdef DEBUG // Don't emit debug-support code unless in DEBUG.
>
> // Print timestamp with no newline in format: MinutesSinceMidnight:Seconds:SubCycleTime
> void _debug_serial_timestamp()
>   {
>   const bool neededWaking = powerUpSerialIfDisabled();
>   // Grab time values ASAP, fastest-incrementing first.
>   // TODO: could lock out interrupts to capture atomically.
>   const uint8_t ss = getSubCycleTime();
>   const uint8_t s = getSecondsLT();
>   const uint16_t m = getMinutesSinceMidnightLT();
>   Serial.print(m);
>   Serial.print(':'); Serial.print(s);
>   Serial.print(':'); Serial.print(ss);
>   _flush();
>   if(neededWaking) { powerDownSerial(); }
>   }
>
> #endif
>
>
> So the three parts are:
>   * minutes since midnight (or at least since the s/w 24h clock rolled)
>   * seconds
>   * parts of a second [0,255]
>
>
>
>
>
>>
>>
>>
>>> 1144:34:11 CfH 93 75
>>
>> This must be a "Call for Heat" with the House code ... in this case,
>> it's my board #2, which I set to House Code 93 75.
>>
>>
>> Now, the lines that begin with "@", which I wasn't receiving before:
>>
>> @5D4A;T20C1;L115;O2
>> @5D4B;T20C0;L19;O2
>> @5D4B;T20C1;L19;O2
>> @5D4A;T20C2;L119;O2
>> @5D4B;T20C1;L19;O2
>> @5D4B;T20C1;L20;O2
>> @5D4A;T20C3;L115;O2
>>
>> In OpenTRV grammar, "T" normally prefixes time; "L" is for light and O
>> for occupancy. I'm receiving messages that begin with "@5D4A;" or
>> "@5D4B;". How do I interpret these lines?
>
>
> I have tried but failed to be consistent with the letter usage between the ‘@‘ and ‘=‘ records.  The JSON style should match the ‘@‘ usage.
>
> The ‘@‘ records have semi-colon-separated field with the leading character giving the field/sensor type, so ‘@‘ gives the ID, ‘O’ occupancy, etc.
>
> The definitive of types/letters is currently in this Java enum:
>
> CommonSensorLabels
>
> javasrc/uk/org/opentrv/comms/util/CommonSensorLabels.java
>
> and the details of parsing them is in:
>
> ParsedRemoteStatsRecord
>
> Note that the format of the data section depends on context, but for both the ‘=‘ and ‘@‘ formats the temperatures is given either as nn Celcius or nnCh where nn is the whole degrees and h the hex digit after the point to represent 16ths of a degree Celcius.  Here L is light constrained to the range [1,254] and O is occupancy as a 2-digit value with 0 meaning unknown/not disclosed, 1 unoccupied, 2 probably occupied, 3 likely occupied.  See:
>
> Messaging.h
>
> // Full Stats Message (short ID)
> // =============================
>
> This many evolve if I decide to jam RH% into the short binary format.
>
>>
>> My two board IDs are "D3EB" and "F6D3", so I can see that what follows
>> the “@" isn't the identifier ...
>
> @ gives the first (two in this case) bytes of the 64-bit random local board ID which is used in some comms if there is no housecode.  The local ID has the top bit of each byte forced to 1 to avoid clash with house codes (running up to 99) but is never 0xff (eg to distinguish from unset EEPROM bytes and for other reasons).
>
>
>> You don't need to explain the plain English lines such as "!RXerr F2"
>> (which I have a few of), except ... does "Bare stats TX" pertain to
>> the preceding or following line(s) of output?
>
> That means one has just been ’sent’ which you should see pop out of the queue shortly after.
>
>> I can see the { ... } experimental lines in Control.cpp but I can't
>> tell what switches them on - I’m not seeing them.
>
> Tell me which lines you care about or post some snippets and I’ll try to explain.
>
> I may be a bit slow responding again today as I need to focus on some (interesting!) interrupt-based stuff…
>
> Rgds
>
> Damon