[bug] NAS-WR01ZE: kWh meter value displayed as negative number #2692
Comments
|
Update: Caught in the act on another node: |
|
Thanks @rickk88! From what I could see yesterday, it might really just be bit 31 randomly toggling between 1 and 0. Anyone agrees? @robertsLando would zwave_js be open to implement masking this bit out as a quirk for this particular device? |
|
I think this should be handled on zjs side. |
|
@andre-richter any chance you could catch this in a zwave-js log with loglevel debug? I wonder if it is only that bit. |
AlCalzone
added
the
investigate 🔎
|
@AlCalzone, are you particularly interested in the event of flipping from sane to negative value or something else? In the meantime, another experiment completed, giving more insight. I have one of those devices connected to a consumer that constantly drains ~ Exactly after 2 hours, it incidentally switched back to a sane value. Taking the last timestamp, which is after 140 minutes, we would expect The reported value is Which would again be double the expected value. |
|
I'm interested in the raw commands that get sent - best case some correct ones and some flipped ones. Make sure to set the loglevel of the zwave-js logger to debug, so we can see this.
Seems correct, in Z-Wave floats are just encoded as integers plus precision (# of decimal places). Based on the history of values I think this device has some big problems with encoding values that aren't divisible by 0.1.
Not much we can do about that if the device reports this. |
Some more from this run:
So some correcting math on the value on retrieval is not feasible? I can hack it into my home-assistant installation, but before I go there, I'm trying to understand to what extend zwave_js is the correct place to correct such awful quirks. Trying to set up your experiment now. |
Generally we do not try to fix application level device quirks in the driver for two reasons:
Other projects (like SmartThings) have done these things by writing device-specific integrations, which in the end just leads to the manufacturers saying "but it works in XYZ 🤷🏻♂️" when in reality they are just too lazy to fix their shit. The stuff above would have been caught by QA if they bothered to test it. Maybe having a majority of their users complain because their stuff does not work with a standards-compliant software will change that mentality. Some manufacturers do care - I've already seen a case where we had a beta firmware version to test just hours after a bug report. |
|
I don't know what is different this time. Currently having a run from |
|
Oh, the messages are encrypted. I need your network key to decode them - you can send it via mail to the one in my profile. |
|
It actually is just the one bit that flips. This seems to be the same in the other bug reports that can be found all over Google. If you ask me, you should complain to the manufacturer about this and ask for a firmware update or return it or something. |
AlCalzone
added
cannot fix ❌
|
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 😅 ) |
|
@AlCalzone Do you think a workaround like that can be implemented ? |
|
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. @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. 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. |
|
I would love to have something like that as well. 👍👍 In the current case, all we would need is to apply some logic and math on the raw device value before passing it on to home assistant or whoever reads it. A hook in zwavejs2mqtt sounds reasonable? |
|
I have a similar use case for a roller shutter that never reaches fully closed or open in some situations. |
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:
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: 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. |
|
I just checked https://zwave-js.github.io/zwavejs2mqtt/#/usage/setup?id=device-values-configuration some more and it seems this would be almost a solution. I think not all problems could be solved with math operations only, though. At least not as comfortable. And sometimes you might not want this for ALL devices of the same type (that's what it does?), but just some specific devices? @AlCalzone since this is in the realm of zwavejs2mqtt, would you be opposed to exploring this more as well? Or is this anyways not "your domain" but @robertsLando's ? :) |
|
@robertsLando Can do what he likes |
|
For the ones using mqtt devices configuration table can already be used to create a custom send and write functions |
@robertsLando would that only affect values sent via MQTT or also affect values sent to HA using the server port integration (posibly not). |
|
It only affect values sent/received via mqtt, I haven't any control on what is done by zwavejs server, it is only another listener of zwave driver events |
|
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. |
|
Hi, the bottom one is the value from the template. |
|
@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 {% set correctionFactor = 0.26 %}
...
{{ ( value * correctionFactor ) | round(roundDecimals) }} |
|
@MarijnS95 ah okay, now i see the point, in that case it seems to be okay. thx. |
|
hello, |
|
Don't comment on a closed issue. Open a new bug report and fill out the template. |
|
okay its here > #4408 thanks |
This gist has disappeared, anyone have a copy? |
Version
Checklist:
Build/Run method
zwavejs2mqtt version: 4.3.1
zwave-js version: 7.5.1
Describe the bug
The
kWhmeter of theNAS-WR01ZE(https://devices.zwave-js.io/?jumpTo=0x0258:0x0200:0x1027:2.32) smart plug is reported/displayed as a negative number.After resetting the accumulated meter values, sane positive values are reported for sometime, but at some point it flips to negative.
zwavejs2mqtt.log:
zwavejs.log:
The negative value also gets picked up by Home Assistant.
To Reproduce
Let the device report for some time.
Expected behavior
A sane number being reported.
Additional context
I am unsure if this is a SW issue or a quirk with the device itself, since it looks like bit 31 is being flipped.
The screenshot below was made not too long after a reset of the accumulated values. If I take the negative number and flip bit 31 from 1 to 0, we get
35, which would be0.35kWh I presume, and that would make sense given that a reset was done earlier.This is happening on multiple of the same devices I own, not only a single one.
The text was updated successfully, but these errors were encountered: