Evohome / Evotouch Wireless protocol?

[qjb]

Closer inspection on the bit level reveal this is more likely a missed bit. The 0xAA and 0x80 are one bit different from 0x55 and 0x00.

[r_255]

So there is some progress!! great to hear Wladimir Komarow has picked up the document
and translated it to a working firmware for the RFBEE


https://gist.github.com/wkomarow/HoneyComm/wiki

PS: The credits for documenting all go to CrazyDiamond, he sadly never finished the partial working .hex file he made for sniffing with the cul.

[Digit]

I have 2 RFBees here, from the time I was interested in this too.
If someone is interested, just let me know.

[r_255]

Interested :O)

[Digit]

I'll send you an email soon (something I should have done 4 months ago already, IIRC )

[Bwired]

Thanks to Jrosser the updated Evohome protocol document
http://files.domoticaforum.eu/index.php?cam=/Evihome

[r_255]

Big hug for jrosser and the others @ honeycomm

[r_255]

I have got the RFbee up and running but i do get a lot of decoding errors like this ( about 95%)
Just a small report of what i experience:

ERROR: Manchester-Decoding the message: A9 6A A9 AA 59 68 5A A5 AA 9A AA 95 69 A1 A6 A5 AA 69 AA A5 AA A2 AA 16 66 9A 58 6A
and

ERROR: Cannot find RF postamble.


But i do receive these
040791040791 Heat Demand Timing Related FC 0 31

10D8C3040791 Command 0x1016 Data: 0 FF 1
10CF61040791 Command 0x1016 Data: 2 FF 1


ERROR: Unknown command: 0x1F9
18 04 07 91 04 07 91 1F 09 03 FF 06 E0 A0

ERROR: Unknown command: 0x3B0 ( so this is also seen in a evotouch setup and not only cm67 related )
18 04 07 91 04 07 91 3B 00 02 FC C8 AF

ERROR: Unknown command: 0x08
18 04 07 91 04 07 91 00 08 02 FC 00 AA ( so this is also seen in a evotouch setup and not only cm67 related )

[jrosser]

I have got the RFbee up and running but i do get a lot of decoding errors like this ( about 95%)
Just a small report of what i experience:

ERROR: Manchester-Decoding the message: A9 6A A9 AA 59 68 5A A5 AA 9A AA 95 69 A1 A6 A5 AA 69 AA A5 AA A2 AA 16 66 9A 58 6A
and

There are only 16 allowed transmission symbols due to the manchester encoding. These are

0xAA 0xA9 0xA6 0xA5 0x9A 0x99 0x96 0x95 0x6A 0x69 0x66 0x65 0x5A 0x59 0x56 0x55

Any other received values (except the preamble and 0x35 End of Block) are due to a reception error, or two devices transmitting at the same time.

I would question using the packet reception features of the C1101, which is inherently synchronous for the entire message duration. It is clear that the signal modulating the RF is formatted exactly like a stream of RS232 data. To correctly receive this potentially asynchronous data you require a UART style function that re-establishes the bit timing on each start bit, something which your configuration of the CC1101 is not doing.

Whilst the transmitted messages may indeed be fully synchronous, we don't have any original specification that states this. All I can say is that my use of the RFBee is different, and I drive the demodulated signal into a UART and achieve about 1 or 2% corrupted packets. This is consistent with colliding messages or interference from other 868MHz activity.

ERROR: Unknown command: 0x1F9
18 04 07 91 04 07 91 1F 09 03 FF 06 E0 A0

ERROR: Unknown command: 0x3B0 ( so this is also seen in a evotouch setup and not only cm67 related )
18 04 07 91 04 07 91 3B 00 02 FC C8 AF

ERROR: Unknown command: 0x08
18 04 07 91 04 07 91 00 08 02 FC 00 AA ( so this is also seen in a evotouch setup and not only cm67 related )

These are not errors, but are message types not understood by the RFBee firmware you are using.

[r_255]

I know i should shut up, but i like to learn and i do come from far as a graphics designer.

So the 1st part is kind of clear, the manchester encoding... and the basics of decoding ( thanks to the .pdf )

About the posted command : taught i mention these as i could not find the 1st command i posted and the other two where described in the document as cm67 related and they appear in the evo touch setup to.

So i do understand correct that we dont receive all code correct because of how the c1101 is connected. Now the decoding is done onboard and it would be better to let the datastream thru a ( like ) a serial connection and decode on a different platform than the atmel 168 ? Or is is due to a different configuration setting on the c1101 ?

Thanks for explaining so far!

[jrosser]

About the posted command : taught i mention these as i could not find the 1st command i posted and the other two where described in the document as cm67 related and they appear in the evo touch setup to.

Ah - I see what you meant now. The "Heat Demad Timing Related" message is of type 0x3150 as in the document.
What HoneyComm prints as 0x1016 is a typo in the code here https://github.com/wkomarow/HoneyComm/b ... m.ino#L552 - it should be 0x1060

Regarding CM67z/Evotouch - i've only got a CM67z so the document does not talk about Evotouch at all. However, I expect that there is a large amount of similarity. Any info on what different things the Evotouch does will only make the document better.

So i do understand correct that we dont receive all code correct because of how the c1101 is connected. Now the decoding is done onboard and it would be better to let the datastream thru a ( like ) a serial connection and decode on a different platform than the atmel 168 ? Or is is due to a different configuration setting on the c1101 ?

Well, I started from the original work done by CrazyDiamond, and he used the asynchronous mode of the CC1101. This is working very well for me and I take the serial data out from a pin to process elsewhere. Wladimir seems to have made some progress on getting everything working just on the RFBee, but it seems quite complicated and your error rate looks much too great.

I tried to use the fifo and packet processing on the CC1101, but IMHO the data format we are trying to decode is not very well suited to this mode. It was just easier to stick with what worked and spend time trying to decode the messages.

Thanks for explaining so far!

No problem! I'm really interested in what an EvoTouch does....

[r_255]

I think ( as in almost sure ) CD did reverse the original firmware of a evotouch or cm67, as one of his 1st posts was assembly showing a contrast setting ( i dont recall that a cm67 has contrast settings so it must have been the evo )

So i guess it makes his document a good start point.

In the way of controlling i dont think there is much ( or even none ) difference in how a evo or cm67 receives or sends out commands.
in the end they control the same hardware that is around for many years now.

i did notice some differences in sniffing output from the cul stick vs the rfbee but i have to investigate that ( need some time stamping on the rfbee output for comparison with the cul output )

I did try to open up the firmware from cd in a interactive disassembler ( its a atmel .hex file ) and got some flowchart and a heap of assembly without any comments or recognizable vars. If you would like to have it or see some sniffer reports from the cul drop me a line on my email account [forumnick]@hotmail.com.

[jrosser]

OK - here's a new toy.

https://github.com/jrosser/honeymon

It's my GUI application for monitoring the messages and helping to understand what is going on.

You'll need to be able to use the Qt SDK / Qt Creator to compile honeymon and the supporting qtserialport library. See the (very) terse help on the github wiki.

Connect an 868MHz receiver that outputs the demodulated data as a raw binary stream to the receive pin of a serial port, and you are good to go. Alternatively, send the same data to the broadcast address of your network, port 8888, and it will be picked up from there.

Probably a bit buggy, and it's only been tested on Linux so far but ought to work on Windows/OSX without too much difficulty.

[r_255]

Kewl,

I have installed the sdk .

Opened the qtserialport file in the sdk, and run
makes a lot of comments and ends with

20:33:30: The process "C:\QtSDK\mingw\bin\mingw32-make.exe" exited normally.
and pops up a terminal programm. and connects to myu cul and data starts flowing.

E

53 A9 6A A9 AA 5A 55 96 A9 AA 9A AA 95 69 A9 A5 A9 99 AA AA A6 AA A6 96 6A A9 55 35

53 A9 6A AA 9A AA 95 69 A9 AA 9A AA 95 69 A9 A5 A9 99 AA AA A6 55 5A 96 6A 5A 69 35


As compiling honeymon give a error on qtseriallib ( cant find .h files )
I did copy them manual to the honeymon folder and now it even gives me more errors like :

C:\QtSDK\Demos\4.7\Honeymon-master\honeymon-build-desktop-Qt_4_8_1_for_Desktop_-_MinGW__Qt_SDK__Debug\..\honeymon-master\mainwindow.cpp:40: error: undefined reference to `_imp___ZN7QtAddOn10SerialPort10SerialPortC1EP7QObject'



so i guess i need to install the qtseriallib some how/where in the sdk ? any clues would be welcome...
Sorry for bothering.

I still am trying without any luck, and ill keep on trying... but running into concrete walls here. I did that 3 times, and now i am going to scratch my head. Sure google is my friend!
but not today it seems. Kind of confusing mathers.

[jrosser]

I think you need to run "make install" in the qtserialport directory. That should install the library and headers in a place that the honeymon build ought to find. I'm not sure that honeymon will work with the cul as it is at the moment....

If you use the "Simple Terminal" example from qtserialport does it just display lines like you posted, or lots of garbage characters?