Aeotec HEM 1E Issues Reading Power

[psyctto]

Having a bit of an issue reading power properly with HomeGenie and my Aeotec ZStick 2E.  Setting Configuration Variable 1 to 123 (VAC) and Variable 101 to 256 (watts, clamp 1) returns a Sensor.Generic value of 122167 with a  150W source on and 87108 with it off, Meter.Watts doesn't change it stays at 21.2.  If I change Variable 101 to 4 (watts, whole device) Sensor.Generic functions the same as above, while Meter.Watts returns 2938.9.
If I change the VAC Variable to 1, in hopes it would just use 1 times the current and return the raw current to me, I get Meter.Watts of 21.2 and Sensor.Generic of 708.2.  Once again I need to use Variable 101 to get updated data for both (values or 4 for Meter.Watts and 256 for Sensor.Generic.)

I'm sure there's something simple, setup wise, I'm missing...  Any help would be greatly appreciated.  I looked around but couldn't find anything with about this specific issue.

Thanks in advance.

[hybridview]

I've been researching this very issue.
If you poll the HEM device from HomeGenie, you get correct values such as "ZWaveNode.MultiInstance.SensorMultiLevel.1". If you rely on HEM to send automated reports, they come back as Generic. When running HG in console mode, I saw this interesting message during an automated report:

[10:05:12.583684] SPI > 01 18 00 04 00 05 12 60 0D 02 00 32 02 21 74 00 06 1B 0C 00 00 00 00 00 00 EF
[10:05:12.587677] SPO < 06
2015-01-14T10:05:12.5936783-05:00       HomeAutomation.ZWave    5       ZWave Node      ZWaveNode.MultiInstance.SensorBinary.2  13338.0
2015-01-14T10:05:12.5976794-05:00       HomeAutomation.ZWave    5       ZWave Node      Sensor.Generic  13338.0

UNHANDLED SENSOR PARAMETER TYPE => 33

ZWaveLib UNHANDLED message: 01 18 00 04 00 05 12 60 0D 02 00 32 02 21 74 00 06 1B 0C 00 00 00 00 00 00 EF


Since type "33" is not defined, it parses the response as Generic and returns param "ZWaveNode.MultiInstance.SensorBinary.1". I also POLLED for a clamp 2 value and got the expected (or close to expected) watts: ZWaveNode.MultiInstance.SensorMultiLevel.2      404.118


It appears as though the value is not being extracted correctly because of this. In my quick tests, it appears to be (actual watts * 33). I'm new to HG and ZWave so am, at this time, researching how everything works.

[hybridview]

By the way, to manually poll the HEM, I used code found in another thread in this forum. The code snippet  to poll looked like below:

var energymeter = Modules.WithName("Home Energy Counter").Get(); // Must add sensor and name as "Home Energy Counter"
// Instruct module to query HEM and set internal param with the response.
energymeter.Command("MultiInstance.Get").Execute("Sensor.MultiLevel/1"); // Execute and Set are aliases

// Access the response that was set in module parameter.
var sensor1_Energy = energymeter.Parameter("ZWaveNode.MultiInstance.SensorMultiLevel.1");
Program.Parameter("Sensor.PM.Clamp1Watts").Value = sensor1_Energy.DecimalValue.ToString();

[hybridview]

I figured out the issue! I had to manually decompose several raw messages to find the pattern.

It looks like there is a bug in the ZWave lib.

In the source file:
HomeGenie\MigFiles\SupportLibraries\ZWaveLib\Devices\ProductHandlers\Generic\Sensor.cs
in function ExtractValueFromBytes, the code that handles precision has a flaw. It multiplies precision by 10 instead of using 10^precision power. In a case where precision is 3, the function multiplies the value by 10*3=30 instead of 10^3=1000. When I modified the code to fix the issue, all of my generics are perfect! I will submit a ticket soon. For now, change the line of code from:

result = ((double)value / (precision == 0 ? 1 : 10D * precision ));

TO

result = ((double)value / (precision == 0 ? 1 : Math.Pow(10D, precision) ));

[Gene]

Hi hybridview,

thanks for pointing to this! In that very moment I must have truly believed that 10*3 was going to be 1000 
Next update will contain the fix.

Cheers,
g.

[hybridview]

It's no problem Gene. I saw that line of code several times before thinking it was correct too. I have to say that I am very impressed with the entire code architecture of this project. It's very elegant and extensible.

[psyctto]

hybridview, thanks very much for looking into this.  sounds like you found the issue, i'll wait for Gene to put out his next update.  i did try your code snippet, but putting it in an automation script didn't return the correct numbers either.  so i'll just see if the next build fixes my issues.

on a side note, did you update the firmware on your HEM?  i did when it wasn't originally working and i'm honestly not sure if the Aeotec firmware is for the 1E or 2E or both, mostly due to Aeotec not really documenting things well.  i can't find the original firmware to roll back to either, again since Aeotec doesn't provide much, which i'd like to try.

either way, thanks again for putting the time in to help.  it's greatly appreciated.

[hybridview]

It's a long shot, but To fix the values in the c# script, you might need to undo the operation that broke the value first. You would divide the bad value by 30, THEN perform the power operation in my snippet. That might fix it until the next update.

I ordered my HEM v1 3 weeks ago and never updated the firmware. It supported the latest ZWAVE protocols, so I didn't want to mess with it. I'll try to lookup what version is on my device this weekend and I'll post it here. The documentation from AEOTEC is indeed bad. Fortunately, their firmware appears to follow ZWave protocols pretty well. Finding good ZWAVE documentation has been a miserable experience, however. I'm getting there, though.

[psyctto]

Gene/hybridview,
Thank you both very much.  The latest update fixed my issues perfectly, I did have to remove the device from the network and re-add, but not a big deal.

Gene,
I guess this is more of a question for you.  Is there any way to display clamp 1 and clamp 2 separately on the HG control widget?  Or at least can I get it myself in a script, none of the naming in the properties of the node seem to suggest so (like the MultiSensor does, with Sensor.Temperature and so on...)
I did try to setup the group 1 to return clamp 1 and group 2 to return clamp 2, but this seems to just cause the HG widget to add a Sensor.Generic and alternate between clamp 1 and clamp 2 values when the HEM sends.  Sensor.Power doesn't change when I set it up like this.  If I go back to group 1 set to MultiSensor Report for the whole device (opt 2), it only returns the total wattage, not individual values.

Thanks again for all the work.  This is a fantastic project you put together, I love the level for customization I am allowed.

[hybridview]

I had the same problem and figured out what was happening.

The ZWave library makes an assumption about the format of all MULTIINSTANCEV2_ENCAP commands that is incorrect. This is fully expected, as documentation for ZWAVE protocols is awful. Fortunately, I found some good references and figured out the problem.

In the MULTIINSTANCEV2_ENCAP command handling part of Sensor.cs, message[13] is treated as a parameter type "key". According to the specs, when MULTIINSTANCEV2_ENCAP encapsulates a METER_REPORT, message[13] is really a set of bit flags indicating "Rate type" and "meter type". Since this index is not a key, Sensor.cs does not recognize it and treats it as generic.

EXAMPLE:

In the response of HEMv1 automated report of CLAMP 1:
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
01 18 00 04 00 05 12 60 0D 01 00 32 02 21 74 00 03 28 7D 00 00 00 01 11 E9 52

the byte at index 13 is "0x21". Sensor.cs treats this as a key, but according to specs, it is really a set of bit flags shown below:
0x21: 0010 0001
      001` ```` => Rate Type  = "Import (consumed)"
      ```0 0001 => Meter Type = "Electric meter"



As a quick "hackish" fix, I just added an extra compare to the POWER parameter handling in Sensor.cs like below:

else if (key == (byte)ZWaveSensorParameter.POWER || key == 0x21 )
{

In the long term, the ZWaveLib will need to be extended to support more of the protocol.

I found the "amazing" zwave docs below on GITHUB:
https://github.com/yepher/RaZBerry/tree/master/docs

The doc of interest is "SDS11060-7 Z-Wave Command Class Specification.pdf". It has everything we would ever need to decode ZWAVE!

[vortmax]

I hate to bring an old thread back from the ashes, but I just installed a gen 1 HEM and am having the same problem.  I am also running the windows version (for now) so, I don't have an easy way to patch the source to fix this bug.

Is the polling option the only existing workaround right now?

Also, on a side note, is there a way to get the widget and the energy monitor graph widget to only show a particular reading?  I would like to monitor both clamps independently.  I also have some of the smart energy lamp modules, which report power usage too, and I think those readings are getting lumped into the total reported by the widget (which is double counting power usage).


-------------------------------
edit:

hope this is useful to someone else:

In my hunting around, I found that others were having the same issue with other controllers.  On one of the Vera forums, a user found out that resetting the HEM by writing 0 to parameter 255 reset the unit and did the trick.  Unfortunately HG doesn't let you do this easily, so you have to use the API.

I just used the webAPI with a single call:

http://<hg_ip>/api/HomeAutomation.ZWave/5/Config.ParameterSet/255/0

As soon as I issued it, I started seeing realistic numbers reported.