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.
Full interoperability through layer 6 with backwards compatibility to all versions.
Hub manufacturers are not allowed to blame end devices manufacturers for a loss of compatibility for an older certified device. Thatâs been part of the standard forever. Zwave wanted to be a consumer-friendly protocol and to assure customers that their existing equipment would not suddenly stop working because the controller was updated.
Please provide a statement from the Zwave Alliance to support the arguments you make above that certified devices from multiple manufacturers are âout of complianceâ and therefore did not have to be supported. (The fact that they donât meet the current specification is irrelevant to Zwave and always has been, because of its promise of backwards compatibility.)
If you are saying that the Zwave Alliance is at fault because it certified multiple devices from multiple manufacturers that did not meet the specification in place at the time that the devices were certified, then again, I would like to see a statement to that effect from the Alliance itself. (And Iâm sure so would Fibaro and Qubino. They paid for certification in part to avoid exactly this situation: that they would be blamed if another brandâs hub was updated and functionality on their devices was lost.)
Either zwave is backwards-compatible for certified devices or it is not. The Zwave alliance has always publicly said that it is, that is part of their brand promise.
Please see my post just above this. The Zwave Alliance has always promised backwards compatibility for all certified devices. Not only would SmartThings not be ârequiredâ to drop support for legacy zwave devices, itâs actually the other way around: the Zwave Alliance requires that hub manufacturers maintain support for older generations as long as the devices were certified, which these were.
This is part of their promise to consumers that they could use devices from multiple manufacturers without fear of having to replace their light switches because they got a new hub.
I have not seen anything from the Zwave Alliance indicating that this has changed.
And this, from the company that now owns the Zwave chip manufacturing:
Together with security, backwards compatibility is a core value and a celebrated engineering principle of the Z-Wave ecosystemâŚ
Z-Wave has been in the market for more than 15 years, with over 100 million products deployed. This impressive market adoption is due to Z-Waveâs interoperability and backwards compatibility, meaning that a home owner can continue to use previously installed smart home devices, together with newly installed devices. This is ensured through the rigorous certification process that all Z-Wave devices are required to pass.
All true. The worrying part is that if, in cases such as this, a hub is updated in line with standards and this results in, say, a fibaro becoming inoperative, then who is to blame? And more importantly who is responsible for the fixes?
Iâd imagine that since the fibaro device is actually the culprit (due to the device itself mildly failing zwave specs), then it comes down to fibaro to fix or replace. Iâm assuming that fibaro would be expected to swap out any ânon standardâ devices, as not everyone who buys a fibaro has (or is expected to have) access to fibaros own hub to push whatever firmware updates they come out with.
Iâm still really impressed that the guys here in tech helped me as much as they did. Because aa annoyed as I was, at the end of the day it wasnât technically smartthings fault.
Which I knew would mean that I was, potentially, screwed.
@djh_wolf you have so completely and utterly misunderstood the last 2 posts by Mr Roberts to such a gargantuan degree that if i were you i would just delete your above post, for everyoneâs sake. You are just muddying the waters, @SmartThings staff will understand very clearly the 2 posts, and their responsibilities regarding Z-Wave firmware being backwards compatible, and in fact being required, and I eagerly await their response.
If a certification is awarded, which is true for both the Fibaro and Qubino devices, then it is a core tenet of Z-wave that any certified hubs (which includes SmartThings) will provide backwards compatibility to ensure that those devices continue to operate with hubs meeting any new Z-wave specifications.
This backwards compatibility is so important to the z-wave brand itself that they have even allowed older generation devices with less adequate security to continue operating if the customer chooses to do so, as explained in the second article I linked to above.
Most other network protocols would require that all devices be upgraded to the new specification, but Z-wave specifically has not. The example the Z wave alliance has always given from the beginning has been that customers should not have to replace their existing light switches just because they get a new hub running a newer generation.
If the devices had been using the âmanufacturer custom codeâ command classes, then thatâs a different situation and other brands donât have to provide support for that. But thatâs not what happened here. They were using the standard multi channel commandset. They got through certification. At that point both device manufacturers and customers are supposed to be able to rely on the promise of backwards compatibility.
In this particular case, since the Zwave alliance did issue certifications for the Fibaro and Qubino devices, if there is a fault it would lie with the alliance itself. But almost certainly the resolution would be that hubs using the newer specifications be required to continue to support those certified devices. That is what has always been done in the past. Otherwise backwards compatibility would be meaningless.
(We saw an exactly parallel situation arise when direct association was changed for zwave plus. The way Fibaro used to use Zwave association is no longer allowed under the current specification, but that didnât break anything for legacy devices. They are still supported using the old method.)
As I posted above, I find it hard to believe the standards body has this requirement as it is exactly opposite to everything that this particular standards body has officially said up until now. I would like to see a statement from the Zwave alliance if they are changing the requirement for backwards compatibility with certified legacy devices. That would be a huge change for the Z wave brand.
I absolutely love all your posts above @JDRoberts. Iâve stayed very quiet in this discussion and in the other one. I remember back in the 28.x firmware update days (or one of those versions) where my hub updates totally messed up my zwave environment. Granted I had a ton of zwave devices back then, and many were chatty, but I specifically recall a post where my issues were blamed on old GE devices that were working perfectly fine prior to one of those hub updates. How interesting that here we are again with more problems related to âgetting certifiedâ at the expense of customers and blaming devices? Thatâs not right.
And since I have been asked privately if I am sure that the devices that people are reporting problems with Really certified, you can look them up for yourself:
Both Qubino and Fibaro are major zwave manufacturers. And no product can be sold with the Z wave logo if it is not certified.
So again, if requiring current compliance of certified legacy devices is part of the next generation certification, itâs a huge change for the Z wave brand, and I havenât seen anything from the alliance about it.
Notice that the newest Homecenter 3 (HC3) is missing in the available for box. A quick search of the Fibaro forums will return results of users who are having issues with the UBS on the latest homecenter.
All that said I am going split the debate about true z-wave certification into its own topic because it is diverting attention from the remaining users who are still having issues with their devices.
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.
Your reasonable compromise is clearly UNacceptable for those direly affected. But who now cares about âcollateral damagesââŚ
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.
I cannot say it better !
Finally, what are the possible solutions ? :
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.
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.
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âŚ
âThere are two classic blunders the first is never get involved in a land war in Asia, and the second is never go against a Sicilian when death is on the line!!!â
And the third - dont question JDâs knowledge of HA specificationsâŚ
One important thing to note about that particular document is that while it does show spoofing endpoints for a multi sensor, and particularly spoofing endpoint 2 to report temperature, it is spoofing the source endpoints From the sensor. The diagrams still show the hub as only having one endpoint.
Apparently the devices that are having problems are those that were spoofing the destination endpoints when communicating to the hub. thatâs an exploit that should not have been allowed when the devices were certified, but it looks like they got through.
So Iâm not sure how that would be fixed with a DTH.
I was dropping in as an illustration about how it is supposed to work. As Kianoosh said in his more detailed post, one can poll those endpoints for updates which is not optimal but is something that will work in a DTH regardless of where the device is sending itâs status updates. Some of these devices also support configuration commands that allow you set which association group updates are sent to. These configuration params can also be set in the DTH. Now, if the device supports these params then you wonât need to poll.
Polling wonât be enough for sensor devices which are spoofing destination endpoints in order to report on a change in a value in excess of a specified Delta. Thatâs going to require both polling and something to compare the result to, so probably a webcore piston to go along with the polling.
