[OpenTRV-interest] Stats from remote units
Damon Hart-Davis
EMAIL ADDRESS HIDDEN
Tue Nov 11 09:23:40 GMT 2014
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
More information about the OpenTRV-interest
mailing list