9

I have a project to automate things in a house. I am a developer but a beginner in electronics and IoT.

What should I use to communicate wirelessly? Wi-Fi, Bluetooth... Where should I look?

I need a cheap, low consumption and tiny solution, for example making extra wireless light interruptor, or, try to do things like local-triangularization with a integrated circuit armlet of my house-mates (there are no prisoners! The house is big and it is for having a "torch-mode"—the lights follow you, for energy savings)

We also grow food (mushrooms), so optimization can be made on cultures in the future. I also want to open/close some doors.

It must be modular so an API at the end can be cool.

Is a Bluetooth-integrated circuit on IoT centralized by Raspberry Pi (server) and controllable by Wi-Fi (or directly through Bluetooth) a good thing to look at? What am I missing?

Improve this question
8
  • 3
    Definitely not wifi due to the power concern, possible bluetooth low energy though as there are number design defects in the spec particularly with respect to sharing, possibly some custom scheme between 2.4 GHz radio/MCU chips designed to more precisely fit your needs instead. Using BTLE literally mostly makes sense if you need to communicate with existing devices that have that, especially phones.
    – Chris Stratton
    Commented Mar 19, 2017 at 3:00
  • 1
    For communicating with phones what if i don't do it directly but handle the data of the custom scheme on a Raspberry PI by exemple and run my server with a web service for the phone/apps ? Do you have any good source to learn for the custom scheme etc ?
    – Morpheus
    Commented Mar 19, 2017 at 3:07
  • 1
    Then you can implement something custom on both ends. Just keep in mind that pi's are fragile due to reliance on an SD card that doesn't like ill-timed power loss.
    – Chris Stratton
    Commented Mar 19, 2017 at 3:08
  • 2
    Not sure where you got the idea that 2.4 GHz is expensive, as that is mistaken. Transceivers are as little as a dollar, in single quantity. However, 25m may be less than reliable for a lot of non-license mechanisms, at least if there are walls or other noise sources. Something like LoRa is designed to go (much) longer distances with low power, but there are much lower limits on the rate and overall amount of data you can put through it.
    – Chris Stratton
    Commented Mar 19, 2017 at 19:50
  • 2
    I'm not sure there is anything off the shelf, but the idea of BT-LE backed up by wifi connected nodes to get the range sounds sensible.
    – Sean Houlihane
    Commented Mar 19, 2017 at 20:44

4 Answers 4

Reset to default
8

Here you have a nice list of 11 IoT protocols you need to know about.

Here is a summary in case the link someday breaks

Bluetooth Standard: Bluetooth 4.2 core specification Frequency: 2.4GHz (ISM) Range: 50-150m (Smart/BLE) Data Rates: 1Mbps (Smart/BLE)

Zigbee Standard: ZigBee 3.0 based on IEEE802.15.4 Frequency: 2.4GHz Range: 10-100m Data Rates: 250kbps

Z-Wave Standard: Z-Wave Alliance ZAD12837 / ITU-T G.9959 Frequency: 900MHz (ISM) Range: 30m Data Rates: 9.6/40/100kbit/s

6LowPAN Standard: RFC6282 Frequency: (adapted and used over a variety of other networking media including Bluetooth Smart (2.4GHz) or ZigBee or low-power RF (sub-1GHz) Range: N/A Data Rates: N/A

Thread Standard: Thread, based on IEEE802.15.4 and 6LowPAN Frequency: 2.4GHz (ISM) Range: N/A Data Rates: N/A

WiFi Standard: Based on 802.11n (most common usage in homes today) Frequencies: 2.4GHz and 5GHz bands Range: Approximately 50m Data Rates: 600 Mbps maximum, but 150-200Mbps is more typical, depending on channel frequency used and number of antennas (latest 802.11-ac standard should offer 500Mbps to 1Gbps)

Cellular Standard: GSM/GPRS/EDGE (2G), UMTS/HSPA (3G), LTE (4G) Frequencies: 900/1800/1900/2100MHz Range: 35km max for GSM; 200km max for HSPA Data Rates (typical download): 35-170kps (GPRS), 120-384kbps (EDGE), 384Kbps-2Mbps (UMTS), 600kbps-10Mbps (HSPA), 3-10Mbps (LTE)

NFC Standard: ISO/IEC 18000-3 Frequency: 13.56MHz (ISM) Range: 10cm Data Rates: 100–420kbps

Sigfox Standard: Sigfox Frequency: 900MHz Range: 30-50km (rural environments), 3-10km (urban environments) Data Rates: 10-1000bps

Neul Standard: Neul Frequency: 900MHz (ISM), 458MHz (UK), 470-790MHz (White Space) Range: 10km Data Rates: Few bps up to 100kbps

LoRaWAN Standard: LoRaWAN Frequency: Various Range: 2-5km (urban environment), 15km (suburban environment) Data Rates: 0.3-50 kbps.

Just consider that:

  1. The longer the distance you want to cover with the signal the more power consumption you need.

  2. The higher the data rate you require, the higher the frequency thus more power consumption.

So I suggest to go for a low frequency protocol; ZigBee works quite well, consumes very low and it is quite popular. The only drawback is that Raspberry Pi does not include a ZigBee transmitter, you may require an extra adfruit.

Improve this answer
1
  • This is a good list, would be nice to keep this going updated. A few things I would add; Bluetooth 5 (data rate and range changes) and mesh capabilities, LoRa could go up to 300 kbps (those are the modules I have seen, but I think there are some that could go even more).
    – dicobraz
    Commented Dec 7, 2017 at 16:30
6

Referring to the list of protocols provided in Snake's answer, it seems you need a protocol with a range of 20-100m, good low-power performance (ideally passive, but I don't know of any solution), and not really much bandwidth for the carried part. In addition, you need some static nodes which can be less constrained from a power perspective.

BT-LE is the most widely adopted protocol. Unfortunately, I don't think you can re-use a cell phone in the same way as you'd use a node (unless you rely on purely passive interactions with the protocol). However, SoCs which provide this protocol, plus sufficient peripherals to enable a fitness tracker or headphones are common (and improving in spec).

If you look at the most recent SoCs with a 2.4 GHz radio, you'll find they often support more than just Bluetooth (you just configure the right software stack), so its worth investigating if you can get better results with a different protocol (but then you have the penalty of needing to add another radio to your static nodes). Your use case seems to rely on having reliable signal strength indication (assuming time-of flight precision is not necessary).

One of the most important tasks at this stage in the design is to work out a power budget and charging profile for the portable device. This will have an impact on sleep profiles and transmission frequencies. You probably want to use an accelerometer to adapt the transmission rate (since the radio will probably take more energy to transmit than just polling to check for motion).

Improve this answer
4

One protocol not listed in Snake's answer are the radio modules for 433MHz/868MHz/915MHz, one of which will cover the hobby/research band in your country, and can be used to create low power nodes. RFM69 and NRF24L01+.

https://www.mysensors.org/ have put these into a network setup with protocol and gateways, all open source, that speak to a range of existing controllers and offer lots of opportunity for development at both sensor/node and controller ends.

Improve this answer
2

I would look at some of Nordic SoC's solutions that have integrated protocols. Its a good way to have a chip that would allow you to test different scenarios, Nordic has SoC's with most of the common protocols (Bluetooth, WiFi, IEEE, ANT etc.) in one chipset.

I would start with Bluetooth, its the simplest, most versatile IMHO solution. Though I am not sure about local-triangulation, seems like an overkill for your requirements, maybe look into Bluetooth beacons.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.