Getting a reliable track of core temperature is quite difficult with externally attached devices. Internal ones, whether anal or oral or infrared via ear, are more reliable.
A wearable, unobtrusive thing that could be worn 24/7 and provide telemetry could be pretty handy… But how to attach the sensor?
…maybe a short-range RFID implant, and something to wear nearby to relay data? This could be potentially also used with other sensors, e.g. CHEMFET sensitive to glucose…
Immerse the subject in a sealed, vacuum-insulated vat of a known quantity of 0°C water. When the system equalizes, stick a thermometer in the water. You should be able to figure what temperature the patient was.
I have not the slightest idea why you would want ‘internet’ involved in a simple home thermometer; but it wouldn’t entirely suprise me if we’ve gotten to the point where building a digital thermometer around a microcontroller with bluetooth low energy is actually slightly cheaper than building one with an LCD to display the output.
I am Very Much Not a fan of the fad for connecting all sorts of things to ‘apps’, each with their own account and data mining and whatnot; but if done tastefully, there is something to be said for the fact that bluetooth is plummeting towards being a near-zero cost addon(vs. a modestly beefy microcontroller, obviously it would cost significantly more to tack it on to a conventional fluid-expansion thermometer design) and it is increasingly likely that your customer owns a much, much, nicer LCD screen than you could ever afford to build into your product. For some applications, the fact that a phone or computer is smart enough for virtually unlimited data logging is also a nice feature.
It’ll be a cold day in hell before I sign into somebody else’s server just to check a thermometer that is within arms length of me; but the fact that BT/BTLE makes adding functions similar to those historically provided by RS-232 console/debug/data logging ports; but cheaper, smaller, and without compromising the case(sometimes just an aesthetic thing; but an important cleaning consideration in this case) isn’t a bad thing at all.
I’d like to be more optimistic about this happening broadly, outside of occasional geek-focused products(like the BT multimeter); but I suspect that we’ll see a lot of pointless app-lockin.
Datalogging and telemetry. “Wake me up if the child’s temperature goes above $LIMIT”. Letting the family doc do the supervision remotely. Kind of like what you would do with remote telemetry with SCADA but with a squishy critter under the sensors instead of a chunk of steel machinery.
I wouldn’t mind seeing some sort of documented protocol(s) to be mandatory. (Anything - as long as there are just a few standards and they aren’t obfuscated. Anything as long as it is verboten to lock out third parties.)
The BT multimeter is a fun thing. More fun, however, would be the same as a generic add-on for serial-port equipped multimeters. Not difficult. The serial-port ones are rare these days, ousted by the USB ones that are more difficult to easily interface with - but all have the USB chipset connected to an optocoupler with a UART going through. Tear out the USB, put in a battery and a BT-serial (or wifi-serial, like ESP8266) chip, and we’re in business. A smarter-than-dumb-converter chip (ESP8266) can even convert the multimeter data (which often are just a binary array with bits that correspond to the segments on the display) to ASCII representation that makes sense. You can even throw in some optocoupler-separated GPIOs, for control of data acquisition automation or for control feedback.
…a sexy thing would be an isolated DC-DC converter that’d feed the multimeter instead of the 9V or 3V battery, so no more dead battery issues…
That’s the freewheeling. If I could get brain into actual gear, if that thing was willing to cooperate and wasn’t Fucking Too Tired All The Time, I’d already have a ESP8266 module cobbled together with a CP2102 USB-serial module and a TP4056 battery charger attached to a TP4000ZC (or DT4000ZC) multimeter, then do it once more, and have two wifi/USB datalogging multimeters with easy USB configuration.
The multimeter has an easy to decode serial protocol described in its chip’s datasheet.
…or even just replace the stock USB-UART converter with a CP2102 module built right into the device’s box. You can reconfigure its USB ID strings and therefore control the appearance of the /dev/serial/by-id/* device names. With the stock chip you not only have to keep the adapter cable from “wandering away”, but also all the chips have the same name and while their /dev/ttyUSBx devices are in their proper numbers, their by-name links are identical and you get just one link - which is annoying when you get more multimeters and want to address them as Multimeter-Red and Multimeter-Yellow in the by-name directory.
I can definitely imagine wanting to pass along data from sensors, this one included, I just don’t trust the probably-not-updated firmware of a severely hardware constrained device to do that itself. Hence being fine with the fact that the falling cost of bluetooth should allow for the reemergence of the features that were relegated exclusively to big clunky professional gear because serial ports are big, require a hole in the case, and demand inconveniently high voltages. I just want the sensor to focus on not screwing that up and leave the business of collecting and forwarding(or not, as one prefers) the data to more capable, more secure, and more frequently updated devices.
If the device tries to handle its own internet, odds are that we’ll be stuck with it phoning back to the vendor’s server even after they’ve shut it down and moved on to version 2. If it sticks to speaking something sensible to whatever bluetooth device it is paired to, you have effectively unlimited options for what you want to handle the data, collect it, reformat it, pass it on to other devices, etc.
As a purely technical achievement, it’s pretty neat that you can get a real computer that speaks IPv6 into just about anything; but barring revolutionary advances in secure, private, automagic, there is still a lot to be said for the conceptual simplicity of a ‘peripheral’(whether hardwired or not), that has a simple, private, link to some more capable device.
If we did have automagic, sure, I’d like my mouse to have an IP address and automatically show up as an IP-HID device on whatever computer I am currently using; but until the myriad questions of how to dynamically assemble networked groups of peripherals for use are resolved, I’d rather keep the peripherals as stupid as possible and let the real computers forward data over the network if desired.
Sometimes the internet link capability is the easiest way to provide this. Many simple sensors run as MQTT data/event sources. That can be implemented in many ways; ESP8266 can connect to a wifi and send data via MQTT itself, or via HTTP requests. That can be done to some server Outside or to a device on a local network (better).
An alternative is a serial line in one of its many flavors (UART, RS232/422, RS485, TCP socket, USB-serial, serial-over-bluetooth…) and a small daemon that converts data to MQTT (or to HTTP requests or any other way to submit data to where they should be).
The latter is easier to secure (except the TCP socket), usually. Less complex. But in the age of $2 wifi chips, and longer range of operation than what the non-wifi approaches typically have, wifi devices are a popular choice.
Good thing I’m not Catholic. I don’t think I could keep myself from snickering whenever someone says “rectory”. Yes, I sometimes have the maturity of a 12 year old.