I've been happily using Node Red with the hub for a few months now. Just use the internet request function with an http input node and a switch node!
Here's how I've configured a single click in the Flic app
And here's what my switch (in node red) configuration looks like:
On receiving my new flics and hub today, I'm reminded how frustrating the memory management is in the iOS app - you can't let your phone go to sleep or switch apps without the whole app reinitialising, and needing to re-connect to a hub every time. This is a really slow process. Could someone look into how the app runs and stays in memory? It's not uncommon to set something up, press a button and check what's happening in my physical environment, only to come back and realise my phone is asleep and the app has shut down.
@Emil Really? This is the exact reason why I just backed your new campaign... I was told that it wasn't going to happen. And it's why I backed the initial campaign, because it was promised.
I'm confused and a bit bummed. I'll keep my pledge open, because I actually still believe in your product in general, and was interested in the updated button - but man, y'all could have been a HEAP more transparent about this.
I've been happily using Node Red with the hub for a few months now. Just use the internet request function with an http input node and a switch node!
Here's how I've configured a single click in the Flic app
And here's what my switch (in node red) configuration looks like:
@svensson-martin buttons will work without the hub, the Flic app has two screens, one for setting hub actions, one for setting actions via your phone, so they still support using the Flic with just a phone.
Excellent news, thanks @Emil
I initially intended to migrate my Flic buttons slowly from my RPi to the hub, but after I accidentally corrupted my Sqlite db containing the flic mappings, it was a rush to get them up and running completely via the hub! Have to say the process was quicker than the SDK 
Given the connection and responsiveness of Flic is far greater with the hub, even if the hub isn't doing any actions itself, it's a brilliant upgrade for Flic owners. That being said, half my Flics are operating in the hub actions
So many of us asking for this.
It really would be excellent if an HTTP request identified the button being pressed. Even if it were by exposing a variable that we could drop into the body by default $ID - so that setting up an HTTP request to work with an external system would be relatively quick.
An even more ideal scenario would be enabling us to save some defaults for quick insertion via a 'Apply defaults' button. For example, a url (http://127.0.0.1) a default port (8080) a default route (/flic) a default method (POST), a default content type (application/json) and then a body template (so we can put in a Key and $ID variable value), would make bringing new buttons into commission so much easier.
@Emil Haha, yes, fliclib-linux-hci SDK.
I understand the battery life concern - it had factored into my thoughts a little, but good to know the specifics of how much of an impact it makes.
Me personally, I'd be making it pulse 6 times (or so) and that'd be it. Obviously, when/if opened up, everyone will have their own way of using it and might see the battery life decrease significantly.
When you say 'currently connected' would that mean an increase in power usage as well?
I'm not sure if the firmware on the button only broadcasts a signal, or if it receives a signal as well (I guess it has to expect some sort of pairing signal for bluetooth, but maybe not any specific data packet)
The other risk is limiting the battery life of a button's battery if this is a feature used quite a lot.