I thought I'd better come back and try and make some sense on this thread, so here goes.
Seemingly you really need to record three bits of information for each reading.
Which Sensor produced the reading. This needs to be unique to avoid confusion and that's exactly the kind of things database's ( databi ?) like to do. In the One world it's a no brainer to use the ID for this field and since you ain't going to do maths on it, make it a Character Field. You don't loose overhead in making this big in modern databases so make it 255 to keep it just below the point at which most databi loose the ability to index on it.
name = models.CharField(max_length=255, help_text= 'The sensor name')
so for a DS18S20 that would start with 10h and the DS18B20 would start with 28h. Now these are actually hexadecimal values (Base 16; you count 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F. Computers like it cos it fit's into ones and noughts really easily so two characters represent all the numbers from 0 (00h) via 16 (10h) and 40 (28h) up to 255 (FFh) but since you ain't going to do any maths on them ( would you, for instance, ever need to multiply your house number by anything to any non frivolous purpose ...?) you don't wory two much about that and you just treat it is a chunk of text.
Next we need to know the time of the reading.
created_date = models.DateTimeField(auto_add = True)
Databai, generally have something that can represent a date and a time. There is some degree of standardization but moving dates and times between systems ( POSTGRES-> MySQL for instance ) can be a real pain. If it's done properly you should record information like time zone and from there onto geographic stuff but for most home systems the native date/time format will work. Just make sure you know about daylight saving times otherwise your going to find yourself comparing different noons and you'll have people in forums laughing at you behind your back, not buying you drinks or questioning anything you may say about your measurements.
and then the value...
and this is where it get's a little dependent on opinion.
There are several different field type for storing 'values', and different sensors might want to store different types of value.
Let's start with our old friend the DS18B20 & DS18S20.
http://www.tempsensornews.com/generic-temp-sensors/comparison-of-the-ds18b20-and-ds18s20-1-wire%C2%AE-digital-thermometers/ Seemingly they are identical, and by and large will do the same sorts of things. Except one of them you can send values to it to change the resolution it can offer.That aspect alone instantly seperates the two of them conceptually because to get an accurate reading that you can believe requires you know other bits of information.
However they do present data identically, to quote from the datasheets...
The temperature data is stored as a 16-bit sign-extended two’s complement number
So one could store precisely that if your database has that kind of definition and that would be the end of the issue, but for one small aspect. We are much more likely to want to actual store it as a number we can manipulate as a number, which we happen to know corresponds to a temperature.
We could store it as an integer...
so 20 °C would be stored as the number 20. This gets useful cos you can now do maths like things like highest temperature or lowest temperature or averages.
But that isn't quite as accurate as it could be.
So the next choice is the engineers favourite the float...
value = models.FloatField()
The database stores two numbers which are a number in binary raised to a power by anothe number. The problem her is that accuracy can get interesting. You very quickly get issues like 2.0 * 2.0 = 3.99999999999999975. Which whilst actually at an accuracy way above anything we might choose to measure till tends to confuse, especially at the display end.
There is the decimal, 20.375
value = models.DecimalField(..., max_digits=5, decimal_places=2)
This does at least keep everything in a nicely handled format without all the fun of displaying floats, so that might be a good solution and from the software side it is exactly accurate.
At the end of the day it's up to you cos your publishing the data.
Of course for the half-bee like projects that use pseudo thermometers as switches you always have the Boolean field, which allows you to show on and off ness and nothing else.
value = models.BooleanField(default = True)
various other types exist, heres' the django take on it
http://docs.djangoproject.com/en/1.2/ref/models/fields/#integerfield but any database supports these basic concepts.
So as you can see a Standard Solar thermal database really needs a lot more detail about Sensors before it can really be a standard. The context of the database is very important and really a standard data base should be able to include suh items as ImageFields to contain pictures of the sensors, and geographical data to actually say where it was.
It gets quite big quite quickly. These are obviously just my thoughts. I'd love to hear anyone else's view, especially if the disagree
More available if people want it.
