Z-Wave Backwards Compatibilty

[geeji (JJG)]

Thanks to @johnny2678 who installed the 0.30.4 beta, we now know that the FIBARO FGK-10x Door / Window Sensor is still broken, and does not report temperature.

Even before the 0.30.4 release, I posted on this thread to mention that the FGK-10x Door / Window Sensor (pre-ZW5, firmware <= 2.5) used Destination Endpoint 2 to report Temperatures.

SmartThings unfortunately ignored that input, taking care only of “Destination Endpoint 1” => the FGK-10x is still broken AND THERE IS NOTHING ANY HANDLER, STANDARD OR CUSTOM, CAN DO TO WORK AROUND THIS PROBLEM, since the temperature reports are filtered out by the Z-Wave layer.

And since the FIBARO FGK-10x takes solely the initiative to report temperatures when increments / decrements since last reported temperature are above some value, an “explicit” polling is not an acceptable workaround which could work.

@Kianoosh_Karami

In 0.30.4, We made a conscious change to allow incoming messages with Destination Endpoints of 1 to also propagate through the system, because the specification available at the time (3 years or older) may have confused some manufacturers on the proper addressing for Destination Endpoint, we also found that most of the “incorrect” messages were using Destination Endpoint of 1. We believe this change is a reasonable and compromise between supporting old/legacy Z-Wave devices and being Z-Wave Compliant.

Your reasonable compromise is clearly UNacceptable for those direly affected. But who now cares about “collateral damages”…

@Kianoosh_Karami

If your affected device is having the exact or very similar issues as the problem statement above, and is a SmartThings compatible device (“Works With SmartThings”), then please do let us know immediately which device it is and what functionality is not working. We will work immediately to ensure the compatibility is what we had provided.

The Figaro FGK-10x Door / Window Sensor ++IS++ in your “works with SmartThings” list

You say “We will work immediately to ensure the compatibility is what we had provided” : ++JUST DO IT !++

The Figaro pre-ZW5 FGK-10x Door / Window Sensor HAS BEEN FULLY CERTIFIED BY THE Z-WAVE ALLIANCE, as proven by this certificate, without any caveat, or any limitation to some upcoming FGK-10x firmware update.

@JDRoberts

The Zwave specification requires that all generations be backwards-compatible. It always has.

The Fibaro and Qubino devices were certified under old generation specifications. It is unfair and inaccurate to say that they are not compliant. They were compliant at the time that they were certified.

Therefore as a zwave controller (hub) it is absolutely required of SmartThings that it continue to support the older generation certified devices. That is part of the current specification.

I cannot say it better !

Finally, what are the possible solutions ? :

1. the cheapest, quickest : you extend the “Destination Endpoint <>0” exception beyond 1, including all numbers which were used by Z-Wave Alliance certified Devices which were also listed in your “works with SmartThings” list.

This is the ONLY quick solution which would both honor the upward compatibility promise of the Z-Wave Alliance and the implied upward compatibility of SmartThings as a member of this same alliance.

And if some “Certification Fundamentalists” (!) complain about compliance with the latest Z-Wave revision, it would be trivial for you to maintain a list of suppliers and Devices which fit the “legacy” rule, and let the Z-Wave layer pass Destination Endpoint <>0 only for those. Thus, there would be no new violation which did not exist before.

2. you work with FIBARO (and QUBINO and …) to provide retroactive firmware updates for ALL past Devices which have the Destination Endpoint<>0 problem, simultaneously with
   implementing in the SmartThings IDE a new facility for Firmware Update for all those impacted Devices

This theoretical “solution” is not a proper solution but a nightmare in the making : many Devices manufacturers will refuse to do it, and if they did they would likely break even more Devices Handlers than we have currently broken.

3. you find a time-machine which can at the minimum go back to 2013 and you change retroactively all those too well hidden non-compliance issues.

Just joking…

So the ONLY actual solution is the (1).

And if you managed to convince your “Certification Fundamentalists” that an exception was acceptable for 1, why not for more numbers ?

We all know the kind of damages “Fundamentalists” can perform against “miscreants”…
If I remember right, some country has even gone to long and costly wars to take care of such damages and make sure (?) they don’t happen again…