@Emil Neat! I am seeing that setting MoveToLevel with OptionsOverride set to 1 does set the brightness when the light is off when it is turned back on via Matter, such as in the Apple Home app (which is something I've never been able to do via any exposed app controls). But, oddly Tapo itself seems to not honor that setting if I turn the light back on via the Tapo app, or more importantly via the wall switch. Seems like a Tapo quirk/bug and not an issue with FlicScript since it seems the setting is properly honored within the Matter protocol.

From poking around more, I found the OnLevel attribute which looked interesting and I was able to set that with matterModule.writeAttribute(thisMatterDeviceID, 1, 'Level Control', 'OnLevel', brightnessLevel, () => {}). This appears to basically do what I want when the light is off, it will always get turned on to the specified brightness level. This has the effect of not keeping a manually set brightness, after the light is turned off and back on it will turn on to the specified OnLevel brightness instead of the previously manually set brightness, but I think that is actually totally fine for my desires in this project.

This is so much fun to be able to work with Matter devices at such a low level! I really appreciate your advice and help with this all!

@Emil Looks like it's fixed in 4.4.1, thank you so much!

Out of curiosity, is there a set time that the Flic Hub LR auto-checks and installs updates? Also, there a log of update history on the device to see when updates were installed? And is there a changelog available anywhere?

@Emil Awesome, thank you so much!

I'm glad this was easy to track down. I'm curious, is there any explanation as to how this popped up in previously working code when no firmware updates were done in the meantime? Does the Flic Hub LR have other OTA updates to the SDK runtime that are separate from the device firmware?

Starting at least last night, using any writeAttribute Matter method started erroring with an uncatchable exception which completely crashes the script.

This exact kind of code worked at least a week ago (maybe even earlier yesterday), and then last night when I was working on some changes I noticed a new crash that was not happening within my code.

I'm not sure what would have caused this as I don't think my Matter devices had any firmware updates, nor the Flic Hub LR getting a firmware update.

It appears that the attribute is getting set, but something after that point in underlying Flic code is not expecting a Success value.

EXAMPLE CODE:

const matterModule = require('matter')
const matterDevices = matterModule.getNodes()

const matterDeviceIDsForNames = {}
for (const thisMatterDevice of matterDevices) {
	matterDeviceIDsForNames[thisMatterDevice.name] = thisMatterDevice.nodeId
}

const thisMatterDeviceID = matterDeviceIDsForNames['Living Room Corner Lamp']

const brightnessPercentage = 80
const brightnessLevel = Math.round(254 * (brightnessPercentage / 100))

matterModule.writeAttribute(thisMatterDeviceID, 1, 'Level Control', 'OnLevel', brightnessLevel, () => {})

ERROR OUTPUT:

SyntaxError: unexpected token: 'Success'
    at <input>:1
    at parse (native)
    at handlePacket (core.js:3259)
    at onPipeData (core.js:3336)

@Emil So you're saying it's not an existing capability in mqtt.js on https://github.com/50ButtonsEach/flic-hub-sdk-mqtt-js and it is something I would have to write myself?

Can the Flic Hub LR itself be an MQTT broker to not need another piece of hardware if I just want the Flic Hub LR to subscribe and respond to MQTT messages from other sources? This way, I could use the Flic Hub LR as basically an MQTT-to-Matter bridge without needing another Raspberry Pi running as the MQTT broker.

@Emil It would be awesome if you all could add a Global Datastore in the future! If you need any help testing, I would be happy to play with a beta version!

The Govee lights I'm working with are an older model H7013 which are warm white dimmable string lights that support Wi-Fi and Bluetooth, but that means the integrations are pretty limited to IFTTT which can be slow, and I can't detect the current state. The LAN API is much faster and I can check the current state, which is great.

I've looked into upgrading to newer Matter versions from Govee or anyone else but they are all more expensive than is worth it for me when what I have it working, and many newer models have more features/complexity than I really want (don't want RGB or anything, just want 2700K warm white and dimmable).

I'm curious if there is any way to have any data storage available across modules. datastore module is available, but it is per-module (looks like it makes a SQLite DB within the module).

I would like the be able to have an IP address discovered from one module available to another.

For the background, I am using the UDP/dgram module to control Govee lights via their LAN API (which is something I've always wanted to play with and the Flic Hub LR made it so easy, thank you!!!). I have one module (we'll call it Module A) which is bound to a port which allows me to listen for a response from a Multicast message which contains the IPs of the Govee lights. I do some controls to the lights within that Module A, but I also want to be able to control the lights from within another module (Module B), which just requires the IPs and doesn't need to do all the overhead of listening to responses. But these IPs aren't static and I was wanting to be able to log/store the IPs from Module A and access them from Module B so that I don't have to manually update Module B whenever the IPs change. Is this possible in any way? Thank you!

PS. For anybody finding this in the future, I also tried setting the StartUpCurrentLevel attribute and that behaves the same as calling MoveToLevel with OptionsOverride set to 1 when the light is off, Matter honors it when turned back on, but Tapo does not.

@Emil Neat! I am seeing that setting MoveToLevel with OptionsOverride set to 1 does set the brightness when the light is off when it is turned back on via Matter, such as in the Apple Home app (which is something I've never been able to do via any exposed app controls). But, oddly Tapo itself seems to not honor that setting if I turn the light back on via the Tapo app, or more importantly via the wall switch. Seems like a Tapo quirk/bug and not an issue with FlicScript since it seems the setting is properly honored within the Matter protocol.

From poking around more, I found the OnLevel attribute which looked interesting and I was able to set that with matterModule.writeAttribute(thisMatterDeviceID, 1, 'Level Control', 'OnLevel', brightnessLevel, () => {}). This appears to basically do what I want when the light is off, it will always get turned on to the specified brightness level. This has the effect of not keeping a manually set brightness, after the light is turned off and back on it will turn on to the specified OnLevel brightness instead of the previously manually set brightness, but I think that is actually totally fine for my desires in this project.

This is so much fun to be able to work with Matter devices at such a low level! I really appreciate your advice and help with this all!

@Emil About needing the current state on demand rather than listing for updates... I want to write a script to adjust the brightness of lights throughout the day (dimming them hourly throughout the evening). This is also why I asked about sleeping in FlicScript.

I've already done this functionality through IFTTT using their scripting capabilities and jumping through hoops triggering Tapo shortcuts for turning lights back off after a delay if they were off before changing the brightness, but I'm hoping to make it simpler and more efficient through FlicScript.

The catch is that to adjust the brightness you need to turn the light on. So, if the light is already on, I can set the new brightness and that's that. But, if the light is off, it needs to be turned on to the new brightness and then turned back off so that when it's next turned on manually it will be at the desired brightness. To do this properly, I need to know if the light was currently on or off before adjusting the brightness so that it can be back in its previous state after the change is done. It's a little weird to have my lights turn on and off throughout the evening but not being blasted will full brightness lights later into the evening is nice.

It would be amazing if it were possible to adjust the "remembered" brightness without turning the light on, but from what you described before it sounds like that's not possible even with this more direct access to the Matter devices. Or am I mistaken? I haven't had a chance to test that deeply yet. Would writeAttribute be able to adjust the brightness without turning a light on?