Evohome / Evotouch Wireless protocol?

[inode]

@DanD thank you, it was exactly what i need.

I hope the process for Y87 is the same, I will do some test when I receive the hardware.

Thank you

[aelorenzo]

HI have the @Colintd evohome implementation in a CUL,

This code is now checked into the trunk of the culfw project, with the default makefile building the support into the CUL_V3_ZWAVE image file.

and I am receiving the packets. How can I decode them? I have been reading the evohome protocol wiki and the trancoder.c file from evofw2 for nanocul. Is it possible to implement the same decoding for the culfw?

Here I have an example of the messages I am sniffing, are these messages correct?

Thanks!

23:11:28.729 -> vr18107CA0056B5512B003030000
23:11:31.940 -> vr18107CA0056B5512B003030000
23:11:45.548 -> vr18107CA0056B55230903030834
23:12:01.916 -> vr18056B55056B551F0903FF07A8
23:12:01.916 -> vr18056B55056B5523090C0008340108340205DC030834
23:12:01.949 -> vr18056B55056B5530C90C00085101085202079203083B
23:12:11.101 -> vr18056B55056B55000802FC00
23:12:29.161 -> vr188974418974413120070070B0000000FF
23:13:05.206 -> vr1889744189744130C903000852
23:13:56.481 -> vr18107CA4107CA430C903000AB0
23:14:16.573 -> vr18107CA4056B553150020130
23:15:19.665 -> vr18056B55056B551F0903FF07A8
23:15:19.665 -> vr18056B55056B5523090C0008340108340205DC030834
23:15:19.665 -> vr18056B55056B5530C90C0008510108520207A503083B
23:16:18.903 -> vr18119C20056B55230903030834

[tinky_doy]

Hello everybody,

I was planning to create a little RPi interface with cheap remote temperature sensors (Xiaomi Aqara Smart Home Temperature & Humidity Sensor Thermometer) and send these data to the Honeywell devices via 868Mhz.

The idea is emulate a Y87/T87 honeywell thermostats, unfurtonatly I don't have one of them (they are not cheap!), can anyone provide me a trace of the communication between the Y87/T87 and the Evotouch controller?

I just bought the hardware and will arrive in some days, in the mean time I would like to get more info as possible.

The best should be:

-sniff of the binding process of the Y87 with the Evotouch
-sniff of communicaiton between Y87 and evotouch during normal operations

Thank you in advance.

Did you make any progress on your attempts? I am very keen on achieving something similar, already having Aqara Temperature sensors throughout the house feeding into my Domoticz setup.

[DanD]

23:11:28.729 -> vr18107CA0056B5512B003030000
23:11:31.940 -> vr18107CA0056B5512B003030000
23:11:45.548 -> vr18107CA0056B55230903030834
23:12:01.916 -> vr18056B55056B551F0903FF07A8
23:12:01.916 -> vr18056B55056B5523090C0008340108340205DC030834
23:12:01.949 -> vr18056B55056B5530C90C00085101085202079203083B
23:12:11.101 -> vr18056B55056B55000802FC00
23:12:29.161 -> vr188974418974413120070070B0000000FF
23:13:05.206 -> vr1889744189744130C903000852
23:13:56.481 -> vr18107CA4107CA430C903000AB0
23:14:16.573 -> vr18107CA4056B553150020130
23:15:19.665 -> vr18056B55056B551F0903FF07A8
23:15:19.665 -> vr18056B55056B5523090C0008340108340205DC030834
23:15:19.665 -> vr18056B55056B5530C90C0008510108520207A503083B
23:16:18.903 -> vr18119C20056B55230903030834

Those messages look OK to me as I recognise the structure. I've highlighted the parts in the first few below [header] [device1] [device2] [command] [length] [payload] in the examples below:

23:11:45.548 -> vr [18] [107CA0] [056B55] [2309] [03] [030834]
23:12:01.916 -> vr [18] [056B55] [056B55] [1F09] [03] [FF07A8]
23:12:01.916 -> vr [18] [056B55] [056B55] [2309] [0C] [0008340108340205DC030834]
23:12:01.949 -> vr [18] [056B55] [056B55] [30C9] [0C] [00085101085202079203083B]

We've developed an extensive wiki on Github which is still work in progress, but has tons of information on the structure and meaning of the different commands : https://github.com/Evsdd/The-Evohome-Protocol

[aelorenzo]

Thank you @DanD, I am able to decode the messages.

Only one question.

In the wiki there is a python example to decode Device IDs, but _tmp variable is missing.

def dev_hex_to_id(device_hex: str, friendly_id=False) -> str:

"""Convert (say) '06368E' to '01:145038' (or 'CTL:145038')."""

if not device_hex:

return f"{'':9}" if friendly_id else "--:------"

dev_type = f"{(int(device_hex, 16) & 0xFC0000) >> 18:02d}"

if friendly_id:

dev_type = DEVICE_MAP.get(dev_type, f"{dev_type:<3}")

return f"{dev_type}:{_tmp & 0x03FFFF:06d}"

I defined it as follows: _tmp = int(device_hex, 16)

Is it OK?

Thank you

[aelorenzo]

Thank you @DanD.

I have a problem with the header and de deviceIDs, how can I decode them with python2 to get the evofw2 format?

I mean:

"--- XX ---" for the header and
"01:000000" for the devices

I am getting wrong devides types and always " I" type message...

I do:

data="1889744189744130C903000852" # HEADER [18] DEVICEID [897441]
HEADER_FLAGS = [0x0F, 0x0C, 0x0D, 0x0B,0x27, 0x24, 0x25, 0x23,0x47, 0x44, 0x45, 0x43,0x17, 0x14, 0x15, 0x13]

then HEADER:

flags = HEADER_FLAGS[(data[0:2] >> 2) & 0x0F]
if (is_information(flags)):
typecmmd = "--- I --- "
if (is_request(flags)):
typecmmd = "--- RQ --- "
if (is_response(flags)):
typecmmd = "--- RP --- "
if (is_write(flags)):
typecmmd = "--- W --- "

For the DEVICE:

device = str(int(data[2:4], 16)).zfill(2) + ":" + str(int(data[4:8],16)).zfill(6))

This str(int(data[2:4], 16)).zfill(2) , data[2:4] is 84 hex, decimal 132....

Maybe everything is wrong...

Thank you,

Antonio

[aelorenzo]

I have solved the problem, I am starting with python, and I forgot to implement the byte operations...

Now I am able to decode all the messages from CUL device.

Next step is to use the Evohome listener from Smar000 in github to implement a virtual serial port, test send functionality and connect there HA or Domoticz. What do you think about this idea?

Which is the best implementation of evohome support, HA or Domoticz?

Thank you

[DanD]

Great, glad you managed to get it working.

If I'm understanding correctly what you've done (created a python-based decoder which turns the raw bytes into structured message bytes) then it sounds like this should work using a virtual serial port and in theory implementing a python encoder for the CUL firmware should work OK too. I'm biased with regards to HA versus Domoticz as I'm one of the developers of the Evohome Domoticz code and I've not used HA . Either of them should work OK for you.

Dan

[aelorenzo]

Thank you @DanD, I appreciate the way you managed my beginer question on HA and Domoticz, sorry for being so so... on this...

I will try to send evohome commands and to setup the virtual port and later on I will check the platform for my smart devices.

I need to integrate Dyson cool fan, xiaomi smart strips, sonoffs flashed with espurna firmwares, another CUL device with 434 support for RTS Somfy blinds, alarm using serial over wifi comms, foscam cameras, LG smart TVs and...

So I will decide later which platform to choose.... It will be a difficult task!

Thank you very much for your support on this,

Antonio

[va1entijn]

Hi, I've been working on an Evohome/Evotouch protocol decoder for STM32 microcontrollers for a while now and it is starting to work. The STM32 has plenty of RAM compared to the Arduino stuff I'm seeing, so it should be possible to build quite a good interpreter in the software itself. Also, I'm using raw C (with libopencm3 for hardware abstraction), so no Arduino overhead, and I'm using serial output for communication with the CC1101 chipset, skipping the rather tedious bit-by-bit interpretation that I'm seeing in several EvoFW implementations (*). However, I'm not sure what is next, as I do not (yet) have a domotica controller active. In this forum, I'm seeing raw messages ("vr181d18251d18251298030001fb8b") and also some sort of interpreted messages, as far as I can see this is a "HGI80" sort of interpretation.

So here are a couple of questions:
- What would be the preferred output for my decoder? Does this differ for different domotica-platforms?
- Am I correct that the only hardware receiving EvoX-messages are the RFbee and the NanoCUL, both with rather outdated ATmega328? Or are there others?
- Is there anything to be said about the sending side of the protocol? Do RFbee and NanoCUL support sending messages? Is there a (serial or USB) protocol for that, i.e. do the domotica-platforms support sending information out through these systems? If yes, how do they format their commands?

My current setup is just an STM32F401 with CC1101 and an HX1230 display, but extending that with USB should be feasible.

(*) rationale for doing a bit-by-bit-readout seems to be that this would improve reception because "you cannot be sure what the baud rate in the air is" (I'm not even sure where I read that, if anyone knows, please reply). However, from thoroughly reading the CC1101 documentation I'm sorry to report that this is probably not true. The clock recovery protocol inside the CC1101 will just adhere to the data stream on air. And as all of the implementations leave register 0x1A: BSCFG as is, the data rate will never be different than the one that is programmed, i.e. 38400 baud. Hence, a single line serial input through the USART hardware will work just as well - the STM32 USART hardware will handle clock recovery and input.

[Marcel1]

Hi all,
Atm I'm working on an usb dongle that is able to control my Orcon ventilation unit from my Home Assistant, so far, with help of what I can find online it works pretty ok. The usb dongle uses atmega32u4 running Arduino micro bootloader, for RF communication it uses CC1101:

Assembled_pcb_small.jpg (148.14 KiB) Viewed 12598 times

When booting the usb dongle, it will be in pairing mode for 5sec, within the 5sec, you can press a button on the standard RF15 remote, the dongle will receive and copy the addresses.

terminal.png (6.25 KiB) Viewed 12598 times

Also controlling the FAN speed works very well. I would like to know if anyone can help me with requesting the current FAN speed from the ventilation unit? Which message do I need to send to request info without changing the FAN speed?

Any help is being appreciated