[OpenTRV-interest] OpenTRV board as 868MHz transceiver

[Alasdair Macdonald]

I have been gathering data from my OpenTRV boards for over a year now,
using an OpenTRV module that I created for fhem. Last time I wrote
here I was struggling to write commands to the board that was
connected to my PC's USB port (although I had been successfully
reading data from it for some time); over the past week or so I have
resolved this. So I can now read from *and write* to the board, via
fhem.

My usage of fhem is currently centered around an RFXcom trx433 with
fhem software:

http://www.rfxcom.com/epages/78165469.sf/en_GB/?ObjectPath=/Shops/78165469/Products/14103

http://fhem.de/fhem.html

The model number seems to have changed; it now has an "E" suffix - I
don't know what difference this means. Suffice to say the version that
I use is a transceiver that works with 433.92MHz RF signals, such as
those used by Home Easy automation kit, Oregon weather sensors, OWL
electricity usage sensor and more. (And I use sensors of all these
types).

So currently I have 7 Oregon Scientific temperature / humidity sensors
spread around the house; about the same number of Home Easy infra red
sensors, and an OWL device in my electricity cupboard that measures
electricity usage. All of these sevices are sensors that transmit data
via RF to anyone that is listening. I also have some Home Easy
hand-held remote controls, like a mini-TV remote. Press a button, a
signal is sent.

And what is listening is the RFXcom trx433, connected to a USB port on
a Raspberry Pi. It has been gathering data, and following rules
relating to that data, for a couple of years now.

Everything that I've listed above is a *sender* / transmitter of RF
data. The trx433 and logic in fhem triggers the sending of RF data to
some wall sockets and light bulb sockets, which are my *receivers*, to
switch them on and off. So, for example, at dusk, I switch on a light
in my hallway. At 11pm, it gets switched off. At certain other times,
if the IR sensor detects movement in the area, it switches on the
light. fhem has the logic for this.

It works. Lots of sensors sending data that is collected, logged, and
potentially acted upon by fhem. I wanted to do the same with OpenTRV.


On a different PC, I have been experimenting with 2 OpenTRV boards.
One is connected to my PC (not the Raspberry Pi) via USB, and it
pretends to be in Hub mode. As such it captures readings sent by the
second board, and I am able to monitor and log readings from both
boards. The second is battery powered and paired with a Conrad TRV.

In the past few days I think that I have come to realise a limitation
of the configuration that I have been working with. What I want to do
is use fhem to make decisions about whether to open or close my Conrad
TRV, but what's happening is that the board that is paired with the
valve is making all the decisions.

If a board is set to Hub mode, then it listens to and captures
transmissions from other OpenTRV boards. It is pretending to be
connected to my boiler (although in fact it is not), and I suppose
that in this situation it is appropriate for it to listen only; as far
as I can tell it does not send its own transmissions.

If it is not in Hub mode, then it is supposed to be a sensor that
detects occupancy and temperature, and make decisions about when to
Call For Heat and as such, it transmits data, but (again, as far as I
can tell), does not receive.

So in one mode it is a transmitter, in the other mode it is a receiver.

When a non-Hub board pairs with a Conrad Valve, the valve knows that
it is paired. I don't know if there is an ongoing, occasional dialogue
between paired devices, but in this relationship the OpenTRV board is
still a transmitter, and the Conrad Valve a receiver. I don't know if
the Conrad Valve actually transmits any information, perhaps someone
here can put me straight on this.


In the current openTRV scheme of things, as I understand it, the
decision making about whether or not to heat, and how much, is made by
the non-Hub sensor. In particular, the key action that it can take is
to send an instruction to the TRV to open or close (and by how much).

It seems to me that *possibly* I can bring the decision logic into fhem if I:

* Have an OpenTRV board that can send data to multiple TRVs, on an
ad-hoc basis. I don't know enough about pairing (and I only have one
Conrad TRV) to know if I can pair with multiple TRVs. Certainly I can
change the mode of my USB-connected board to not be a Hub; I can
change the House Code by (programmatically) sending commands to the
board, but I don't know is at all sensible (in the case of multiple
radiators / TRVs) to change House Code (and re-sync?) whenever I want
to control any individual radiator.

So I perform the following:
* Set the appropriate House Code
* Wait for sync to complete
* Set a mode and target temperature such that the board will send a
command to open or close its paired TRV. (And I'm not sure what
strategy to use here, given that essentially I want to "trick" the
OpenTRV board into sending its own command to the TRV).

And if I'm right (that an OpenTRV board is to all intents and purposes
a sender or a receiver but not both), then if I am using the
PC-connected board to send commands (based on the Oregon temperature /
humidity sensors), then I'm not making any use of any other OpenTRV
board. And I'd probably like to use the OpenTRV board, because it has
a luminance / occupancy reading that I can't get from the Oregon
devices.

So, conceivably, I could:

* At the same time as having one OpenTRV board connected in non-Hub
mode (do we call this sensor mode?), have another board on another USB
port connected in Hub mode, so that I can receive data from other
OpenTRV sensors. Right now this is meaningless, since I only have the
two boards.

But ideally, I would like the board that is connected to my PC act as
a *transceiver*, giving me the ability to gather stats that it
reports(to the PC), but also stats that it receives from remote
unwired sensors, and also the ability to send to devices with
arbitrary / different House Codes.

And my gut instinct right now is that the openTRV concept of "Hub
Mode" seems to work against this, since "Hub Mode" is specifically
intended to receive Calls For Heat and relay power on or off to a
connected boiler.

So the purpose of my post is ask for confirmation that my
understanding of sender / receiver modes is correct, and whether my
board software version might have any bearing on this functionality.
My version was built on 2014-11-07 with help and guidance from Damon.
I think that I may be able to save some time asking the question here,
but if you guys think that ad-hoc switching of House Codes can work
with my Conrad TRV (I know I only have the one right now, but I'm
trying to devise a whole house system for the future that will have
about 6 in all). If that might work, I can implement logic in fhem
based on temperature readings, but ideally I'd like my OpenTRV board
to act as a transceiver so that I use the luminance / occupancy data
that it would receive from other boards.

If I can get things working the way I want I can move the openTRV
board over from my "test" PC to my "live" Raspberry Pi, and start
controlling TRVs.

Hope that all makes sense.


If anyone else is interested in logging OpenTRV data with fhem, please
say so and I can share my code. Now that it works, I just have to tidy
it up a lot but ... it works.

Alasdair