Information about Nexa AB distributed Z-Wave devices.
Please note that this document is a compilation personal notes and opinions about my experience (<1yr) with these devices (and not a complete list). Your experience may vary... and I would love to hear about it in the comments.
Switch with power metering kWh and W/A/V sensors and up to 2500W load (w/over-load detection).
Product information (archived)
Device:
0x0268-0x0002-0x1027FW: v2.23.0
SDK: v6.81.3
Main Values:
Binary Switch v1,Meter v4,Supervision v1,Notification v8
These are things I personally have encountered while using these switches of the same revision (noted above).
700-series controllers was used. Also a Nexa Bridge X. I have switches from other brands not experiencing these issues (not included in these datasets).
Also, note that even though illustrations are represented in Home Assistant, the actual end-user app has nothing to do with this, neither does the controller software (like Z-Wave JS 3 or Open Z-Wave). This is all raw data.
These problems occur if security is enabled or not, and even after multiple exclusion and re-inclusions.
Has a random Bit 31 flip bug 1 in the kWh power metering that causes massive negative numbers, ex -21474835.85 kWh. This is the most significant bit, which inverts the number when toggled (so it starts from -2147483648).
It seems that the Nexa Bridge gateways corrects (or rejects) these, but most other gateway software won't... which is technically correct. It's not the responsibility of z-wave gateway software maintainers to handle bad implementations/defects/etc. from device manufacturers/distributors.
It also seems like the number of the kWh meter is incorrect and overshoots in most cases.
In my case over 50% on average combining all 10 devices.
The readings from the
Wsensor are good, and calculatingkWhbased off this manually is fairly accurate. So I'm not sure how the values from the provided meter could be this far off.
The over-current protection trigger causes additional overshooting with massive values in some cases!
This illustration clearly demonstrates that the values are wrong, because they exceed my total energy usage reading from my smart meter. The switches are only expected to consume 10-15 kWh when combined in this period.
Also there seems to be some kind of bug causing the switch to perform random power cycles without any user interaction.
The switch makes a very obvious auidble relay toggle sound when this occurs, just like if you were to press the toggle button manually on the device.
I have several switches on the same circuit, and this never happens to multiple switches at the same time. These are also assigned to the same z-wave group and have 1 hop in the network mesh.
This is exaggerated on devices that don't draw much power ?! The switches I own that are mostly "idle" seems to exhibit this behavior more often.
This also seems to revert the power metering kWh value to an earlier state. This might be because the state was not stored to EEPROM before the power cycle happened or some other edge case.
I'm unable to reproduce the cycling, and have not yet established a pattern, but the reverted value is always observable, as seen as straight vertical dips in the following graphs.
Noticable 24hr gap:
And then another 24hr, followed by 12hr gap:
And a completely wild one that seems to be related to (false positive ?!) over-current protection. Every dip or spike here is exactly when a trigger for that condition occured (even when anything connected to the switch was completely turned off):
Taken from my influxdb instance that gets raw data because I forgot to screen capture this in HA and it was scrubbed because I only have 7 days retention
This is a rare one, and has only happened to me personally 3 times.
A few different variations observed:
Solution is to take out and re-insert the switch.
I personally suspect this is related to the unsolicited power cycles because the intial symptoms are the exact same (i.e. audible relay sound occuring without any user interaction and completely random.) or to false-positive over-current detection (which in turn causes a power-off state).
If your gateway uses MQTT then it's possible to add a function to correct the metering value. Or if you're brave, then you can patch your gateway (or HA integration) source code.
Example code:
// JS
return val >= 0 ? val : (val * 100) & 0x7fffffff) / 100# Python
return val if val >= 0 else float(int(val * 100) & 0x7fffffff) / 100This does not fix the overshooting values, but you can add a factor, i.e.: (new_val) * 0.45 to the calculation to offset that somewhat (0.45 is just a dirty approximate of my case... change this).
Home Assistant users are better off using Riemann sum integration to calculate the metering based on the W sensor. You can combine this with a Utility Meter to get periodic reports for your energy dashboard, etc.
The
Wsensor is fairly accurate, which leads to better end-result than hacking the metering like described above in the notes.
Complete template example:
# If you have multiple of these, combine all the `W` into one.
# Skip this one if you just want to monitor individual switches.
template:
- sensor:
- name: Calculated Total Wattage
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: >
{% set ns = namespace(states=[]) %}
{% set includes = [
'bathroom_electric_consumption_w',
'bedrooom_electric_consumption_w',
'livingroom_electric_consumption_w'
] %}
{% for s in states.sensor %}
{%- if s.object_id in includes and s.state != 'unavailable' -%}
{%- set ns.states = ns.states + [ s.state | float ] -%}
{%- endif -%}
{% endfor %}
{{ ns.states | sum | round(2) }}
# A new sensor that increments based on kWh and resets every day
utility_meter:
calculated_daily_energy_spent:
name: Daily Switch Energy
source: sensor.calculated_total_energy_spent
cycle: daily
# A new sensor that samples a series of W to kWh using Riemann sum that increments constantly
sensor:
- platform: integration
name: calculated_total_energy_spent
unit_time: h
unit_prefix: k
round: 2
source: sensor.calculated_total_wattage
# Or if you didn't use the combination template and just want to monitor a single switch:
#source: sensor.bathroom_electric_consumption_wAccording to my research, this also happens with other brands (example) with very similar looking products (at least by comparting the plastic molding imo), which is why I believe this is a whitelabel device and noted it as such. The fact that other devices (documented in this gist: 1, 2) identifies as other brands according to publicly sourced data reinforces my suspicions. ↩ ↩2
I will update and amend anything that comes from my discussion with Nexa support. AFAIK the product team has been informed with everything documented in this gist. ↩
I submitted an entry to the database index to warn about some of these findings. ↩
Up to 250W (or 40W LED) load.
Product information (archived)
Device:
0x0060-0x0003-0x0003FW: v1.2
Main Values:
Multilevel Switch v1,Notification v4
Everspring device.For doors, windows, etc.
Product information (archived)
Device:
0x0260-0x0168-0x0168FW: v3.1.1
SDK: v6.71.3
Main Values:
Notification v8,Battery v1
Shenzhen Heiman Technology Co., Ltd. deviceSee this gist for more information about this device.