remove superfluous eval conditions

[bluemoehre]

Signed s16 integer supports values from -32768 to 32767, so Attr.val != 32768 is superfluous. Typically the lowest value, -32768 is used to indicate an invalid value.

[github-actions]

Hey @bluemoehre, thanks for your pull request!

Tip

Modified bundles can be downloaded here.

DDB changes

Modified

• eva/powermeter.json : Meter Reader ✔️

• legrand/Contactor.json : Contactor ✔️

• Jasco-GE/GE45856_wall_switch.json : GE ZigBee in-wall smart switch (45856GE) ✔️

• bosch/plug_compact.json : Plug compact EU (BSP-FZ2) ✔️

• develco/zhemi101_external_meter_interface.json : Electricity meter interface (ZHEMI101) ✔️

• legrand/cable_outlet.json : Cable outlet 3000W (064879) ➰ (unvalidated)

• immax/07048L_smart_plug.json : Neo smart plug (07048L) ✔️

• lixee/zlinky_tic_historique_mono_base.json : ZLinky_TIC mode historique base ✔️

• lixee/zlinky_tic_historique_mono_hphc.json : ZLinky_TIC mode historique HPHC ✔️

• lixee/zlinky_tic_standard_mono_base.json : ZLinky_TIC mode standard base ✔️

• sengled/e1c-nb7.json : Smart plug with power monitoring (E1C-NB7) ✔️

• sonoff/ck-bl702-swp-01(7020)_plug.json : Smart Plug (eWeLink) ✔️

• third_reality/3RSP02028BZ_smart_plug.json : Smart plug (3RSP02028BZ) ✔️

• tuya/_TZE204_ac0fhfiq_energy_meter.json : BiDirectional zigbee energy meter (TS0601) ✔️

• adeo/ldsenk02f_plug.json : Plug 16A ✔️

• develco/emizb-141_electricity_meter_interface_2.json : Electricity meter interface 2 EMIZB-141 ✔️

• frient/emizb-141_electricity_meter_interface_2.json : Electricity meter interface 2 EMIZB-141 ✔️

• lixee/zlinky_tic_histo_tri_hphc.json : ZLinky_TIC mode historique HPHC triphase ✔️

• lixee/zlinky_tic_standard_tri_hphc.json : ZLinky_TIC mode standard HPHC triphase ✔️

• robb_smarrt/rob_200-017-0_plug.json : Smart plug 3680W (ROB_200-017-0) ✔️

• aubess/aubess_plug_TZ3000_hdopuwv6.json : Smart plug 16A EU (TS011F) ✔️

• heiman/smartplug.json : Metering Plug (HS2SK) ✔️

• innr/sp_120.json : Smart plug (SP 120) ✔️

• innr/sp_240.json : Smart plug (SP 240) ✔️

• innr/sp_234.json : Smart plug (SP 234) ✔️

• niko/170-33505_170-33605_smart_socket.json : Smart socket (170-33505/170-33605) ✔️

• sinope/sp2610zb_smart_switch.json : Smart in-wall outlet US (SP2610ZB) ✔️

• third_reality/3RSPE01044BZ_smart_plug.json : Smart plug ✔️

• tuya/_TZ3000_cehuw1lw_smartplug_EU.json : Standard plug (TS011F) ✔️

• wiser/fuga_socket_outlet.json : LK Fuga Wiser wireless socket outlet 16A (545D6115) ✔️

• wiser/smart-plug-single-16A.json : Wiser smart plug 16A (CCT711119) ✔️

• wiser/socket-outlet-double-16A-connected.json : Elko smart socket double 16A plus PW (EKO09738) ✔️

• xiaomi/xiaomi_dcm-k01_t2_dual_relay.json : Aqara Dual Relay Module T2 (DCM-K01) ✔️

• xiaomi/xiaomi_wp-p01d_h2_wall_outlet.json : Aqara wall outlet H2 EU (WP-P01D) ✔️

• blitzwolf/bw_shp13_smart_plug.json : Electricity metering 16A EU plug (BW-SHP13) ✔️

• blitzwolf/bw_shp15_smart_plug.json : Power monitoring 16A 3680W EU plug (BW-SHP15) ✔️

• develco/splzb-131_smart_plug.json : Smart plug mini type F - Schuko (SPLZB-131) ✔️

• frient/splzb-131_smart_plug.json : Smart plug mini (SPLZB-131/SPLZB-134/SPLZB-141) ✔️

• lidl/hg08673.json : SilverCrest smart plug (HG08673) ✔️

• neo/NAS-WR01B_TS011F.json : Smart plug 16A with power monitoring EU (NAS-WR01B) ✔️

• tuya/_TZ3000_TS011F_smart_plug.json : Smart plug power monitor (TS011F) ✔️

• tuya/_TZ3000_typdpbpg_smart_plug_eu.json : Smart plug EU (TS011F) ✔️

• tuya/_TZE200_byzdayie_din_enrgy_meter.json : Single phase 65A DIN rail smart energy meter (TS0601) ✔️

• tuya/nous_a1z_smart_plug.json : Smart zigbee socket (A1Z) ✔️

• xiaomi/xiaomi_zncz12lm_smart_plug.json : Smart plug (ZNCZ12LM) ✔️

• namron/4512737_thermostat.json : Thermostat touch zigbee 16A (4512737/4512738) ✔️

• xiaomi/xiaomi_sp-euc01_smart_plug.json : Smart plug (SP-EUC01) ✔️

• xiaomi/xiaomi_lumi.relay.c2acn01.json : 2 way control module wireless relay ✔️

• namron/5401395_heater.json : Panel heater 1000W (5401395/5401399) ✔️

• xiaomi/xiaomi_ws-euk04_h1_switch.json : H1 dual rocker switch neutral wire (WS-EUK04) ✔️

• xiaomi/xiaomi_zncz04lm_smart_plug.json : Smart plug (ZNCZ04LM) ✔️

• xiaomi/xiaomi_zncz04lm_smart_plug_v24.json : Smart plug (ZNCZ04LM) ✔️

• ubisys/s1_5501_s1r_5601.json : Power switch (S1 (5501)/S1-R (5601)) ✔️

• ubisys/s2_5502.json : Power switch (S2 (5502)) ✔️

• ubisys/s2r_5602.json : Power switch (S2-R (5602)) ✔️

• xiaomi/xiaomi_ws-euk03_h1_switch.json : H1 single rocker switch neutral wire (WS-EUK03) ✔️

• xiaomi/xiaomi_ssm-u01_t1_switch.json : T1 single rocker switch with neutral wire (SSM-U01) ✔️

• bosch/bmct-slz_shutter_light_control2.json : Light and shutter control II (BMCT-SLZ) ✔️

• ubisys/j1_5502.json : Cover controller (J1 (5502)) ✔️

• ubisys/j1r_5602.json : Cover controller (J1-R (5602)) ✔️

• icasa/ICZB-IW21D.json : Zigbee Dimmer PRO ✔️

• ouellet/OTH4000-ZB.json : Smart thermostat (OTH4000-ZB) ✔️

• sinope/th1124zb.json : Smart thermostat for electric heating (TH1123ZB/TH1124ZB) ✔️

• ubisys/d1_5503_d1r_5603.json : Universal dimmer (D1 (5503)/D1-R (5603)) ✔️

Validation

Tip

Everything is fine !

_{🕟 Updated for commit ffdb8f3}

[bluemoehre]

@ebaauw FYI

[SwoopX]

While this is technically correct, there's devices out there depending on this check to discard blips. Given the fact that this check doesn't hurt and there is a necessity, we should keep this untouched.

[bluemoehre]

While this is technically correct, there's devices out there depending on this check to discard blips.

Do we know which ones?

Given the fact that this check doesn't hurt and there is a necessity, we should keep this untouched.

That's bad practice. Like @ebaauw asked me to change this (at least for the generic one), and I found the same "error" in other files, it may happen again that people reading the code want to fix that, because it looks like a bug. If only a few people have that hidden knowledge, it's a risk.
I would recommend to make the generic one correct and then take care about the the blippy bloppy devices. We should also leave a comment in the code or add a test, so everyone can understand why it's like that and prevent accidentally breaking something.
What do you think?

[SwoopX]

I'm afraid I cannot follow you to a certain extend. Where is the bad practice? We're discussing a valid boundaries check here being there for a reason. This is neither a bug (which is by definition a programatical misbehavior), nor an error (as nothing is working falsely) so there is nothing to fix in my view.

Leaving the code as is has 0 risk, changing the code as proposed introduces an unneccessary risk of breaking functionality of an unknown number of devices, hence I prefer avoiding that risk.

Regarding your suggesting to add a respective comment in the code, I'd fully buy in. Although this possibility is not given yet (I find the "description" key not really suitable for this purpose and placement is restricted), we should introduce a "comment" key to allow for some (important) documentation within a DDF at the place specifically required. "comment" key is available and usable, however, not displayed in DDF editor.

[ebaauw]

It's technically not possible for an s16 to report a value >= 32768; it simply doesn't fit the 16 bits. Any device depending on this check would have to use a different data type. That alone is reason enough to override the default item definition in the device's DDF.

[bluemoehre]

Where is the bad practice?

"Given the fact that this check doesn't hurt" [...] "we should keep this untouched"

It's bad practice to keep a workaround in a generic file just because it doesn't hurt. Especially if only a few devices are to be fixed with it. The generic files should kept clean all the time, since the amount of devices will continuously keep growing. (Imagine having in there all workarounds for all types of devices - that won't work out.)

Also we should not keep this untouched, since the workaround is not documented at all.

Undocumented workarounds will lead to copies pasted somewhere. If you need to clean this up in the future, it will take a lot of effort.

We're discussing a valid boundaries check

It is not, as @ebaauw already described. 1 Bit is used for the sign, 15 Bits remaining for the magnitude: 0111 1111 1111 1111 = 32,767

According to the specification the value always must also be an s16:
ZigBee Cluster Library

---

I checked all the devices that were changed by this PR and their commits to see if there was any information about special treatment required. If there really was a problem, it was unfortunately not documented. But you may check yourself:

• devices/Jasco-GE/GE45856_wall_switch.json: Device Request | Pull Request
• devices/eva/powermeter.json: Device Request | Pull Request
• devices/ouellet/OTH4000-ZB.json: Device Request | Pull Request
• devices/sinope/th1124zb.json: Device Request | Commit

That's all I can do at this point to convince everyone that we are doing the best possible here.
Please let me know how we continue with this PR, because it's affecting the device request #7959.