Results 1 to 4 of 4

Thread: Evohome wireless protocol

  1. #1
    Automated Home Legend
    Join Date
    Sep 2014

    Default Evohome wireless protocol

    I came across this document quite some time ago but didn't read through it until now, and although its based on the original 8 zone Evohome black and white model of 2010 I suspect most if not all of the 868Mhz Ramses II over the air protocol is similar if not identical.

    I thought I'd share it for those of you who like to get a low level understanding of how something works like I do. (you know who you are ) It's by the home automation company Tridium, so a lot of it is specific to their software and how it interfaces with Evohome via an HGS80, but it gives some insight into what can and can't be done over the Ramses II protocol.

    It's a long read, so here are a few bits that I thought were interesting:

    Q: Why do some points such as Boiler Demand and Upper Setpoint Limit in the EvoTouch controller
    remain stale for a long time?
    A: The EvoTouch controller only transmits some of its point data every 60 minutes unless there has been a
    change to it.
    This implies that a heat demand was only sent from Evotouch to BDR91 once every 60 minutes if there is no change in demand, however Paul's Domoticz dump recently showed a regular 20 minute heat demand update when the demand remained the same. Perhaps latter models of controller reduced this to 20 minutes so that the consequences of a lost heat demand transmission were minimised ? (EG only 20 minutes of additional run on instead of 60)

    Q: When I set the time in the EvoTouch controller using the Menu…Setting Menu…Time/Date Setting, the
    controller time was changed OK but the next time I looked at the controller, the time had reverted back
    to its old setting. Why is this?
    A: As part of its routine request cycle, the driver will update each EvoTouch system controller with its
    NiagaraAX station’s current date and time. This ensures that all the systems are synchronised to the
    same time. You should go to the NiagaraAX station platform, update its time and date and the
    EvoTouch controller will automatically follow it.
    It looks like another device can do a push update of the system time on the Evotouch via Ramses II - whether that is still the case on a Wi-Fi model that supports internet based time update is unclear.

    EvoHome Monitoring:
    A number of items of EvoHome information can be monitored. These are as follows:
    EvoTouch Controller:
    Current Mode Current [Time/Date] Password Mode
    Outdoor Temperature Boiler Demand Max Valve Position
    Fault Logbook Controller Software level
    Apparently the full Fault logbook can be retrieved via Ramses II. (Shown in detail later in the document)

    Domestic Hot Water Zone:
    Current State Current [Time/Date] Schedule
    DHW Setpoint DHW Setpoint Differential DHW Temperature
    DHW set point and differential can be retrieved by Ramses II, but not via the Web API.

    Known problems and observations
    Here are known problems and observations of the driver:
    Schedule Period Time Restriction
    For both the zone and DHW schedules avoid period start or end times between 02:56 and 02:59 inclusive.
    A period that ends at 02:55 and a period that starts at 03:00 are both OK
    Apparently it is "bad" to have any scheduled set point occur between 02:56 and 02:59. Of course the Evotouch itself doesn't let you do this since you can only set on 10 minute boundaries, nor does the iPhone/Android app, but if you set an override using Domoticz you can use both non standard set point temperatures (such as 21.3 - which does in fact work) and non standard set point times, like 14:28. (Which I think also works, but I haven't tested it) I wonder if not using this time period is related to handling of daylight savings changes ? This might trigger a bug that no longer exists in the current models of course.

    All the radio transmitters in the EvoHome Room Control System components are classified as “Short
    Range Devices” or SRD’s and as such they have a number of operational restrictions which include that
    they operate in shared bands and are not permitted to cause harmful interference to other radio services.
    All the devices operate in the G1 frequency band (868.000 – 868.600 MHz) and they are restricted
    to ≤25mW ERP (Effective Radiated Power) with a ≤1% Duty Cycle.

    Due to the single channel band, to prevent excessive interference between devices, regulations require that
    the devices do not exceed a 1% transmission duty cycle. This means that each device can only be
    transmitting 1% of the time. This impacts on how fast the application in each device can send data over the
    air. The HGS80 serial interface is similarly restricted to the regulations and it is a throttle or regulator to the
    amount of traffic that the EvoHome driver can transmit to the EvoTouch controller. If the HGS80 is sent
    data at a rate faster than it is permitted to transmit over the air, then messages will fail.
    We knew about the 1% airtime restriction, but it's interesting to see that it is enforced by the HGS80 and presumably HGI80 as well - this has implications for systems like Domoticz trying to send out commands to the system - if it tries to send them too quickly the interface will just drop them.

    The battery powered devices, which include the Outdoor Sensor (HB85), DHW Sensor (CS92A), Radiator
    Controller (HR80) and Room Sensor (HCW82) are subject to the same 1% duty cycle regulation but they
    also limit their transmission rate in order to maximise battery life. Messages from these devices are
    optimised so that some data points (such as a temperature value) report only on change of value and some
    data points (such as battery condition) are only transmitted on a time interval of several hours.
    I wonder if a cylinder heating up too quickly causes too many updates to be sent which then causes the CS92 to have to go "quiet" for a while due to exceeding its 1% airtime quota ? What I can't find anywhere is over what period of time this 1% quota is measured, and how long it has to wait before sending again if the air time quota is exceeded.

    Some of the request messages require the receiving device, which in this case is the EvoTouch controller
    to acknowledge with corresponding data and some of the request messages are unacknowledged. Some
    of the request messages send data to the controller such as in the case of time schedule transmission.
    So as we speculated some messages to the Evotouch are acknowledged but some are sent without expectation of an acknowledgement to the sender. I'm sure temperature readings from temperature sensors would fall into this latter category.

    The Evotouch controller has a feature to prevent unauthorised changes being made by enabling a
    password-protection mode. This mode is not part of the normal Evotouch features and is not documented
    in standard user or installation guides. It can nevertheless, be used by building managers and others and it
    is also supported by the EvoHome driver.
    I've never used the black and white Evotouch but my interpretation of the above is that it did NOT provide a user password feature in the GUI like the current colour and colour Wi-Fi models have, but it appears that the password restrictions can be enabled and disabled via Ramses II messages ? That is interesting to say the least, if it still applies on current models.

    Note: The default password is “evohome” (without quotes and is case-sensitive) and this default
    password is always active. It is possible to enter a new (user) password which would be active in
    addition to the default password. On a factory reset, password protection will revert to disabled and
    the user-defined password will revert to the default password.
    A default password that can't be changed or disabled in additional to a user set password ? Tsk tsk. Surely that isn't the case with current models ?

    Sending a Message
    The EvoTouch controller can receive a number of text messages which are viewed by the user from menus
    in the controller. There are several ways to initiate a message to one or all EvoTouch controller systems
    from the driver:
    Apparently Ramses II can be used to send a text message to the controller that will pop up on the screen, presumably in a modal dialog. This is pretty neat if true!

    I know one gripe people have is that faults are not brought to the users attention well enough, (as any modal error message disappears if an intermittent fault resolves itself) I could imagine a feature in Domoticz which monitored the Fault Logbook and if certain types of faults appeared would then send a custom text alert back to the controller - effectively giving us some custom control over alert display in a round about sort of way.

    For that matter, if Domoticz read the fault log book regularly it could also send a push notification or email to the user via the normal Domoticz notification methods when a new fault logbook entry was found. I'm sure this would be well received by some users, as quite a few people have complained that the fault logbook is not made available either by the phone apps or through email alerts. I wonder if DanD is reading this.

    Anyway, I thought those were some of the interesting points in that document.
    Last edited by DBMandrake; 16th November 2016 at 12:18 PM.

  2. #2
    Automated Home Guru
    Join Date
    Oct 2016
    Bath, UK


    Good find and summary, I'm wondering if they reverse engineered a lot of this information by monitoring or had inside knowledge, who knows... The 1% limit on Tx time is interesting, although ~15-mins/day is a lot I think given the amount of data it can send in that time. Another (slightly) interesting point is there is no user licence just a manufacturing one, so this is how they (Ofcom) are controlling band access and yet there are other bands that are dead in-terms of RF, so quite why they wish to limit usage at 868 is beyond me, even if (eventually) there were 1000's of the devices in a street like the 440Mhz band is now, so I suppose there is logic in their controls.

  3. #3
    Automated Home Legend
    Join Date
    Jul 2014


    I know @DanD was trying to get the fault log to download to Domoticz but without the actual message, he has not managed so far. The message on the Evohome screen would be super cool. DanD, you reading this!

  4. #4
    Automated Home Legend
    Join Date
    Jul 2014


    The current implementation of the Domoticz via the HGI80 also doesn't get the DHW setpoint or differential. So there much be a command to query that from the controller, rather than it sending this information out. In fact I wondering if anything is queried from the controller or is it all just listening for the moment.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts