Yep, same for me. My graphs suddenly got a lot smoother!
Decoded - EvoHome API access to control remotely.
Collapse
X
-
I too saw an outage from approximately the same time however I do not see any increase in resolution.
I use both munin-evohome, and have recently set up domoticz as well - both are still showing 0.5 degree increments. Both use the version 2 API so on a hunch I did some manual tests with my munin-evohome plugin, which can be switched between V1 and V2 API's. The first is the V2 API the second is the older V1 API:
Code:pi@pi1monitor:~ $ ./evohome_test {'temp': 22.0, 'setpoint': 22.0, 'thermostat': 'EMEA_ZONE', 'name': u'Bathroom', 'id': u'1377389'} {'temp': 21.0, 'setpoint': 21.0, 'thermostat': 'EMEA_ZONE', 'name': u'Living Room', 'id': u'1378782'} {'temp': 18.5, 'setpoint': 18.0, 'thermostat': 'EMEA_ZONE', 'name': u'Main Bedroom', 'id': u'1438045'} {'temp': 21.5, 'setpoint': 20.0, 'thermostat': 'EMEA_ZONE', 'name': u'Kitchen', 'id': u'1643296'} {'temp': 20.5, 'setpoint': 20.0, 'thermostat': 'EMEA_ZONE', 'name': u'Hall', 'id': u'1643302'} pi@pi1monitor:~ $ nano evohome_test pi@pi1monitor:~ $ ./evohome_test {'temp': 22.11, 'setpoint': 22.0, 'thermostat': u'EMEA_ZONE', 'name': u'Bathroom', 'id': 1377389} {'temp': 20.77, 'setpoint': 20.0, 'thermostat': u'EMEA_ZONE', 'name': u'Hall', 'id': 1643302} {'temp': 21.86, 'setpoint': 20.0, 'thermostat': u'EMEA_ZONE', 'name': u'Kitchen', 'id': 1643296} {'temp': 21.01, 'setpoint': 21.0, 'thermostat': u'EMEA_ZONE', 'name': u'Living Room', 'id': 1378782} {'temp': 18.98, 'setpoint': 18.0, 'thermostat': u'EMEA_ZONE', 'name': u'Main Bedroom', 'id': 1438045}
I'll switch my munin-evohome graph plugin back to the V1 API for now, its only a one line tweak in the script to do so. (I think in the evohome-munin plugin Git repo, the V1 API is already the default, but I had changed it to V2 recently on my local copy) The domoticz plugin I don't think can be made to use the older API - anyone know ? It would be nice to get the full un-biased resolution on my Domoticz dashboard.
BTW as well as not being rounded to 0.5 degrees it appears the figures do not have the set point bias either. Check out the Main Bedroom temperature which says 18.5 on the rounded output with an 18 degree setpoint even though the "raw" figure is 18.98 - clearly biased towards the setpoint on the rounded figures...
I checked my controller and it is still running the same firmware, so it appears the evohome has been sending raw un-modified temperatures to the servers all along... which means all Evohome devices (evotouch controller, HR92, DTS92, honeywell servers) deal with the raw figures internally and then independently apply a setpoint bias and rounding before local display. (Or in the sever case, before returning figures via the API)
This probably explains why for example a DTS92 might consistently disagree by 0.5 degrees with the Evotouch, as their biasing/rounding algorithm might be slightly different and give a different result for the same raw value which straddles two rounded figures. I've sometimes noticed this on my DTS92.
As the phone apps use the V2 API they are currently still displaying setpoint biased rounded figures. It will be interesting to see whether increased resolution is extended to the V2 API in future.Last edited by DBMandrake; 4 August 2016, 07:01 AM.
Comment
-
-
Had a quick look at the domoticz evo-update.sh script which I'm using from here:
Unfortunately it's not just a simple matter of flipping the python import to the old API like I can do in my munin script, because it is also retrieving information other than just temperatures which is not available in the V1 API.
So it would be necessary to rewrite the script a bit to use both API's, to retrieve temperatures via the V1 API and everything else via the V2 API. A little bit of a pain but not too difficult, so if nobody else steps forward I'll have a go at hacking this in to the script.
Does anyone else here actually use Domoticz with the Honeywell API instead of an HGI80?Last edited by DBMandrake; 4 August 2016, 07:28 AM.
Comment
-
-
Originally posted by DBMandrake View Post
Does anyone else here actually use Domoticz with the Honeywell API instead of an HGI80?
I did a quick check this morning and noticed a strange one : only 1 out of my 9 rooms is now showing more granular info.
I'll check again when i get home tonight and report back.
Comment
-
-
Are you sure you're seeing more granular info on that one zone ? The existing domoticz script polls the V2 API which still only gives 0.5 degree resolution, so I don't really see how that one zone could have additional resolution.
Is that from looking at the exact temperatures on the temperature dashboard or are you judging by graphs ? The graphs will have interpolation which may make it appear there is more detail than there really is.
I'll see if I get a chance to try adapting the script tonight or maybe tomorrow.
Comment
-
-
Originally posted by DBMandrake View PostAre you sure you're seeing more granular info on that one zone ? The existing domoticz script polls the V2 API which still only gives 0.5 degree resolution, so I don't really see how that one zone could have additional resolution.
Is that from looking at the exact temperatures on the temperature dashboard or are you judging by graphs ? The graphs will have interpolation which may make it appear there is more detail than there really is.
I'll see if I get a chance to try adapting the script tonight or maybe tomorrow.
Comment
-
-
Ok I got it to work. You can find the modified version of the script here:
Code:#!/usr/bin/python # # Copyright 2015 - fullTalgoRythm # # Licensed under GNU General Public License 3.0 or later. # Some rights reserved. See COPYING, AUTHORS. # # @license GPL-3.0+ <http://spdx.org/licenses/GPL-3.0+> # # see http://www.domoticz.com/wiki/Evohome # see http://evohome-client.readthedocs.org/en/latest/index.html # import evoconfig from evohomeclient2 import EvohomeClient import evohomeclient import requests import json import datetime import base64 import os import sys, traceback if os.path.isfile("/var/tmp/evo-noup.tmp"): os.remove("/var/tmp/evo-noup.tmp") sys.exit(1) #connect to evohome web portal @ http://www.mytotalconnect.com client = EvohomeClient(evoconfig.usr,evoconfig.pw) #also connect to V1 API to fetch more accurate temperature readings client1 = evohomeclient.EvohomeClient(evoconfig.usr,evoconfig.pw) fi=client.full_installation() systemId=fi['gateways'][0]['temperatureControlSystems'][0]['systemId'] modelType=fi['gateways'][0]['temperatureControlSystems'][0]['modelType'] status=client.locations[0].status() tcs=status['gateways'][0]['temperatureControlSystems'][0] zones=tcs['zones'] currentmode=tcs['systemModeStatus']['mode'] createdev=False updatedev=True hwname="evohome" if len(sys.argv)>1: mode=sys.argv[1] if mode=="init": createdev=True if len(sys.argv)>2: hwname=sys.argv[2] elif mode=="quick": updatedev=False if createdev: #create evohome script hardware r=requests.get("http://%s:%s/json.htm?type=command¶m=addhardware&htype=40&port=1&name=%s&enabled=true&datatimeout=0" % (evoconfig.url,evoconfig.port,hwname)) #find last added evohome script hw r=requests.get("http://%s:%s/json.htm?type=hardware" % (evoconfig.url,evoconfig.port)) hwl=json.loads(r.text) hwid=-1 for hw in hwl['result']: if hw['Type']==40: hwid=int(hw['idx']) if hwid==-1: print "ERROR: evohome hardware not found" sys.exit(1) if createdev: #create evohome controller device r=requests.get("http://%s:%s/json.htm?type=createevohomesensor&idx=%d&sensortype=69" % (evoconfig.url,evoconfig.port,hwid)) #create evohome dhw device r=requests.get("http://%s:%s/json.htm?type=createevohomesensor&idx=%d&sensortype=71" % (evoconfig.url,evoconfig.port,hwid)) #create evohome zones - create all 12 as helpful if they are sequential for i in range(12): r=requests.get("http://%s:%s/json.htm?type=createevohomesensor&idx=%d&sensortype=70" % (evoconfig.url,evoconfig.port,hwid)) #update evohome devices with default name, id for portal access and correct location/name of script to run r=requests.get("http://%s:%s/json.htm?type=devices&displayhidden=1&used=all" % (evoconfig.url,evoconfig.port)) devl=json.loads(r.text) for dev in devl['result']: if dev['HardwareID']==hwid: if dev['SubType']=='Evohome': if updatedev: r=requests.get("http://%s:%s/json.htm?type=setused&idx=%s&deviceid=%s&used=true&name=%s&strparam1=%s" % (evoconfig.url,evoconfig.port,dev['idx'],systemId,modelType,base64.urlsafe_b64encode('%s/evo-setmode.sh {status}' % (evoconfig.srt)))) r=requests.get("http://%s:%s/json.htm?type=command¶m=switchmodal&idx=%s&status=%s&action=0&ooc=1" % (evoconfig.url,evoconfig.port,dev['idx'],currentmode)) elif dev['SubType']=='Hot Water' and 'dhw' in tcs: dhw=tcs['dhw'] if updatedev: r=requests.get("http://%s:%s/json.htm?type=setused&idx=%s&deviceid=%s&used=true&name=%s&strparam1=%s" % (evoconfig.url,evoconfig.port,dev['idx'],dhw['dhwId'],"Hot Water",base64.urlsafe_b64encode('%s/evo-setdhw.sh {deviceid} {mode} {state} {until}' % (evoconfig.srt)))) zonemode=dhw['stateStatus']['mode'] if currentmode=="HeatingOff" or currentmode=="AutoWithEco" or currentmode=="Custom":# dhw has no economy mode and does not turn off for heating off also appears custom does not support the dhw zone currentmode="Auto" if zonemode=="FollowSchedule": zonemode=currentmode req="http://%s:%s/json.htm?type=command¶m=udevice&idx=%s&nvalue=0&svalue=%s;%s;%s" % (evoconfig.url,evoconfig.port,dev['idx'],dhw['temperatureStatus']['temperature'],dhw['stateStatus']['state'],zonemode) if zonemode=="TemporaryOverride": req+=";%s" % (dhw['stateStatus']['until']) r=requests.get(req) elif dev['SubType']=='Zone' and dev['Unit']<=len(zones): zone=zones[dev['Unit']-1] if updatedev: r=requests.get("http://%s:%s/json.htm?type=setused&idx=%s&deviceid=%s&used=true&name=%s&strparam1=%s" % (evoconfig.url,evoconfig.port,dev['idx'],zone['zoneId'],zone['name'],base64.urlsafe_b64encode('%s/evo-settemp.sh {deviceid} {mode} {setpoint} {until}' % (evoconfig.srt)))) if not zone['temperatureStatus']['isAvailable']: continue zonemode=zone['heatSetpointStatus']['setpointMode'] #for custom mode the rooms are assignable so ideally we need to check the schedule and see if the room is assigned or not if zonemode=="FollowSchedule" or currentmode=="HeatingOff": #heating off doesn't support override i.e. heating is permanently switched off zonemode=currentmode # Extract the measured temperature from the V1 API for increased accuracy. Match zones between API's via id/zoneId. for zonetemp in client1.temperatures(): if int(zonetemp['id'])==int(zone['zoneId']): break req="http://%s:%s/json.htm?type=command¶m=udevice&idx=%s&nvalue=0&svalue=%s;%s;%s" % (evoconfig.url,evoconfig.port,dev['idx'],zonetemp['temp'],zone['heatSetpointStatus']['targetTemperature'],zonemode) if zonemode=="TemporaryOverride": req+=";%s" % (zone['heatSetpointStatus']['until']) r=requests.get(req) if createdev: print "Your evohome zones should now be available in the Domoticz"
Here it is as a diff to make it more obvious what I changed:
Code:--- evo-update.bak 2016-08-04 20:46:45.063303828 +0100 +++ evo-update.sh 2016-08-04 22:46:30.607098161 +0100 @@ -13,6 +13,7 @@ import evoconfig from evohomeclient2 import EvohomeClient +import evohomeclient import requests import json import datetime @@ -26,6 +27,8 @@ #connect to evohome web portal @ http://www.mytotalconnect.com client = EvohomeClient(evoconfig.usr,evoconfig.pw) +#also connect to V1 API to fetch more accurate temperature readings +client1 = evohomeclient.EvohomeClient(evoconfig.usr,evoconfig.pw) fi=client.full_installation() systemId=fi['gateways'][0]['temperatureControlSystems'][0]['systemId'] modelType=fi['gateways'][0]['temperatureControlSystems'][0]['modelType'] @@ -103,7 +106,11 @@ #for custom mode the rooms are assignable so ideally we need to check the schedule and see if the room is assigned or not if zonemode=="FollowSchedule" or currentmode=="HeatingOff": #heating off doesn't support override i.e. heating is permanently switched off zonemode=currentmode - req="http://%s:%s/json.htm?type=command¶m=udevice&idx=%s&nvalue=0&svalue=%s;%s;%s" % (evoconfig.url,evoconfig.port,dev['idx'],zone['temperatureStatus']['temperature'],zone['heatSetpointStatus']['targetTemperature'],zonemode) + # Extract the measured temperature from the V1 API for increased accuracy. Match zones between API's via id/zoneId. + for zonetemp in client1.temperatures(): + if int(zonetemp['id'])==int(zone['zoneId']): + break + req="http://%s:%s/json.htm?type=command¶m=udevice&idx=%s&nvalue=0&svalue=%s;%s;%s" % (evoconfig.url,evoconfig.port,dev['idx'],zonetemp['temp'],zone['heatSetpointStatus']['targetTemperature'],zonemode) if zonemode=="TemporaryOverride": req+=";%s" % (zone['heatSetpointStatus']['until']) r=requests.get(req)
The way I did it is open a connection to the V1 API as well, all data except for the measured zone temperatures is still retrieved from the V2 API, then to find the measured temperature from the V1 API, for each V2 zone I iterate the list of returned V1 zones looking for a match between the V1 'id' and V2 'zoneId' fields. When a match is found the 'temp' figure is retrieved and substituted in place of the V2 temperature reading.
Seems to work for me, and I now have two decimal places on my domoticz temperature dashboard...
By the way I've also confirmed from my munin graphs that this new more accurate V1 temperature data does indeed have no setpoint biasing - the difference is clearly obvious in the graphs due to the way I overlay set points and measured temperatures on the same graph - previously every time there was a large set point change from below to above the current temperature (or vica versa) you would nearly always see an immediate 0.5 degree change in the measured temperature at the same time the set point changed, even though the room can't have possibly changed temperature so quickly. (This is the set point biasing)
No such effect now - when a zone is scheduled to come on all I see is the valid, delayed, gradual rise in temperature, no immediate 0.5 degree "rise".Last edited by DBMandrake; 13 August 2016, 11:47 AM.
Comment
-
-
Hi,
Now with some data in, you can see the rather coarse steps on the left of the graphs contrasted with the rather smoother parts of the graphs on the right.
I am seeing ~0.06°C increments now.
Hope this was of interest?
Would love to get clearer information about Revision 1 and Revision 2 mentioned as the key I have only seems to allow me to access revision 1
evohome01.jpg
evohome02.jpg
Comment
-
-
Originally posted by DBMandrake View PostOk I got it to work. You can find the modified version of the script here:
Back up evo-update.sh and replace it with this. Remember to make it executable, and it might be better to use the download link rather than copying and pasting from the text link into an editor.
(Edit: and here it is as a diff to make it more obvious what I changed: http://paste.debian.net/786972/ )
Thanks
Comment
-
-
Originally posted by victorp1612 View PostCould you reshare your updated script please as the links above are dead ?
Thanks
Comment
-
-
I assume there is still no way to log if there is demand for heat? I think I may have spotted a bug. The valves are reading around 21c due to the hot weather. The summer setpoint is 16C. if eco mode is enabled the boiler will fire up. As there is a 8C difference i wouldn't expect the boiler to fire up. if eco mode is off the boiler doesn't appear to fire up.
Comment
-
-
Originally posted by dp11 View PostI assume there is still no way to log if there is demand for heat? I think I may have spotted a bug. The valves are reading around 21c due to the hot weather. The summer setpoint is 16C. if eco mode is enabled the boiler will fire up. As there is a 8C difference i wouldn't expect the boiler to fire up. if eco mode is off the boiler doesn't appear to fire up.
Don't just take what the Evotouch controller says for granted if you have phantom boiler activation - you need to go around every single HR92 and manually check what it's reported set point actually is. I can almost guarantee that there will be a discrepancy where the set point shown on the Evotouch says 16 but the HR92 itself says something higher, thus explaining the boiler activation.
It is possible (if communication messages between controller and HR92 are lost) for the controller to report a low set point on the screen, and yet the system will call for heat from the boiler. The messages from an HR92 that call for heat (relayed via the controller) are completely separate to the indicated measured temperature and set points. This is a "heat demand" figure which is not displayed to the user, nor provided by the server API and is only available via an HGI80.
BTW there is also a bug in Eco mode (which I've reported before in the wishlist thread) both in documentation and operation. Eco mode is documented to reduce "all" set points by 3 degrees according to on screen help and PDF documentation, however in actual fact it won't reduce any zone which is already at or below 15 degrees. In my opinion this is by design and it is the documentation which is in error.
In addition to this discrepancy between documented operation and actual functioning, there also seems to be a bug - rather than all zones above 15 degrees being reduced by 3 degrees then being "clipped" at 15 degrees, instead, if the zone temperature minus 3 degrees would fall below 15 degrees the temperature is not reduced at all.
Thus what actually happens is any zone at or below 17.5 degrees stays at the temperature it was at, yet zones at or above 18 degrees will be reduced by 3 degrees.
So you get the weird situation where a zone set to 17 degrees remains at 17 in eco mode but one that is at 18 degrees drops to 15! Clearly a bug that was missed during testing...
One other thought - although I haven't proven it, I suspect that the bi-weekly "cycle" that HR92's which would otherwise always be closed (due to low set points) do to help prevent valves sticking may actually send a boiler demand and thus bring the boiler on for a short time.
On a couple of occasions in the summer I have noticed the boiler come on when I'm not expecting it to based on measured temperatures and set points, I've literally run around the house checking the set points of all HR92's manually, not found any that should be causing heat demand, but by the time I've been around the house the boiler has gone back off and remains off for the rest of the day - I believe this could be an HR92 doing it's bi-weekly valve cycling.
In both cases the boiler only came on once and only remained on for less than a minute, judging by my 3 minute pump overrun which had just finished by the time I had been around the house checking.Last edited by DBMandrake; 28 August 2016, 11:05 PM.
Comment
-
-
Originally posted by dp11 View PostThanks for that. Time to add a relay controlled by a raspberry pi so the heating is only allowed to come on if it is colder than the set points.
The idea that heating should only come on if the temperature is below the set point and go off if it is equal or even slightly above is false - in all but the warmest weather it takes a constant input of heat to maintain the set point. Doing what you suggest would cause the temperature to oscillate up and down which is exactly what the evohome system strives to avoid.
Better to locate the real cause of the problem.
Comment
-
Comment