RPI <> i2c and SPI devices, spread around a house. How best to extend range?

[cdev]

I'm working on coordinating weather/ventilation control which I would like to inform with lots of sensor data and in the future add HVAC and maybe even skylights (which currently are unmotorized, so will need to add motors)  To do this I need to bring in data from around the house. Wifi would work for that, and be more resistant to damage from lightning, etc. I want to use ESP8266 because it looks like I can use them instead of an i2C extender. I may eventually have a lot of sensors hooked up. temperature, humidity, air pressure, and some means of sensing rain and approximate sky cover. (I may try to see if I can set up a misting system for cooling the roof)

Does this sound like a good plan? My home is really tiny, only around 1500 square feet. ESP8266 should be able to make it through standard wood/wallboard walls, right?

Does anybody know of any similar projects I can learn from? RPI as the hub and a lot of sensors - not that far away but maybe wirelessly connected.

[WastelandTek]

My buddy is working on a homebrew mocap suit with a bunch of accelerometers over i2c.  I know he was struggling a bit with range and his i2c multiplexer a few days ago.  I'll check in and see if he has a link to any sort of build log up.

[jbb]

Radio based systems are popular for this sort of thing.

WiFi (EPS8266) may not be the best choice for it, for two reasons:

• Your WiFi / internet router may not be able to handle a large number of connected devices. Some of the lower-quality ones get unhappy and unreliable.
• WiFi is quite power-hungry which would mean larger batteries for wireless sensors.

A lot of similar schemes such as proprietary 915MHz links for reduced power.

If you decide to try wired:

• I wouldn't recommend extending I2C outside whatever box you're putting the controller in.  I2C isn't meant to leave a circuit board, because it's very susceptible to noise.
• I would be nervous about extending SPI for similar reasons.  It would likely be more stable than I2C, but SPI doesn't have any error checking built in (because it assumes you've mounted everything on a reasonable circuit board) so things could go horribly wrong in the field ('oh look, the temperature is 79 deg C, open the skylights! When it's actually 15 deg C + 64b deg C error from one flipped bit.)
• I would thoroughly recommend RS485 serial because it only needs 3 wires (A, B, ground.  Ground is not optional), can go for hundreds of m, and is generally tough enough to give ling service in industrial sites. Adding a CRC in software provides very reliable data links.  You will however need a small micro controller at each measurement node.
• CAN could also be a good option (does CRC and transmission retires for you), but may not be able to support the wire length you need.

[rstofer]

If you want to use wire, you can extend the I2C bus for a very long way - like a mile or so (IIRC):

http://www.ti.com/lit/ds/symlink/p82b715.pdf

If I were doing distributed sensors, I would probably opt for RS485 and place a small uC at each node along with a level translation device.

There are some interesting bus protocols that allow for multi-master and so on.

http://www.bdmicro.com/code/robin/

[Delta]

RS485 serial because it only needs 3 wires (A, B, ground.  Ground is not optional)

RS-485 is fully differential, it is not ground referenced.  A ground connection is only needed if you are expecting ludicrous common mode voltage differences between nodes, and then you'll have to deal with circulating currents on the ground loop you've just created.

[C]

There is a lot of info on YouTube for ESP8266 and ESP32
search for MQTT

Keep in mind that CAN is built for events with priority.
Think ESP32 can do CAN
No reason you could not have many smaller networks also, much easer to find problems.
 
An RJ31x can be nice

[cdev]

My main concerns are RFI, ESD and lightning. My sensors will likely mostly be powered by AC power (cell phone chargers) with one fallback on a battery..  One I figure out the best senor locations a bus extender would make the most sense if its robust.

[C]

There are ESP's with battery connections.

You could have a separate wireless network with no INTERNET router needed.
ESP's can do access point and be a wireless router.

If you use wires, give it a lot of thought on how you run the wires.
RS485 does not like taps off main cable, It wants a daisy chain.
You can get around this by having each tap be out and back.
The RJ31x with it's shorting bars makes this easy to do.


 

[cdev]

C, thinking about it, because of cost and flexibility, wifi - a dedicated wifi channel - not connected to internet, might make the most sense.


The information which is going to be moving through this network is just short ASCII strings representing things like temperature, humidity, barometric pressure, and whether its sunny or cloudy/raining...  Very low bandwidth.

So one ESP running in AP mode talking to nodes would work fine and would offer much more immunity to lighting .

I'm actually very concerned about lightning because lightning hits around here a fair amount.

Once in a while we get really brutal storms. In the past Ive lost two trees to lightning strikes.

[C]

I was thinking battery as backup power. I would not expect long runtime with ESP
There is a board with socket for 18650 battery and I think all needed circuits to charge and protect battery. Some others also.

Think the latest for ESP is over the air programming.
Configure by connecting to it when it is acting as an access point.
It can connect to a second network and still be an access point and route data between them. WIFI with no internet is better security. You computer can still connect when needed.

If I am not missing something, all the ESP's could connect to one ESP acting access point. MQTT & RPI will show some programs for RPI and automation.

Before you pick the ESP8266, take a good look at ESP32. newer and more IO with dual CPU.
If you look at MQTT videos with ESP you might find all software you need..

You might think ahead to what else it could do that you might like in future and allow for this addition.

[cjs]

So I notice you guys haven't really discussed authentication on these wireless networks. Are you just working on the assumption that a password-protected WiFi network is secure enough and any device that can get on it should be fully trusted to manipulate anything else on the network?

As someone whose day job is running IT systems, the IoT world to me, at first glance, looks shockingly naive about security. But maybe I'm missing something here.

[cdev]

I agree with you. I think many of the IOT devices wifi is just leveraging the cheapness of wifi chips, and that wifi doesn't even have to be connected to the Internet in any way.

[cjs]

IOT wifi doesnt have to be connected to the Internet or networked computers at all....

True. However, it is also true that attackers need not directly use the Internet to access WiFi networks. (They may or may not use it indirectly as part of an attack on a "non-Internet-connected" network.)

If I use wifi, it gives me a chance to re-use an old obsolete AP I have that had truly awesome range but only supports 802.11b (too-weak encryption)

See, that's the kind of thing that excites me as an attack opportunity when I put on my black hat.

802.11b is great because it's trivial for me to get the password "protecting" that network by simply listening for a few minutes (or hours, tops) to the packets it's broadcasting to everyone around it. Longer range is great because it makes it easier to place or find a device within range of the network that I can use for my attack.

With a cheap, home-made antenna I can probably connect directly to this network from several hundred meters away. But I wouldn't start there; my first thought would be to take over someone else's WiFi device (such as a vulnerable home router in the area) and then stage the attack from there. I can do that from the other side of the planet.

It's reasonable, however, to assume that I'm not targeting you directly. I'd "0wn" various routers in your area merely becuase my automated system scans the Internet and collects them to be used for various purposes, and I'd have access to your WiFi network because my automated software would automatically crack all easy-to-crack WiFi networks in the area of my devices again because it's easy to do, they could be handy for further attacks, and who knows what fun stuff I might find. You'd just be one of many caught in the automated sweep.

I've been thinking about this on and off over the past few months and one of the main problems in securing small devices along the lines of an ATMega is that they simply don't have the computing power to do enough crypto even for something more minimal than TLS. My current thought is that perhaps Bluetooth is the solution here: if set up properly (i.e., proper PIN confirmation for pairing on both sides) it's pretty secure as far as I know, it's low-power, and the modules are cheap and easy to add to devices with a small microcontroller. I'm not sure about the implications of this on the design of the overall system, though, especially when it involves devices that can be tens of meters apart with walls and the like between them.

(Sorry if I'm hijacking this thread; I'm happy to continue elsewhere if someone wants to point me to a new or existing discussion where it would be better for me to be posting this sort of thing.)

[3db]

This guy  http://jeelabs.org/ has done a lot of work on sensors monitoring etc.
He sells stuff but I think it's open source/hardware too.
There lots of information on his site about his projects.

Peter Oakes who is a member here has done some stuff on his  Youtube channel using  NodeRed/MQTT  on a PI
His  friend ( Peter Scargill I think) has also done some good work.
Hope this is of use.

3DB

[cdev]

<just havin fun>
(high pitched squeaky voice)
What would you DO, tell my system its colder or hotter than it really is?
</fun>

I see what you're getting at, basically, the performance hit or meaningful crypto is standing in the way of properly securing the devices.

certain kinds of data is so trivial and unimportant that it sort of begs some very low tech means of communicating. There is absolutely no need to use wifi to connect two devices just maybe ten or twenty meters away at the most. Bluetooth maybe makes a bit more sense. Wired probably makes the most sense once I figure out the permanent locations of the sensors.

I have to look into the cost of RS-485 hardware.

Ive gotten conflicting info on whether i2c would work. Probably best to err on the safe side and long term, RS-485 seems like the most expandable, standardized way to send information like that. (eventually also HVAC commands probably, if I can figure out a good way to make my registers adjustable.)

[cjs]

<just havin fun>
(high pitched squeaky voice)
What would you DO, tell my system its colder or hotter than it really is?
</fun>

Sure. Maybe open your windows during a storm, or run both your furnace and aircon full blast while you're away on holiday, costing you hundreds of dollars.

certain kinds of data is so trivial and unimportant that it sort of begs some very low tech means of communicating. There is absolutely no need to use wifi to connect two devices just maybe ten or twenty meters away at the most. Bluetooth maybe makes a bit more sense. Wired probably makes the most sense once I figure out the permanent locations of the sensors.

There problem is, doing a proper analysis of what really is "trivial and unimportant" is difficult and requires a security expert. And if you're going to hire one, it's generally going to be a lot cheaper to have him show you how to use some standard reasonably good security than to have him do the analysis that shows you really are able to use less security. And even if he does the complex analysis, he'll tell you you should go with the solution based on a simpler analysis anyway, because not only will it be more reliable at the start, but things change, usually without people considering all the security implications of the change.

In the course of my career, people saying "Oh, well I don't really think I need to use standard, relatively easy security measures on this because..." has always been a fruitful source of attack vectors for hackers.

I have to look into the cost of RS-485 hardware.

Pretty darn cheap! The last set I ordered was just over a US dollar for a pair of transceivers. (These don't support listening as you transmit, though, so you can't easily do collision detetion.) Given the low data rates you need I think a microcontroller even significantly less powerful than a typical ATMega could bit-bang the communications. This also gives you some further easy options for routing power to the devices, I would guess, such as using cable with a couple of extra conductors to run power along with the communications.

[/quote]Ive gotten conflicting info on whether i2c would work. Probably best to err on the safe side and long term, RS-485 seems like the most expandable, standardized way to send information like that.
[/quote]

RS-485 uses differential signalling so it's going to be way, way better and more reliable for your purposes than I2C.

[Kjelt]

RS485 transceivers can be gotten pretty cheap however the better transceivers that have ESD protection and other safety precautions will cost about $2-3 a piece.
The 3v3 ic's are more expensive than the 5V ic's.
That said, for outdoor systems and your multiple statements about lightning, I would suggest if you are going to use RS485 to fully isolate those outdoor systems from the indoor systems, look into RS485 isolators there are optical and transducer versions like the ADUM series from AD. Expensive though.

[CJay]

Others have already answered with solutions that will work and if you can run cables then I would but it does make it a bit more difficult to relocate or add to the 'network'.

I would just throw one more option into the mix as well, Raspberry Pi Zero W, not quite as cheap as ESP8266 and a bit more power hungry but it's quite a bit more powerful and means you only need to code for one platform, plus, as with ESP8266, you can configure them as an AP using the built in WiFi.

[capt bullshot]

I'm running a similar system at my home:
http://wunderkis.de/datenkrake/index.html

It's made of all kind of stuff that I could get my hands on, but it's core communication means is CAN, RS485 and Ethernet. Most of the sensor / actor network is done with STM32Fxxx controllers with CAN bus.  I've made my own simple and stupid protocol for CAN communications, as a library that gets configured by some headers and is linked into each node that I build on the basis of STM32Fxxx controllers. The sensor nodes make use of all kinds of devices using I2C, SPI, plain analog (like a RTD), but these are local to the node. All the longer range is done via CAN.

I do avoid wireless communication, since it's unreliable and very short range (see the TI sensor tags) or opens up a lot of security and authentification issues (WLAN)

[Kjelt]

I do avoid wireless communication, since it's unreliable

I agree the ether is becoming "full" and on tradeshows it can be noticed that some demo's that depende on Wifi or other 2,4GHz based wireless protocols just do not work because there are too many transceivers nearby (smartphones from the audience), it can be easily jammed.
Then I had this experience that on a crowded marketplace my cardoor could not be opened with my wirelesskey, probably some pirate transmitting on the same frequency but what if that happens in your neighbourhood, the entire system is rendered useless. Wire is still the way to go IMO if you can get away with it (invisibility for the WAF).

Short remark, I can see you know what you are doing and you built an amazing setup , but this kind of wiring as in the picture can also cause issues over time, please use end sleeves (aderendhulzen), sorry just had to say it 

[capt bullshot]

Wire is still the way to go IMO if you can get away with it (invisibility for the WAF).

I've got an agreement, where I may run wires and where not, so the WAF has been taken care of.

Short remark, I can see you know what you are doing and you built an amazing setup , but this kind of wiring as in the picture can also cause issues over time, please use end sleeves (aderendhulzen), sorry just had to say it 

Yep, that's correct. I just don't like the additional effort of using them. BTW, these black connectors have a tendency to get unreliable over time, depeding on the voltage / current you pass over them. Never use them for small signals. Even when using at a reasonable current according to their specs, sometimes they suffer from increased contact resistance. Most of them are replaced now by other connectors, preferably soldered or crimped to the wires.

[Kjelt]

BTW, these black connectors have a tendency to get unreliable over time, depeding on the voltage / current you pass over them. Never use them for small signals. Even when using at a reasonable current according to their specs, sometimes they suffer from increased contact resistance.

Ouch! is that the same for the green Phoenix connectors? , I just bought a bag full of them on a fleemarket 

[capt bullshot]

BTW, these black connectors have a tendency to get unreliable over time, depeding on the voltage / current you pass over them. Never use them for small signals. Even when using at a reasonable current according to their specs, sometimes they suffer from increased contact resistance.

Ouch! is that the same for the green Phoenix connectors? , I just bought a bag full of them on a fleemarket 

I've seen burned green Phoenix connectors in the past  (long time ago), so I'm cautious. Here and now (@work) we use literally tons of them (genuine Phoenix) in our products, over the full range of current / voltage ratings. There are no known (at least to me) failures. Maybe Phoenix made them better in the meantime, other brands may be compatible but not of equal performance.
I've never seen a minimum voltage / current rating on them, but their contact materials aren't suitable for small signals (same issue as for power / small signal relays).

[L1L1]

I did an open-source project exactly for this purpose based on CAN-bus and fully Arduino-compatible: you can basically control an army of Arduino boards from a PC, program each node with the Arduino IDE and update firmware over the network. You just need a single cable kind of like PoE. Distances of over 1000 feet are not difficult to achieve.

I actually launched a Kickstarter a while ago: https://www.kickstarter.com/projects/1242572682/omzlo-one-reinventing-the-arduino-with-built-in-ne.

The Kickstarter failed  It was mainly because of my lack of experience in crowdfunding and mistakes I made in marketing the project. But it was also because some people don't see that a connected solution like CAN-bus is sometimes better than Wifi...

Anyways, I will relaunch a new Kickstarter in a few months with a faster, stronger, smaller platform. I've started already sharing some ideas here: http://omzlo.com/articles/back-to-square-one.

I'd be happy to share ideas with others in the process!

[capt bullshot]

I did an open-source project exactly for this purpose based on CAN-bus and fully Arduino-compatible: you can basically control an army of Arduino boards from a PC, program each node with the Arduino IDE and update firmware over the network. You just need a single cable kind of like PoE. Distances of over 1000 feet are not difficult to achieve.

Hey, that looks great. I like your first version with the LSA connectors. I'd also like to see a simple single row 5 pin header for the CAN and power connection (GND, CAN lo, CAN hi, 5V input, wide range input). If the HW was STM32 based and with a reasonable pinout that fits your ubiquitous perfboard (like the older and simpler STM32 discovery boards), I could integrate these boards into my network using my firmware and libraries. Atmel and Arduino is a no-no for me.
USB to CAN host is useless for me, either Ethernet to CAN or the Banana PI with integrated CAN would be my choice.