Support new outdoor probes from Wireless Sensor Tags

[hlapp]

Wireless Sensor Tags recently released new dedicated outdoor probes. Essentially, these are 3 models, with related but not identical features.

With respect to our data model and API, they don't fit right into the current assumptions for a number of reasons, and as a result pose some questions for how best to implement support for them.

1. They appear to use tagType == 42, which has until now been used for the current sensor.
2. They each have in essence a temperature sensor, so in principle tag.hasTenpSensor() should return true, and tag.tempSensor should return the sensor object. However, the actual picture is more complicated:
   1. The only temperature sensor of the "Basic" model is a removable external DS18B20 probe. Apparently, it does not require a separate "activation" step once connected. Hence, at a given time there may or may not be a physical temperature probe. What should the API do if no probe is connected?
   2. The "Thermocouple" model allows connecting either a DS18B20 or a k-type Thermocouple probe, and after connecting and disconnecting a DS18B20 probe it needs to be activated and deactivated, respectively. In addition, the model has an internal temperature sensor, for which the temperature value is read from a different property (cap, otherwise used for capacitive resistance-based sensing of moisture or humidity) than that of the DS18B20 and the thermocouple probes (which use temperature). This means there is always a temperature reading from an active sensor. Should the internal temperature sensor be available from the API as an additional sensor object? How should (or shouldn't) the value of tag.tempSensor depend on whether an external probe is connected or not?
   3. The "GE Protimeter" model allows connecting an external DS18B20 probe, and has an additional internal temperature sensor. (It does not support connecting a Thermocouple probe.) Furthermore, it accepts an external BLD5079 or BLD5060 protimeter probe, in essence a humidity sensor. Questions for API behavior are the same as for the "Thermocouple" model.
3. All external as well as (for "Thermocouple" and "GE Protimeter" models) internal temperature sensors are high-precision (albeit not 13bit, but substantially higher than the 8bit resolution of the original WST tag model), but only the "GE Protimeter" model has a humidity sensor.

Considerations for implementation:

• Issue 1 has been addressed by simply removing all support for the current sensor (Removes support for the current sensor #43), leaving tagType == 42 uncontested for the new outdoor probes.
• For the issue of handling external probes that can be connected or disconnected, two options seem available. One is to treat a disconnected probe as an absent sensor, and the other is to treat a probe's connection status as a property of the sensor.
  • Treat as absent sensor, i.e. tag.tempSensor === undefined: This would correspond most closely with the physical scenario (the probe is simply not there. However, this means that tag.hasTempSensor() would give different answers over the lifetime of the tag object depending on when a probe gets connected or disconnected, which in turn runs counter to the notion currently followed by the API that sensors are capabilities of the tag (hence, tag.sensorCapabilities()).
  • Treat as sensor property, for example, sensor.probeDisconnected === {true | false | undefined }: This turns an absent sensor into one that's present, with an attribute saying it's actually not, and major consequences if the attribute is ignored (for example, sensor.reading returning undefined, or worse yet, a bogus value (such as 0 for temperature). On the other hand, it keeps the overall notion that sensors are capabilities a tag comes with, and those capabilities don't change from one moment to another. Which allows for an API that's much more straightforward to program, and even for the outdoor tags it isn't that their sensor capabilities change, just the connectedness of a particular sensor might change on occasion (and in reality probably not very often).
  • The same considerations should apply to handling the humidity sensor that can be connected to the "GE Protimeter" model.
• It doesn't seem justified to treat a k-type Thermocouple and a DS18B20 probe as different types of sensors. In practice, they are temperature sensors for all intents and purposes, and hence should be returned by tag.tempSensor. There might be a sensor.probeType property that allows distinguishing between them for those that need it.
• Given that the primary purpose of these outdoor probes is to connect external probes, the internal temperature sensor (for the "Thermocouple" and "GE Protimeter" models) should I think not stand in for the external temperature sensor depending on whether the external probe is connected. Instead, they should be an additional type of sensor, even if the physical property being measured by them (temperature) is the same. Or more precisely, although they both measure temperature, they measure them in different environments (the external environment to which the probe is exposed versus the internal environment of a certified water and dust-proof enclosure). So, maybe tag.internaltempSensor and tag.hasInternalTempSensor(), or some such.
  • Note, however, that if one defines the most intuitive use-case for these probes as connecting one external probe, this might result in different expectations for the most intuitive default behavior. I.e., arguably the "Thermocouple" model's primary use-case is to connect an external temperature probe, whereas that of the "GE Protimeter" is to connect a humidity (or moisture) probe. Hence, one might expect the temperature for the latter by default in tag.tempSensor.

See #36 for the initial trouble report as context.

[hlapp]

Leaving this open until more thorough testing completed once Outdoor tags are delivered and connected.