navitron
 
Renewable Energy and Sustainability Forum
UK's most popular Renewable Energy Forum February 08, 2012, 10:57:07 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Anyone wishing to register as a new member on the forum is strongly recommended to use a "proper" email address - following recent spam/hack attempts on the forum, all security is set to "high", and "disposable" email addresses like Gmail, Yahoo and Hotmail tend to be viewed with suspicion, and the application rejected if there is any doubt whatsoever
 
Recent Articles: Yingli Green Energy's PV Module Ranks No.2 in TUV Rheinland Energy Yield Test | Navitron Solar Showers at Glastonbury for Year 5! | Lights go on in Sierra Leone
   Home   Help Search Login Register  
Pages: [1] 2   Go Down
  Print  
Author Topic: Digitemp! And then what?  (Read 4390 times)
KLD
Hero Member
*****
Offline Offline

Posts: 1340


« on: October 07, 2009, 04:54:36 PM »

Having collected data manually every day since installing our solar panels, I thought it's about time to get going with the 1-wire sensors etc. The plan is to use a NSLU2 (a.k.a. slug) as a low-power recorder. Every so often the data should be copied over to another computer for analysis. Both, the slug as well as my laptop, are currently running under Debian. So far, at least 10 temperature sensors will be dotted along the solar loop and the thermal store.

To date, the manually collected daily data are typed into a spreadsheet in OpenOffice Calc. In there I do all my analysis, like daily/ monthly/ annual consumption (leccy, gas), solar heat gain, tank losses, you name it.

How do you folk automate this? What's the best way to collect/ keep/ analyse/ visualise all those data? I haven't got very far yet, apart from getting digitemp running and logging into a file. Don't even know whether that's a good starting point.

Klaus
Logged
StBarnabas
Hero Member
*****
Offline Offline

Posts: 2089


St Barnabas Chapel (2009)


« Reply #1 on: October 07, 2009, 07:46:14 PM »

Klaus
currently I use MATLAB - but it is not free; IMHO beats the socks off anything else though Mathematica and ROOT are also very useful in their place.

http://en.wikipedia.org/wiki/MATLAB
http://en.wikipedia.org/wiki/ROOT
http://en.wikipedia.org/wiki/Mathematica

Matlab has great graphics and makes dynamics such as tank modelling not quite a piece of cake but at least doable.

I'm sure others may be fans of PYTHON etc...
Logged


Gestis Censere. 40x47mm DHW with TDC3. 3kW ASHP, 9kW GSHP, 3kW Navitron PV with Platinum 3100S GTI, 6.5kW WBS, 5 chickens. FMY 2009.
sleepybubble
Hero Member
*****
Offline Offline

Posts: 988


expect the unexpected, then its expected


« Reply #2 on: October 07, 2009, 08:15:13 PM »

Having collected data manually every day since installing our solar panels, I thought it's about time to get going with the 1-wire sensors etc. The plan is to use a NSLU2 (a.k.a. slug) as a low-power recorder. Every so often the data should be copied over to another computer for analysis. Both, the slug as well as my laptop, are currently running under Debian. So far, at least 10 temperature sensors will be dotted along the solar loop and the thermal store.

To date, the manually collected daily data are typed into a spreadsheet in OpenOffice Calc. In there I do all my analysis, like daily/ monthly/ annual consumption (leccy, gas), solar heat gain, tank losses, you name it.

How do you folk automate this? What's the best way to collect/ keep/ analyse/ visualise all those data? I haven't got very far yet, apart from getting digitemp running and logging into a file. Don't even know whether that's a good starting point.

Klaus

un my slug runnig SlugOS, I have installed MySQL, I use the Perl scripts that come with Digitemp to poke data into the SQL database, run on the crontab at five minute intervals.  For interpretation, some SQL queries and Open flash Charts.

I'm never happy with it, but it does work to current satisfaction, I haven't played with it for some time now, so it must be ok.  If you need pointers to howto's and scripts let me know and I will put together a list of things that work and also try and let you know where I failed.
Logged

;-)
wookey
Hero Member
*****
Offline Offline

Posts: 2558


WWW
« Reply #3 on: October 07, 2009, 08:20:52 PM »

KLD - I currently use a combination of munin (for logging) and a rather simple-minded shell script for control and logging.

A better solution is almost certanly temploggerd:
http://sourceforge.net/projects/owfs/files/temploggerd/ which annoyingly isn't in Debian yet, although I'm planning to fix that at some point. I keep meaning to set this up, but my current bodge works just fine so leaving it alone all summer has seemed like a good plan :-)

Here's the munin tank-log script:
#!/bin/sh
#
# Plugin to monitor heating sensors.
#
# Usage: Place in /etc/munin/node.d/ (or link it there  using ln -s)
#
# Parameters understood:
#
#    config   (required)
#    autoconf (optional - used by munin-config)
#
# Magic markers - optional - used by installation scripts and
# munin-config:
#
#%# family=auto
#%# capabilities=autoconf

#read owfs config, then export it so backticks work
. /etc/default/owfs
export CLIENT_OPTS

if [ "$1" = "autoconf" ]; then
   if owdir $CLIENT_OPTS ; then
      echo yes
      exit 0
   else
      echo no
      exit 1
   fi
fi


if [ "$1" = "config" ]; then

   MAX="126"
   MIN="-4"
#   if [ "$scaleto100" = "yes" ]; then
#      graphlimit=100
#   else
#      graphlimit=$PERCENT
#   fi
   WARNING="80"
   CRITICAL="95"
   echo 'graph_title Tank Temperatures'
   echo "graph_order tank5 tank4 tank3 tank2 tank1"
#   echo "graph_args --base 1000 -r --lower-limit 0 --upper-limit $graphlimit"
   echo 'graph_vlabel Degrees Celcius'
#   echo 'graph_scale no'
   echo 'graph_info This graph shows hot water tank temperatures.'
   echo 'graph_category solar'
   echo 'graph_period minute'
   echo 'tank1.label tank-base'
   echo 'tank1.draw LINE2'
   echo "tank1.max $MAX"
   echo "tank1.min $MIN"
   echo 'tank1.type GAUGE'
   echo "tank1.warning $WARNING"
   echo "tank1.critical $CRITICAL"
   echo "tank1.info Temp at base of tank"
   echo 'tank2.label tank2'
   echo 'tank2.draw LINE1'
   echo "tank2.min $MIN"
   echo "tank2.max $MAX"
   echo "tank2.warning $WARNING"
   echo "tank2.critical $WARNING"
   echo 'tank2.type GAUGE'
   echo 'tank2.info Temp 20cm up tank'
   echo 'tank3.label tank3'
   echo 'tank3.draw LINE1'
   echo "tank3.min $MIN"
   echo "tank3.max $MAX"
   echo "tank3.warning $WARNING"
   echo "tank3.critical $WARNING"
   echo 'tank3.type GAUGE'
   echo 'tank3.info Temp 40cm up tank'
   echo 'tank4.label tank4'
   echo 'tank4.draw LINE1'
   echo "tank4.min $MIN"
   echo "tank4.max $MAX"
   echo "tank4.warning $WARNING"
   echo "tank4.critical $WARNING"
   echo 'tank4.type GAUGE'
   echo 'tank4.info Temp 60cm up tank'
   echo 'tank5.label tank-top'
   echo 'tank5.draw LINE2'
   echo "tank5.min $MIN"
   echo "tank5.max $MAX"
   echo "tank5.warning $WARNING"
   echo "tank5.critical $WARNING"
   echo 'tank5.type GAUGE'
   echo 'tank5.info Temp at top of tank'
   echo 'pump.label solar-pump'
   echo 'pump.draw LINE'
#   echo 'pump.color black'
   echo "pump.min 0"
   echo "pump.max 5"
   echo 'pump.type GAUGE'
   echo 'pump.info Solar pump runnning'
   echo 'dump.label heat-dump-on'
   echo 'dump.draw LINE'
#   echo 'dump.color black'
#   echo "dump.min 0"
#   echo "dump.max 1"
   echo 'dump.type GAUGE'
   echo 'dump.info Heat dump runnning'

#if [ "$scaleto100" = "yes" ]; then
#   echo "system.cdef system,$NCPU,/"
#   echo "user.cdef user,$NCPU,/"
#   echo "nice.cdef nice,$NCPU,/"
#   echo "idle.cdef idle,$NCPU,/"
#fi
   exit 0
fi


TANK1SENSOR="28.850874010000"
TANK2SENSOR="10.AD188A010800"
TANK3SENSOR="10.634B8A010800"
TANK4SENSOR="10.E7EE89010800"
TANK5SENSOR="10.AEEA89010800"

TANK1=`owread $CLIENT_OPTS $TANK1SENSOR/temperature`
TANK2=`owread $CLIENT_OPTS $TANK2SENSOR/temperature`
TANK3=`owread $CLIENT_OPTS $TANK3SENSOR/temperature`
TANK4=`owread $CLIENT_OPTS $TANK4SENSOR/temperature`
TANK5=`owread $CLIENT_OPTS $TANK5SENSOR/temperature`
IOREG=`cat /sys/bus/i2c/devices/0-0038/read`
PUMP=$(($IOREG & 4 ))  # bit 2 set
if [ $PUMP = 0 ]; then PUMP=6; else PUMP=0; fi
DUMP=$(($IOREG & 56 ))  # bits 3,4,5 set
if [ $DUMP = 0 ]; then DUMP=3; else DUMP=0; fi

#   awk '/^cpu / { print "user.value " $2 "\nnice.value " $3 "\nsystem.value " $4
"\nidle.value " $5 }' < /proc/stat
   echo "tank1.value $TANK1"
   echo "tank2.value $TANK2"
   echo "tank3.value $TANK3"
   echo "tank4.value $TANK4"
   echo "tank5.value $TANK5"
   echo "pump.value $PUMP"
   echo "dump.value $DUMP"

The munin server connects and runs this script. RRDtool collates and compresses the data and draws nice graphs. The catch is  that the recorded data resolution drops over time, which may not be what you want.

Here's my control script, which is GPLed so feel free to use it. It mixes control and logging, which would be separated in a sensible software design. This logs to a simple log file. (It used to log to an rrd database).

#!/bin/bash
#set -x

. /etc/default/owfs

#PANEL_SENSOR=28.D23974010000
PANEL_SENSOR=10.B8E089010800
#TANK_SENSOR=28.850874010000
TANK_SENSOR=10.AD188A010800

TANK_TOP_SENSOR=10.AEEA89010800

SOLAR_PUMP=4  #bit 2
CH_PUMP=8     #bit 3
CH_VALVE=16   #bit 4
DHW_VALVE=32 #bit 5

TEMPSTART=10
TEMPSTOP=5

OVERHEAT=90

IOREG_DEV="/sys/bus/i2c/devices/0-0038"

function turnonoff ()
{
  ioreg=`cat $IOREG_DEV/read`
  case $1 in
    pump)
      facility="solar pump"
      twiddlebits=$SOLAR_PUMP
      ;;
    dump)
      facility="heat dump"
      twiddlebits=$(($CH_PUMP + $CH_VALVE + $DHW_VALVE))
      ;;
  esac
  case $2 in
    on)
      pumpstat="on"
      echo "$(($ioreg & ~$twiddlebits))" > $IOREG_DEV/write
      ;;
    off)
      pumpstat="off"
      echo "$(($ioreg | $twiddlebits))" > $IOREG_DEV/write
      ;;
   esac

   echo "Turning $facility $pumpstat"
   logger -i -s -p local0.notice -t solar "$facility $pumpstat"
}


function higher ()
  # returns 1 if $1+tempdiff> $2, otherwise returns zero. * status is $1<$2
  case `echo "a=$1;b=$2;d=$3;r=-1;if(a-d<=b)r=0;if(a-d>b)r=1;r"|bc` in
    0) return 0
    ;;
    1) return 1
    ;;
    *) return 0
    ;;
  esac
}

      
while true
do
  owdir ${CLIENT_OPTS} > /dev/null
  sleep 20
  echo `date`
  PANEL_TMP=`owread ${CLIENT_OPTS} $PANEL_SENSOR/temperature`
  PANEL_TMP=${PANEL_TMP#"${PANEL_TMP%%[! ]*}"}
  TANK_TMP=`owread ${CLIENT_OPTS} $TANK_SENSOR/temperature`
  TANK_TMP=${TANK_TMP#"${TANK_TMP%%[! ]*}"}
  TANKTOP_TMP=`owread ${CLIENT_OPTS} $TANK_TOP_SENSOR/temperature`
  TANKTOP_TMP=${TANKTOP_TMP#"${TANKTOP_TMP%%[! ]*}"}
  higher $PANEL_TMP $TANK_TMP $TEMPSTART
  RET1=$?
  higher $PANEL_TMP $TANK_TMP $TEMPSTOP
  PANEL_TMP=${PANEL_TMP#"${PANEL_TMP%%[! ]*}"}
  TANK_TMP=`owread ${CLIENT_OPTS} $TANK_SENSOR/temperature`
  TANK_TMP=${TANK_TMP#"${TANK_TMP%%[! ]*}"}
  TANKTOP_TMP=`owread ${CLIENT_OPTS} $TANK_TOP_SENSOR/temperature`
  TANKTOP_TMP=${TANKTOP_TMP#"${TANKTOP_TMP%%[! ]*}"}
  higher $PANEL_TMP $TANK_TMP $TEMPSTART
  RET1=$?
  higher $PANEL_TMP $TANK_TMP $TEMPSTOP
  RET2=$?
  higher $TANKTOP_TMP $OVERHEAT 0
  RET3=$?
  higher $PANEL_TMP $TANKTOP_TMP 4
  RET4=$?
  if [ "$RET3" = "1" ]; then
    turnonoff dump on; #Overheat status
  else
    # normal operation
    turnonoff dump off;
  fi
  if [ "$RET1" = "1" ]; then turnonoff pump on; PUMP=1; fi
  if [ "$RET4" = "1" ]; then turnonoff pump on; PUMP=1; fi
  if [ ! "$RET2" = "1" ]; then turnonoff pump off; PUMP=0; fi

#  rrdtool update /var/log/solar.rrd N:$PANEL_TMP:$TANKTOP_TMP:$TANK_TMP:$PUMP
  echo "Panel:$PANEL_TMP  Tank Base:$TANK_TMP  Tank:$TANKTOP_TMP"
  logger -i -s -p local0.notice -t solar "Panel:$PANEL_TMP  Tank Base:$TANK_TMP  Tank$
done
Logged

Wookey
StBarnabas
Hero Member
*****
Offline Offline

Posts: 2089


St Barnabas Chapel (2009)


« Reply #4 on: October 07, 2009, 08:35:00 PM »

Wookey
nice stuff. Very useful for "bang bang" control and very easy to read. I'm not sure what sort of tools Klaus is looking for - but I though it was more graphing and analysis - but this is interesting from my point of view.
Logged


Gestis Censere. 40x47mm DHW with TDC3. 3kW ASHP, 9kW GSHP, 3kW Navitron PV with Platinum 3100S GTI, 6.5kW WBS, 5 chickens. FMY 2009.
KLD
Hero Member
*****
Offline Offline

Posts: 1340


« Reply #5 on: October 07, 2009, 09:20:48 PM »

Thank you all for the replies. And yes, my main aim is to (1) create a data table for the various sensors; at the moment I'm planning to record data on a time scale typical for the system, say ever 5min or so; and I like to keep that resolution even for historical data; (2) be able to access the data to do some mathematical transformations; (3) visualise the results.

I've never worked with databases,  horror, so I don't even understand (yet ;-) the differences between RRD and SQL. Worse then that, I'm not even certain whether storing the data in such a format is necessary. But that probably depends on the interface to step #2. Ages ago I used to work with a plotting software called Genplot, that used a script language to do basic transformations, and to create the plots. Later Xmgr sort of served a similar purpose. I've installed it's successor Grace now and am trying to (re-)learn it. [The handling of date and time in Grace drives me mad!]

I find it important that you can go back to the data and re-analyse them in a different way. Obviously it would be impractical to hold all data in a single long table (every 5min translates to about 100'000 per year). So, it would be good to have a rolling "active" table spanning from "today" to say "1 year ago". All older data could be archived, after some meta data (totals of consumption or heat gain etc) were extracted.

Ah, and there is a need to be able to manually input data for those "sensors" that aren't automated yet (e.g. leccy and gas meters, comments, etc).

Let's hope for long dark winter  Grin

Klaus
Logged
sleepybubble
Hero Member
*****
Offline Offline

Posts: 988


expect the unexpected, then its expected


« Reply #6 on: October 07, 2009, 10:29:01 PM »

simple advice.... have a long hard think about what you want from the graphs before you start, then go and find a graph tool that can deliver what you want, then look at the data problem....

I have 1 years worth of plots at five minute intervals for 8 sensors and it adds up to about 15mb so don't worry about size.

If your running the slug on Debian your options are wider, I slinged my box with SlugOS and am constantly regretting it. DO have a good look at OFC http://teethgrinder.co.uk/open-flash-chart-2/ it really is very nice. Eccentric annomaly ( I think!) posted a link to another very nice charting package a while ago which I looked at but didn't use. Tried to find the orignal post but couldn't  Undecided sorry.
Logged

;-)
AndyB
Full Member
***
Offline Offline

Posts: 172


« Reply #7 on: October 11, 2009, 06:59:29 PM »

Hi I started off using http://www.audon.co.uk/labjack.html it comes with Daqfactory software and i now use if for all my live monitoring, logging and graphing.

Andy
Logged

NON MEUS MENDUM
wookey
Hero Member
*****
Offline Offline

Posts: 2558


WWW
« Reply #8 on: October 11, 2009, 10:16:45 PM »

I've never worked with databases,  horror, so I don't even understand (yet ;-) the differences between RRD and SQL.

RRD is 'Round Robin Database'. It allows you to specify a number of readings at a given frequency to be stored. Once that lot gets full then it wraps round. The advantage is that your database does not grow forever and has known size. The disadvantage is that your database eventually loses old data. Munin works round this by keeping older data too but at lower resolution.

SQL is a generic database access/query langauge.

For this application you don't actualy need a real database at all: you can just write simple text files, in CSV or xml (or homegrown) formats, and use a pile of tools to analyse/process them. Logrotating those files is a good idea, to keep filesize sensible.
Logged

Wookey
KLD
Hero Member
*****
Offline Offline

Posts: 1340


« Reply #9 on: October 13, 2009, 09:20:33 PM »

Thanks Wookey, the RRD idea didn't quite appeal to me, so I didn't look properly into munin. Is it adjustable how much resolution you'd loose in the older data archived from / by munin?

Klaus
Logged
StBarnabas
Hero Member
*****
Offline Offline

Posts: 2089


St Barnabas Chapel (2009)


« Reply #10 on: October 13, 2009, 09:39:24 PM »

Klaus
data storage is cheap these days. Go for non lossy compression and if you must lossy. In my day job hundreds of  terabytes is entry level. This is a big problem with  cluster comouting raid arrays etc.  But as terabyte hard drive is under £100 these days the sort of data we are talking about here is not a major problem. I would also not worry about databases. Not needed for this sort of data
Logged


Gestis Censere. 40x47mm DHW with TDC3. 3kW ASHP, 9kW GSHP, 3kW Navitron PV with Platinum 3100S GTI, 6.5kW WBS, 5 chickens. FMY 2009.
KLD
Hero Member
*****
Offline Offline

Posts: 1340


« Reply #11 on: October 14, 2009, 09:39:53 PM »

Sean, thanks for the heads up re. amount of data. So, to start with I'll do away with a "proper" data base, and stick my data simply into a CSV file. The "date" question in Grace is solved. At the mo I'm gnawing at how to use the script language to perform the number crunching. Should be possible, somehow  Undecided

If only I was a little better (well, any good at all  wackoold) in writing my own little program ...

Klaus
Logged
wyleu
Guest
« Reply #12 on: November 09, 2009, 12:13:13 PM »

It's probably worth while doing the sql database route.
csv files are tempting but as they grow in size they tend to get sloooooooooooooooow, and unwieldly unless you set up some clever mechanism to rename them, archive them and then you have all the complication of searching for data across several (maybe hundreds) files in different directories.

SQL attracts a lot of mathematical analysis in the early stages of learning where learned types waffle on about normalisation and joins and other such detailed data analysis stuff but at the end of the day it's basically a file system that can Add data, Change Data, Search for Data and Delete data.
So if you have a table ( One chunk of related data) in a Database ( several tables and other related bit's and pieces ) you can search by an English like request.
So you'd set up a table

CREATE TABLE 'onewire_readings' ('measure_time' DATETIME, 'measure_sensor' NUMBER, 'measure_value', FLOAT);
This will probably be typed on some command line type application or better yet some form of GUI interface.

Now your little logging programme would need to connect to this database and that's down to the code you use.
It will probably involve loading a library of some sort and then using a command to establish a connection to the database and something called a CURSOR which points at the current record being considered.

You will then use your code to submit the SQL statement to the database to add a value.

INSERT INTO 'onewire_readings' ('measure_time', 'measure_sensor', 'measure_value')
VALUES ('2009-11-9 11:54:08', '0D5AE100000', 12.75 );

notice the quotes round the text and how it's not round the 12.75?, welcome to the wonderful world of databases.
This will write the value away and if the database is any good ( and most of them are) it shouldn't make too much diference if your writing the first or the millionth value ( yeah ,well some difference but certainly faster than CSV files ).

And that really is all your logging programme needs to do.

To read a value you use select;

SELECT * from onewire_readings;

And that will return ALL the values from the database in one long list. IT might not be quite what you want but there are times when you do want it.

You can be a bit more selective so

SELECT * from onewire_readings WHERE measure_value > 45; 
This will give you all readings that are above 45 degrees.

SELECT * from onewire_readings WHERE MEASURE_VALUE > 45 and  MEASURE_TIME between '2008-01-01' AND '2009-02-01'

For all Januaries hot days.

In this sort of stuff you don't tend to do too much deleting and updating unless your doing some form of data compression .

There are (sadly ) several different dialects of SQL ( MySQL, POSTGRESQL, ORACLE, SQLITE ) and they all have slightly diferent ways of asking the questions and adding the data. Especially around such throny issues of how they deal with dates. But the big advantage is pretty much any kind of programme will speak SQL and can do Select request. So you can use ODBC connections ( a form of Microsoft plug and socket mechanism ) to use EXCEL to enquire on your database AT THE SAME TIME as your logging programme is still adding to it. ( Sorry about the capitals you tend to use them a fair bit in SQL ,athou' they ain't required it tends to be the way its' done)

Don't be hung up on which particular database you use. 
For small ( 500M or so ) I use sqlite3 it's installed in python by default, it's easy to use and theres a stonking firefox plugin (SQLite Manager) which will allow you to do everything you want to do with a database from the warmth of the tools menu of your browser) It will run on windows,linux and Macs's and it doesn't require a lot of configuring of users as some of it's big brothers do.
MySQL is probably the de-facto in that logtemp can chuck out to it pretty easily. IT also runs on pretty much any machine you can mention, but it's SQL can be a little bit querky. I've used Postgres and Oracle as well, and they all do pretty much the same sort of thing. You wouldn't run a bank on sqlite but then you wouldn't probaby use Oracle to log a sensor every thirty seconds.

Stuff like backups and performance tools are all available, and it can probably be said that they all just work, which is not true of csv files as they get huge. Windows can have some awful problems with big files.

Give it a go. It's where you will almost inevitably end up, so it's worth investing a little time now rather than finding in a month's time it's all a bit unwieldy and you have to upgrade to a database with 30 days worth of carefully won records to integrate into your new system as well as getting the new system working.

Please feel free to ask any questions on this sort of stuff. There are lots of people who can help and we've all been there.
You will make mistakes but it's surprising how quickly it all becomes second nature, and you will realise there is some truth in the old maxim, there are two types of programmes; those with databases and toys.






Logged
KLD
Hero Member
*****
Offline Offline

Posts: 1340


« Reply #13 on: November 09, 2009, 03:19:34 PM »

Wyleu

Thank you very much for your pointers re. databases! It sort of confirms what I worried about handling larger amounts of data in csv files.

Since I'll try and run the initial data logging on a NLSU2 (aka slug), unslung to Debian, I need to be a little careful with the demand on resources. And as you said, for this application a very basic set of operations is all that is required. When I (very!) briefly  looked into the various sql dialects, I found the Wikipedia pages quite helpful. One of the things that stood out was that it claimed there that sqlite cannot handle dates?!?

AFAIU SleepyB runs a very similar setup already.

Cheers
Klaus
Logged
wyleu
Guest
« Reply #14 on: November 09, 2009, 03:43:28 PM »

I tend to do all my database handling through django ( www.djangoproject.com ) which removes you from the sql dialect debate.
SQLite may not do dates directly but it can most certainly handle real numbers so you tend to use functions like datetime ( in python another something I mention occasionally..... Ok all the bloody time ) to convert dates into a real number that will squeeze into the database easily enough, you then just place a wrapper round the calls which you'd probably do anyway for sanity checks and error checking.
it's horses for course really sqlite gets django going pretty quickly, it also builds commercial grade websites so you don't to worry quite as much  about being hacked throu' some grubby little website you working on yourself.

It's probably something you should consider ultimately running on some other box rather than your slug, and that of course has all the joyous aspects of how one caches data for update. This is a well warn path and we are now getting enough people walking down it to start to see more elements of commonality between our differing approaches rather than the differences we tended to concentrate on in the early days.

Databases make other things easy. For instance if someone makes a nice database structure describing one wire device types then we can all use that table to refer to the devices rather than having to come up with our own equivalents. So for instance at some long distant time a 30 tube array with one wire sensors could become a standard module to plug into a system with enough attached data to allow it all to just 'know' what it's meant to do with the data. That kind of stuff is really powerful. ( see wyleu rants passim).

SQL ain't wonderful and it does disappear up it's own posterior at several points  but it is a standard and it's worth supporting them where ever they appear.


Logged
Pages: [1] 2   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2011, Simple Machines Valid XHTML 1.0! Valid CSS!