Yet another one that could be useful to control the environment in a house or larger building.
At the risk of taking this way out in left field. . . .
I think you have to define pollution. CO2%? COppm? O2%? Some combination? Something else? Based on some standard? If so, which? What if there is more than one accepted definition of pollution?
Maybe you let SmartApps evaluate the level of pollution based on a number sensors. CO2 measurement has already been suggested. There is a CO detector already (adding a value attribute has been suggested elsewhere). Maybe we should identify all the gases we would want to measure and define, for each, a capability.[someGas]Measurement . One or more SmartApps can be written against these capabilities based on one or more definitions of pollution (there’s bound to be more than one definition).
What the heck are we suppose to do with capability.sensor? There are no attributes. Is it just there to provide a framework for the implementation of special sensor via Device-Types with custom attributes? Is there some way to leverage capability.sensor to address all of the capabilities that have been proposed that are all some sort of gas measurement?
I will delete or move if the OP requests as this is a little bit tangential.
1 Like
What @AaronZON said. 
For an open platform like ST, the device type shouldn’t care what’s being measured. Just that the end device measures something, probably can receive a target parameter for triggering (maybe several). Can return the measured values. May have a scheduler for how often to measure as well as to report, so can receive values for those as well.
But the point is from a capabilities standpoint, it won’t matter whether the end device is measuring humidity or pollen or smoke or toxic gas. Or light levels. The physical devices have to be different, but they fit into the same capabilities framework.
“Purpose is for people.” The person selecting that particular end device will have a reason for doing so, and will make a decision about what actions, if any, the reported values should trigger. The ST capabilities shouldn’t require a separate capability for each category of substance a sensor might measure.
This is not related to Co2Measurement.
This kind of sensor detects unpleasant odors, tobacco smoke, and
vapors emitted by such materials as furniture, carpets, paint,
glue, etc
The attributes would be as such:
Kitchen exhaust,
alcohol,
gas such as NH3, CHâ‚‚O, C7H8, C6H6,VOC
This capability is based on those devices:
And others that are starting to be zigbee, such as:
It could be renamed as airQualitySensor. I haven’t seen any related sensor for this.
It still feels like you’re trying to design for a closed system. Or design the devices themselves. ST capabilities are for a way to communicate with existing devices that are manufactured by third parties. You can’t predict in advance every possible physical substance a third party sensor might be designed to detect.
What you can do is design a message format that would handle the generic needs of a sensor. But all ST really does is efficiently pass messages back and forth to third party devices. ST itself shouldn’t care about the content of those messages, only their format.
One of the shortcomings that others have pointed out is that the current capabilities for sensor reporting don’t handle different formats for the values (PPM vs percentage, for example). And may not handle multi sensors as well as we’d like precisely because ST keeps trying to assume what a sensor will be used for. That shouldn’t matter.
If there’s a third party device that measures CO2 and pollen count and humidity and temperature all in one device, great! It should still fit into a multisensor capabilities.
Think of it this way. ST is like DHL or FedEx. A package delivery service. It may have special rules for transporting different types of packages. “Requires signature.” “Fits in a box.” Etc.
It may even have special rules for transporting certain types of materials, like flammables.
But it is not going to have one rule for transporting red paint and another rule for transporting blue paint and another rule for transporting turpentine.
Messages from sensors will need to be able certain kinds of parameters. And multisensors need a way of handling each individual message. But ST itself shouldn’t need to know the exact content of each message. Just how many parameters and what kinds of values go in each. ST doesn’t need to know the color of the paint.
That’s where a weather report device might be an example of a different kind of message format than, say, a humidity sensor. But it’s just the example. It doesn’t mean ST needs a “tomorrow’s weather forecast” capability. It means there are missing generic parameters. Which might be used for a weather report or a device with a different purpose but a similar message structure.
Now there may be a whole separate group of “capabilities” (.I myself would call them hub services) so that a smartapp can ask the hub for some commonly needed information without having to have a physical device on the network to do it. The kind of stuff Siri or Amazon’s Echo comes with. Weather report, sunset time, day of the week, stock prices, current hub geolocation. I don’t think ST currently has this. But if you’re going to be a cloud service, it’s a nice feature to have. This is stuff that is the same no matter what physical devices you’ve chosen to install. That’s a separate issue.
But for an open system, I would respectfully suggest that ST has no idea what a sensor will be measuring. And shouldn’t care. Red paint, blue paint, turpentine, olive oil. But ST does need to provide a message format that the necessary parameters will fit into.
So definitely use specific device features as examples of message parameters that need ST needs to be able to send through the system, like the example of PPM. But I wouldn’t try to design capabilities based the content of each message.
@JDRoberts, I understand your point. People ask for concrete examples of devices. so that’s why I gave some specific attributes as examples.
All these attributes can be aggregated to a pollutant.
I think that the capability that I suggest here is high level enough: pollutantMeasurement which does not refer to any specific pollutant.
Bye.
Aaron, @JDRoberts et al.,
You make great observations in various posts in this thread.
Capability is a little twisted in the current implementation because of the limitations in the way it must be used in the UI for Device Selection in the SmartApp Preferences “input()” section.
It’s no rush, but I would appreciate feedback on my discussion of this in the following Topic:
1 Like
Personally, I feel that it should be a capability.concentration – which would have a units in ppm. This is very standard for pollution measurements, as well as various other automation-friendly applications (pool chemicals, soil measurements, air quality, etc)
1 Like
(I have ADD, so I certainly wish I had capability.concentration, ha ha ha)…
Anyway…
It is a bit of a chicken - egg scenario, since, in the Guidelines I drafted, I do observe that the “primary” Attribute of a Capability is frequently named the same as the Capability (though the existing Capability definitions are not entirely consistent on this – some of them add the word “status”, “measurement”, “meter”, “sensor” or other suffixes in the Capability and/or Attribute name, others do not…):
“concentration” is a good name for an Attribute that describes pollution or particulate levels, and it is comparable to the case of “Attribute: temperature” in “Capability: Temperature Measurement”.
But the word “concentration” is not as commonly understood as “temperature”, perhaps, and also may be too generalized to define a specific Capability. Or maybe it’s perfect.
NB: Capability != Attribute != Command
But rather: Capability >= ( Attributes + Commands )
Still unresolved: How to decide if a Capability is “optimally granular”.
Being a bit of a hardware hacker, and having interests closely aligned with @yvesracine wanting detectors for specific pollutants, I look at this problem more simply. I have this thing, this sensor, I put voltage in, I get voltage out… my microcontroller that supplies and listens to the signal only cares about that voltage, I can output 0-255, or bananas, it doesn’t matter. I’m with @JDRoberts in the “keep it generic” sentiment. I would envision 2 generic sensor classes, analog and digital. Each one would have a length. It’s typical for something like an arduino or raspi to read an analog line like the ones on a lot of the gas sensors and format is in 0-255 0x00 - 0xFF… Then say I have 5 sensors on the “gadget” that measure all sorts of stuff, I just package all of those bytes up in a string… 00ff00ff00 and voila… Now I don’t really need to differentiate until I’m in the device handler what those different segments are since they’re going to get parsed… so if I could say ok, the first byte is device.analog.type =“co2” and the next is device.analog.type =“H2S”, etc… SmartThings sees that its device.analog and should be smart enough just to divine the rest. keep it all object oriented… class.object.property That way say someone comes out with said device, a handler is written and apps written around it. To me, the scaling shouldn’t matter as you could handle that in the device handler with what amounts to a lookup table or similar then just slap the measurement on there as part of the data… so you get device.analog.UOM (unit of measurement) and just import all the relevant stuff from NIST like PPM and Watt and Degrees, hell maybe even Weber and Tesla, you never know! That way SmartThing just collects the data and publishes it for use by whatever apps are there. Hey this thing says 102 Degrees and 120 PPM CO2, etc… it doesn’t need to be aware of what the stuff means…
Sorry if this is dicombobulated. I’m really wanting to measure for gases that come off the local refineries… It can be real bad in the morning down here by NASA (Houston) and I’d like to know whether or not I should strap on a gasmask before I go outside to bring out my trashcans LOL! And you KNOW the refiners are TOTALLY honest and transparent about the crap they put out in the air…
1 Like
This entire New Capabilities Category is being completely ignored by SmartThings at the moment… Not with any bad intent… They just have higher priorities. But I’m not sure if our suggestions here will ever be given serious consideration. No clue.
Your message makes excellent discussion points. Coming up with the right balance of logic placement in the Device vs. Handler is one great Topic of many.
And if you look up my self-discussion on Capability granularity, it may or may not provide some guidance.
Perhaps SmartThings needs more “generic” Capabilities… But those aren’t any better than ad hoc Attributes and Commands when it comes to helping SmartThings match appropriate agnostic brands of swap-out/swap-in physical Things.
I like the way Microsoft approaches instrumentation with WMI… If you’re not familiar, check it out. There are tons of standard classes but in any class you can put whatever properties you want and the software querying at the time is responsible for figuring out what it wants to do with it. There are a few system properties but they pale in comparison to the software defined ones. There is even a query language similar to SQL, called WQL or WMI Query Language. I write plugins for monitoring software (among other things) at my job that usually utilize PowerShell or Java to accomplish it and WMI is a pleasure to work with (most of the time).