[OpenTRV-dev] Two-way working for OpenTRV
Damon Hart-Davis
EMAIL ADDRESS HIDDEN
Sun Apr 13 15:46:03 BST 2014
Hi,
FWIW, in the light of all sorts of comments from various of you, I’m going to establish the viability of:
1) Piggybacking some info onto the end of an FS20 frame (eg, subject to security concerns, mode, temperature, target temperature, occupancy, light levels, etc). The idea with this is to only require a few ms of extra radio run-time to get the info to a central point, not a whole extra radio and frame setup.
2) Two-way working, eg the hub sending an ACK plus possibly a queued command back to the leaf nodes in immediate response to an incoming frame, again using the FS20 carrier and basic frame to minimise complications and new work and maximise ease of switching between TX and RX.
Obviously in the light of (a) Mike’s work and (b) possible OEM interop the channel in either direction might have different carriers and bit patterns, but I’ll try to abstract that a little inside so I don’t care what the carrier is, (and more than one could be used in parallel) though it will care whether the channel is secure or not.
If I get (1) running I’ll use it to centrally monitor temperatures around my house, etc. If I can use Mike’s stuff to make this an MQTT frame with optional security all the better. For now this is all just testing the waters.
One use of (2) is to help simplify pairing and key exchange between a leaf and the hub as well as allow control from the central hub.
Rgds
Damon
More information about the OpenTRV-dev
mailing list