[OpenTRV-dev] Possible basis of OpenTRV hub?

[Kevin Wood]

Hi Bo,

I think it depends what we want to achieve.

If we want to listen for EMonTX nodes and control FHT valves with the same
hub node then there are going to be some compromises.

I haven't looked into the FHT protocol much but I assume that, because the
nodes are both battery powered, that they must establish some sort of
schedule rather than have the receiver monitoring constantly, so we know
when we need to be active in the FHT protocol, and it doesn't matter to
the valves what the radio module is doing in-between.

That gives us windows in-between FHT radio activities that we could use to
listen out for EmonTx nodes. If the duty cycle is good enough we might not
miss too many node transmissions.

Even with 2 radios, FHT activity might well swamp reception of EmonTx
nodes, especially if we operate both in the same band, although we could
easily move EmonTx activity to 433MHz. So, 2 radio modules might not
actually buy us anything.

Of course, the OpenEnergy protocols as they stand are unsuitable for
reception by a node that is battery powered since the protocol requires
the receiver to be "always on". With a bit of work they could be made to
work on a schedule that we could arrange such that the two protocols could
co-exist without any compromises with a single radio - but then it
wouldn't be a "standard" EmonTx.

But.. Back to the original question - what would we be looking to achieve
by interworking with the OpenEnergy kit? ;-)

Best Regards


Kevin

> Before reading the details one Q:
>
> Would it be better to have dual radios? one for OEM and one for the
> valves?
>
> And then adding a kind of module for OEM that allows control of the
> valves?
>
>
>
> -----Oprindelig meddelelse-----
> From: Kevin Wood
> Sent: Wednesday, April 09, 2014 12:03 PM
> To: Closed list for developer discussions
> Subject: Re: [OpenTRV-dev] Possible basis of OpenTRV hub?
>
> Hi All,
>
> As promised, here's a brain dump of everything I've discovered about the
> RFM12 protocol used by OpenEnergyMonitor.
>
> It's very different to the OOK protocol used by the FHT valves, of course.
> Whether we'd be able to use a single RF module and reconfigure it between
> the two "standards" each time we need to talk to a valve I don't know.
> There is no synchronisation of the OpenEnergy nodes at the moment, so the
> hub would need to monitor the OpenEnergy signalling for the majority of
> the time in order not to miss too many transmissions.
>
> That said, the most valuable part of the OpenEnergyMonitor suite for us is
> probably EmonCMS, and I think the best way to interwork with that would be
> to have a hub node that speaks to it using JSON, so the RF protocol would
> then become irrelevant and we could "roll our own".
>
> Anyway, here's the detail. If there's a better place to post this (a wiki,
> etc?) then please feel free to do so, or point me in the right direction.
>
> Cheers,
>
> Kevin
>
>
> OpenEnergyMonitor RFM12 signalling protocol:
>
> Jeelib defaults are used for the radio parameters. These are as follows:
>
> Centre Frequency:
> 434.0 MHz (with 433 MHz module selected)
> 868.0 MHz (with 868 MHz module selected)
>
> Transmission settings:
>
> FSK, 90KHz deviation, 49.2kbps
> RX and TX FIFO enabled
> 12 pf load capacitor
> Fast VDI
> 134KHz RX Baseband bandwidth
> LNA gain 0db
> RSSI threshold -91dbm
> Auto clock recovery, slow mode, digital filter, DQD threshold 4
> FIFO it level 8, 16 bit sync pattern, RX FIFO fill after sync pattern
> Sync pattern 0x2d,<group id>
> AFC auto, keep during VDI, deviation unrestricted, coarse mode
> Mod polarity 0 (1= fc+dev 0=fc-dev), 90kHz deviation, output power max.
> PLL BW wide
> Wakeup disabled
> Low duty cycle disabled
>
>
> Packet format:
>
> {transmission start}
> 0xaa
> 0xaa - 24 bit preamble
> 0xaa
>
> 0x2d - 16 bit receiver wakeup sequence
> <group id> (configurable - default is 210 decimal)
>
> <header byte> - Combined node ID and flags:
> bit 7: CTL
> bit 6: DST
> bit 5: ACK
> bit 4-0: <node id>
>
> <length byte> - Number of bytes in payload
> <payload> - 66 bytes maximum
> ...
> <CRC low byte> - Initialised to 0xffff for each packet. Calculated on
> group byte onwards.
> <CRC high byte>
> {transmission end}
>
>
> Protocol Detail:
>
> If a group ID is allocated, only nodes with the same group ID can
> communicate. If a group ID is not allocated,
> the module is configured with an 8 bit wakeup byte of 0x2d.
>
> If the DST flag is set, the node ID indicates that of the destination
> node, else it is that
> of the source node.
>
> If the DST flag is set, a node will ignore packets that don't match its'
> node ID unless its' node ID is 31.
>
> The ACK flag appears to request that a transmission is acknowledged by the
> receiving node.
>
> The CTL flag in conjunction with the DST flag appears to indicate that a
> packet is an acknowledgement
> initiated by a previous packet from the addressed node with the ACK flag
> set.
>
> CRC Check:
>
> The CRC algorithm employs the avr-libc function _crc16_update
> (util/crc16.h). Note that the inline assembler
> version of this algorithm seems to bear no relation to the C version shown
> in the comments!
>
> The CRC is initialised to 0xffff at the beginning of each packet transmit
> operation and
> each byte from the group id byte onwards (excluding the first byte (0x2d)
> of the wakeup sequence)
> is incorporated by a call to _crc16_update.
>
> On the receive side, the CRC is initialised to 0x0000 and each received
> byte from the
> group id onwards is incorporated by a call to _crc16_update. Since the
> group id is part of
> the wakeup sequence and not passed to the AVR from the RFM12, the local
> group id is used.
>
> Upon error free packet reception, the receiver's CRC will evaluate to
> zero.
>
> Payload data in EMonTX:
>
> EMonTX nodes simply pack a struct of 16 bit integer measurement values
> into the payload.
> There is nothing in the data to indicate what the values represent.
> Incoming measurements are
> assigned labels and their values processed into "real" units by input
> configuration in the EMonCMS software.
>
> Node firmware that I've looked into simply sleeps between updates, and
> there appears to be no attempt to
> synchronise reporting times or to mitigate against collisions between two
> nodes whose transmission schedule
> has become "synchronised".
>
> Forwarding to EMonCMS:
>
> The firmware in the RFM12Pi daughterboard for the raspberry Pi simply
> forwards received RFM12 messages to the
> serial port as a sequence of byte values in ASCII format, and facilitates
> transmission by a command that
> allows a byte sequence to be sent.
>
> An accompanying script running on the raspberry Pi listens for incoming
> RFM12 messages, formats the data within
> into JSON and sends them to the EMonCMS server via HTTP.
>
>
>
>
>
>
>
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>