Anyone use the Flair Puck API?

I want to automate my Fujitsu mini-splits. I ran across the Flair Puck which has an API. I sent them an email asking if the API is intended only for app developers or also for end-users. Here's their reply:

Our API can be used both by end users and App developers! Here's some more information about our API—please read to the end.

We have a full featured API available at api.flair.co.

You can easily explore the responses in your browser by going to my.flair.co/api/structures/12345 (where 12345 is the structure number you are examining). The site at api.flair.co/api/ has information on the OAuth2 flow. Please note that our request response documentation is not up to date. We recommend using the request and responses seen on my.flair.co/api/structure/12345 to code against until the documentation has been updated. We recommend installing a browser plugin like 'JSON Formatter' to make browsing endpoints and responses faster.

There is an example python client available at github.com/flair-systems/flair-api-client-py and a few additional examples available at github.com/flair-systems/flair_api_client_python_examples.

In order to get developer credentials, please send us the email address that you will use to sign in to api.flair.co/my.flair.co.

That sounds promising. I don't know anything about OAuth2 and have just started looking at mentions of it here in the forum. It looks like it is tricky but I haven't figure out yet if it's tricky because it's inherently difficult to do in the Indigo framework or if it's because it's tricky to get developer credentials. If it's the latter, it looks like that won't be an issue.

Any words of wisdom or pointers in the right direction regarding using an API with OAuth2 are appreciated. (I'm an experienced programmer and have done some Indigo Python scripting in the past. I'd say my Python skills are advanced intermediate and are much better than they were when I did my previous Indigo scripting.)

[jay (support)]

IIt looks like it is tricky but I haven't figure out yet if it's tricky because it's inherently difficult to do in the Indigo framework or if it's because it's tricky to get developer credentials. If it's the latter, it looks like that won't be an issue.

Neither. It's tricky because it was clearly designed by committee and is truly a horrible (and big, complex) specification. But it's now standard so we must all deal with it. At the moment we're working more on the server side (to enable OAuth clients like Alexa and Google Home) to enable authentication to a user's Indigo Server via their Indigo Account so we're not spending a lot of time on the client side.

Any words of wisdom or pointers in the right direction regarding using an API with OAuth2 are appreciated. (I'm an experienced programmer and have done some Indigo Python scripting in the past. I'd say my Python skills are advanced intermediate and are much better than they were when I did my previous Indigo scripting.)

We include both the oauth and the requests-oauth Python modules with Indigo (starting with Indigo 7.1) which is generally all you need to implement an OAuth client. Attempting to make OAuth easier to use for our plugin developers (from the client side) is something we would like to do and is on the list, but at the moment we just provide the modules and you'll have to work through the details (though, feel free to ask specific questions here and if we know the answer we'll be glad to share).

That sounds promising. I don't know anything about OAuth2 and have just started looking at mentions of it here in the forum. It looks like it is tricky but I haven't figure out yet if it's tricky because it's inherently difficult to do in the Indigo framework or if it's because it's tricky to get developer credentials. If it's the latter, it looks like that won't be an issue.

The basics of OAuth aren't all that bad -- IF you take the time to understand the logic and flow of how it works (such as understanding the differences in the authentication code, the refresh token, and the auth token). Now, I haven't tried this in Python, only via .NET (C#), but the concepts wouldn't be hard to translate over to Python.

Unfortunately, as Jay mentions, there are a crap-ton of nuances that can be utilized, such as as the spec allows sending a new refresh token each time an auth token is generated; but not all providers do this. Just one specific example I can think of, I'm sure there are many more.

From what I am learned utilizing it in .NET, IMHO the best situation is a base class that implements the "guts" of the OAuth process and a descendant class which implements the JSON/XML/whatever API client. The reason is that basically each request that you do to the service needs to be aware and handle responses. Example, if your authentication token times out, your client can generate a new one IF the refresh token is still valid. If the refresh token goes stale then the user (or your settings) must provide the username/password to get a new token. But then some OAuth hosts don't require the auth code and give you the refresh off hand. Regardless, once you have it you can re-send the request. Ideally the API class handles all this behind the scenes so that logic of the program doesn't have to worry about it. Goes back to what Jay said about it being large and cumbersome.

If you are targeting one specific API, thought, you can easily tailor the client to it and it isn't too bad.

Adam

Thanks for the input, Adam & Jay. I think I’m going to bite the bullet on this one. The downside to it being cloud-based, of course, is that when (I’m not feeling optimistic enough to say “if”) the company goes under I’m dead in the water. I don’t know if the thing would be completely bricked or only work manually, but I guess all of us here live in the bleeding edge, right?

Did you ever get anywhere with this? I'm still working on solving an HVAC issue in my house where one room is getting way too much air flow. I've been looking at controllable vents to solve that problem. Looks like Flair is the only one with an approachable public API.

I'll probably order the components and stay playing with the API in a month or so. Busy until then. But if it's doable, I'll be writing a plugin for the system.

No, I never got started. I just never seem to have the urge to work on weekend programming projects these days.

No, I never got started. I just never seem to have the urge to work on weekend programming projects these days.

Did you install the vents? Can you describe your setup?

No vents, I don’t have central heating. I bought two thermostats to control my two mini-splits. They have worked well. The main issue in my house is that my wife is not into controlling things from a phone app so she wants to use the mini-split’s remote. The remote isn’t in sync with the thermostat so we can run into problems when two different systems are trying to control the same device. If both are active, you don’t know which display is correct.

Ah, OK. Thanks.

FYI All - I just installed a Flair Vent and Puck in one of my bedrooms. Trying to solve an over-cooling problem with the smallest room in the zone. I've requested developer access to the Flair API. I hope I can figure out a way to deal with their OAuth system. A brief look at the API docks looks like it might be possible.

When I actually get started on a plugin, I'll post a thread in my forum.

Any Flair users - please see viewtopic.php?f=216&t=23449