whaleygeek / pyenergenie

A python interface to the Energenie line of products
MIT License
82 stars 51 forks source link

Possible to support PT2260/PT2262? #95

Closed steadramon closed 5 years ago

steadramon commented 6 years ago

Hi I'm looking through the code here - I'm wondering if we have the ability to use the radio to send PT2260/PT2262 based messages?

Using rtl_433 I have sniffed the packets from the remote I want to duplicate:

2018-05-18 11:29:54 : Generic Remote House Code: 27849 Command: 209 Tri-State: F!1010!F1F0F

I'd be interesting in looking into this myself, a few pointers would be handy - experienced programmer but just getting into radio

As far as I can tell if the radio is possible of transmitting this a fair amount of code would have to be added but overall I think this would be a great addition.

whaleygeek commented 6 years ago

The PT2260 is a bit encoder, that encodes a house code and a command code, which is then via some other means modulated onto a radio carrier.

The Energenie devices supported by this library may be OOK modulated or FSK modulated, and the radio.c module supports both configurations.

In OOK mode, the Energenie devices use a protocol compatible with the Rato RT1527 device (which is an OTP encoder with address bits and a small number of command bits like the PT2260)

So, assuming that the transmit frequency, modulation type, baud rate and preamble bits are the same, all you would need to do is write and insert a new encoder into the OnAir module, because I have already architected the software to support multiple encoders.

FSK modulated messages are encoded using OpenThings payloads. OOK modulated messages are encoded using TwoBit payloads (TwoBit is my name for the RT1527 encoder).

Look here specifically: https://github.com/whaleygeek/pyenergenie/blob/master/src/energenie/OnAir.py#L114

Each Device in Devices.py is configured to use a specific modulation and encoding (which is grouped into an air_inteface).

Look here for an example of the legacy OOK TwoBit air interface for the older receive-only Energenie devices:

https://github.com/whaleygeek/pyenergenie/blob/master/src/energenie/Devices.py#L379

The actual code for the TwoBit encoder is here:

https://github.com/whaleygeek/pyenergenie/blob/master/src/energenie/TwoBit.py

So, you could copy and rename (LegacyDevice, TwoBitAirInterface, TwoBit) and register in the OnAir module, and then modify the equivalent TwoBit file to implement the PT2260 encoder algorithm.

You would then get interoperability with everything else in this library, allowing you to use Legacy Energenie OOK, MiHome Energenie FSK and PT2260 devices in a single application.

You will need to check still what modulation, frequency and baud rate your PT2260 remote requires (if it is different from those already in radio.c, you will have to add a third 'mode' and use the mode switching logic in radio.c to reconfigure the radio when you transmit a masqueraded PT2260 remote message (the radio.c module already supports multiple radio configurations and will switch between them on-demand). For specific details about configuring the radio, (if different to Energenie) you'll have to consult the Hope RFM69 data sheet.

Seems I left the path open for you in my existing architecture already! Let me know how you get on.

steadramon commented 6 years ago

Hi there!

Thanks for the reply and advice, after a bit of struggling, Google and just plain experimenting I've had a fair bit of success with this and have successfully replicated the generic remote I wanted to.

I need to make a few alterations to my code to clean it up and make it a bit more generic to other remotes of this type - would this be something you'd possibly be interested in seeing, even though not specific to Energenie, don't know if you'd consider it for inclusion (assuming code is up to scratch)

Thanks again!

Paul

whaleygeek commented 6 years ago

Hi Paul,

Great news, glad you have made progress here!

Yes, it would be good to include your work here if possible. The easiest way for us both to do this would be for you to fork this repo, make and test the changes, then send a pull request. I can then review it and merge into mainline (or suggest other modifications that would make it easier to merge).

David