SmartThings Community

Device handler supporting multiple firmware versions with different parameters?


(Bradlee S.) #1

I have a Z-Wave device that has since seen a firmware update which exposes additional parameters on the device. I have added separate fingerprints in my device handler which are identical other than ver:“x.xx” vs. ver:“y.yy”. Version y.yy has added 2 new parameters that I have incorporated into my DH, but I would like these to be hidden to devices at x.xx which don’t support them.

Is this possible? Can I wrap parts of my tiles section in some sort of if/then/else statement that will display based on the current device?


(Jimmy) #2

i believe @krlaframboise has done this with some of his Zooz handlers


(Bradlee S.) #3

Any chance you could point to one as a reference example?


(Jimmy) #4

try this


(Bradlee S.) #5

That handler seems to be checking the firmware version and handling something differently based on the reported version. That part is simple enough.

What I need is a way to hide a tile based on something similar. I don’t know if this is possible.

I guess I could have my tile show the firmware version if at the older level. And if it’s a newer version, then display what I want it to do. That might be a good enough solution for me.


(Jimmy) #6

oh, no, tiles can’t be hidden. Your workaround is what i’ve seen before. Or just leaving the tile blank.


(Kevin) #7

Not possible.

I use firmware version to determine which fields to sync, but there’s no way to conditionally show preferences because the device data, attributes, and raw desc are null while the preferences are loaded.

I usually just put a note in the pref title or next to the supported options.


(Bradlee S.) #8

Thanks. Yes, this seems like the most straight forward solution.


#9

I know it’s simplistic…but you could just have two version of the handler too. When fingerprinting, the “ver” will be the device’s firmware version. So different version of the DTH could be associated with different versions of the firmware.


(Bradlee S.) #10

Yea. That’s what I’m trying to avoid.


#11

Yeah…but I don’t understand why? If the devices are different, then just build different DTHs. You can always just install both of them and the device should know which to use.


(Kevin) #12

Until ST breaks something or you get feature requests and you have to make the changes twice or the manufacturer releases another update and now you’re dealing with 3 DTHs for the same device.

Also if a user buys the device and installs the DTH then 6 months later they buy another one they most likely won’t know the firmware changed or expect to have to install a different DTH for it.


(Bradlee S.) #13

Exactly. Why have multiple device handlers for different versions of otherwise identical hardware if you can handle all of them in a single DH?


#14

If you say they have different functionality, why not put them in separate DTH? If they’re the same, then yeah.


(Bradlee S.) #15

They function the same. They are the same device. The newer version simply adds 2 configurable parameters.

Even if they were completely different, but could both be handled by the same DH, then why would anyone bother with 2? No one needs extra useless code.


(Kevin) #16

I’m just curious, how many DTHs have you written and posted on the forum?

I ask because supporting a DTH can be time consuming and if you have multiple versions of it users will end up trying to use the wrong devices with them and it will become much harder to support.

Assuming it is possible to assign the correct DTH based on the version number, that only works if the user installs all the DTHs before joining the device which often doesn’t happen.


#17

That’s awfully rude. I was merely making a suggestion. If you don’t like it, don’t use it. No need to be a jerk about it.


(Kevin) #18

I apologize, I didn’t mean to be…

You posted 3 times about splitting them into 2 DTHs and questioning why that wasn’t an option so I was just trying to explain from a community developer’s perspective why maintaining multiple DTHs for the same device is such a problem.

If you had responded saying that you had posted code then I would have been genuinely interested to know how you’ve worked around some of those pitfalls.


#19

Actually, I asked why not post two if there is different functionality. And then said if they were the same, then yes it makes sense to have one. But it doesn’t make sense to me why you are harping on the fact that I asked a question. Are you that threatened by someone asking questions? Are you that insecure that you can’t tolerate anyone disagreeing with you?
And for your information, for several years I ran software testing for a medical device company. So I know all too well about maintaining and supporting multiple version of software, thank you very much.


(Bradlee S.) #20

Your questioning made it seem that you either didn’t bother reading the issue, or just have no clue and wanted to post anyway. It added no value to the topic.