@johan-0 could you try to change the listen
call to
server.listen(1338, "0.0.0.0", function(...
instead?
@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.
@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?
@joacim-n-linder The twist rotational functionality for lights controls lights of the following Matter device types:
Dimmable Light (0x0101),
Color Temperature Light (0x010C) or
Extended Color Light (0x010D)
There is also something called "On/Off Light" (0x0100). These don't support dimming and hence cannot be controlled from Flic Twist (rotational feature). It appears from the comment below that HA Matter bridge plugin incorrectly puts 0x0100 as the device type for dimmable lights and hence the issue.
@mon-bosma you should contact the developer of that plugin to add support for dimmable lights. Seems like a very important missing feature.
@mon-bosma An "On/Off Light" (0x0100) only supports two physical levels of brightness: either 0% or 100%. From the Matter specification of this device type:
"For this device, since its only states are on or off, if the Level Control cluster is implemented, it SHALL not have any effect on the actual light level except for those commands that cause an on/off state change, that is, the “with on/off” commands."
You need to bridge your light as a Dimmable Light (0x0101), Color Temperature Light (0x010C) or Extended Color Light (0x010D) instead if you want the Level Control cluster to have an effect on the actual (physical) light level.
@mon-bosma in matter bridge plugin view, can you please tell me which device types you have on your devices? There seems to be a column for that.
@mon-bosma Exactly what light type(s) do you have, manufacturer and model? Note that there are both dimmable lights as well as non-dimmable lights (only on/off-lights) device types in the Matter standard.
@mon-bosma do you run iOS or Android? What app version do you have? You should see your lights.
We have a business solution that might have the functionality you are looking for: https://flic.io/business/device-manager.