After a recent reboot (which involved Windows 8.1 updates being installed) I lost support for the second screen which started in highest brightness mode. It does not dim with the primary screen anymore.
I have restarted the PC and flux several times.
I have searched this forum for similar problems but did not find any other users experiencing this.
And no, I can't upgrade to Windows 10.
Hi David - yes we have a long list of things to add to the client software. I regard the current efforts in the display industry as largely nonsense not founded in good science, and I will try to clarify why.
The main reason is that "ratio" is not a risk - instead, "dose" (total photons absorbed) is how risk is measured.
If you are concerned about hazard standards, you need a meter that can respond to extremely high light levels (usually as a spot meter), and currently the meters we recommend cannot do this. So for our research partners who are actually measuring hazard levels, we do not want to misrepresent our capabilities.
But what we are talking about here is the idea from people in the displays industry that levels 50x lower than the international standards may pose a risk, and simply put: there is no documented hazard at normal display radiance levels.
We can compute a hazard factor at lower light levels, but we do not think the TUV/etc. focus on this single number is appropriate, because it ignores overall radiance level. The retina is known to respond to total photons absorbed, not to a ratio, so without a measurement that corresponds to actual ICNIRP dose levels, we should not endorse a metric like this.
As for your worry that f.lux is not adequate: f.lux by default reduces the hazard factor by more than 90% (exceeding the levels of 10-20% that are being used in the market), so I would not worry about us in that regard. If there is a problem in these ranges, we are doing something to help, and I would submit that reducing this light by 10-20% does not do very much at all.
@alex said in Feature Request: MQTT Support:
Bit late to the party, but I've only just got started with MQTT and automation.
If you're using Node-RED, you can use it to receive the data from f.lux with the built-in nodes.
I was inspired by this reddit thread - https://www.reddit.com/r/tasker/comments/a6q8vl/looking_for_better_mqtt_integration/ejrgl2l/ - which discusses Tasker, but the pertinent information is the post which describes using Node-RED and the "http in" node.
f.lux uses HTTP POST to send "?ct=xxxx&bri=x.xxxxxx" (replacing "x" with appropriate values). For example, "Working Late" sends "?ct=6500&bri=0.800000", while "Cave Painting" sends "?ct=2300&bri=0.800000".
The appropriate Node-RED objects for them are "msg.req.query.ct" and "msg.req.query.bri".
Looks like the "bri" values are computer-dependent. One of my computers sends "0.800000", but the one next to it sends "0.275000". Still, Node-RED captures both quite happily.