Closed epetousis closed 2 years ago
Hi there! Sorry I haven't had any input in the discussion on #1 yet - all the notifications for it are sitting in my unread/todo inbox still ;-) I've been scanning the subjects as they come in though and it's definitely quite exciting, thanks for all your hard work!
My last couple of weeks have just been rather hectic so been waiting for some space to catch up on the discussion and test it all out myself. I've only for Evap AC on my unit and it's been winter here so I haven't been using it much lately, but am very keen to get the automation up and running in the next couple of months before it warms up here again.
Long story short I'm happy to colaborate / review&merge / release this together if you like.
Great to hear you're still interested in the project. Would much rather have the code merged into here than spun off.
The code could definitely use a bit of cleanup, and despite me removing the MQTT code and switching to HTTP polling, I'm not 100% sure that Seeley stopped using MQTT - I personally think it's probably the better choice. Apart from this it's basically good to go, pending testing with Evap AC systems, as I've only been able to test with a heating system myself.
Yeah in theory MQTT should be more reliable, and I'm pretty sure it'd have to still be in use between the wifi unit itself and the AWS cloud system... unless they remotely auto-upgrade the firmware in the wifi boxes which seems unlikely to me. Could be though.
I had a really hard time trying to get the mqtt stuff to work reliably though, so even if it's technically more efficient I'm happy to go with http if/while it works! Even when I had the mqtt login working, it would at best run for a few hours and then myseriously stop updating again... I suspect there's some painful stuff to do with the AWS MQTT login token system where you probably need to regularly renew the logins or something. Before you can even get to that point there was a lot of pain with the matrix of required packages for the aws login vs aws mqtt with lots of version to version incompatibilities. http can be much simpler in this way :-)
One of my goals/motivations for this module was to try to make it update on-screen faster than their app does, however I discovered most of the delay was in the mqtt itself.
I've just had a play with the official magiqtouch app myself and they've clearly updated things, presumably switching to http api themselves as suggested on https://github.com/mrhteriyaki/MagIQTouch-Control - previously if you changed multiple things at once (switch from cooling to fan-only, then increase fan speed) only one of the changes would get registered. Now every change is registered and comes through correctly, It does appear to be a bit faster too.
So yeah, assuming the http api is the new "official" api, it makes sense to focus on using that really!
Definitely sounds like a reasonable justification for sticking to the HTTP API for the time being. When I last sniffed requests from the app, I couldn't see any requests related to state beyond the initial request, which is why I believe that state refreshes still use MQTT in some form. I'm not hugely fussed about it, though. Setting changes do go through the HTTP API now, so makes sense that you see an improvement there.
I'll sort out getting my changes cleaned up and improving the refreshing process (currently each individual zone triggers a refresh, rather than using something like HA's DataUpdateCoordinator), and after that I'll submit a pull request.
Pull request submitted, see #5.
@andrewleech just wondering what the state of this project is now? My original plan was to get my changes upstreamed here but this repo seems inactive - if you're not interested in maintaining this project anymore I'm happy to spin my code off into its own separate repository (being sure to give due credit, of course).