@stevehooper yeah we should really try to add a direct Home Assistant integration from the Flic hub someday, since it is so popular...

In the meantime, can you use the Internet Request action in our app to send a simple http request to your device running Home Assistant maybe?

We are today announcing a Beta release of some new features in the Hub SDK that can be used together with Flic Twist.

In order to seamlessly continue to work with the rest of your smart home devices that you might have assigned to other triggers on the Flic Twist, we introduce the concept of Virtual Devices. A Virtual Device is handled by the Flic Hub firmware just like any other supported real device, but its functionality is implemented by the user in the Hub SDK, typically by writing some kind of bridge software that sends commands and receives update events over the LAN to/from the real device. If for example the brightness of a (real) light is changed by some external means, it is possible to tell the Flic Hub firmware from javascript about the new brightness level, which the hub then forwards to the Flic Twist, so that the LED status can update accordingly. That way when you twist it, it will start from the correct position.

We are also adding a "message" action that can be used to send arbitrary strings to your scripts whenever the action is triggered. The intended use case is to be able to trigger custom code also for Push/Double Push in the Selector feature or perform some action when a specific point is reached in Advanced Dimming or Scene Blender.

The virtual devices can be created in the Flic App and be set to be controlled by a Flic Twist as follows:

Using this piece of code, updates are received in your javascript code after configuring a virtual device to be triggered in the Flic App for a specific Flic Twist:

const flicapp = require("flicapp");

flicapp.on("virtualDeviceUpdate", (metaData, values) => {
    // The values object can contain hue, saturation, brightness, colorTemperature, volume, position (for blinds)
    console.log(`Twist ${metaData.buttonId} updated virtual device ${metaData.virtualDeviceId} of type ${metaData.dimmableType} with these values: ${JSON.stringify(values)}`);
});

When a device is modified externally, we use this function to inform the system of the change:

flicapp.virtualDeviceUpdateState(dimmableType, virtualDeviceId, values);

The dimmableType can be either "Light", "Speaker" or "Blind". The values is an object containing at least one of the fields mentioned above that is appropriate for the corresponding dimmableType. For example:

flicapp.virtualDeviceUpdateState("Light", "my_ceiling_light", {hue: 0.6, saturation: 0.7, brightness: 0.8});

The values themselves are always floating point numbers between 0 and 1.

Configure an action message to be triggered by assigning the following action in the Flic app:

The action messages are easy to receive, just register a listener as follows:

flicapp.on("actionMessage", message => console.log(`Got a message: ${message}`));

We'd love to hear your feedback!

We are slowly rolling this out in different regions. Stay tuned.

@bulk Yes we have made the submission.

@abboberg All our firmwarers are auto-updated. In some cases we have assigned a specific firmware to specific people on request. Please reach out to us if you want to go back to the public release track.

The current hub fw version is 4.2.11.

Usually when we update the hub firmware we also update the apps. In the apps you can see a Change log in the settings menu.

@steveff Our Matter integration is just around the corner. For the Twist this is probably most relevant for lights, as no speakers I know yet support Matter.

What we also have in the pipeline for Twist is e.g. more configurable steps (4 -> 12) for Advanced Dimming/Scene Blender so that you can trigger an action (e.g. Alexa) with higher resolution and before as well as Hub SDK features for the Twist so that you can build custom integrations.

Spotify has an API (over cloud) that we could potentially use for controlling the volume, but we are not sure if the latency will be low enough to make this action have a good user experience. We also don't like that they don't provide any means to "push out" the volume status when it is changed so that the LEDs on the Twist could update accordingly (https://community.spotify.com/t5/Spotify-for-Developers/Access-to-websockets/td-p/4955299).

@hello_marley the ball is moving according to plan. Please stay tuned

@giannis-yt I would guess at the moment the Raspberry Pi Zero Wireless is one of the cheapest options.

What you should do is to first call bind, followed by setBroadcast(true) on the socket. Then you can send messages using send.
FYI, the API is made to be compatible with Node.js API https://nodejs.org/api/dgram.html.

Hi. You need to manually construct the Authorization header. See https://en.m.wikipedia.org/wiki/Basic_access_authentication.

@thomas-vorndran Hmm ok... What Hub FW version do you have (and what Hub variant) and what app version?

@stevehurcombe said in Matterbridge, Flic twist and Home Assistant:

Hi,
I've installed Matterbridge, connected it to Home Assistant and I've connected it to the Flic app.

However in the app all the devices show as the name 'Matter device'. What am I doing wrong? Obviously I'm aware that there are two API connections and three developers involved, but I have to start somewhere.

Ok, let's start here then
The name that shows up is read directly from the remote device over the Matter protocol. The name is stored in the NodeLabel attribute in the (Bridged Device) Basic Information cluster. If the name is missing, we try to show something else, like the product name. You can however change the stored name using the Flic app if you go in to the Providers settings and then under Matter. This will send the new name over the Matter protocol to the remote device and it will be stored there.

Since you are using a Bridge, the name is most likely simply stored in the Bridge software. I'm not sure if Matterbridge has a UI to configure the name or not.

Secondly, I've added a Spotify account to Home Assistant, which then appears as a media device. Matter supports Media, can that be enabled for the Flic twist? Then I can use it for volume control and playback and even track\playlist selection.

In my opinion the Media support in Matter is currently not the best. In any case, can you check using the "Matter Other" action to see if it exposes the Level Control cluster (for volume), the Media Playback cluster (for next/previous/skip etc.) and/or the Content Launcher cluster (for launching content either from a search or a URL)?

@thomas-vorndran Sonos will soon require Sonos account authentication for accessing Sonos products. Before this is enforced in a few months, the latest firmware currently requires the user to login using the Sonos account before any action can be saved. So please press "Setup" and then login with your Sonos credentials.

@mosthated Hmm I just tried to reproduce this, but the latency is always instant for me. The LED on the hub should light up when the button is pressed. Does this have the same latency as well? Have you tried any other actions, like turning on some smart light? Just trying to figure out where the issue might be...

@rickard Yes! This will be possible, but note that we have not yet started to ship Flic Duo. We still need to finalize the Hub SDK events for the Duo so I can't give you an example right now. For MQTT itself, please see https://github.com/50ButtonsEach/flic-hub-sdk-mqtt-js.

@mosthated The Android app with this functionality has now been released!

@buckyswider Yeah you shouldn't really trust all the generated nonsense text AI bots spit out, especially if there are no cited sources that can validate the stated facts. In this case, you can ignore everything it says as everything it says is just misleading.

During the commissioning phase, the device does not advertise _matter._tcp but _matterc._udp.

The _matter._tcp service is advertised in the operational state, i.e. after it has joined a fabric. If it has joined multiple fabrics, it will advertise one service per fabric. It will continue to advertise this service (forever) as long as it wants to accept Matter commands and stays on the network.

When I say "advertise", I use the same terminology as in RFC 6762 (the mDNS standard specification), i.e. when a service is "advertised", it means the service is registered on the local network according to the rules in the mDNS standard. On a low level, according to the mDNS specification, this means that unsolicited udp packets containing the dns record can be sent from the device, e.g. when it boots up so that clients performing service browsing can quickly be notified about its presence, as well as that it will respond to explicit queries requesting that service. It seems ChatGPT means "send a udp packet" when it says advertise, which is not really the same thing. It is of course true that a device does not blast mDNS packets all the time as long as it is "advertising" a service.

DNS-SD with mDNS is more or less standard nowadays for devices on the local network that need to be able to be discovered by other devices. Chromecast, Spotify Connect, Airplay, printers etc. all use this protocol.

@pico We currently use QuickJS and it seems like that js engine does not support that Intl feature.

We might add the feature to set time zone, it can be useful for a few other purposes as well, e.g. in timestamp header for our Internet Request action. But right now I suggest to use the workaround I suggested.

@pico As you can see on https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleString, the parameters supplied are only used if the Intl.DateTimeFormat API is supported. We don't support that API and hence you can't get any time zone support, unfortunately.

I would suggest you to manually extract the components using getUTCHours, getUTCMinutes, getUTCSeconds etc. and then apply your time zone offset and DST formula manually, which should be doable if you know you will only be using a fixed time zone.

@buckyswider _matterc._udp is for commissioning, so that one is only present while the device is "pairable", typically 15 minutes after boot when the device is factory reset (i.e. no Matter pairings yet).

_matter._tcp shall be advertised after the device has been commissioned (paired), one service per "fabric" (i.e. per "hub" it has been commissioned to), as long as it is powered on and connected to the network. If it does not advertise this service, it will not be possible to reach it by Matter controllers. If you don't see this service when you expect to, it seems like a bug in that device.

Maybe you have devices from other Matter brands you can test with?