Barbduino – more design decisions

I haven’t done that much on my Barbduino BBQ Controller project for about a month. No good reason, other than simply doing other stuff.

After hesitating over how the device is going to connect to the outside world, I decided to abandon the idea of a WiFi shield, and bought a standard Ethernet Shield instead. The reasons for this were various.

  • The Ethernet shield is half the price of the WiFi shield.
  • It is more “standard” than the WiFi shield. There seems to be a common Ethernet library, whereas the different makes of WiFi shield all seemed to require their own code. (I may be wrong on this, but it did seem that way.)
  • The Ethernet shield comes with a mini-SD card slot built in – useful for data logging.
  • Should I (or someone wanting to use my code) really needs WiFi, they can simply use a Ethernet to WiFi bridge device.

As it happens, I no longer need WiFi to connect up, as my garage once more has a network connection, which I can tap.

So tonight I have been playing with the Ethernet Shield, and got as far as a simple plain text web page, which displayed multiple probe temperatures on screen, and refreshed every X seconds. This was achieved by running simple Web Server code on the Arduino. It was surprisingly easy to set up, and I was delighted to see it working.

This now brings me to a new design decision:

1) Serve web pages from my Arduino, as above. This is simple, and self contained, and will probably be more useful to other people, should I share my code (and why not?). However, while it will happily support a single browser pointing at it (either a desktop, netbook, or Android), the processing power is probably not sufficient to do any more than that.

2) Serve pages from another machine – either a webserver on a desktop here, or (more likely) my main website. The Arduino will run a webclient which will upload temperature data, using POST, and download commands, using GET. The web interface will update a mySQL database, which is what the human interface will use. So essentially:

Arduino <---> apache <---> mySQL <---> apache <---> Human

This will let me do all sorts of things, like data logging and a publically accessible webpage for my Smoker! However, it does mean that the whole things breaks down if my broadband goes down!

Fortunately, the hardware configuration is going to be the same for either, so I can afford to tinker, and can always change my mind later. Or perhaps come up with a hybrid idea, where the Arduino serves pages for a single primary controller, but periodically (every 5 minutes) uploads temperature data to a public website for pure geekiness.

2 Comments

  1. July 7, 2011
    Reply

    Is there space on the device for enough code to support both interfaces, with a command available in each mode for switching over to the other? Then you’ve got something that other curious users can get up and running straight away as a self-contained gadget, but with the option to later switch up to your more sophisticated set-up (or their own variation thereof). The default mode up on bootup should be the simple web interface, and then your separate web server/database just needs to recognise that and send the “ok, flip modes please” command.

    Alternatively, can it run the basic web interface on the usual http port number, with your other interface available on another port?

    • chris
      July 7, 2011
      Reply

      At the moment there is space, as I am nowhere near filling the available space with code (although there is yet a lot to do). However, it would be simpler just to supply two lots of code.

      Anyone with an Arduino board will also have the Arduino software used to upload the sketch (programme) being used – this is done over USB, so is easy and convenient.

      Note that whoever uses this will need to configure the software anyway – at minimum assign it a fixed IP address, and in the second case, details of the remote server. This would be done by editing parameters in the code itself, so there is no avoiding the edit and upload process. So there is no real advantage in combining the two versions.

      The real issue is do I want to develop two lots of code? 🙂

      The interesting idea is your “Alternatively” which I called “a hybrid idea” in my last paragraph. In which case we would be dealing with two ports. However, I would probably reverse how you have it, and use the nonstandard port for the basic control interface, while talking to the remote (hosted) server on port 80.

Leave a Reply to Paul B. =:o} Cancel reply

Your email address will not be published. Required fields are marked *