Hi all,
As mentioned on the forums for the existing Honeywell plugin, I have been working on a Python 3 plugin to support Evohome as it was my last critical yellow dot. As others have commented it was not possible to upgrade Nicks plugin directly, but this plugin is heavily inspired by it and for Evohome users is functionally equivalent, but uses the publicly available evohome-client libraries rather than the official API. This is almost ready to release, I have found a small but irritating bug when I went to deploy on my main server which I should address quickly (and a workaround is a plugin restart after devices are created fixes the issue). I am looking for people to test and I wanted to explain some decisions/implications to allow upgrades.
1) This uses a new plugin-id so it cannot upgrade the existing Honeywell plugin directly, but it will run in parallel so that you can transition any references to the old devices (control pages, action groups, triggers etc). I am in the process of doing this, then once complete I will disable the old plugin and upgrade indigo on my production machine.
2) The devices created will have the prefix "EVO" rather than "EV", this is deliberate to avoid duplicate device names and to ease the migration when the devices are created. If this is problematic I can look to make this configurable but I don't think it should be an issue, but let me know.
3) I have found a number of actions that actually don't make sense (setting a zone to temporary override but without a temperature or on/off value), I have implemented whenever possible to maintain compatibility but I suspect some of these have never actually worked. I will document examples, before I formally release.
4) I have tested this and install should not have any negative consequences and it respects the rate limiting requirements of the API. It includes a lot of actions and given Evohome can take a while for API initiated changes to update the app/controller it is possible some of these have been missed so please accept that I may have missed something, but I should be able to address anything you find. I also do not know if the public client is as robust as the "official" one, but it seems the major difference is in how authentication was managed rather than the API calls themselves, and it appears pretty robust and is the basis for a number of other integrations.
5) My system has a Hot Water System under Evohome control, so I have not been able to test it on a system without a HW zone, again any issues should be easy to address and I believe it is covered but just in case please be warned.
I have yet to create documentation but it behaves in the same way as the earlier plugin (for Evohome users at least, but without the Wifi related options. I even found a bug that unlocked a useful feature (Indigo devices show zone errors, but the code that set the state has never worked) and that showed be one of my actuators had failed (as I never look at the controller itself).
Credit to the great work Nick did on the original plugin, it was a great effort, without which I could not have done this, and to @howartp for getting me into plugin development with his original version of this some time ago.
Please let me know if you need this and want to be involved in the testing, I should have something to publish by tomorrow latest.
Neil