@b-bech-l

The reason why we cannot give you transparency is because we simply don’t know ourselves how long it will take. We are currently working with the MFi Test labs to certify our product. This MFi process is under NDA so we cannot simply share all the details on what’s going on and where we are at.

What I can say is that we have had some setbacks due to improper implementation on our end, but also due to delays caused by Covid19. Having said that, my hope is that we will have submitted all the materials/documents/samples needed by next week. After that your guess is as good as ours as to how long time it will take. We have never completed a HomeKit (or MFi) certification before, so this process is completely new to us as well.

I know that this is not what you want to hear, but it is the truth.

I also feel the need to say that even though communication with Apple has not always been the quickest, they have been very professional and helpful towards us. So I will not put any blame on them.

Strange. I tested it just now on iOS 13.3.1 and it works.

Calling:

[button disconnect];

Causes:

- (void)button:(FLICButton *)button didDisconnectWithError:(NSError *)error;

And you are sure that the delegates are set properly and that you are not accidentally calling on a nil-object or something?

Can you tell me if you are using the fliclib or flic2lib? Also, does this callback not get sent when you manually call the disconnect method of the framework, or does it not get sent when the button goes out of range?

@poczta I don't have an IR in front of me to confirm, but from my notes this should be the pinout (in order):

• Tip - Red - 3.3V
• Ring - White - RX (IR Wide Receiver)
• Ring - Green - TX (IR Blaster PWM)
• Sleeve - Black - GND

However, this will be at your own risk. Let me know if you need further info!

Regards,
Anton

Thank you for posting this! It is really nice for us to hear about good use-cases like this.

I think bt .tn closed down (or similar) about a year ago unfortunately.

To your questions:

1. I believe that the output from both stderr and stdout is consumed within the Flic app. This is if I recall correctly. If so, no output is available. This could be changed in a future release, but for now it is the case.

2. To be honest with you, this is largely a business decision rather than a technical requirement. Sure, some features, such as IFTTT, Zapier, Microsoft Flow, need a Flic account in order to work, but in reality the app does not really need a login for most features. What I can say though is that once you are logged in, the app will not rely on our backend in order to work locally (at all). If our backend goes down your app will continue to work fine, unless of course you log out (in which case you would not be able to log back in again). I do understand your concern and if you truly want to have an offline solution with full control, then I recommend that you take a look at our https://github.com/50ButtonsEach/fliclib-linux-hci. Using that you could yourself fully implement Flic into a Raspberry Pi, for example. If you feel really motivated and don't even want to use our SDK, then you can also take a look at the Flic 2 Open Protocol Specification, but maybe that would require a fair bit of work.

3. This is mostly due to Apple’s App Sandbox . Basically the Flic app can not access any folder on your computer other than exactly /Library/Application Scripts/com.shortcutlabs.FlicMac. The app also does not have write access, only read and execute, which is why you have to manually place the files there.

Anyhow, I think it is cool what you have implemented. However, I will say that if reliability is critical to your use-case, then a purposefully build Raspberry Pi server might be a better way to go. It is more difficult to guarantee uptime on a Mac since it can go to sleep mode, software updates, etc.. I mentioned the fliclib-linux-hci earlier and I don’t think it would be very difficult for you to set that up, judging by the code you have already written :)

The Flic app version 4.0.1 for iOS should fix the Security Code issue with IKEA Tradfri gateways. Let me know if you have further issues.

@robert-j-erickson Yes, we know. I am trying to delete this when I see it, but I agree that it is just way too much.
.

Hello again. It turns out that this was in fact an issue introduced with iOS 13. This has now been fixed and will be released new week. Sorry for the inconvenience :(

@garethw00 I have some follow-up questions:

1. Is the behavior the same regardless of the color setting, as in, does it still happen if you choose the option to keep the current color and not alter the color setting?

2. It is slightly unclear whether you use toggle or on/off. Can you verify that the issue is still the same if you have only "on" or "off" and not "toggle"?

3. What exactly do you mean when you say "First one or two turn off, then they all come back on"?

Sorry for the inconvenience, but the more information the better.

@garethw00 I will take another look at the implementation of the LIFX LAN toggle feature next week. Although I can't seem to understand why it would occur. The toggle feature sends the same command to each lightbulb once the toggle state has been decided. So it should not be that they end up with different states.

The only thing I can think of is if some of the lights for whatever reason don't process these commands properly.