Originally published at: https://tidbits.com/2018/07/25/wireless-sensor-tags-protect-against-freezer-failure/
If you’ve ever worried about losing food due to a freezer breaking or a refrigerator door being left open, the Wireless Sensor Tags system could save your bacon by monitoring temperatures and reporting significant changes on your iPhone. Other available features include motion detection, moisture monitoring, light sensing, and even locating lost items.
We have a large freezer, and its door has been left open more than once. This would be a good solution. Did you look at any competitors?
This could be what I’ve been looking for.
Quick question to which I could not find an answer on their web site: are the data downloadable? I’d like to be able to track temperature etc. and place the data in a spreadsheet for further analysis.
At the time, I didn’t find any competitors. A search now reveals
Which looks awfully similar. There are more dedicated devices for this task, but they tend to be aimed at commercial installations.
I’m not sure exactly how to accomplish this, but their site says: “You can also download the entire captured raw data as one CSV file for custom processing.”
Thanks! I missed this.
Battery life is advertised at 1 year, although I think I’ve gotten more like 9 months.
I would expect the battery for a device inside a fridge or freezer to not last as long because of the cold. As long as the low battery warning works, it shouldn’t be a problem. And kudos to them for using user-replaceable, common batteries instead of something proprietary and/or in a sealed case.
A sensor for a sump pump may be the most valuable, least sexy smart home product.
For people who are interested in this more for curiosity than to avoid a significant financial loss, I’m sure there are many DIY examples online that combine a sensor, a small microcontroller, wireless communication (WiFi, Bluetooth, or something designed for this use-case like ZigBee), and a battery.
Hi Adam
I was excited about this right up until the point you showed having to have an incoming TCP port 6667 mapped on your router. Is this really needed? I read the support FAQs you linked to and none of the articles mentioned having to do this (two said you need outgoing TCP 6667).
From a security perspective I would be very wary of having a <$50 device accepting incoming TCP connections from the Internet - this would allow any security vulnerability to be remotely exploited.
—Jonathan
Anything is possible these days with regard to IoT devices, but if you want it to be controllable or able to alert you from the Internet, then it must be able to do so through an open port. Although http port 80 is probably the most common, using a different port doesn’t really make you more or less vulnerable to attack. You have to either trust that the device isn’t doing anything malicious out of the box or not. The rest is mostly up to you to make sure any password required to make changes to the device is strong and changed from default.
Err - I think you misunderstand. The issue is having an open INCOMMING port to the device. Almost all IOT devices work by connecting OUT and thus are protected by the inherent security of your border NAT router. It is very unusual and much less secure to have an open incomming port exposed to the Internet.
According to Trend Mirco’s Network Scanner https://itunes.apple.com/us/app/network-scanner-wifi-security/id1103147103?mt=12 three of my IoT devices have open incoming ports. Two are port 80 and the Smart TV is 3000.
-Al-
That’s incomming to the device from the LAN - I’m talking about Incomming from the public Internet which would require port-forwarding (if you are using a NAT router).
Hmm, I hadn’t thought about it just being outgoing, since all the port mapping I’ve done in the past has been both incoming and outgoing. AirPort Utility won’t let me click the Save button in that dialog unless both the Public TCP Ports and Private TCP Ports fields are filled out. Is there any way to configure just outgoing in AirPort Utility?
Isn’t default that routers always allow outgoing unless specifically blocked? I thought port forwarding on AirPorts was essentially to open up for incoming traffic. I never opened 80, but my all my devices’ browsers can always reach arbitrary websites.
I can’t remember the details now, since I set this up so long ago, but the port mapping was necessary to make it work. In this case, I don’t think there’s a huge security risk, since the port is only opened to that particular IP, and that device doesn’t have many (any?) other capabilities on the network, apart from hearing from its sensors.
Some routers will let you specify which local IP address traffic from any given incoming port is directed to, so although the port is open, incoming traffic on that port would only go to the tag manager.
I believe that is referred to as a DMZ.
I suppose the specific worry is not that the device itself can do much, but that it can by design access any other clients that are on the LAN since they’re on the same subnet with no firewall in between. Your LAN clients are normally protected from the WAN through the firewall on your AirPort. But if you open up an external port to your device for incoming traffic that means there is now a possibility for an arbitrary WAN machine (the bad guy) to connect to any of your LAN clients through that one open port if that intruder can hack your device. Since IoT devices are usually cheap closed-source hardware it’s difficult to convince yourself that the level of risk you’re exposing yourself to is acceptable.
@Simon has explained the issue clearly.
Port forwarding is when you allow an incoming TCP connection to be initiated from the public Internet to a LAN side device. Almost all NAT firewalls/ routers allow outbound connections - so you don’t do outbound port forwarding. If the sensor hub is not security hardened then an attacker could quite easily exploit a flaw and connect to anything else on the LAN (NAS, Mac etc…).
You should only every have “raw” incoming traffic opened up to devices that are built with good security and receive regular security updates (say a Synology NAS).
My original point was that according to the documentation “inbound” traffic is not required so it should be possible to remove the port forwarding and it still work. If you think about it - the hub just needs to connect out to upload the data, there is no requirement for the cloud service to initiate a connection “in”.
If anyone is interested in seeing what ports they have open to the internet you can run this test:
https://www.grc.com/x/ne.dll?bh0bkyd2
The scan is done from the GRC server on the Internet so tests what your router has open on the WAN side (i.e. it does not test from the LAN side.
That gives an invalid link for me. A better one is: GRC | ShieldsUP! — Internet Vulnerability Profiling
For what it’s worth, the Shield’s Up test showed port 6667 on my system as “stealth” and not “open” or “closed,” which Gibson claims is the best. In tests of common ports, a few others show up as stealth and most are closed.
I’ll have to see if I can remove that port mapping and continue to have the Wireless Sensor Tags keep working…
And the answer is: yes and no. When I eliminated the port mapping, I lost access to the system via the Web client at https://my.wirelesstag.net/eth/. Not surprising, of course, since it would need to communicate in to the Ethernet Tag Manager, and would thus need port 6667 open.
However, I pulled a tag out of the fridge, warmed it up in my hand for a few seconds, and then forced it to update via the WirelessTag app. It promptly told me that that the tag was too warm. This also makes sense, since the tag is communicating to the Ethernet Tag Manager, which is then pushing the information out to the Internet and back to the app.
So if I had to say right now, without more involved testing, I’d say that the port mapping may be one of those things you need to do right off to get things set up, but once things are set up and working, if you don’t need the Web client, you should be able remove the port mapping entirely.
If I notice any problems going forward, I’ll report back.