Sending sensor's binary signal to the cloud through a wireless settings

Question

I’m relatively new to iot and I'm looking for ways to send a binary signal from a tiny sensor (size of a coin) to the cloud through a wireless setting. 

Basically, sensors would emit a simple binary signal (0 or 1) at regular interval (say once a day, or once a week). Once the sensor goes from 0 to 1 it stays in that position forever. (I'm just looking for the activation and the date of when it happens). Additionally, each of these sensors would be identifies with a unique ID. 

so the data gather through the sensors would look like this =>

DATE | SENSOR_ID | STATUS (0/1)

Environment: Sensors are meant to be positioned within a household environment, presumably with a close access to internet, WifI, wireless connections, bluetooth, etc… 

Battery: I think the battery is not so much of an issue because of the limited amount of data to be sent by the sensor (just a binary 0/1) and the low frequency (once a day).  Besides, sensors have an average life span of only 2/3 months. (no recharge needed)

Connection settings: Ideally, I'd like to have a very limited manual setup for the connection to be required (none if possible).

Questions: What processes or existing protocols could be used to receive the signal from these sensor and upload it to the cloud ? What type of signal would work best in that scenario ? (radio / wifi / bluetooth or any other format) ?

Thank you very much for your help

Answer 1

If you want to get data to "the cloud" (a server somewhere on the Internet) wirelessly, you have at least the following options:

• Device has a cellular modem built-in. Will require the modem, a subscription to a carrier, data charges, and coverage. Depending on the modem you may need a physical SIM in each device or you could use an eSIM. Nowadays one would probably use the "IoT" cellular technologies such as LTE-M (aka Cat-M1 or more recently CAT-M2) or NB-IoT. You can provision the devices with the SIM before shipping them out, provided you get the subscription from a carrier (or more often an MVNO) that will give you coverage wherever you need (many IoT-oriented operators will have global coverage through roaming agreements). Not really sure you could get down to "the size of a coin", though.

• Device has LoRaWAN capabilities. Will require the LoRa modem, coverage from a LoRaWAN network, possibly a subscription with such a network. The issue here is mostly coverage which is quite variable, some areas have extensive coverage, including from free networks like TTN, some have very little coverage. Also I don't think roaming is quite there yet. You could also deploy your own gateways. Again, not quite sure you could get down to "the size of a coin", though possibly not very far.

• I won't mention SigFox. Being tied to a single network is risky (as they aptly demonstrated through their bankruptcy proceedings).

• Device uses WiFi. The problem here is provisioning: you need to connect to a WiFi network, which means selecting the network, having the required identifiers, etc. Also WiFi is relatively power hungry. You could overcome the provisioning by using BLE with an app on a mobile phone to perform this task (this is what many IoT WiFi devices do).

• Device uses BLE (Bluetooth Low Energy). You will need "something" to receive whatever your device sends and forward it to the cloud. This could be an app on a phone (but this would most likely require the app to be opened regularly to query the device to see if it has something to say), or some custom gateway. I don't think there's any standard stuff that would do that for you (at least not something as ubiquitous as WiFi).

• Device uses Zigbee. Requires a Zigbee network, and some way to make sure the information is sent back "to the cloud". Clearly not as ubiquitous as WiFi, and some Zigbee networks are quite restricted (e.g. Hue will accept nearly any Zigbee bulb, but only a very limited set of other Zigbee devices), and access to the data may be complex.

• Device uses Matter. Barely launched, but Apple is making a big push on that, and many others will probably follow, so while now you can't count on it, in a few years it will probably be a good option.

• There may be something to do with Apple's "Find My" network (where you could rely on the billions of Apple devices out there to relay the information), but I have no idea if you could send an actual signal other than just the presence of the device, or how difficult it may be to plug into that ecosystem.

There are quite a few possible trade-offs.

• Cellular is probably the easiest if you need to have devices that are pre-provisioned (i.e. end user has nothing to do).
• Otherwise I would probably go for BLE + mobile phone app for the setup phase, then WiFi for the regular data.

One thing to note, though: while BLE for instance requires very little power, others such as WiFi or cellular are more power hungry, and even though your device intends to be active only for a short period of time with lots of sleep in between (so the average current or total energy needed is quite low), it requires a current source which can deliver relatively higher peak current (50-100 mA, sometimes more), which not all coin cells may be able to do. Check the specs of the battery, or maybe add a supercap to provide that peak current when needed. But that quickly makes your device larger. See https://electronics.stackexchange.com/questions/601865/voltage-regulator-for-esp32-running-from-coin-cells for a related discussion for an ESP32 (not even using WiFi).

I believe the only way to have a vaguely coin-sized device (like Apple's AirTag) at this time is to use BLE only, but you'll be faced with the issues mentioned above regarding communication back to your server.

For reference, a few devices which use BLE only and are coin cell powered: Espruino’s puck.js and Ruuvi’s Ruuvitags.

Answer 2

Thank you very much @jcaron for your comprehensive post. This has been a tremendous help. I have spent some time looking at the different options you mentioned and made some additional research online here and there.

Given my specific use case it turns out that cellular / gsm module is the way to go. I am looking at some off the shelf components for binary sensors (kind of a circuit breaker system with on/off position) , a microcontroller (esp32), a gsm module such as SIM800L and a battery of 100Ma. I believe the whole thing shouldn’ t be that large and also pretty cheap. (about 10 EUR without the sim card)

My geographical target is worldwide and as you rightly pointed out I could use an MVNO to facilitate connectivity across multiple countries. Also, I believe this solution could scale well to thousands or even hundred thousand of such sensors positioned at various locations. Cellular 2g/3g cover the vast majority of the world.

Here is the weak points of this solution, and possible remediations I came up with:

Battery : For the battery part, I actually realised from my initial post that I don’t need the device to send data at regular frequencies (say daily). Instead, because it is a binary signal, I will only look at the activation (sensor being triggered). So the system will effectively be in sleep mode until the sensor gets triggered. Then, one and only one signal will be sent to the server and the device could be discarded (because the activation happened and I won’t need any more data from the system). So this, I think, effectively reduces the battery constraint a lot, and also reduces the required size.

Size : I was referring to the size of a coin but you can imagine multiple coin stacks on top of each other (pretty much like a cylinder). Cylinder shape is not really feasible using off the shelf components but if it is small enough I’m happy with it for the time being.

Connectivity: Again, as you rightly said it appears that cellular is the only way to avoid end-user logging in or to do any actions. Process has to be seemingless to the end-user and I think gsm is the only option here.

I’d be really interested to have your feedback on the configuration I highlighted above. Do you think it is appropriate for my use case ? Are there any other constraints I should be looking at ? Thank you very much again :)