Remote sensors/displays over cat5 - ATTiny? RS485? Modbus?

I'm still trying to flesh out my vocabulary, so I'm looking for some project direction.

Here's the scenario: One or more Arduino's in central location (telecom closet/workbench) with an incoming (say a 48-port) cat5 patch panel. Each port in the patch panel leads to a sensor (pir/motion, temperature, humidity, luminosity, etc), display (16x2 lcd), relay, or (stepper) motor somewhere else in the house. Any voltage (3.3V/5V/7.5V/12V/30V/48V) and also power over Ethernet (802.3af) is available at the workbench and can be patched into any port. Multiple (reasonable number of) cat5 cables can be run to any location (currently). Let's assume that each cat5 could be up to 100m in length (it won't be, hopefully closer to 60 ft max).

I'd love to simply run Ethernet to every location, assign an IP address to every sensor and collect the data over the network. From what I've found so far, it looks like any option which includes TCP/IP instantly starts looking like $60 per location. It needs to be cheaper than that. XD

What technologies should I investigate in this scenario?

Ideally, everything would be powered from the central location either by running voltage directly over cat5 or using PoE (and splitting it out on the other end with something like TRENDnet TPE-104S) if necessary.

Could the intelligence on the remote ends could be provided by something like an ATTiny with a RS485 chip? That looks mucho cheap. I'm guessing program the ATTiny like this so it knows how to communicate with the attached sensor and transmit that data to the central Arduino(s) via RS485/Modbus? ATTiny chips are cheap/simple enough (it looks like) that even with 48 different locations, it could still be affordable. ATTiny's also look smart enough to be able to be functional.

I'm thinking an application larger than just one project. If I could eventually build a simple enough PCB that could be used in this scenario, it seems like it would be a useful tool for these types of projects. Most of the Arduino projects I've seen online (like bildr.org) assume a sensor and an Arduino together. Since I'd like to distribute these sensors and/or displays throughout a (somewhat large) house, I'd like to flesh out my knowledge so I know what I should look for if I need to find a consistent way to do so.

I might also be under the mistaken impression that remote sensors/displays/relays/motors are going to be much more complicated that it actually is. Lacking the most basic knowledge/what is generally feasible, I need to get my feet wet. I haven't started playing yet: my Arduino kit and sensor stuff won't arrive until tomorrow.

All of the walls in my house are completely open and I have have time to experiment.

Forget about how I would do it -- I don't know what I'm doing. How would you do something like this?

From what I've found so far, it looks like any option which includes TCP/IP instantly starts looking like $60 per location. It needs to be cheaper than that.

Looks like ~$26 might be a starting point.

http://www.ebay.com/itm/UNO-ATMEGA-8U2-ATmega-328P-Ethernet-Sheild-W5100-For-ARDUINOs-IDE-/160934440513?pt=LH_DefaultDomain_0&hash=item257870ae41

if you aren't running the cat5 cables through anything that expects to deal with IP packets like a router (i.e. just using the cable as a convenient way to string 8 wires), for short runs, you could just connect the wires to each pin. I suspect for longer runs, you want to add something that can deal with check-summing and resend the packets if there are errors. You could use some cheap microprocessor on the remote end to do checksums, etc. I am currently thinking of doing this, but in my case the distance is fairly small so I don't have to worry about errors.

Note, the problem of point to point links like this is only one system can control them. You can of course log onto the central system to control the Arduino. It would be more flexible (and costly) to have each controller be a separate entity that has its own network IP address.

You can pick up the RJ-45 connectors at Radio Shack (RadioShack.com Official Site - America's Technology Store) if you want to connect the 8 wires yourself. You can also find these at places like Home Depot, Lowes, etc.

Sparkfun sells the connector and a small breakout board also: (https://www.sparkfun.com/products/643 and SparkFun RJ45 Breakout - BOB-00716 - SparkFun Electronics).

If you don't want to solder it, you can find similar breakout boards for about $10 each on ebay.

Obviously with a cheap processor, you could implement TCP/IP yourself, but that is likely to be fairly complex.

The 'UNO' link provided by zoomkat looks like a generic processor that mimics an Arduino UNO. Hopefully it is fully compatible, and they did not cut corners in some fashion or another.

MichaelMeissner:
If you aren't running the cat5 cables through anything that expects to deal with IP packets like a router (i.e. just using the cable as a convenient way to string 8 wires), for short runs, you could just connect the wires to each pin.

That's what I was thinking -- just using cat5 as a type of common wire with 8 wires. For digital sensors only though, right? If the sensor is an analog sensor, the signal won't make it 100m, right? Or is there something that can be used to repeat/amplify (some sort of capacitor/diode/something else) an analog signal? Is there a reasonable (known) limit that even digital sensors would fail at? 10ft? 50ft? 200ft?

MichaelMeissner:
I suspect for longer runs, you want to add something that can deal with check-summing and resend the packets if there are errors. You could use some cheap microprocessor on the remote end to do checksums, etc.

What I'm trying to find out, is what is the minimum electronics needed on the remote end beyond the sensor itself? You mentioned a checksum, what type of microprocessor should I research? An ATTiny?

MichaelMeissner:
Note, the problem of point to point links like this is only one system can control them. You can of course log onto the central system to control the Arduino. It would be more flexible (and costly) to have each controller be a separate entity that has its own network IP address.

The idea behind having the Arduino(s) in a central location is that they can be really beefy Arduino(s) with Ethernet, logging stuff to cosm.com, and displaying appropriate data on one of the four remote LCD displays throughout the house.

The patch panel that I'm looking at is the Leviton that use the QuickPorts like the ones you linked from Radio Shack. Thanks for the link to the RJ-45 jack on Sparkfun, I hadn't seen that yet.

Thanks for pointing out the "UNO" link. I wouldn't have seen it wasn't an Arduino-branded Uno, if it hadn't been pointed out. If it does work like a real Arduino Uno, that's a great deal. I'm hoping that the cost for the electronics at the remote end can be done a lot cheaper.

Has anyone here ever used an ATTiny (any model) with an RS485-type technology with a sensor or LCD display or to control a solid state relay or drive a motor, at a (not insignificant) distance from the Arduino it is connected to?

Is there a reasonable (known) limit that even digital sensors would fail at? 10ft? 50ft? 200ft?

With an RS-485 driver 4000' at slow speeds (~100kbps).

You shouldn't need a full Arduino at every location, maybe one or two per room each with X number of sensors plugged in to each one. This is the approach I'm using with this

www.ardweenet.com

But it doesn't satisfy your "the minimum electronics needed on the remote end" requirement. It does however have the advantage that local control can be autonomous to the master, so if your master dies or is having new code tested you can still turn the lights on in each room. Also I plan to have single-chip nodes after we get the first Arduino node working. These single-chip nodes will be very small and (presumably) very cheap.

But all this is a way off yet.

Meanwhile there's nothing wrong with using a Tiny84/85 at each node either. They don't have serial ports but you can bit-bang that and there's an Arduino port to both devices I think.

Rob