Print

[apemberton]

I am devising a network monitoring and controlling connection to maintain a decent environment for for my Guruplug network routers. I will be enclosing all three guruplugs in a single case. The existing GP's cases are crumbling so a radical solution is needed. As we know, Guruplugs run hot and cooling is needed. I will be using an old PC PSU to provide 5V (and 12V for fans). I will be monitoring the temperature using DS18B20's (or are the DS 18S20's I can never remember) attached à la Confusticated's sticking to the CPU as described elsewhere. There will be a Raspberry Pi equipped with a Piface module and a DS2482 I2C to 1-wire reading three (possibly four) DS18B20's with OWFS and passing the data back to the central, duplicated automation controllers, which are also Rpi's. Thats the easy bit and I already have temperature monitoring (using rrdtool) examples in service.

The other half of the project is the Piface equipped RPi in the network router box which receives commands from the automation servers over the network and turns on the fans as required. For me it is no problem controlling the fans that will be attached to the Piface's relays, nor the software mechanics of getting data received from the automation servers and decoding it. I have already done this with a couple of ethernet relay boards using a very crude modified telnet protocol (not my devising I might add). Of course you may be thinking that the RPi in the router case could perform control autonomously but thats not the way I want to do it.

At present, my mind is blank about what protocol I could use across the LAN for control. I could use an adapted telnet/ssh message protocol, devise my own protocol, use some sort of home automation protocol for message passing (e.g. MODbus, X10). Help me clear this mental block please!

[Confusticated]

How many ways are there to skin a cat ?

You could use a web server on the Pi with a simple webpage allowing you to switch the relays on & off.
Then you write a couple of HTML pages identical to the one's your browser sends to operate the switches (you can capture that).
Just have the guruplug send (curl, netcat, etc) the appropriate HTML POST page to the Pi to operate the required relay.

It's simple, you can monitor the Pi relay states in any browser that can reach it, and change them if you feel like it.
I am not recommending this method over any other, just mentioning it as most people don't think of this as an interface method for automated control.

[apemberton]

How many ways are there to skin a cat ?

Not a great thing for a cat lover! 

I don't think a browser approach will cut it although using PHP or Java might have done the job. The whole thing should be automatic, no manual intervention apart from monitoring and resilient. However;

I have decided after looking at the WIKI and modbus.org pages that MODbus is suitable for my task and seems to be well specified. There is a MODbus library for Debian in the repo although I havn't yet checked the Raspbian repo. MODbus has a limited number of functions (in C - my preferred tongue - call me old fashioned) for short message passing. It is a bit like CANbus in that each message has very few bytes and message checking built in. It is simple to set up a TCP connection. This will simply be between Pi's as I don't want to make the Guruplugs do clever things that might get in the way of their primary function of being routers, DHCP and BIND servers.

There is also the advantage in that, after the learning curve, the protocol can be used for other automation projects.

[Confusticated]

I don't think a browser approach will cut it

Not a browser, a web server, how powerful do you need it to be (actually overkill for your purpose).

The whole thing should be automatic, no manual intervention

Don't follow this, what part of the system requires manual intervention ?

I have decided after looking at the WIKI and modbus.org pages that MODbus is suitable for my task

MODbus is quite old (OK ancient)...but it is an industry standard so that would be a good reason for learning it.

in C - my preferred tongue

You could always write your own bespoke server\client tailored to your needs.
There are plenty of tutorials out there to help, this is just the first one I came across...
http://www.tutorialspoint.com/unix_sockets/socket_server_example.htm
http://www.tutorialspoint.com/unix_sockets/socket_client_example.htm

[apemberton]

After much time taken to search out the materials for MODbus, it is finally coming together! I always wanted to use TCP/IP but there is a lot of kit that uses MODbus over RS-485 (RTU). The documentation seems to have been written by people who know how it all works in the first place and that does not encourage take-up! For Debian there is libmodbus5 and libmodbus-dev (and python) libraries in the repository. The description of the use of the library functions is not great and some parts are distinctly missing. I did at least find useful tools for MODbus testing on my PC (Farrellton Solar) which can test each end of the link.

I looked at the examples created for the RaspberryPi and I'm afraid that served to confuse me more. Not sure what the author is trying to achieve as WiringPi crops up but not adequately explained. Cobbling together bits from some proprietary device is not a great idea either.

I'm not sure about the endian-ness of TCP MODbus, which is not a great problem in my closed system but might be if I were to purchase proprietary devices in the future. I thought transmitting floating point numbers (temperature values) would be a problem but actually does not seem to be if the library functions are used. As the MODbus protocol is octet and 16 bit oriented, extensive use of type casting is needed. I have time values in 64bit (unsigned long long) to be transferred which requires octet shuffling!