Currently working on
Currently working on
If it helps Jasper I can give you short term access to my evoHome account so that you have a live XML feed. I have 10 zones + HotWater and I have a currently unused second controller so could easily add that to test dual controllers.
I do have one zone at the moment that does this all the time - not sure why… but it can’t be from the data polling as its way too frequent… it repeats every 15 secs.
2017-12-14 14:49:45.743 [vent.ItemStateChangedEvent] - BathKH_CurrentSetPoint changed from 10.0 to 15.5 2017-12-14 14:49:45.824 [vent.ItemStateChangedEvent] - BathKH_CurrentSetPoint changed from 15.5 to 18.0 2017-12-14 14:49:45.831 [vent.ItemStateChangedEvent] - BathKH_CurrentSetPoint changed from 18.0 to 10.0 2017-12-14 14:50:01.044 [vent.ItemStateChangedEvent] - BathKH_CurrentSetPoint changed from 10.0 to 15.5 2017-12-14 14:50:01.131 [vent.ItemStateChangedEvent] - BathKH_CurrentSetPoint changed from 15.5 to 18.0 2017-12-14 14:50:01.142 [vent.ItemStateChangedEvent] - BathKH_CurrentSetPoint changed from 18.0 to 10.0
Wow, what a very generous offer! Once I get at a place where I want to test with a live system again I’ll definitely take you up on that offer. Your system is a very nice testcase.
The problem you display doesn’t directly ring a bell. Perhaps I can take a look at it when I connect to your system?
I believe you can create a guest account of sorts, maybe you can add some time limit of sorts to that so you can always have control of the access?
Yes, I can just send you a guest invitation. Drop me a PM whenever you’d like me to do that with an email address to send the invite to.
Thanks for the new topic, and once again great work on the updates.
I’m out of the office atm so don’t have access to my evohome setup, but I created a python script which can work alongside this binding temporarily to allow temporary override of zone temperatures (until the next set point).
I’ll grab it later as it might be useful for others / @jvanzuijlen to implement similar functionality within the binding itself (preferable end goal).
I ended up making a new post to keep this a bit seperate.
really good job!
I implemented this binding, using .things to configure it
it created several things, one for each zone I have in my heating system
and I was able to build a sitemap to manage them
my only problem is that I’m not able to write the SetTemperature for each zone
Setpoint item=EVOH_STUDIO_CurrentSetPoint label="SetPoint (±1) [%.1f °C]" minValue=4.5 maxValue=30.5 step=1.0
when I change the value, I can see it moving in events.log
2018-02-18 19:21:47.054 [vent.ItemStateChangedEvent] - EVOH_STUDIO_CurrentSetPoint changed from 20 to 19
but no effect on evohome setting point
is this a problem of my configuration?
or is this an actual limitation of the binding?
thank you in advance for any support
A general update: I’ve been working to get the .items files to work and saw that it required refactoring the binding. From the reviews it also showed that the general structure could be improved and should be done in order to get it merged. Knowing this, I’d like build up the binding step-by-step and include support for setting the temperature for a zone as well.
I reached out to @martinvw to discuss an approach that would hopefully speed up the process, and I’m currently waiting for a response on his end.
All I can ask of you to to please have patience. The reviewers are a small group of people that have to do a lot of work. Therefore review cycles take a little bit of time and require me to keep in sync with the rest of the application as well. My time is limited too, so I can only do so much in a period of time. I trust that someday it will be merged and I can start adding smaller increments more easily!
A little update: I found some time to work on the binding again and revisiting the design as well as fixing the PR comments. I implemented autodiscovery of things when the Gateway is ONLINE i.e. when the authentication info is correct. Currently I only re-added the Display which is now discovered and configured correctly. Both the Gateway and the Display are now configurable via
items file as well, That proved to be more work than I though, but resulted in a better implementation so overall I’m happy.
Next up is making sure the Display still works and making the status updates better (it now is ONLINE by default, which is not correct). Then, obviously, I’m moving on the Zones, not doing temperature setting yet.
I assume this binding is only for the heating side of Evohome - I am probably one of a handful of people owning the Evohome Security alarm kit (which is controlled through the same app, but not sure if the API is exposed). Is there functionality / do you have plans to integrate the security side of things in the binding too?
Currently I am focussing on implementing the heating side indeed. This has been in review for 8 months now, so I’m not really far you could say
Though not in scope for this round of the binding, I don’t see anything against adding the security
Things as well. I don’t have any concrete plans for it though, mainly because I never attached any security related products to my setup. I’d expect that they are exposed over the same API but I wouldn’t know that to do with them
Please create an Issue on my github page describing the desired functionality. If you could include the (anonymized) response data (available in the debug output of the binding) then I possibly could create an implementation based off of that?
Great, let me try to get you what you need on github. Also, feel free to reach out if you need temporary remote access to my system when you come around to looking at it.
So thanks to @xAPPO I’ve been able to get some more data from the api. I’ve spent some time revising the data model I had. It should be very doable to add support for multiple gateways and multiple locations. This I will add together with the revised way of pushing the data through the binding which I’m busy with right now. Stay tuned!
@VibroAxe I recall you mentioning that you actively check for the next scheduling moment. Isn’t that something that is fine by the api when you assign a temporary setpoint? I haven’t investigate it yet, but currently at least I do not know the schedule of a particular zone yet.
Last night I finished the acount setup and the addition of the display. Both work via Paper UI and things file. Also the setting of system mode with the revised structure is operational again.
Next topic of focus for me is to add the temperature zones, by Paper UI and by config file. I’ll investigate the amount of effort needed to update temperature setpoints as well, both permanent and temporary. I’m thinking of making two separate channels for this ChangeSetpointPermanent and ChangeSetpointTemporary. The latter would make a change until the next switchpoint time.
I updated the TS to indicate the scope of the initial PR. I added permanent setting of temperature of a zone to the initial scope since this has been requested by a lot of people. Temporary setting of a setpoint based on the next schedule time would require implementing requesting the schedule as well. I want to keep the PR as thin as possible so I decided to postpone that to a later PR.
Done! I’ve reworked most of the binding, added support for
items files, and added zone channels for setting a permanent temperature override as well as a channel for cancelling any override on a zone. I’m now going to look over my sources, brush it up a bit where needed, create a new release and update the pull request. Let get this in!
Well done. Looking forward to trying this out.
I’ve created a build for the 2.2.0 version, it’s up on github: https://github.com/Nebula83/openhab2-addons/releases/tag/evohome-2.2.0-1
I just started testing myself so it doesn’t have much milage yet, please help me improve that