more G-Labs products

Author Topic: Aeotec MultiSensor Luminance value  (Read 7303 times)

February 11, 2014, 05:27:16 PM
Read 7303 times

Zed

  • *
  • Information
  • Newbie
  • Posts: 7
First post so let me start by congratulating Mr Martello on this great project; my platform of choice for first steps with Z-Wave.

I am having some trouble with the luminance readings from an Aeotec MultiSensor (1.18, Manufacturer Specific = 0086:0002:0005).

I get meaningful readings for Battery, Humidity and Temperature but Luminance is always 0.0 or 1.0 regardless of the actual light value.

I have set all device values per the usual recommendations (e.g. parameter 101: 225).  MultiSensor is running under USB power.

I confirmed the Luminance values via scripts and also by running HomeGenie via the console outputting to a log, sample output:

...
2014-02-10T16:16:23.1594374+01:00   HomeAutomation.ZWave   4   ZWave Node   ZWaveNode.Battery   100
2014-02-10T16:16:23.1624376+01:00   HomeAutomation.ZWave   4   ZWave Node   Status.Battery   100
SPO < 06
SPI > 01 0C 00 04 00 04 06 31 05 03 0A 00 12 DA
2014-02-10T16:16:23.2094403+01:00   HomeAutomation.ZWave   4   ZWave Node   Sensor.Luminance   0.0
SPO < 06
SPI > 01 0C 00 04 00 04 06 31 05 05 01 1C 00 D9
2014-02-10T16:16:23.2594431+01:00   HomeAutomation.ZWave   4   ZWave Node   Sensor.Humidity   28.0
SPO < 06
SPI > 01 0C 00 04 00 04 06 31 05 01 22 00 B6 54
2014-02-10T16:16:23.3094460+01:00   HomeAutomation.ZWave   4   ZWave Node   Sensor.Temperature   18.2
...


I have also contacted the MultiSensor seller thinking I may have a faulty product since values other than Luminance are meaningful.

I would appreciate any ideas on resolving this or finding out if anyone is having a similar problem with this sensor.

HomeGenie version: 1.00 beta r329
Controller: Aeotec Series 2 USB Controller
OS: Windows 7

Many thanks in advance.

February 11, 2014, 06:40:55 PM
Reply #1

nolio

  • *****
  • Information
  • Global Moderator
  • Posts: 544
Hi,
With the same sensor but on a raspberry pi, i have max to 3 for luminance.
I think it was normal but perhaps not ...
bye

February 11, 2014, 10:14:28 PM
Reply #2

Zed

  • *
  • Information
  • Newbie
  • Posts: 7
Hi nolio,

Thanks for your reply, it was helpful.

In constant daylight my sensor was reporting 0.0 and 1.0 so I had thought it was not reacting to light changes at all but I now find that if I shine a bright light directly into the sensor I too can get a reading of 3% (or 3.0 in the debug output).  It's only ever a whole number value though, in the range 0 to 3.

However this 4 in 1 sensor is supposed to send a value of 0 to 1000 LUX for luminance so is there any way we can see or control what HomeGenie is doing with the raw value reading when it is converted to a percentage?

February 12, 2014, 04:09:49 PM
Reply #3

Zed

  • *
  • Information
  • Newbie
  • Posts: 7
I was able to obtain a correct value by changing code in ZWaveLib.dll (generic handler in Sensor.cs) and rebuilding.

Code: [Select]
else if (key == (byte)ZWaveSensorParameter.LUMINANCE)
{
    // From this...
    //luminance = val;

    // To this...
    luminance = BitConverter.ToUInt16(new byte[2] { message[12], message[11] }, 0);

    //
    _nodehost._raiseUpdateParameterEvent(_nodehost, 0, ParameterType.PARAMETER_LUMINANCE, luminance);
    //
    handled = true;
}

Obviously this fix is make/model specific and I suppose the MultiSensor needs a dedicated handler section if this is not the typical format for Z-Wave luminance values but it quickly corrects the interpretation of the reading for my Aeotec MultiSensor.  Typical values reported are now ~280 for good daylight.

February 12, 2014, 09:31:38 PM
Reply #4

nolio

  • *****
  • Information
  • Global Moderator
  • Posts: 544
Hi,
How did you change this ? How did you rebuild zwavelib.dll ?
Otherwise, is it simple to integrate this modification to next release ?
Bye

February 13, 2014, 08:44:45 AM
Reply #5

Zed

  • *
  • Information
  • Newbie
  • Posts: 7
How did you change this ? How did you rebuild zwavelib.dll ?

Using the HG source code I found the section in zwavelib.dll where the luminance value was being interpreted (Sensor.cs) and made the modification mentioned in my last post.  I rebuilt the dll using Visual Studio C# 2010.

Otherwise, is it simple to integrate this modification to next release ?

I posted in the Feature Request section referencing my findings so hopefully this can be considered for a new release.

February 13, 2014, 09:56:37 AM
Reply #6

dani

  • *****
  • Information
  • Global Moderator
  • Posts: 535
Otherwise, you can use MonoDevelop. It's a free C# IDE for Linux, Windows and Mac.

February 13, 2014, 12:57:13 PM
Reply #7

Gene

  • *****
  • Information
  • Administrator
  • Posts: 1472
  • Tangible is the future!
    • Yet Another Programmer
Hi Zed,

thanks for helping with this. I was just wondering if a value of 280 it's correct for luminance. Usually it's given as percentage value (0-100). Pheraps it's 28.0%?
Did you try putting a light near the sensor simulating lights changes and seeing how the bytes are changing too?
...
SPI > 01 0C 00 04 00 04 06 31 05 03 0A 00 12 DA
2014-02-10T16:16:23.2094403+01:00   HomeAutomation.ZWave   4   ZWave Node   Sensor.Luminance   0.0
....
expecially those "bold" bytes.
To wake up the sensor manually, and make it send report, press the button on it.
Once we ensure that the bytes decoding is correct, I'll be including this fix on a separate handler brand-specific file (Sensor.cs is a generic one).
Btw there must be a byte (0A?) that tells how the value is to be interpreted, but I'm missing this z-wave spec info at the moment.

Cheers,
g.

I was able to obtain a correct value by changing code in ZWaveLib.dll (generic handler in Sensor.cs) and rebuilding.

Code: [Select]
else if (key == (byte)ZWaveSensorParameter.LUMINANCE)
{
    // From this...
    //luminance = val;

    // To this...
    luminance = BitConverter.ToUInt16(new byte[2] { message[12], message[11] }, 0);

    //
    _nodehost._raiseUpdateParameterEvent(_nodehost, 0, ParameterType.PARAMETER_LUMINANCE, luminance);
    //
    handled = true;
}

Obviously this fix is make/model specific and I suppose the MultiSensor needs a dedicated handler section if this is not the typical format for Z-Wave luminance values but it quickly corrects the interpretation of the reading for my Aeotec MultiSensor.  Typical values reported are now ~280 for good daylight.

February 13, 2014, 02:59:29 PM
Reply #8

Zed

  • *
  • Information
  • Newbie
  • Posts: 7
Hi Gene,

Thanks for taking a look at this.

When I saw the generic handler was looking for a % value I thought the Aeotec sensor behaviour must be unusual because the product spec. says it's operating range is between 0 and 1000 lux and it also sends a value in this range (confirmed with the product seller).  From the code I assumed that most sensors report a % as you just confirmed.

I'm away from the sensor as I write this but I did at the time of my previous post run some (rather unscientific) tests on the interpreted value to ensure it was meaningful:

  • 0 when sensor covered
  • 275 +/- in the grey winter afternoon daylight (value is rather low for daylight but the sensor is indoors, well away from the windows)
  • 500 +/- when a torch is shone near the sensor
  • 1000 exactly when the torch is shone right into the sensor (overloaded)

I realise this is not disproof of a % value! But a quick look around the open-zwave forum also indicates others are reading values between 0 and 1000 for this device.

As an aside I'm not sure how the "typical" Z-Wave % reading works for luminance unless there is an acknowledged standard for devices like this whereby 100% is typical daylight at perhaps 1000-2000 lux ("Typical overcast day, midday" http://en.wikipedia.org/wiki/Daylight) and 0% is of course total darkness...?  It would make for challenging automation scripting with a variety of sensors operating in different lux ranges!

Thanks again,
Zed

August 05, 2014, 08:03:05 AM
Reply #9

FozzieKev

  • *
  • Information
  • Newbie
  • Posts: 6
http://www.fibaro.com/manuals/en/Motion-Sensor/Motion-Sensor_EN_5.3.14.pdf

I have the Fibaro motion sensor. It reports in LUX but HomeGenie only shows %. Is it possible that O could test the same change?

August 05, 2014, 08:08:23 AM
Reply #10

FozzieKev

  • *
  • Information
  • Newbie
  • Posts: 6
I too only ever see 0% or 1%. I need to dig out the console output. Looking at other forums and systems there seems ti be a difference between Lumens and LUX. The fibaro forum has users talking of LUX in integer valies.

http://forum.fibaro.com/viewtopic.php?t=4702


September 04, 2014, 03:26:24 PM
Reply #11

nolio

  • *****
  • Information
  • Global Moderator
  • Posts: 544
Hi,
After the upgrade to r411, the value luminance for my aoetec equipment are again between :
  • 0 -> 3 instead of
  • 0-> 1000
is there a rool back on this part of code ?

Bye

September 04, 2014, 05:27:13 PM
Reply #12

Gene

  • *****
  • Information
  • Administrator
  • Posts: 1472
  • Tangible is the future!
    • Yet Another Programmer
this issue should be fixed by r412.

Cheers,
g.

September 04, 2014, 08:56:52 PM
Reply #13

nolio

  • *****
  • Information
  • Global Moderator
  • Posts: 544

September 26, 2014, 12:58:05 AM
Reply #14

FozzieKev

  • *
  • Information
  • Newbie
  • Posts: 6
Thanks for creating a Fibaro version. I've not been looking at this much since our second child was born.

Fibaro manual says 'Light Intensity Measuring Range: 0-32000 LUX'

Playong with some ideas, and came across this which looked interesting:

From Everspring ST815:

The illumination detecting range is from 0 to 3000 LUX. When illumination reaches the limit (3000 LUX), MAX icon will be displayed on the screen
....

SENSOR_MULTILEVEL_REPORT
[Command Class Sensor Multilevel, Sensor Multilevel Report, Sensor Type = 0 x 03 (Luminance), Precision+Scale+Size = 0 x 0A, Sensor Value 1 = (High Byte of Illumination Value), Sensor Value 2 = (Low Byte of Illumination Value)]
Example:
Sensor Value 1 = 0x08 Sensor Value 2 = 0x02 Illumination = (Sensor Value 8*256 + Sensor Value 2) = (8*256+2) = 2050 (LUX)