Now, as someone who is both a home owner and a member of other homes (I installed an ecobee for relatives and I’ve helped troubleshoot issues for them), it would be nice if I could use the power of beestat to guide my suggestions or spot potential problems, instead of being stuck with ecobee’s Home IQ interface for their system.
I’d imagine the Change Thermostat dialog could show thermostats you own at the top, and thermostats shared with you on a separate line below that (if one is both a home owner and home member).
I realize this could potentially be a significant additional load for beestat to deal with. Perhaps try the API call on the server side to see how many additional thermostats this would pull in?
If I’m correctly understanding the changes in logic to support this, this only impacts fetching the thermostat identifiers, and the rest of beestat’s code is unmodified.
Rather than falling back to an exception handler, both code paths should always run, and the resulting $response['thermostatList'] objects would need combined into a single array that the two foreach($response['thermostatList'] as $api_thermostat) { … } sections would iterate over.
It seems like the beestat UI treats every thermostat as distinct, except for maybe the Visualize feature, so I don’t think it’ll cause conflict having two separate locations. And this could already happen if someone registered ecobee thermostats at two different places.
@ziebelje Would you be willing to accept a change that made beestat always fetch both registered and shared thermostats?
I’m new to PHP development, but this sounds simple enough for me to try to take on and I’d find it rather helpful.
(I recently visited the relatives whom I had set up their ecobee thermostat for them, and being able to use beestat’s visualization through logging in with their account was so much more useful than ecobee’s own Home IQ for helping troubleshoot their ongoing HVAC concerns.)
Alternatively, it may make sense to add a new configuration setting to opt-in to fetching shared thermostats, not just ones that are registered to your account. But that would be a far more involved change to beestat’s code, and I’m unsure of how best to go about that.
Today, when you open beestat (and also automatically behind the scenes at least once per week), beestat does a sync of your account. The first step in this is getting a list of your thermostats. I first look using the ecobee API, and if no results are returned, check this other endpoint. The reason I don’t always do both is because the exception flow uses an undocumented API and I’m not sure if it’s well-suited for the amount of traffic I would send it from my background sync. It might be fine, it might not…I was trying not to rock the boat too much.
The current workflow doesn’t really help you, because it’s never running and so you never get the other thermostat. The way the official ecobee API works, I have access to thermostats that are shared with you, but I just can’t get a list of them.
If I knew that you had shared thermostats, I could use that information to conditionally hit the undocumented endpoint so I’m not sending these calls for every user. Finding that information automatically is preferred, or I could add a way for users to set this flag…I don’t love that though. I could also check this endpoint at a lower frequency per user but that just generates support emails because it might take a day or a week for a shared thermostat to appear in beestat.
I don’t know the best solution…but this can definitely be improved! I have reached out to ecobee before about the lack of shared thermostats in my API responses and unfortunately didn’t get the outcome I was looking for. I’ll give this some more thought…thanks for the thoughtful suggestions!
Ah, that makes sense. I didn’t consider the potential infrastructure impact from potentially thousands of beestat users needlessly pinging the undocumented API endpoint. I imagine the majority of users either have the thermostats registered directly, or (as of recently) only have thermostats shared with them - not both. (Even though ecobee’s marketing emails seem to think I will buy additional thermostats every month…)
I agree with you in that any sort of manual step complicates the otherwise simple beestat experience. Having a “Missing a shared thermostat?” button/link in settings and on the thermostat chooser dialog to manually trigger the unofficial API endpoint call, alongside less-frequent background syncs for accounts that have never detected a shared thermostat is… possibly better, but still not great, and a fair bit of UI work.
I appreciate you looking into this, and considering the niche situation, I’d understand if the decision is to just not touch this.
Would it be feasible to add a backend account-specific setting of “always also check shared thermostats”, where folks just email you (via support) to request it be turned on? Or a beestat API call that someone can run in the browser Developer Tools…?
The goal being nobody would have this enabled without understanding what they’re opting in to, hopefully reducing confusion, and it might give you a chance to see how many folks even want this - it might just be me. If it’s worthwhile expanding this later, it’s (hopefully) not much wasted effort.
That said, not an obligation, and I realize you only have so much time to put towards beestat in general. The new fast thermostat switcher is great!
(I’ve been considering asking for a second home invite from the relatives I’m offering HVAC support to, just to have beestat accessible. The native Home IQ UI is just… not great.)
Sure I’m game to try and see if it works. If you get the invite and have some extra thermostats linked, I’ll add a setting you can set to force the secondary “shared” sync to run. For my part, it shouldn’t take too long but I’ll use your account to test against so we’re sure it’s working.
Shoot me an email if you set up the sharing and we can go from there.
Thanks! I’ve gotten sharing set up, and I sent you an email with the relevant details via the Contact link on https://app.beestat.io/ - though there’s no hurry to get to this.
As a quick follow-up to anyone else who discovers this issue - there is now a hidden setting for beestat that you can toggle on with your browser’s developer tools, forcing the secondary sync method that shows both owned and shared thermostats.
I’ll leave it up to @ziebelje to decide if/where to share this information due to not wanting to use this undocumented API endpoint excessively.
