node-zwave-js: [bug] NAS-WR01ZE: kWh meter value displayed as negative number

there might be a better approach from a overall smart home architecture perspective than making it a problem of the users (either buy new devices or implementing workarounds)

This may sound cynical but I disagree. It really should become a problem of the manufacturers who release these buggy devices and don’t offer any support whatsoever. The huge bunch of workarounds that other drivers implemented (some still do, see SmartThings) make it too easy for manufacturers to reject responsibility and claim “but it works in XYZ, cannot be our fault!”

I can understand the sentiment of making things work when you’re using unofficial APIs etc, but Z-Wave is a standard, devices have to be certified and these things still happen too much. Only when we stop solving the manufacturers’ mistakes for them and make them fix them, then we can get to a point where it becomes a benefit for the smart home community.

Unfortunately, I don’t have the power to make manufacturers do that, so all I can do here is stay strong and say “I will not fix this” (and neither should the other projects), even if it is annoying for users. In the end, the users have the power to make a change:

1. When there are issues with a device, contact the manufacturer support. Open Source projects are not free tech support for manufacturers.
2. Hold them accountable. If there is clearly an issue with the device firmware, demand them to fix it. Even if they initially claim its not their fault. European law recently even made it mandatory to provide updates for ~5 years.
3. Vote with your wallet:
   • Don’t buy from manufacturers that don’t provide any support
   • Don’t buy from manufacturers that don’t provide firmware updates or make you pay for them. Nowadays there is really not a reason not to provide them online.
   • Don’t buy from manufacturers that tend to seek fault elsewhere (“The device is certified, cannot be our fault…”)
   • DO buy from manufacturers that have reliable devices and give good support.
   • Inform yourself before you buy

We can help with the latter - we recently added the ability to display comments in our device configuration DB, but it isn’t used much yet: https://devices.zwave-js.io/?jumpTo=0x0258:0x0100:0x1027:0.0

Side note: I currently have devices from 3 large manufacturers. Of these 3, I’d only buy from one again and my DO-NOT-BUY list is growing rapidly just by looking at the issues that are reported here.

@heapxor That gist also mentions this in the top-level comment:

# In addition to random most significant bit flips in the 32-bit energy consumption value reported
# which results in massive negative values, the NAS-WR01ZE also generally computes the energy consumed incorrectly.
# In brief practical tests the actual consumption is actually ~1/4 of the value reported.

It seems to have deduced a correction factor of 0.26 which when multiplied with the original value of 18.48 results in 4.8048:

        {% set correctionFactor = 0.26 %}
...
          {{ ( value * correctionFactor ) | round(roundDecimals) }}

I’ve created a Template Sensor that does corrective calculations on the values reported by NAS-WR01ZE devices:

https://gist.github.com/KloudJack/4489ffcbeae58b88072f391dca55b40d

I’ve been using this successfully with my power sockets until a firmware fix is released, not holding my breath though as this issue has been known for at least 2 years.

@robertsLando Can do what he likes

Generally we do not try to fix application level device quirks in the driver for two reasons:

1. While these values seem obviously wrong, it is impossible to tell automatically whether the value was reported like this on purpose or not
2. It is not our job to clean up the manufacturers’ mess. Sure, we work around some things to make the devices usable at all, but fiddling around with the reported values doesn’t belong in this project.

As a rule we don’t implement device-specific workarounds. Doing so is part of what led to OZW’s bloated code. You can use an automation or template a sensor entity in HA on your own to fix this.

@AlCalzone, @blhoward2 I can fully understand and support these statements so zwave-js can keep its high quality and speed of development. Nevertheless there might be a better approach from a overall smart home architecture perspective than making it a problem of the users (either buy new devices or implementing workarounds that create much more and duplicated complexity on other parts of the smart home system (solving this using template sensors in HA for every affected entity is a huge code duplication mess and a nightmare to maintain). Wouldn’t it be possible to support a kind of layer or hooks to do some device-specific processing before passing the values on to the applications?

@robertsLando, wouldn’t the device values configuration of zwavejs2mqtt already allow something like this? But I’m not sure, if this helps, if e.g. Home Assistent is connected directoly to the zwave-js server port of zwavejs2mqtt.

If not, maybe providing something like that as part of the zwave-js server but on top of the zwave-js driver would solve the need (not only to fix device bugs but also to do some other useful pre-processing or conversion of data) while keeping the the concerns of clearly separated from the core. Maybe the device configuration could be extended to provide device-specific implementations for hooks that are called by the driver or server.

Since I don’t know enough about the (existing or still to be created) possibilities on the driver/server level I’d like to hear your opinion on that.

Fair enough, I’ll work around it in SW on my local HA overlay. I have little hope to see FW updates for such budget devices, but lets see (the first of the two support email addresses already replied my email wasn’t delivered because the inbox quota was full 😅 )