HomeGenie Forum
General Category => Troubleshooting and Support => Topic started by: Zed on February 11, 2014, 05:27:16 PM
-
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.
-
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
-
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?
-
I was able to obtain a correct value by changing code in ZWaveLib.dll (generic handler in Sensor.cs) and rebuilding.
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.
-
Hi,
How did you change this ? How did you rebuild zwavelib.dll ?
Otherwise, is it simple to integrate this modification to next release ?
Bye
-
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.
-
Otherwise, you can use MonoDevelop. It's a free C# IDE for Linux, Windows and Mac.
-
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.
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.
-
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 (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
-
http://www.fibaro.com/manuals/en/Motion-Sensor/Motion-Sensor_EN_5.3.14.pdf (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?
-
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 (http://forum.fibaro.com/viewtopic.php?t=4702)
-
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
-
this issue should be fixed by r412.
Cheers,
g.
-
Oki good !
Bye
-
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)
-
And a bit more research...
In the below URL, one of the responses details: 01 0C 00 04 00 07 06 31 05 03 0A 03 E8 20
Not sure what sensor they are using, but applying the logic as used by Everspring..
The Precision is 0A, which is for LUX and there must be a different value for Percentage.
03 * 256 + E8 (232) = 1000, which is shown in the output.
2014-03-30 16:30:57 DEBUG o.o.b.z.i.p.c.ZWaveMultiLevelSensorCommandClass[:92]- Received Sensor Multi Level Request for Node ID = 7
2014-03-30 16:30:57 DEBUG o.o.b.z.i.p.c.ZWaveMultiLevelSensorCommandClass[:127]- Sensor Multi Level report from nodeId = 7
2014-03-30 16:30:57 DEBUG o.o.b.z.i.p.c.ZWaveMultiLevelSensorCommandClass[:132]- Sensor Type = (0x03)
2014-03-30 16:30:57 DEBUG o.o.b.z.i.p.c.ZWaveMultiLevelSensorCommandClass[:147]- Sensor Value = (1000.000000)
https://groups.google.com/forum/# (https://groups.google.com/forum/#)!msg/openhab/899g2eVIuGw/aec8PgxJNgIJ
There's some quite useful info in the Open-ZWave code: http://code.google.com/p/open-zwave/source/browse/trunk/cpp/src/command_classes/SensorMultilevel.cpp?spec=svn602&r=602 (http://code.google.com/p/open-zwave/source/browse/trunk/cpp/src/command_classes/SensorMultilevel.cpp?spec=svn602&r=602)