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.
Posts made by areader0
-
Flic app memory management
-
RE: Hacking the flic hub
@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. -
RE: MQTT client Flic Hub support
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:
-
RE: Using buttons without a flic hub?
@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.
-
RE: HTTP 'apply default settings' and 'Flic ID' variable?
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 SDKGiven 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
-
RE: Option to include the unique id of the button with the http request
So many of us asking for this.
-
HTTP 'apply default settings' and 'Flic ID' variable?
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.
-
RE: Possible future LED behaviour via Flic API
@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?
-
RE: Possible future LED behaviour via Flic API
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.
-
Possible future LED behaviour via Flic API
I doubt this is actually possible, but unless I ask, I won't know!
It would be excellent if the LED of the Flic button was accessible to program in some way - even if it was with restricted patterns so as not to be confused with the regular not-connected pattern.
Here's my use case, I'm sure there may be others:
Using Node-Red and a Raspberry Pi I am controlling my Hue Lights in my home - as the sun goes down, I've been automatically changing the colour of my hue bulbs from a blue/white light, to a yellow light - but before this happens, I've been flashing my hue bulb red, and Node-Red then waits for a click of my Flic button before beginning it's transition. No click - the transition continues, with a click, the transition is terminated and it stays on the whiter light.
It would be excellent if the LED on the Flic button itself could flash for a similar 'deadman switch' kind of scenario, when a hue bulb isn't handy or isn't related to the task to be achieved. For example, my coffee machine via a Wemo is set to turn itself off at 9am, but if I'm at home and haven't had a coffee yet, and am sitting at my kitchen bench, it would be great to have a 'warning' flash via my flic, and be able to intervene in order to stop the machine turning off.
As I said, probably a pipe dream, but would be a small and very cool way to add a significantly powerful feature to the Flic buttons.