administrators

@flic-1b Hmm, sorry but this is a mistake on our side.

I have found your email in our support system and I will instruct my colleague to go ahead with the refund. Again, sorry about this.

@flic-1b Hi! If you made a Duo purchase, you should have been receiving the production updates by email that we send out regularly, (unless you unsubscribed).

But a short recap is that we have been struggling with getting through radio certification, partly due to it taking a lot of time to get a slot for testing and then struggling with some spurious emissions. It's a game of finding the sweet spot through fine tuning components to get the best range possible and this step took a lot longer than it usually takes.

Regarding PayPals 6 month claim period, we did promise "refund at anytime" so if you want a refund we will solve it regardless of PayPal's policies.

We are sorry for the delays but I can assure you that we are doing everything we can to get this product into your hands as soon as possible! There are always new challenges when creating custom hardware from scratch.

@pianosimon Hi! Are you using Flic Universal or the Flic app for macOS?

@kerry-thacher Hi!

Unfortunately, no. At least not from what we have found.

You can use the "alternative keymap" in the Universal Keyboard action to prevent the on-screen keyboard from hiding while the Flic is connected, however, this also limits what we can do with keyboard commands.

(Note that you need to "Forget" the Flic from iOS Bluetooth device list if you change the keymap for it to have effect).

So Apple requires the device to identify as a keyboard to be able to do certain things, like trigger system wide keyboard commands (which is what this video suggests as a trigger for Shortcuts), and this enforces the behaviour that the on screen keyboard disappears.

Sorry about this, it would certainly be a neat feature to be able to trigger iOS Shortcuts without affecting the on screen keyboard.

@josh-k Hi!

The way we get around the keyboard not showing is to report as a "Consumer Control" device, which is what tells iOS that it might not be a full keyboard, thus still showing the on screen keyboard.

It seems that this is also what imposes the limitations on sending key codes to a web page.

Sadly, in my testing I could not find a combination where the on screen keyboard was still visible and at the same time getting key events through to an unfocused web page.

We are still on the lookout for a workaround for this but right now I'm afraid we don't have a solution.

@josh-k I see, it indeed seems like capturing keyboard events without having a text field focused has been restricted since iOS 18.

There might be workarounds but I have not tried them personally, but maybe try this:

Set "contenteditable" to "true" on an element, and have the user tap the element to give it focus:

<div id="editor" contenteditable="true">Tap here</div>

@josh-k

Hi!

I tested this on iOS 18.4, and it seems to work. I tested with the "A" and "Return" to type into the address bar of Safari. Both seem to work.

I also tested on:
https://www.toptal.com/developers/keycode

(Note that you have to focus the textfield for this to work)

Could you let me know if there is any detail I'm missing in recreating this issue?

Note that it's a good habit to "Forget" the device if you go between different keymaps since this is cached for the Bluetooth device.

@beachb_sl

Hi! You can find an implementation of SHA-256 here:

https://geraintluff.github.io/sha256/

@tamengua Hi! May I ask how your filetree looks like? Is the mqtt.js file at the right position? And which firmware version does it show in the HubSDK?
You can also contact us directly over dm-support@flic.io

@philippe-lux-67 Hi!
Sorry for not getting back, we did have a look at the logs but unfortunately there was nothing we could see that would spark an idea for a potential workaround. We do not have the ability to test or update old versions of our app, so I'm afraid there is not much we can do about this.