Script for feeding Honeywell Evohome data into Emoncms

Here is my latest offering which I will run with for a while and soak test it. It removes the need for a shellscript to run it and I hope has error checking to keep it running.

#!/usr/bin/python
import requests
import json
import time
import math
from sys import exit

USERNAME = 'xxxxx'
PASSWORD = 'xxx'

while True:
    # Initial JSON POST to the website to return your userdata
    url = 'https://tccna.honeywell.com/WebAPI/api/Session'
    postdata = {'Username': USERNAME, 'Password': PASSWORD, 'ApplicationId': '91db1612-73fd-4500-91b2-e63b069b185c'}
    header = {'content-type': 'application/json'}
    # get sessionID
    data = json.dumps(postdata)
    response = requests.post(url, data=data, headers=header)
    str_response = response.content.decode("utf-8")

    #print(str_response)
    userinfo = json.loads(str_response)

    if 'userInfo' not in userinfo: 
        #print "not allowed - header"
        # sleep for 5 minutes
        time.sleep(300)
        continue

    # here havea  connection so can get data
    userid = userinfo['userInfo']['userID']
    sessionId = userinfo["sessionId"]

    # setup and receive data then loop and extract temperature for each device
    params = ""
    url = 'https://tccna.honeywell.com/WebAPI/api/locations?userId=%s&allData=True' % userid
    header['sessionId'] = sessionId
    response = requests.get(url, data=json.dumps(postdata), headers=header)
    str_response = response.content.decode("utf-8")
    #print(str_response)
    fullData = json.loads(str_response)[0]
    #print(fullData)
    if 'devices' not in fullData: 
        #print "not allowed - data"
        time.sleep(300)
        continue


    for device in fullData['devices']:
        stemp = ""
        if params != "": params += ","
        # Add device current temperature
        if device['thermostatModelType'] == "DOMESTIC_HOT_WATER": params += "hot_water_temp:"
        else:  params += device['name'] + "_temp:"
        stemp = str(round(device['thermostat']['indoorTemperature'],1))
        #stemp = str(math.ceil((device['thermostat']['indoorTemperature'])*10)/10)
        params += stemp

    #now generate the insert into emoncms
    url = "http://xxx.xxx.xxx.xxx/emoncms/input/post.json?node=evohome&apikey=8fd1xxxxxxxxxxxxxxxxxxxxxxx4fc2&json={"
    url += params + "}"
    #print(url)
    response = requests.get(url, headers=header)

    # debug - read the response and print it
    str_response = response.content.decode("utf-8")
    #print(str_response)

    del params
  
    time.sleep(300)

apart from replacing the shellscript with the py script there is no real difference from the instructions before.
Hope this is usefulā€¦

Edit - Munged API key. BT, Moderator

This gives an example of the output I have on a tablet ( this has lost its ability to be able to charge - a common USB fault ) so it sits in a prominent place. ( Note this is from a web-page on my main computer so the formatting is more complete on the tablet.

This is created by having a html page that calls 2 screens from Emoncms and combines them using iframes. I had to trigger a re-load every 5 minutes because the graphs do not move with time but the values outside the graphs do - maybe a weird defect with emoncms as within emoncms they do update. However it works and I am pleased with the result.

The next improvement would be to combine all into one Emoncms screen but that would involve pulling data directly from Agile source rather than using the app.

I use requests and have gotten bit by this one, or rather the lack of including itā€¦

From Quickstart ā€” Requests 2.26.0 documentation

You can tell Requests to stop waiting for a response after a given number of seconds with the timeout parameter. Nearly all production code should use this parameter in nearly all requests. Failure to do so can cause your program to hang indefinitely:

requests.get('https://github.com/', timeout=0.001) Traceback (most recent call last): File "<stdin>", line 1, in <module> requests.exceptions.Timeout: HTTPConnectionPool(host='github.com', port=80): Request timed out. (timeout=0.001)

Note

timeout is not a time limit on the entire response download; rather, an exception is raised if the server has not issued a response for timeout seconds (more precisely, if no bytes have been received on the underlying socket for timeout seconds). If no timeout is specified explicitly, requests do not time out.

1 Like

Thanks for that - good to learn about the timeouts and interesting article. If you were the one who removed my api key thanks as well.
I have put the timeouts in - interestingly needed to increase timeout to 1 sec on the honeywell request.

YVW, S.

I figured youā€™d find it useful. (I sure did)

Yes, that was me. :wink:

1 Like

Just to say, thank you Frank and Andy, Iā€™m running the script on my Pi pulling Evohome data and itā€™s working great! No issues setting it up at all.

Mark

As the owner of a shiny new evohome, and an emonpi set up that is only a couple of months older, Iā€™m looking forward to saying the same as @markb.
At risk of getting somewhat ahead of myself here but, in anticipation of that moment -
Thanks, @fversteegen, @Andybeevers and others contributing above.

did you get it working?

Hi dj,

The most recent post in this thread is a bit over a year old, and the one before that
is a little more than two years old. You might not get an answer. If you do, it might
be quite some time before that happens.

I can highly recommend running Homeassistant if you want to feed data from/to emoncms. Nowadays there is quite good support on it for emoncms.

Hi Frank,

Welcome back!

Thanks for your input.

Hi dj and thanks for remembering

(rest assured @Bill.Thomson, email alerts work nicely for me :wink: )

I didnā€™t try yet, Iā€™m ashamed to say, but I will make the time to do it before winter sets in.
My aim is to combine data from evohome with independently monitored temperatures (distributed EmonTHs) and use that information to find out whether the existing radiators, plumbing etc are sufficiently oversized to work well with a heat pump, when the still-new gas boiler is replaced.

And thanks @fversteegen for the Homeassistant tip - I was already curious about that and will surely be giving that a go at some point.

Thanks Simon - itā€™s possible Iā€™ll be on the same EvoHome journey as you this quarter - lets stay in touch!

Weā€™re planning on putting into our church here for the main halls; and as a big OEM fan Iā€™m keen to feed into into that as the monitoring. (and possibly add EvoHome also for the block of meeting rooms / offices: but with ~ 8 rooms and 20 radsā€¦ not sure the cost-benefit of so many digital TRVsā€¦

Iā€™ve no doubt that evohome could do what you want - Iā€™ve watched it ā€œlearnā€ the characteristics of my installation 2 or 3 times and, in the end, it does an impressive(*) job in controlling all its zones independently of one another. But Iā€™ve learned that optimising the installation (cost-wise) can be non-trivial.

My installer, though claiming some experience with evohome, specified two controllers (and allowed for up to 16 digital TRVs - because he thought the limit was 12 radiators per controller (rather than 12 zones). Having things spread across two controllers is somewhat inconvenient for the user, so I was motivated to learn enough to re-do the setup after heā€™d finished (and gone): in the end there are only 12 digital TRVs in 10 zones. (A refund for the surplus controller and 4 digital TRVs is ā€œin progressā€ ā€¦)

(*) Itā€™s easy to be fooled by one detail tho - the displayed temperature per zone has a 0.5 degC resolution, but is always rounded towards the set point. This means that the sensed temperature can wander randomly within a band thatā€™s 1 degC wide, but the displayed value will remain rock steady, to one decimal placeā€¦ the metrologist in me thinks thatā€™s playing slightly fast and loose with the information, but it is what it is.

Looks like youā€™re pretty EvoHome savvy now!
Do you use Opentherm to the boiler?

Boiler people seem routinely to be weak on the controller side of things.

Iā€™m not surprised really - the Boiler makerā€™s manuals are badly written: make it really hard to understand the control options just with the boiler!
easy to get caught between boiler + controller ā€˜fightingā€™ each other.

And will get worse as the controllers do ā€˜more clever stuffā€™ - so trouble shooting is a pain: the boiler wont do the same thing every dayā€¦ unless the weather/demand etc are all identical too!

The boiler is a Viessmann, and Iā€™ve learned that, although officially ā€œcompatibleā€, they donā€™t play well with opentherm, which would explain why the installer wasnā€™t at all keen on following up my interest in that idea - controllers fighting one another is the kind of reason he cited.
I soon learned that the apparently crude approach taken by evohome, of just demanding heat or not, on a regular cycle but for a variable amount of time, is entirely capable of achieving good control.
In the absence of any boiler modulation parameter for evohome to manipulate ā€œdynamicallyā€, I just set the boilerā€™s maximum output to 25% (so 8 kW instead of 32 kW) and brought the set flow temperature down to 40 degC. The modulation happens automatically (down to 3.2 kW, once the burn has stabilised after firing up). I assume the boiler tries to adjust its modulation to suit whatever the return temperature value is and, if it canā€™t keep the flow temp down to the set value, it will close the gas valve.
8 kW was my estimate of the sustained output needed to cope with the worst spell we had in the last three winters, and 40 degC is what Iā€™ve learned is achievable by a heat pump running with a reasonable CoP.
Time will tell whether we remain comfortable when things get chilly and windy outside. Of course the radiators need to be significantly ā€œoversizedā€ to do the job, and thereā€™s no substitute for an empirical approach to see whether theyā€™re big enough. They are somewhat oversized, certainly.
In one respect, I can take a leisurely approach - the boiler has another 9 years warranty to run, and it will probably be my conscience telling me to stop burning gas, before the boiler warranty runs out.

@JustPlaying Your last comment reminds me - the biggest problem I have with evohome is its proprietary nature.
I can tell that it is doing some clever things, and reasonably effectively. I just wish that it were opensource and ideally also ā€œfreeā€ (as in freedom) so I could see what might be missing.
(As part of the day job I used to tinker with - and have even implemented from scratch - systems for very close temperature control, but in bench-top sized experiments rather than in heating buildings.)

I assume the boiler tries to adjust its modulation to suit whatever the return temperature value is

Actually -Viessmann boilers do NOT do that. I phoned them last week.
They do not even have a Return temperature sensor!

They ONLY module to get Flow temp at the target - ie 40 in your case above.

if it canā€™t keep the flow temp down to the set value, it will close the gas valve.

Yes -they do exactly that. They modulate their pump speed to, as part of managing the desired Target flow. (unless using a LLH with temp sensor).

apparently crude approach taken by evohome,ā€¦ is entirely capable of achieving good control.

Yes - and I my case here of Halls, with high thermal mass - that is good to know! Tweaking the Flow temp a few degrees that is done by ā€˜clever controllersā€™ or ā€˜boiler -built-in-controllersā€™ there days: is not doing much.

On cold mornings - starting the UFH heating earlier would be more effective (wonder if we will add Evohome settings, to get the effect that '2 hours before the hall heating is due to start with a 20C target - start with an 18 C target: )

I can tell that it is doing some clever things, and reasonably effectively.

What kind of things?

Also -Do you have EvoHome on wifi and pulling in Weather forecasts from the internet - which their blurb says is coming orā€¦?

Catching up - apologies, @JustPlaying, for failing to notice your reply, with its questions, before now ā€¦

Almost by chance, I strapped my single temperature sensor on the ā€œreturnā€ pipe, after the CH and HW returns have merged and about 30cm before it enters the heat-only boiler, and have been observing for a couple of weeks or so. Very instructive. Here is the last 24 hours:


and here, for comparison, is my smart meterā€™s indication of gas consumption for the same period

(not quite complete - the consumption from 21:00 onwards wasnā€™t available when I took that screenshot, but it was about 0.9 kWh per half hour). The main features in the emonpi temperature plot are: boiler off up to 2am, then gentle heating till 6am (it was a cold night) before the water heating starts at 6am (the water temperature reported by evohome had fallen from about 53 to around 40 over the course of the day: water heating is limited to the hour starting at 6am) and evohome decides the water is hot enough just before 7am, which is when the first zone demands heat. More zones demand heat at 8 and 8:30 (one can see the return temperature dip as more radiator valves open), and from a little after 9am, the zones are all close to temperature and evohome drops into TPI operation, which continues over most of the day.
There was an octopus saving session for an hour starting at 5:30pm and, in the interests of minimising electricity consumption by the boiler and pump, I turned the heating off then too.

Mine is an S-plan system and until recently I had been unclear how to ensure that the boiler was always condensing fully: the high flow temperature apparently required for water heating seemed to be a problem and for a while I didnā€™t use the boiler to reheat the HW cylinder at all (using the immersion heater instead). This meant I could set the boiler flow temperature very low (e.g. 37 degC was fine in the mild autumn weā€™ve had) and be sure that it was condensing fully. The heat-only boiler being used in the way its name would imply, perhaps.

Independent of this, Iā€™d limited the maximum output of the boiler to 25% (because 8 kW was my estimate of whatā€™s needed to to meet the highest demand for heating Iā€™d seen in recent winters) and set the pump speed to low. Both of these changes helped quieten what had been a troublingly noisy set up.

It happens that this combination of heating power and flow speed leads to a delta T at the boiler of around 9 degC. That does the trick, re condensing, because my measurements showed that the return temperature is mostly around 30 degC (see the plot above), only rising towards 40 degC in the recent cold weather. This ensures that even the boiler flow temperature remains far below the point (a maximum return temp of 55 degC) where condensation is said to happen. Sure enough, the clouds of ā€œsteamā€ commonly seen coming out of boiler flues are completely absent in my case. I infer that all the steam is actually condensing in the heat exchanger, usefully, instead of when the exhaust gases emerge from the flue into the cool outside air.

Belatedly, I realised that I could set the maximum boiler flow temperature to 60 degC and be confident that evohome would cut its demand for heat and turn the boiler off long before the actual flow temperature gets anywhere near the set value. This is confirmed by the plot (in particular the many hours in TPI mode, when evohome is calling for heat for a minute or two at a time, once every 10 minutes. What I called crude but effective.

With this setup, and relying on the ā€œhot water priorityā€ setting in evohome, it is safe to let the boiler reheat the water in the cylinder. (I had the installer connect both the coils, so the cylinder has a very efficient heat exchanger, and the measured return temperature ramps up over the course of an hour or so starting at 6am. The boiler flow temperature does eventually get to the set value, 60 degC, at which point it gradually modulates its output down from 25% to the minimum (claimed by Viessmann to be 10%, i.e. 3.2 kW). At around this time, evohome turns the boiler off because the stored hot water has exceeded its set temperature, 51 degC.

At this point the hot water priority no longer applies and the piping hot water in the system is diverted straight into the radiators, just when evohome starts to warm up the first zone.

The measured return temperature then plummets from around 56 deg C to around 25 degC as soon as any radiator valves open and, immediately, the boiler is back and condensing completely.

Sorry for the long and wordy post, but with this measurement, I have little doubt that the boiler is working properly, and Iā€™ll guess that heat is being extracted from the burning gas with a %age efficiency which is in the high 90s (apart possibly from a few minutes towards the end of the water heating). Iā€™m left thinking about boiler condensing efficiency in a way that has strong parallels with heat pump CoP: they both need a low return temperature.

PS - to answer some questions, the internet weather info isnā€™t really the whole story for us - ours is a leaky house and the killer is when lowish temperatures combine with a stiff ESE breeze. A low outside temperature with no wind isnā€™t such a problem. But Iā€™m trying the ā€œinternet-based weather compensationā€ anyway. Too soon to tell.

PPS - as a ā€œheat-onlyā€ boiler with an external pump, the scope for being clever is pretty limited: only one output temperature (the maximum flow temperature can be set in degC), and a maximum output power can be set (between 100% i.e. 32 kW and 11% which is not quite the 10% advertised, but is near enough that I donā€™t care). From observation, the boiler fires up at over 25% output and has a period of grace (which may be as long as a minute) during which the burn has to stabilise and during this time it will modulate down to its maximum setting, or below if needed to avoid exceeding the set flow temperature. I dare say that ā€œsystemā€ and ā€œcombiā€ boilers can do more, as they can manipulate the speed of the flow from the internal pump.

Thanks Simon - youā€™re on the right track.
Time for you next to add alot more temp sensors - by updating the emonTH firmware first.
More data is always what folks want here!

Oh - and a Diagram of the system - a picture paints a thousand words!

It looks like the Viessman boiler is hunting - and firing at the max ā€˜6 times per hourā€™ setting that you selected in the EvoHome settings - when the house is hovering near desired temperature.

Efficiency wise - I wonder if any folks here would suggest trying to reduce the number of ā€˜firings per hourā€™ - as each one loses some gas in the pre-flush before fire ?