FlicTeam

@djadin14 maybe you got a defect unit. You should contact support at https://flic.io/support and see if you are eligible for a replacement.

@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.

@j that is the simplest way to get automatic access to your flows. You can probably set up your manual web hooks if you want, using the http request action, but you need to manually enter the url.

@j the homey action is cloud based. The Flic Hub communicates directly with the Homey cloud servers.

@kerry-thacher the action should definitely be there for Flic 2 buttons, as long as they are directly connected to a phone/tablet (not through flic hub).

@gabrielmgrossman Please file your issue to https://flic.io/support.

The problem is that groups can be pretty dynamic. You can hold the play button on one player and it automatically joins another group that is playing music in your household. And with the sonos app it is easy to move around speakers between different groups. That said, it is possible that a group id that was valid when a flic was configured might not be valid after a while after grouping back and forth.

That's why we think it's more simple to pick a player you want to play on, and we will then at runtime when the action is executed check which group that player belongs to and play on that group. May I ask in what circumstances this strategy is a bad idea?

@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.