I've been having a lot of fun messing around with the Raspberry Pi as a server and decided to upgrade the temperature monitor with some more advanced I2C shenanigans.
I got 10 LM75 I2C temperature sensors on eBay for less than £3 including the delivery, which was a real bargain. The only drawback was that they are SOIC-8 (i.e. tiny) 8-pin packages, but a small piece of tri-pad copper board and some fine soldering and I was able to come up with the adaptor in the photo below for prototyping purposes.
The red LED is just to confirm that 3.3v power is getting to the LM75 on the little breadboard and the white and grey wires are the SCL (clock) and SDA (data) lines for the I2C bus coming from the Raspberry Pi.
Reading temperature data from the LM75 is very simple, but I have hit a minor snag. The LM75 uses a 2 byte data format although the device is essentially 8-bit. Only 1 bit in the second byte is relevant, but it is the least-significant bit which represents 0.5 degrees C (or 0.5 Kelvin if you like). The Python library I'm using insists on writing a byte to an I2C device if you want to read 2 bytes (or a 'word'), but this doesn't seem to work right so I am just reading 1 byte and losing the half-degree resolution until I can figure this out. That said the data is accurate, if only to 1 degree resolution.
So on the programming and server end, I went for a graph this time as well as a table. In behind this, the Python program is reading the LM75 and formatting the time and temperatures into a JSON file. This is then decoded by a Java Script program at the client end and displayed as a little bar chart.
The next step I want to take is to log temperature data over a number of hours and display it as a graph on demand as well as having live data displayed in a table. I want to use this to test the possibility of having 'almost live' telemetry data output over wi-fi from a car engine system. As previously blogged, I want to try and get running data out to a low-cost Android tablet that only has wi-fi and a browser. My thinking is that although there will be a limit on the number of browser requests possible (I'm aiming for 1 per second), the data logger/server would be collecting data much faster, collating it and then sending it as a JSON file. In this case the Raspberry Pi would be running in access point mode as tested here over a short range (engine bay to the tablet computer on the dashboard).
It may be better to create the graphs at the server end in PHP and then send them as a JPEG or GIF image, but part of the fun will be seeing which works best. They key thing is in cracking the AJAX concepts to get regular timed updates on the browser without needing to refresh the whole page. That has been a real revelation to me (yeah, I'm not an early adopter!) and