Evohome / Evotouch Wireless protocol?

[Happyboy]

Meantime found a picture of the HGI80 inside... will dive in to this.

[DanD]

@Happyboy

It's a good idea to first test whether your RFBee can successfully send using my firmware outside of the Domoticz set-up. What I suggest you do is open your favourite serial client (I just used serial monitor in the Arduino IDE) and type an evohome serial command something like 'RQ - 18:730 --:------ 01:012345 10E0 001 01' with the NL and CR line endings. If you've typed in the command correctly and it sends, it should be echoed in the serial monitor window and if you replace '012345' with your Evohome controller's device ID you should also see a response message from the controller. Once this is all working you should be able to send commands within Domoticz, change the controller mode, setpoint overrides etc.

I think the Evohome debug log isn't on by default in my Domoticz code (as it can create a very large evoraw.log file if you leave it on for many days). If you turn on the Evohome debug log we'll then be able to see more details of some of these commands and we can work out what's going on.

Let me know if you have any problems and I'll try and provide additional guidance.

Dan

[Happyboy]

Dan, Thanks so far.

I "read" the whole firmware including lib's etc.
Quite "easy" to follow, now writing out the flow chart.

Sending part is working with 0.8Dan, with 0.92 i doubt..

Running a Diff now to check the differences.

Keep you all posted...

[Happyboy]

@ DanD,

Seems all post need first to be approved... this slowes things down...

Anyhow writing the flow down, comparing, running now with 2 changes :

CC1011 at 4 mhz SPI clock instead of 125khz (I couldn't figure out why it is set so low..)
Under de ~ 6 mhz you don't need to take any additional care for teh CC1011 spi (support till 10 Mhz SPI)
This could prevent that the CC1011 is still sending on SPI when already an other message arrive.

Serial port @ 76800 to be " in Sync", 250k seems also to work fine (even 500k...)

Benefit until now seems to be that the message " to many at once" seems nearly to be disapeerd.
and less incomplete messages.
Would be good to have some statistical counting tool to see if things really improve...

Now first time for a rest...

[psr]

I've just installed Evohome and am now interested in getting it working with an rfbee (currently on order) ideally directly connected to a BeagleBone black.

I'd really like to be able to backup and restore schedules to the Evohome controller. It looks like this should be possible judging from the Tridium documentation. Has anyone been able to decode the messages required for this functionality? Looking at the Domoticz implementation and Evomon I've not seen any encoder/decoder for these messages.

[DanD]

@Happyboy

Excellent! Thanks for posting this information. I'm looking forward to seeing the results of your testing.

Dan

[DanD]

@psr

I'm working on trying to extend the commands that the Domoticz Evohome code can interpret, but unfortunately the commands to query the heating schedule from the controller and possibly to send a schedule back to the controller aren't known. The best way to find this out would be to monitor the commands being sent in a NiagaraAX installation, but I've never seen anyone publish any results from this approach. I've written a simple Python script which sends sequential values to my Evohome controller to identify which are recognised as commands and obtain a response from my controller. I've been using this approach to gradually work out a few more of the Evohome commands and I'll be adding these to the Command_Ext development branch of my Domoticz Evohome work. I'm also extending the support of various Honeywell Evohome devices to this branch (I'm working on the Opentherm Bridge at the moment).

Here's the link to my Github area:
https://github.com/Evsdd

If you're interested in searching for additional Evohome commands using the Python script, let me know and I'll post some more details on the structure of the commands etc.

Dan

[bruce_miranda]

I would have thought even if we can use the RFG100 the message structure for the scheduling should be easy to find. The RFG100 was able to read and push schedules back to the controller.

[bruce_miranda]

I've just installed Evohome and am now interested in getting it working with an rfbee (currently on order) ideally directly connected to a BeagleBone black.

I'd really like to be able to backup and restore schedules to the Evohome controller. It looks like this should be possible judging from the Tridium documentation. Has anyone been able to decode the messages required for this functionality? Looking at the Domoticz implementation and Evomon I've not seen any encoder/decoder for these messages.

If you have the internet gateway or the wifi controller then the best implementation for schedule back ups and restore is via the json interface. See an example here

http://www.automatedhome.co.uk/vbulleti ... #post27405

I also like this feature to increase or decrease zones by a fixed temperature instead of the silly ECO which takes the zones down by 3C.
http://www.automatedhome.co.uk/vbulleti ... #post27413

[DanD]

Hi Bruce,

I would have thought even if we can use the RFG100 the message structure for the scheduling should be easy to find. The RFG100 was able to read and push schedules back to the controller.

I thought that the RFG100 just allows use of the Evohome phone app which simply creates setpoint overrides and controller overrides (e.g. away etc)? These commands are all supported in the Domoticz code. I didn't think the RFG100 enabled any alteration of each zone's scheduled program which are maintained on the controller. For example, I didn't think it was possible to change or query the weekly schedule for a zone via the RFG100 or the scripts. It's these schedules that I think psr was referring to.

Dan

[bruce_miranda]

If the WiFi controller can display and amend the schedules on the phone app, then the RFG100 should also be capable of doing that. I don't have the RFG100 to confirm my thinking though.

[DanD]

Hi Bruce,

Sorry, you're correct and you can change future setpoints on the app. I'd forgotten that there is a calendar button in the app as I only ever use the app to tweak the current temperature. I'll have a play with the ZONE_SETPOINT (0x2309) command to see if it supports obtaining the weekly schedule information or whether possibly the RFG100 uses an additional command. I only have the Wifi controller, so can't check what commands the RFG100 uses for this.

Dan

[dty]

Hello all,

I totally forgot to post on here about my firmware for the SCC and Domoticz!

Here it is: https://github.com/codeaholics/evofw2

If you're familiar with building the CULFW firmware for SCC, then building my firmware will be straightforward - it's the same Makefile!

A lot of the concepts are taken from the FullTalgoRythm firmware, but following recent conversations with DanD and bruce_miranda, I think the message parsing in mine is much tighter. Specifically, I think it will handle most, if not all, of the odd variants that people have been talking about recently.

The USB interface runs at 38,400, while Domoticz expects 115,200. It's impossible to get this board to run at 115,200 reliably because of the 8MHz crystal and the way the Atmel atmega1284p MCU derives the serial clock from it. So you'll need the latest version of Domoticz (from source code) which includes a patch to allow the baud rate to be selected when creating or updating the Evohome interface. Sometime soon, I will increase the baud rate to 76,800 to give a little bit more headroom.

I am interested in exploring colintd's CULFW modifications. It appears as though this uses the MCU's second USART to interface with the CC1101. I wanted to take that approach, but couldn't get any information from the SCC manufacturers (busware.de) about how the CC1101 pins were wired to the MCU pins. I know (because my firmware works!) that they're wired to PB1 & PB2, but if colintd's approach works too then this would suggest they're also wired to PD for the second USART. If I can make this work it will significantly cut down on the work being done by the MCU which currently processes bits off the radio one-by-one and probably loses sync because it attempts to do so synchronously with no accounting for drift and/or timing errors, which I assume the hardware USART will take care of.

[hox]

Hello I'm new in this interesting forum.
I heve an evotouch controller and 5 THR092HRT.
As I have a SDR(software defined radio) where I can see the RF comunication directly.

[hox]

Continuing the last post.

I inverted the signal after the sync FF00 plus additional 2 bits (ff008) to get
aaaaaaaaaaaaaaaaaaff00833555355a9a96a966569aa565aa6a966569aa565aa6695a699696a9
so I get the sync bits 335553
After the 29th byte I make a Manchester decoding:
0ee7946f13de51bc4f58da6791eb7b98a7b40000000
At this point I could not decode futher like it is in download/file.php?id=1396

Also the RFBee and CUL data showed different results.

The SDR work was a test only, to see real data of the CC100 RF output.
In the end I'm interested in an Arduino + CC1100 modul.
Does anyonyone have a running Arduino-Code which communictes with EVOtouch


Hox