Posts made by Emil

@bytheedgeuk We will investigate this. I'll see if we can change to make it possible to omit the value entirely instead of sending an empty bytestring.

@dhtbrowne The server sends an invalid certificate chain according to https://datatracker.ietf.org/doc/html/rfc5246 7.4.2 Certificate certificate_list:

This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it.

This is a trace when connecting to that server:

As you can see, the second certificate is incorrectly duplicated so hence the last one does not certify the one preceeding it.

If you go to https://www.digicert.com/help/ you can also see that the server is incorrectly configured (second certificate is duplicated):

I suggest you to reach out to the website owner to fix the problem.

@bytheedgeuk could you try an empty PIN by just writing "hex:" in the field?

@bytheedgeuk It's a bit annoying that the PIN code is defined by the Matter standard to be an arbitrary byte array and not a 6-digit integer or something. Byte arrays are entered in hex format using the syntax "hex:010203" to represent the byte aray [1, 2, 3].

Therefore, if your PIN code consists of the ASCII string "123456", then the PINCode field should be written as hex:313233343536. Note that the PINCode field is optional though according to the Matter standard.

Note that the PIN code is not the setup code written on the Matter sticker (with QR code) but a code you set yourself in the lock manufacturer's app (assuming the lock supports a PIN code).

@bytheedgeuk no such log is available unfortunately.

What smart lock are you using and how have you configured your flic action?

@dunderovic so it fails when you try to pair the button regardless if you try to pair it to a hub or phone?

Please attempt to pair to phone without hub, then go to settings in the app and press Submit Bluetooth log. Then we can have a look.

Remember to keep your flic pressed for at least 7 seconds while you pair it.

@house hmm we currently simply list all the flows. Do you have many disabled flows? Is it very annoying that these are listed?

I still see the use case when you want to have a flow assigned but want to every now and then disable/enable it in the Homey app.

@johan-0 could you try to change the listen call to

server.listen(1338, "0.0.0.0", function(...

instead?

@ryan_joyner Can you please try the new firmware 4.3.5?

Hi Michael,

Trust me – we have had long discussions both internally as well as with the Connectivity Standards Alliance about Matter bridge vs Matter controller and in the end come to the conclusion that a controller would be the only useful and feasible option that would make a good user experience for Flic Twist.

The most important point is that there is no support for rotational devices in the Matter standard, so even if we did a bridge, the rotation feature of Flic Twist would not be supported, making it quite useless. We could support only the button on the Twist using the Switch cluster if we were a bridge, but then it would not be supported in e.g. Google Home since they don't support that cluster.

So to fully support Flic Twist with Matter, we came to the conclusion that the only feasible way forward is to make a Matter controller.

Regarding the normal Flic button, we could of course build a Matter bridge to be able to make them appear in other controllers. There are multiple reasons we have not yet done that. First, we are already integrated natively with most of the popular controllers on the market, like Homekit, Smartthings and Alexa, so the customers would not see a big value here. Second, it could confuse the users if we would be a Matter controller and Matter bridge at the same time. Third, developing this, including testing at a test house as well as certification costs would rise to the sky (Matter is already by far the way most expensive integration we have ever made). In any case, it would also have delayed the release a lot if we made both a controller and a bridge. Fourth, we believe many devices that are currently not Matter enabled but only e.g. Homekit enabled will eventually become Matter enabled, making the extra Matter controller like Homekit or Smartthings unnecessary to make the device compatible with Flic. Fifth, being only a bridge, if a user wants to control a Matter device through Flic, it would be necessary to additionally buy a third party Matter controller and have it plugged in all the time, as well as additionally download and use that corresponding app.

Even if Matter had some kind of support for rotational devices as input device, we don't see how it could nicely apply to all our features of the Flic Twist such as push-twist, selector mode, how to update the LEDs according to the status etc.

And just because we at the moment only have a Matter controller doesn't mean that we will not eventually also build a Matter bridge, but I don't see that likely until Matter adds support for rotational input devices.

There is also a feature in Matter that is very seldom talked about – the Binding feature. This is a feature where a Matter "director" can instruct a Matter client device such as a brightness remote control to start controlling a particular Matter light. This way, the client device talks to the server device directly without the need to go through any controller, after the setup is done. Unfortunately, none of the "big" controllers support this feature, and even if it did, it would only be native Matter devices that could be controlled, which we can already control anyway, since we're now a Matter controller.

With the logic in your post that Matter is made to be interoperable, note that all of the big players, Homekit, Google Home, Smartthings and so on are in that case also doing exact same thing ("locking in people") since they only implement one of the sides in Matter, namely a controller and not a bridge. If they implemented a Matter bridge, they would open up so that other apps can control devices that only support their respective protocol. When we asked a few of these players about this at CES, it seems they hadn't even thought of this idea.

For Home assistant on the other hand, you can expose your devices there to Flic using their Matter bridge feature, see https://community.flic.io/topic/18457/home-assistant-twist-another-angle. That way, Flic Twist can control them.

Regarding our "expensive hub" as you say, note that we have recently released Flic Hub mini, which is significantly cheaper than our previous hubs as well as other comparable smart home hubs, and most definitely the cheapest Matter controller on the market (feel free to correct me). We created this to make it an easier decision to start using Flic.

One last point, some/many users (including you from what I understand from your post) only want one single app to control their smart home, e.g. Snartthings or Homekit and for that reason would like to see us being a Matter bridge, so that our buttons and Twists would show up there directly instead of having to use the Flic app. Well, true, but compared to other smart devices (controllable ones), the main interaction point is not the app but the Flic itself. You usually set up the Flic once, and then you can theoretically throw away the app. In the end, our main goal and priority is to make Flic compatible with as many end devices as possible (thanks to the Matter standard, we will now be able to natively support more and more brands), so the way that it's configured is not the most important point, as long as the user can somehow set up the configurations he/she wants.

As a conclusion, it's not that we want to "lock people in" to our hub, it's just that we build what we see feasible to produce, that will satisfy most customers' needs and be a good user experience. In this case, we didn't see the usefulness and feasibility of a Matter bridge for the mentioned reasons. On the other hand, a Matter controller would open up so many opportunities not otherwise possible, so that's where we're currently focusing on.

This post became longer than intended, but I hope it delivers the big picture. Feel free to post feedback.

@ryan_joyner you can create a new udp socket. Just remember to close the old one to avoid resource leaking. The osc module currently exposes no way to close the socket so you would have to add that.

@bukhalina The flic app asks for all the permissions that are required when the action is saved, as well is registered to start automatically upon boot. It might be that Xiaomi had added extra restrictions so that you must manually go into some menu to allow the app to run on boot or something. Exactly which permission did you enable to make it work in the background?

@bukhalina What Android phone model do you have? Works perfectly fine for me on my Pixel 7 running Android 14.

@ryan_joyner Thank you for this bug report. We will investigate.

@szczepan-kuzniarz Thanks! The new ES version is more strict that "new" must be placed before a constructor. We have just released a new firmware update that is more relaxed regarding creations of new Sockets, as a workaround for users of that lib.

The website is up and running now. We have upgraded the js engine to a new modern one. If your previous code is not working, please share it.

@admin-flic please see https://community.flic.io/post/21479

@sgemmen Yeah, it's still on the roadmap. But first we are prioritizing to finish the general available Matter release.

@dainova I would use a Google Pixel with "stock" Android instead of those asian brands which often like to introduce "power saving features" which kills apps every now and then, even though they are declared to stay alive by using a Foreground Service.

In any case, which action are you using and in what do you mean exactly with "more reliable"? Is something not working as expected, in that case, what exactly? Does the button stay connected to the phone (LED should flash green when you press it) or is it something wrong with the action you try to execute?

When you open up the app it should give you a popup or similar allowing you to enable the permission if not already enabled. Is this not working?