Lux has always been a pain for me, especially when I have a number of different devices.
They all seem to report in their own special way. Some are 0-100, some go 0-10,000. I have some that go 0-256. Even if I modified the driver to map the values so they all report something in a similar range, they all reported differently in that range. So I really had issues including them all into automation's.
My advice is to try stick to one brand. At least you will have consistent reporting that you can use in your automation's across those devices. If you stick to devices that "do it right" then that would be preferred as you can mix them and feel good that they are also consistent (hopefully) with others that do it right.
I understand and agree that 0-100 is not a lux range. Zooz never calls the sensor reading lux. Yet Hubitat already takes that sensor reading, multiplies it by ~50% and puts it in the illuminance field.
The Zooz 4-in-1 perform fine in my home to in defining at least 3 levels - dim/dark, light, bright. I don't even know if giving 2x the range would improve the ability to discern between levels.
It just seems weird for Hubitat to take the sensor reported level and multiply it by about 0.5.
You need to read the specs on what they are reporting, if you're trying to measure something, and the specifications don't enumerate the units or range of reporting available then it's generally prudent to look else where for that specific attribute.
Yeah, i get the frustration with this device and illuminance, in retrospect it would have been wiser not to include the illuminance capability and just deal with the resulting complaints generated by that decision...
To get it straight - do you in the Hubitat driver take the sensor output and run it through a conversion (multiplying by about 0.5) before outputting the level to the state?
As stated in other posts above even the devices that try to report real lux are often not comparable between brands. So to set up automations based on levels requires a bit of trial and error if one is using different sensors. A Zooz sensor is not any different even if it's on a different scale. It might or might not be accurate enough for a particular application.
I really don't have a problem with the device as it works for my simple turn on the lights if there is motion and its dark enough scenario. I'd just like the raw sensor value (translated from decimal to integer) to be the reported Hubitat illuminance level.
I can't state this enough, Lux is Lux, anything else isn't.
Every device that I've owned or tested that claimed in the spec to report Lux, did in fact report Lux, the upper limits to the ranges varied, but all of these devices were accurate within their given specified range.
While everyone else argues about how a device reports, how it should report, how a driver does or does not report correctly....
I messaged you and didn't get a response. I have a spare Hue and Fibaro both @mike.maxwell has "approved" of for Lux reporting. If you're in the US (I'm not paying Canada shipping) tell me which one you want and I'll put it in the mail for you.
Sad this thread like most was derailed instead of being a simple help a member out.
Aaaaaaaaahhhh... I get what you are saying. If the device reports that it is giving you a lux value then that is what you are getting, its just the limit on what its giving you that is different.
So in the case of the HS-FS100+ it states it is giving you a Lux value from 0-250 which makes sense as it uses this setting to determine dark/light, so it probably doesn't care about anything higher.
Where a device that will give you a reading of 0-100 but not specify that it is Lux, that value is more of a "brightness" value that they have created.
You didn't answer my question - does the Hubitat driver multiply the Zooz raw sensor data by about 50% and report that as illuminance? If not by Hubitat driver how/where is the conversion done?
This is why I was so surprised when I hooked a BH1750 lux sensor to a NodeMCU and got readings around 10,000 when in bright sunlight. I had not seen people mention lux readings anywhere near that scale from any devices.
There is a conversion lookup in there, its not linear, I'm not going to get into how it works, as I said, I'm regretting having implemented this in the first place...
I'm sure there's another driver out there for this device that you can modify to do whatever you want.
Most likely due to the apparent plethora of devices out there that don't do a good job of reporting in standard units, or were intended only for internal applications where it's difficult to generate readings above 500 Lux using artificial lighting...
Also, Lux isn't a value unit that the average person has much expierence with...
It happens often. But I think it was important to distinguish the difference between a device reporting Lux and reporting brightness (for lack of a proper term). It did clarify a few things for me and hopefully later down the road if somebody were to run across this thread (maybe the rare searcher) they would find this little bit of info useful.
So why don't you just take the conversion out? The Zooz manual says it reports 0-100. You admirably attempted to make it resemble lux. But the results you programmed don't make sense. (If they did 100 from the sensor would be something like 1000 ore more based on your statement in post #20.) And now you say find another driver to fix the thing that your driver doesn't come close to doing correctly?
As I said a few times, I can make 0-53 work for me. Would 2x resolution would make a difference? I don't know.
I find this conversation very odd.. Lux is a real measurement.. 0-100% light? what is 100%? All the light? Seems very arbitrary to use percentage for a measure of illuminance.
It is. But that's what the device reports. And the values work in my, and probably most other, automations. Even as the user needs to set different values than a real lux. I just don't get why Hubitat driver can't be changed to pass the raw value, 0-100, instead of 0-53 calculated value. It seems that it would be easier to not calculate than to calculate incorrectly.
Sure.. But that would be inconsistent with how the data is reported throughout the rest of the ecosystem. As it's pretty well established that illuminance is reported as lux. And I have noticed internal HE drivers try to maintain consistency between devices (which is totally understandable).
0-53 is even more wrong. Whatever calculation the driver does bears zero resemblance to an even a half-baked lux value. So all the driver does is cut the resolution of the value by 2.
