Closed andycarle closed 2 years ago
Thanks for pulling this all together. I gave it a quick review and it appears to match what we discussed in committee. I will give it a more detailed review soon.
I've taken a look and things look good to me. Thanks for creating the spec text update.
This looks ready to merge.
I took a few notes that don't need to be addressed immediately:
CarbonMonoxideGasSensor
, HydrogenSulfideGasSensor
, etc) is clear, but we tried to avoid that in the 1st edition. Dropping sensor here might be OK or strange (new CarbonMonoxideGas
). What you have may be the best we can do.sensor
as that is clear from the context. That would change sample hydrogenGasSensor.H
to sample hydrogenGas.H
, for example.H
, CO2
, etc) are capitalized. That's inconsistent with the naming guidelines. When I see a capital letter like that, I tend to see "constructor" because the JavaScript convention is so strong. But maybe your use of capital letters is appropriate here to be consistent with standard chemical notation. FWIW – We have a similar issue in MQTT where the quality of service property could reasonably by qos
, QoS
, or qualityOfService
. Maybe the guidelines need to be expanded.
This PR takes the Sensor Class proposals that have been discussed and reviewed at recent TC53 committee meetings and merges them into Section 14 of the main spec text.
I would appreciate a review from everyone on the committee that has an interest in the Sensor Class definitions. In particular, the names that I've chosen for various pieces (the Sensor Classes,
sample
object property names, etc.) all could use some final consideration. Units chosen for sensors are also up very much up for debate until this is finalized.Tagging a few people that I know may be interested: @rwaldron @dtex @jsiegelmsu @phoddie