$12.90 from Futurlec, connects to anything with simple RX/TX/POWER for monitoring of a CANBUS 2.0 line. Simple commands to get and put values to the CAN line.
I recently discovered extensive research proving what I already guessed a while back - CANBUS started as a DOD standard for creating EMP resistant networks and gradually filtered down to the civilian industry starting with the car manufacturers. CANBus was designed to survive nuclear war and solar flares! The design of CANBus makes it possible to both shield and ground network lines in a way that is impossible with ethernet and traditional power lines.
Implications : Once you reduce any monitoring to a TTL interface you have any number of options to use it from a conventional PC, embedded controller or other device to make it available globally. The total price with a TTL converter ($3) on Ebay (USB or RS-232) comes to $15.00 or so which makes it much cheaper and simpler than the older standard ELM327 serial devices for connection to a CANBUS.
For me it also raises the possibility of a very small x86 device running a minimal OS in DOS or Linux to act as a consolidation node for transmitting/serving up CAN information over a tiny web service to make it available to the whole shelter. A TTL device like the one above doesn't require any special drivers, either DOS, Windows or Linux/FreeBSD write to it with simple COM port commands. I have had good results previously with a tiny program in PowerBASIC sending sensor information to mailslots running over LAN Manager for DOS. My biggest problem in the past running on these very small RAM devices (192K on my smallest x86 board) is not sending messages over the network through mailslots or a packet driver, but trying to fit the I2C TSR and CANBUS TSRs into memory with the TSR for the packet driver. So if the only TSR I had running was the packet driver and the I2C and CANBUS were both simple serial commands you'd have a very stable system that would fit onto a tiny machine. My main interest in this area is driven by my desire to watch my security triggers and seismic posts in real-time, no big fat Windows OS running, just sitting on the raw metal of DOS/BusyBox Linux watching these ports and waiting for interrupts to go off. In a dedicated box like this I want it to be fixed purpose, it doesn't need to run an inventory program or manage a schedule of work orders like the more ambitious Vault-OS program I am still working on. It just needs to sit there watching those security triggers and notify the rest of the system immediately if something is triggered, with an audio/visual alarm in addition to an alert message sent out to all machines watching over the network lines for these kinds of events.
So you've got a web browser running Vault-OS and it is watching for AJAX messages in real-time. It's really good if this page is up to let you know that somebody has broken the perimeter. What if you're in inventory while this occurs? This is the problem with web browser client pull monitoring architecture. I am still trying to solve this problem but the ultimate backup is to have the dedicated machine deliver it's own alert and notification you can hear, in addition to providing web services to any machine to let them know what was happening. Ideally this might be a snapshot of the particular region monitored that has just triggered, showing a guy in PIR sneaking beside the monitoring post as a thumbnail in the web service. I had this semi-working about two years ago when it was a dedicated device but right now it is still under development after I changed the nature of the TCP-IP communication by making it into an AJAX service.
When I started work on Vault-OS embedded server in OpenWatcom in 2010, these libraries were not available. Very impressive lineup for DJGPP. My long term dream of running Vault-OS as a pure DOS-32 program with it's own web browser as it's own GUI could still become a reality but first I have to get the Win-32 version out. This cross-platform serial CANBus solution could be a big part of that. The source code would look nearly identical on every single platform for monitoring the bus directly.