And maybe it can make coffee for the first responders while it’s at it. (engineer joke)
Seriously, though…
The capabilities of a device are what that physical device can do as delivered by the manufacturer. One fairly stupid device.
a communication standard like zigbee or zwave is what allows a pretty smart coordinator, like the ST hub, to tell a known pretty stupid device to use the built in capabilities it has, usually in messages of 2 bytes or less. Or to receive a report from the pretty stupid device about what it did.
Like @chuckles and @pstuart said above, the klaxon won’t necessarily have a report capability. That’s important to know.
PRINTER DRIVERS
Java runs on the ST hub or in the ST cloud. In any case, someplace pretty smart. Zigbee and zwave are what happen on the other side of a Java interface. Basically like a printer driver. The interface part of an OO model is more like the word processing program. Two different things, both necessary to actually get a page to print.
You can’t print in color on a black and white printer, no matter how much code you write.
SO WHICH DEVICES ARE ABOUT THE SAME PHYSICALLY?
The question is always which physical devices should use the same device type. Are a black and white printer and a color printer the same sort of physical thing, just with a some features icon or off? Possibly. Maybe even probably.
Are a klaxon siren with no reporting function and an SMS messaging system the same sort of physical thing? Not a chance. To a human, they serve some of the same purposes. But to a communications protocol, or a network engineer, they’re totally different.
Device type is about what the physical device can do when delivered by the manufacturer. Not about what purpose you intend it to serve.
PURPOSE IS FOR PEOPLE.
A printer driver can control a device used to print a sign that says: “WARNING:ELEVATOR OUT OF ORDER.” Does that mean a printer should be put into an Alert device type?
The english word “Alarm” might be a mode, available to other apps. It might be a scene, that causes many things to happen at about the same time. It might be a smartapp that changes mode and does a bunch of other things, including trigger a klaxon and send an SMS message. That’s terminology, and you can decide how rigorously you want to control the terminology used in the ST ecosystem.
But device type capabilities should model the manufacturer-delivered abilities of a set of pretty similar physical devices, because they represent the printer driver. They should have map well to existing communication network protocols. They should associate device models that have similar energy draw and routing table functionality.
THINGS THAT MATTER INSIDE THE BLACK BOX
There’s a very important reason why zwave separates static controllers and handhelds, and it’s all about the routing table. To a human, their purpose is the same. But to the communication network, the difference is really important. It’s similar to the reasons why a printer driver doesn’t include display screen options. Monitors are a separate device type because of differences in the physical devices, not their purpose.
The communication protocols allow for sending a code. And we want that code to be as tiny as possible (small packets sent over short distances to/from low power devices).
Look at the conformance statement for the Schlage lock:
It supports the battery reporting code. Since it’s also a lock, it supports the “anti theft” reporting code.
Now look at the Philip flood sensor. It supports the battery reporting code, but NOT anti theft.
Why not? Because unlike a software design philosophy, as engineers we want each device to support the FEWEST possible features to meet the use case. Lower the power draw, lower the memory requirements.
I guarantee you you will only find an anti theft code supported in a device that supports beaming. Because if the sensor is asleep for 10 minutes, there’s not much point in the anti theft alert. Plus the device itself doesn’t have the physical security features of a lock. But beaming adds expense from about 5 different angles.
WHAT YOU CAN SOLVE WITH SOFTWARE
So device types are printer drivers. (Technically, the UI to the printer driver.) And communication network protocols for home automation think 3 bytes is verbose. And we intentionally keep the end devices pretty stupid and limited in features to keep power draw and costs down.
Don’t overload a device type with features not frequently supported. A door lock is not an on off switch. It has a bunch of built in security features plus a requirement for instant on. (Hence beaming.) but if a switch is smart enough to know all the things it CAN’T Do, I’m paying for intelligence I don’t need.
And don’t send messages any longer than needed. Quite often a new device type is added just to drop a few bytes from the packets. ZLL distinguishes color scenes from no color scenes just so they don’t have to have white bulbs processing parameters that are meaningless to them.
Put the smarts into the code run by the smart machine. Not the driver for the not very smart device.v