Yeah, it is a bit old i think, we just moved to a new house and it was already installed, i had to fiddle around to get the gateway to work as it looked like it was never used… will have a play and see what i can get out of it. Thanks!
maybe a gateway that was unused for years could get a firmware update? I have as well a GW01, an old one but it reports with a type 3.
in 2021 EPH changed the API. This triggered the move from pyephember to pyephember2. In that change the API endpoint /zoneProgram was introduced and also MQTT and other things. Back then users were moved slowly to this new API (not sure what that ment; maybe in the background old systems like mine got a firmware update pushed). For me HA things stopped working one day and I had to move to pyephember2 (in the App this would have been handled transparent and you would not notice). So maybe, if you activated an old system that was not moved to the new API, maybe the EPH cloud recognizes this in the next days and updates your system in the background (not sure how they schedule this if this is the case)?
Yeah sounds about right, I think the gateway was never used as I needed to pair it to the Controller, will have a look in a few days and see if it gets an upgrade, will also look into anyway of forcing an update. Thanks
Hi UTZ, did you get a chance to look into the logic when the mode is set to ALL Day. I think the logic is taking that to mean the system is using the the ‘On’ target temp as though the system was fully on for 24 hours, but it actually means the system is on from that start of period 1 to the end of period 3, then it drops to the setback temp. Thus the logic is
Mode
-
‘On’, sets the basic target temp 24 hours a day
-
‘Auto’, sets the basic target temp for periods between On/Off of each of the three periods scheduled each day. Outside these times, the target is reduced by the set back temp.
-
‘All Day’ sets the basic target temp between the start of P1 to the end of P3 of each day, then falls back to the reduced setback temp
-
‘Off’ not sure if this is truly off or sets the system to the set back temperature.
-
Holiday mode, Ignore mode and set off between a given start and end date/time
-
Frost protection set, if so, then temp not allowed to go below 5 deg
-
Boost set. raise target by a given number of degrees for a given period.
You can see on Saturday, 10th Jan we had the mode set to ‘All Day’, that should mean from 8 am (P1 on) to p3 off (9pm) the target should be 21 degrees. However from midnight to 8am the target should drop to 19 degrees which is missing. However at 11am we left home and changed the mode to Auto at which point the target correctly drops to 19 degrees, As we returned at 6.16 we reactivated the ‘All Day’, mode and the target returns to 21 degrees which is correct. However at 9pm P3 off, should reset the target to 19 degrees but as you can see the target does not change.
I think the issue is handling the target temperatures when the mode is set to ‘All day’.
I hope this insight helps.
EPH understands the modes ON/OFF/All Day/Auto (there is also Frost and Holiday) and then Boost.
The integration in the current version understands ON, OFF and Auto which are corresponding to the EPH modes. The integration can also do Boost. What the integration currently does not understand is All Day, Frost and Holiday (if you select these in EPH it would not know what to do; it probably shows if its heating and setpoints and so on).
I think for now I leave frost and holiday modes out. I am not sure if we need the all day mode? I can see if that can be put in.
Currently I have a problem with EMBER-PS2 and EMBER-TS2 regarding the setpoint in auto mode (and all day is probably the same). I try to figure out how the system reports the setpoint changes. I have someone running an experiment and when I get the results I can implement this and that hopefully also fixes what you see (I think that is the same issue).
Does your EMBER-PS2 system have a dedicated ‘set back temperature’? I know the EMBER-TS2 has a way to program times and setpoint temperatures. However, my EMBER-PS only has the 3 time periods P1, P2, P3 that are activated when in auto mode, using the setpoint selected on the thermostat. I looked at the EMBER-PS2 manual and could not see a ‘set back temperature’.
You are right the manuals are certainly lacking. The R27-RF(V2) doesn’t mention setback, although it is described in the RFR(v2) thermostat manuals. P06 - Setback Mode on page 25 if you have access to that.
ah ok, so it exists. I have a look at that manual.
1 Like
The manual is avaialble as a PBF on the Ember website:-
RFR-V2_Datasheet-1.pdf
ok we need to find out on what pointindex that feature is communicated. You posted some of your debug information a while back. I have a look if I find the 3degree setback in there some where.
I suspect it is
“pointIndex”: 34,
“value”: “20”
indicating a setback of 2 degree. Maybe. What you could do is to have have a look at the ‘Download diagnostics’ output from your zone (that now reports just the pointindex values without many of the other data.) Then set the setback to something you did not use before (4degree) and after the next http update one of the pointindex should show a 40. I guess its that 34 one.
It seems that during auto mode all EPH devices calculate the setpoint different. The EMBER-PS, EMBER-PS2, EMBER-TS2 and EMBER-RS all do that in different ways. I guess some engineer wanted to create a maintenance challenge for themselves when defining all these cases.
1 Like
I released version 3.7
-
Changed the HAVAC modes (only OFF/HEAT as modes, rest via preset). So the climate entity is either OFF or it is on HEAT. When HEAT it can be either just be HEAT (the EPH ON) or in the modes AUTO, ALL DAY or BOOST selected via the preset. This seems to me the best way to map the EPH behaviour on the HA climate entity.
-
Integrated sensors in zones to monitor heating times. I added sensors to the zone devices that now measure the heating system on time per day. There is also a sensor measuring overall boiler on time per day.
-
Integrated sensor to monitor gas consumption. I added a sensor that measures gas consumption. This assumes the system controls a gas boiler (if not just ignore this). It makes the assumption the boiler uses a fixed amout of gas per hour running. You can determine this by looking at your gas meter in the beginning of the day and the end and then see how long the thing was on during the day. This gives you a reasonable estimation of gas usage. This sensor can then be used as input in the HA energy dashboard. So you can then see electricity and gas consumption together (if you have an integration that measures electric energy consumption).
-
A number of stability improvements
-
Changes to accomodate EMBER-TS2 setpoint
Outstanding. I have just downloaded and installed version 3.7 and will report back how that works out. I can see already that the preset is picking up when the thermostat is set to Auto or All Day. I will let you know if the behaviour of the Upper Zone which is set to All Day and was previously not switching the target down to the setback temp after P3 off time has been passed and up to the next P1 On time.
I do have a sensor of the gas meter from the Octopus integration, but that does not provide regular readings. I will reach out to them to see if there is something I am missing or whether I need to use a different integration.
What I can confirm from the data being reported by the two thermostats
Mode - Auto
Current temperature, correctly follows the temperature reported by the thermostat.
Heating, correctly follows when the thermostat calls for heat.
Target temperature correctly follows the schedule.
Mode - All Day
Current temperature, correctly follows the temperature reported by the thermostat.
Heating correctly follows when the thermostat calls for heat.
Target temperature does not follow the logic which is that the target temperature is reduced by the setback assigned to the thermostat from the end of P3 end to the beginning of P1 start
The following shows an example of charts from thermostats, one using the ALL DAY
mode, which shows the issue. the other shows the output for the AUTO mode which reports correctly.
If that could be addressed, that would be fantastic.
In future it would be nice to have a sensor that reports and could set the set back temperature on a thermostat. But that can a v4 project 
Thanks for testing and reporting this.
So it seems that AUTO is ok and ALL DAY has this issue. My first question (and also to others here) do we need ALL DAY? I ask this as some EPH systems do not know the concept of ALL DAY, they only have OFF/ON/AUTO. As far as I can see I can program with AUTO the same beaviour as with ALL DAY (just using P1 and have P2 and P3 unused).
The other issue with this is how to represent the different modes in the HA UI. In the recent change I represent all the additional modes such as AUTO/ALL DAY/BOOST as preset. An argument would be that this way you cant see which exact heating mode it is on. The alternative is to go back to previous way and have OFF/HEAT/AUTO as modes and only Boost as preset (loosing the ALL DAY option).
Besides the above, it would be nice to find out if we can learn the setback temp (either to display or to maybe even modify from HA). For that I need to know where a thermostat with setback reports that. So, please have a look at the zone that has the setback and put it to an unusual value (maybe 4). Then after the integration has done an HTTP poll (visible in the ‘EPH Controls Ember’ device via the ‘Last HTTP Request’) go to the respective zone device use the ‘Download Diagnostics’ button and get the JSON file. In there would be all the pointindex and we need to see which pointindex number reports the setback. If we choose a setback of 4degree this should show a 40 somewhere. From previous samples posted here I assume it is pointindex 34 but I cant be sure yet with a sample size of one.
Out of interest, did that thing update and come to life?
Hiya, it has not updated, not sure if it cannot? ran the Python test and still getting the same back.
urllib3.connectionpool: https://eu-https.topband-cloud.com:443 "GET /ember-back/homes/list HTTP/1.1" 200 269
HTTP RESPONSE: 200
Response Data:
{
"data": [
{
"deviceType": 1,
"gatewayid": "xxxx",
"invitecode": "xxxx",
"name": "xxxx",
"productId": null,
"sysTemType": "EMBER-PS",
"uid": null,
"zoneCount": 4
}
],
"message": "succ.",
"status": 0,
"timestamp": 1769079881065
}
Will see if i can find someone at the EPH side and ask!
Just an update, spoke to someone at EPH, the Firmware cannot be upgraded on the gateways, mine is just a very early model. Will look at getting another gateway and trying that!
1 Like
Hope that works and it is not the RF controller that needs the update (or also an update).