[Feature request]: Support custom external sources for luminance value

[odiroot]

Please describe your feature request

Idea

Let wluma call (periodically) an external script/binary to fetch the current luminance information.
Alternatively it could source the same information in a "smarter" (non-polling) way by listening on a TCP/unix socket.

Background

Webcams have a few issues when being use as a light sensor:

• Their fidelity is not great
• Can be obscured by privacy filters/flaps (e.g. ThinkPads)
• Are facing the user instead of looking from the PoV of the user.

This inspired me to look into sourcing the luminance using an external PIR/light sensor connected to my smart home system.
Unfortunately, since it's not exposed as a device directly on my laptop (it communicates over Zigbee), I couldn't possibly use it for brightness control.

I can though source the luminance information from the sensor over network / listen to state changes on MQTT broker.
Still there's no way to feed this information to wluma.

[maximbaz]

Hello!

Definitely a valid use-case, and I'm happy to see the first person who is using an external device to get luminance info!

There actually is an existing way to feed this info to wluma (albeit hacky), but maybe it's something we can start at, just to see whether the rest of the functionality would work satisfactory for you, before we spend time designing how to better feed this info to wluma.

What you can do is make a script that "simulates" iio sensor device files, and make wluma think that you have a real iio sensor.

1. Create a folder structure like so: /home/user/sensor/values.
2. Make a script that takes the values from your external sensor, and continuously writes that value into a file /home/user/sensor/values/in_illuminance_raw.
3. Create a file with contents "als" in the location /home/user/sensor/values/name.
4. Observe the values range that comes from your sensor, say what number is a bright day, and what number is a dim evening.
5. Add als section to your config.toml like so:

[als.iio]
path = "/home/user/sensor/"    # notice the folder is one level higher than the file is in
thresholds = { 0 = "night", 20 = "dark", 80 = "dim", 250 = "normal", 500 = "bright", 800 = "outdoors" }   # define as many as you need, see README for more details

I'm typing this without testing it, but I'm pretty sure it will work.
If your sensor provides intensity values for red, green and blue, as opposed to a single value, there is a support for that too. You can just have a look at this file for more details, or I will help out with the correct file structure.

Let me know how this initial experiment goes!

[odiroot]

Hey Maxim, Thanks for the quick response. I'll test it after work.

…

On Fri, 1 Mar 2024, 11:28 Maxim Baz, ***@***.***> wrote: Hello! Definitely a valid use-case, and I'm happy to see the first person who is using an external device to get luminance info! There actually is an existing way to feed this info to wluma (albeit hacky), but maybe it's something we can start at, just to see whether the rest of the functionality would work satisfactory for you, before we spend time designing how to better feed this info to wluma. What you can do is make a script that "simulates" iio sensor device files, and make wluma think that you have a real iio sensor. 1. Create a folder structure like so: /home/user/sensor/values. 2. Make a script that takes the values from your external sensor, and continuously writes that value into a file /home/user/sensor/values/in_illuminance_raw. 3. Create a file with contents "als" in the location /home/user/sensor/values/name. 4. Observe the values range that comes from your sensor, say what number is a bright day, and what number is a dim evening. 5. Add als section to your config.toml like so: [als.iio] path = "/home/user/sensor/" # notice the folder is one level higher than the file is in thresholds = { 0 = "night", 20 = "dark", 80 = "dim", 250 = "normal", 500 = "bright", 800 = "outdoors" } # define as many as you need, see README for more details I'm typing this without testing it, but I'm pretty sure it will work. If your sensor provides intensity values for red, green and blue, as opposed to a single value, there is a support for that too. You can just have a look at this file <https://github.com/maximbaz/wluma/blob/main/src/als/iio.rs> for more details, or I will help out with the correct file structure. Let me know how this initial experiment goes! — Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE3IKBN7HSTANV77IAKS4DYWBQ7XAVCNFSM6AAAAABEBSW5J2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZTGAYTSNRSGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[odiroot]

@maximbaz I don't think it worked.
My config

[als.iio]
path = "/home/odi/.config/wluma/sensor/"
thresholds = { 1331 = "night", 2292 = "dark", 2408 = "dim", 2700 = "normal", 2889 = "bright", 3500 = "outdoors" }

File structure

/home/odi/.config/wluma/sensor/
└── values/
    ├── in_illuminance_raw
    └── name

Try changing values in in_illuminance_raw but wluma doesn't react to that.

Debug log:

[2024-03-01T20:21:47Z DEBUG wluma] Using Config {
        als: Iio {
            path: "/home/odi/.config/wluma/sensor/",
            thresholds: {
                1331: "night",
                2700: "normal",
                2292: "dark",
                2889: "bright",
                2408: "dim",
                3500: "outdoors",
            },
        },
        output: [
            Backlight(
                BacklightOutput {
                    name: "eDP-1",
                    path: "/sys/class/backlight/amdgpu_bl1",
                    capturer: None,
                    min_brightness: 1,
                },
            ),
        ],
    }
[2024-03-01T20:21:47Z INFO  wluma] Continue adjusting brightness and wluma will learn your preference over time.

[maximbaz]

Have you tried to train it after the new config , by changing brightness manually to the desired values in bright and dark environment?

[odiroot]

I haven't, will try.

[avalsch]

I implemented support for reading an external command in #99. I would also be interested in implementing reading from a socket, is this something that you'd want to add @maximbaz?

[maximbaz]

Cool! Maybe I should ask first, did you actually get it working? Does it work as expected? How frequently does your external sensor update the value? Is there a noticeable delay (and if so, is it annoying?), say when you turn off the light, does it take wluma long to reduce brightness?

[avalsch]

I currently have it polling at the same rate as the webcam implementation. I haven't been able to test it as I don't have any external devices but I am working on writing a script to simulate changes to see how it responds.

[avalsch]

@odiroot I'd love it if you could also test my branch to see if it works for you.

[odiroot]

@odiroot I'd love it if you could also test my branch to see if it works for you.

I'd gladly do. Just have to figure out how to do it. I've been using Arch package for wluma.

[odiroot]

@maximbaz @avalsch 's branch actually worked for me.
For now I just set cat file.txt as the command but I'll look into hooking it into my Home Assistant setup.

[maximbaz]

Nice! Once you get it working, please do share some feedback, particularly about frequency of updates that your external sensor is capable of. With webcam we just don't have any other option, but here I think we can do better than polling approach, to both not waste resources executing potentially heavy scripts when the value is known to not have changed, and at the same time to not limit fidelity if sensor is able to provide more frequent accurate info.

[odiroot]

My sensor updates at most only once a minute (I guess to save battery).

I also couldn't get my curl/jq script to do anything with als.cmd, despite the cat version working. Guess I'll just keep writing to that file and catting it ;)

[maximbaz]

Okay thanks for sharing!

I would also be interested in implementing reading from a socket, is this something that you'd want to add?

I think it's a good idea, let's give it a try! I'd really love to not have another polling-based method, but something that is reactive and at the same time super easy to script into, and I think your idea with a socket fits this description perfectly 👍