Tweet
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:
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)
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.
Apparently the full Fault logbook can be retrieved via Ramses II. (Shown in detail later in the document)
DHW set point and differential can be retrieved by Ramses II, but not via the Web API.
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.
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.
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.
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.
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.
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 ?
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.
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.
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.
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.
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.
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
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
Domestic Hot Water Zone:
Current State Current [Time/Date] Schedule
DHW Setpoint DHW Setpoint Differential DHW Temperature
Current State Current [Time/Date] Schedule
DHW Setpoint DHW Setpoint Differential DHW Temperature
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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:
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.
Comment