Discussion: The best way to implement device specific features in generic device types

As we all have seen, ST tends make generic device types for broad categories of devices. For example, all z-wave switches share the same device type, even if some support indicator lights, some don’t, etc. Sometimes, this just makes ST look stupid and/or have a support headache (such as the example above) and other times, it can lead to a huge inconvenience for an owner.

Today, I discovered that my schlage z-wave lock reports a 70% battery strength and then an hour later reports 0%. (While at 0, the deadbolt motor won’t run, but it still is reporting z-wave events.) My first thought is that I can take this into account in my custom device type for this door lock.

However, it got me to thinking: What would be a good way for ST to handle this (and SHOULD they?) It seemed like a good topic for discussion (and I haven’t seen any good long novels from Terry recently…)

2 Likes

Carry a physical key for your Schlage at least! :wink: I do!

Actually, Ron, I was using that as an entry for the topic. While it’s a true story, it’s really irrelevant to the topic beyond one of two examples.

ST’s Z-Wave implementation is mediocre at best, to put it mildly. It’s clear that their primary focus was on Zigbee and Z-Wave was just thrown in for a good measure. No wonder their device handlers are “generic”. I guess they just wanted to tick a “supported” checkbox and be done with it.

Simple…, not a novel:

At “Add Device” time, SmartThings picks a default certified best dumb-fit Device Type and assigns it to the Device.

Then the detail screen for the Device shows up with a highlighted button that suggests alternative available Device Handlers for user selection (if any), giving the detailed brand and model number and other information to help the user choose. A “reset to default” button should also be available.

It’s a *non-*compromise. A win-win.

I don’t think the device types should be generic, they would get too fat real quick, and then how could you deal with the different preference options that should be exposed?
If a device has enough “special” features, and most of them do, I think it should have a dedicated device handeler to advantage them.

2 Likes

It would be easier for ST to include the device types that are generic in firmware for V2. Imagine if they have specific device type for each devices, the firmware would be huge. I hope that ST will let us load the specific device types to the HUB locally some day.

1 Like

[quote=“tgauchat, post:5, topic:22726”]
hen the detail screen for the Device shows up with a highlighted button that suggests alternative available Device Handlers for user selection (if any), giving the detailed brand and model number and other information to help the user choose. A “reset to default” button should also be available
[/quote]This could work… Actually, based on MSR (that most devices provide) it could auto-select the best device type. However, do all the device types for every possible device have to be pre-loaded on your v2hub?

By having conditionals in the property pages, it should be doable. Either based on the device type “description”, or the MSR (if supported.) As an obvious example, if a z-wave switch doesn’t advertise the configuration command, don’t show the tile for “indicator light” on the device page.

On the other hand, some of the “special features” of an otherwise generic device type can be quite extensive. There are 5-6 “special features” of the schlage z-wave lock that are either unique or uniquely implemented. If the same holds true for other z-wave locks, then a single generic type that intelligently exposes the proper features might become overwhelming. However, the alternative of a generic type that exposes nothing for any of them is also not great.

So, I actually do have an idea on this…

What if a device type could be generic, but also load type-specific modules? So, the z-wave lock device would be the catchall. After getting the MSR from the device, it would call a ST function passing the raw z-wave description and MSR as parameters. Then, something on the server side would recognize the description and/or MSR and send back a specific “add-on” to the device type which implemented the extra features?

So, for example, the generic “z-wave switch” would ONLY provide on/off capability for a GE z-wave switch. After detection, it would send the raw description (0 0 0x1001 0 0 0 7 0x25 0x27 0x73 0x70 0x86 0x72 0x77) and MSR (not sure if this switch supports it or what it is) to the server. The ST server would recognize that as a GE branded switch that, in addition to on/off, also supports an indicator light with 4 possible states. A linear switch would support an indicator light with 3 possible states. The z-wave socket adapter I have doesn’t even support the configuration class, so would ONLY be an on/off switch.

This differs from what Terry suggested in that it wouldn’t CHANGE device types… it would still use the “basic generic” device type, but would add on special modules for specific devices. So, the BASIC functionality is always 100% the same no matter what else changes. Even if the device specific module breaks, the basic type still works.

I realize the idea isn’t complete here. I’m only brushing the edges of the concept… Of course, none of us have a clue if ST is capable of doing anything like this with their infrastructure and the v2hub. Even if all the technical aspects aren’t hurdles, it would still take at least “a few weeks” before they could even consider the idea…

You’d need to keep the autoselect from operating if the person is trying to use a custom device type. That adds yet another layer of complexity.

The current architecture that SmartThings is using for Hub V2 code distribution (Device Handlers and SmartApps) — i.e., pack everything into the single firmware image — is not sustainable for many reasons and I sure hope it is an interim solution.

This is the equivalent of having every single App from the Play Store or App Store pre-loaded onto your phone. Talk about bloatware!

The architecture needs to evolve into the one originally proposed and planned by Jeff Hagins and which every reasonable OS developer would have built… i.e., a fully modular system that will dynamically download only the Device Handlers and SmartApps that the Customer is using and kick out least used / low priority when memory is low, and individually update modules from the Cloud.

Ummm…the Hub V2 is running Linux variant, no?

Whatever. They ran into a problem getting dynamic loading to work in their “rushed” timeline.

Samsung already does that with their phones… (and didn’t Samsung buy ST? hmmm…)

1 Like