I am considering implmenting an home automation system around my Raspberry Pi but I found the price and space requirement of inserting a Pi every place some control is required too much but the Cat5e cables required for this design is already installed during renovation. I have some PCF8574's, PCF8591's and SSRs lying around so is it possible to drive them using Cat5e cables?
All my Cat5e cables are already wired with TIA/EIA 568B pinout. They are part of my structural cabling and are not shielded, so higher line voltage is required. I am thinking sending power and I2C lines over the cable, with this pinout:
Pin 1 (Pair 1): SCL+
Pin 2 (Pair 1): SCL-
Pin 3 (Pair 2): SDA+
Pin 4 (Pair 3): +12V
Pin 5 (Pair 3): +12V
Pin 6 (Pair 2): SDA-
Pin 7 (Pair 4): GND
Pin 8 (Pair 4): GND
The power pin arrangement is same as 100BASE-TX PoE wiring so power rating will be the same too, and using of bidirectional differential signaling is found in 1000BASE-T which requires Cat5e.
Original I2C SCL and SDA lines are derived into two bidirectional differential pairs at TTL levels (the open-drain is not kept on the wire, but restored in the line termination/level shifting device that I am designing)
Any suggestion on that? Also, which chip should I use to convert I2C lines to the differential signalling? Please suggest chips with DIP through-hole option to me. I do not know how to handle SMT stuff.
EDIT
I found this chip, SN65LBC180, is it a good choice? How to wire it into a bidirectional unit? How to shift level (it is a BiCMOS part requiring TTL level but Pi drives at 3.3v CMOS levels) and make it open-drain-compatible?
EDIT 2
Commenters suggested RS-485 which appeared acceptable to me, but still the two differential pairs are required to be bidirectional and only two bidirectional differential pairs only. I am repurposing existing Ethernet cables.
EDIT 3
Since someone brought it up, I cannot use CAN. There is no way I can fit CAN onto RPi without sacrificing anything (SPI is occupied by a touchscreen, so no SPI to CAN converter)
I am aware of the limitation of I2C PHY so I am essentially trying to fit 1000BASE-T PHY to it – bidirectional differential signaling for SCL and SDA signals, but on top of that runs I2C protocol.
EDIT 4
A new chip came to me: NXP P82B96 which splits I2C into 4 unidirectional lines, which in turn can be used to feed into SN65LBC180 through opto-isolation (Pi-side only) to form a 8-pin long-distance-ready signaling. Now I just need to figure out how to get power through the wire, or how to determine if the bus is sending and make the pairs bidirectional.
EDIT 5
From the suggestions of answers, I think I need to change the power pinout a little:
Pin 1 (Pair 1): SCL+
Pin 2 (Pair 1): SCL-
Pin 3 (Pair 2): SDA+
Pin 4 (Pair 3): +5V
Pin 5 (Pair 3): GND
Pin 6 (Pair 2): SDA-
Pin 7 (Pair 4): GND
Pin 8 (Pair 4): +12V
I2C differential signaling voltage is TTL. The +5V over pair 3 comes from the Pi, unbuffered but fused. The +12V over pair 4 may not be present is only used to drive some high-power devices. If needed the device may use its own power supply and leave both rails hanging unconnected or supply its own higher voltage but use the 5V rail.
SCRATCH THAT
Pinout is still my original design, which is 802.1af compatible.
Best Answer
Trying to do with with IIC is a bad idea. IIC is really meant for communication between chips on a single board. Since the maximum required current to pull a line low is limited, the lines are relatively high impedance (a few kΩ). This means they can pick up noise easily, which is a serious issue when running in unshielded cable in the walls possibly right next AC power wires.
I would use CAN for this. CAN uses a single twisted pair pulled together with only 60 Ω at any one point, and the signal is differential. That means most of the inevitable common mode noise that will be picked up due to capacitive coupling can be cancelled by receivers. CAN running at 500 kbits/s can cover something the size of a ordinary house.
Many microcontrollers are available today with CAN built in. You usually need a separate physical tranceiver chip (like the common MCP2551), but the lowest few layers of the protocol are implemented in silicon in the CAN peripheral. The firmware interacts with the CAN bus at the level of sending and receiving complete packets. The collision detection and retry, checksum generation, details of the bus packet signalling, received checksum validation, and clock drift adjustment are all handled for you.
Don't fall for RS-485. That's a relic from a bygone era. It also uses a single differential signal like CAN, so also has good noise immunity. However, people usually fall for RS-485 because it looks "simpler". This is only because they don't look at the whole system. First, it's not really any less complex electrically. You will still need some kind of transciever to drive and receive the differential signal. Whether you have a RS-485 transceiver connected to the microcontroller's UART, or a MCP2551 connected to the CAN peripheral is pretty much irrelevant in terms of cost and hardware complexity. The big difference is that RS-485 leaves you at the raw byte level (via the UART). This means to implement any meaningful and robust system, you have to invent your own protocol to handle collision detection, decide how to handle retries, packetization, checksum generation and checking, flow control, etc. You can use a single master architecture, but getting the details right is a lot more tricky than people think that haven't analyzed all of them carefully. With CAN you just send and receive packets, and the hardware takes care of the details.