Setting up Sheepdog Software's Weather Monitoring application "DS025"
version: 16 Nov 2009

Full details about obtaining the application are at...
http://sheepdogsoftware.co.uk/ssds025.htm

Apologies for the poor formatting of this.... would you rather I spent my time improving the application, or doing a polished manual?

The file was created with something like the "Notepad" app that comes with Windows (Textpad, from textpad.com)

It was uploaded with Terrapin

I did a test access with Firefox, then from the browser, did a "File | Save PageAs.

The result had carriage return/ linefeed problems... the breaks between paragraphs weren't there if I opened the file with Notepad. It opened fine in Textpad. It also loaded into ooWriter, OpenOffice's wordprocessor.... you need to use "Insert | File", though, not "Open"... because it is a text file.

Sorry... hope you don't have hassle. Or are happy just to read it in your browser!

===================================================================
THIS DOCUMENT SUPERSEDES THE HELP FILE DISTRIBUTED WITH THE PROGRAM
===================================================================

Enjoy!

New! Improved! Definitive instructions!

Built from a fresh start in November 2009.

========
  TOC
========

What you need... minimum hardware
What you need... minimum software
   ... with short form "setting up" information

The required DS025ini.txt file... what goes there
The optional DS025**2**ini.txt file... what goes there. (Stars
      just to emphasise difference in names. Actually: "DS020ini2.txt")

END TOC
=======

MINIMUM HARDWARE ---------------------------------------*****

Much of this is just to enable you to use the Dallas 1-Wire family of chips, upon which DS025 is built:

i) A DS1820-type temperature sensor, e.g. a DS18B20. This will be your "dongle", and your use of the software will be ties to this chip, so install it somewhere that will give it the best possible chance of always being visible to the software.

The software does not support 1-Wire hubs, by the way.

ii) An ordinary 1-Wire adapter between Microlan and host PC, be it one of those made by Dallas or from a third party. I like the iButtonLink USB adapter. Beware of the extra signals... including a voltage supply... on the contacts of the RJ-45, thogh. Easly worked around, or even useful... but be aware that they are there!

iii) Host PC: Program will, as far as I know, run on a Windows 95 machine. I currently use XP machines. Should, again afaik, work with Vista or Windows 7.

MINIMUM SOFTWARE ---------------------------------------*****

i) OS: see above. No Linux or Mac versions, sorry.

ii) Dallas 1-Wire Drivers. See....

http://www.arunet.co.uk/tkboyd/e1dsu.htm

... for details of obtaining, setting up those (free) drivers.

iii) I strongly recommend that you install either OneWireViewer or iButtonViewer. They are free, come from Dallas. They are utilities for checking that your MicroLan is working, and for exchanging information with the chips on it. (It is actually quite hard to set up the drivers without getting the OneWireViewer.) DS025 doesn't actually <i>need</i> either present, but there's no reason not to have them. (Running DS025 and one of the utilities at the same time will not always work, by the way. No harm is done to your hardware, but attempts to communicate with the MicroLan may be unsuccessful.

====
Once you have the above in place, use one of the utilites to make sure that the temperature sensor is "visible" to the PC, and make a note of its serial number. ("device address" in OneWireViwer terms. Sixteen characters, 0-9, A-F)

For more features, you send the serial number to me, and some money (PayuPal or other) and I send you the "key" that turns your DS025 on. You don't have to re-install, just edit the main ini file.

But I get ahead of myself.

At 11/09, things are less flexible than I would like.

Your data is stored in files which are in the root of your C: drive.

The main ini file, DS025ini.txt, must be in the same folder as the .exe file. We'll look at that file more closely in a minute.

A second ini file, ds025ini2.txt, at 11/09, must be in the following folder: C:\DS025. Again, I'll tell you what's in it in a moment. As you need a C:DS025 folder for DS025ini2.txt, you might as well put DS025.exe and DS025ini.txt there too, although you don't have to.

Sorry about the inflexible file location situation.

REQUIRED INI FILE: Ds025ini.txt  -------------------------------*****

You can create and edit this file with any simple text editor. Windows' "Notepad" will do... but do yourself a favor and get Textpad... from Textpad.com.

What goes in DS025ini.txt?

In general: The basic parameters to set up the operation of your weather recording software. No matter how you have the *DISPLAY* of the data set up, using the other, optional, ini file, you have to have this first ini file set up to "marry" your sensors to my program.

The first 26 lines must start with a lower case letter, in order, followed by a space.

In the following "Must have}}" indicates what must be on a given line. Anything in the text which is enclosed in curly brackets, {like this} is a description, so if you saw....

Must have}}Rainfall line {color name}

... it would mean that something like one of the following must appear on that line...

Rainfall line red
Rainfall line blue
... etc.

A word about line numbers: Sometimes computer people count from zero, making the first line "line zero". I will try to avoid refering to lines by number. When I do, I can't promise that I will always use the same numbering system. As humans and my text editor, the excellent TextPad (www.textpad.com), number lines using "1" for the first line, I will try to use that convention... but there may be scraps left of the Bad Old Days when I was using what is normal amoung computer programmers.

Just to add confusion to complication, at 11/09, the first line of the ini file had to have text declaring that it is line "zero".... I will be removing that in future editions of the program!

Line "a", the first line of the DS025ini.txt:
Must have}}aa DS025ini.txt file This is "line 0" (not line "1")
Note: the "aa" indicates the format used in the ini file.

Line "b":
At 11/09: Not used, and reserved for you! But at least a "b" and a space must be present. Put what you like here, after the b and the space. The program will not use it at some future date.ini file

Lines "c" and "d":
At 11/09, the rest of the line after the letter+space was not being used, but at least a "c" of "d" (As appropriate) and a space must be present. These lines may be put into use at some future date. (In other words, use is reserved for yet-to-be-implemented features, but in the meantime, you can use these lines if you wish.)

Lines "e" and "f":
These should either consist of the letter and a space, if you are using the program in its free demo mode, or they should consist of the "gibberish" I have sent you, if you have paid to have features beyond what the demo mode offers. The lines still start with "e" or "f" and a space, even when the rest of the line is the gibberish registration key.

Line "g":
At 11/09, this was not being used, but at least a "g" and a space must be present. This line may be put into use at some future date. (Use is reserved, in other words, but use the line if you wish, in the meantime.)

N.B. Many of the following lines have an exclamation mark (!) in them. The exclamation mark begins a comment. The comment should probably stay, but it can be edited or removed, as you wish.

Line "h":
After the space after the h there should be a digit to indicate which port, e.g. COM1? COM2? the adapter is on. Where there is no port number, e.g. if you are using a USB adapter, just put a 1 after the space after the "h".

Line "i":
On this line, you specify the adapter type. Use....
1 for a DS9097 with no suffix, or a DS9097-E
5 for a DS9097-U
6 (I think!.. let me know?) for a "true" USB adapter.

If you are using an iButtonLink or similar USB adapter, the system "sees" it through a "virtual" serial port. Use 5 for the adapter type code for an iButtonLink adapterm and set the "serial" port number according to where the iButtonLink's "virtual serial port" is. (My Computer | Properties | Hardware | Device Manager is the place to go to find out.)

Line "j":
At 11/09, this was not being used, but at least a "j" and a space must be present. This line may be put into use at some future date. (Use is reserved, in other words, but use the line if you wish, in the meantime.)

Lines "k" to "w":

Each of these lines is made up from...

1) a letter (k,l,m,n....)
2) a space
3) an "e" or a "d" for "enabled" or "disabled"... the e or d causes the device to be enabled or disabled. No attempt is made to read it, and no results from it appear on the display.
4) a 16 character string made of digits and/or letters from the set a,b,c,e and f. (In other words, a 16 hex character number). This string should be the same as the "device address", or serial number or "ID", of the chip you want to do a particular job. One chip's number may appear on more than one line, by the way. (Common for counters (DS2423) where one chip has two counters within it.
5) a three character code. It must always be present. (Use "zzz", unless told not to. The code, in some cases, affects the way the specified chip is used.
6) (Optional) Following the three character code, you can put what you like on the rest of the line. This can be helpful for reminding yourself about what or where a chip is, what it is monitoring, e.g. "Indoor temperature", "Lightning", "Rainfall".

So much for the general rules for lines "k" to "w". Now for some information specific to each line.

Note: While it would be possible to connect the chip specified on line "p" to something other than a rainfall detector, you can only "bend" things so far. The rainfall detector "feeds" a counter chip, so if you wanted to monitor something else that a counter chip can monitor, fine, but don't expect, say, to read temperatures via the "p" channel.

Lines "k","l","m","n", and "o". These all are for temperature sensor chips. The three letter code at the end does nothing at 11/09. You can use DS1820s or DS2438s. The chip specified in "k" is read more frequently than the others.

"l" is special... if you fill it with...

l d0000000000000026zzz

... and make e and f just lines with those letters, followed by a space, then
... then the program will run in demo mode, reading temperature on the chip specified in line "k".

Several of the following lines are for specifying DS2423 counter chips. Each has two channels. If you put "zzz" after a space after the chip's ID, then the "page 14" counter (or "page 0", OneWireViewer) will be read. Use "zzy" to read the other counter.

Each line is nominally dedicated to a particular meterological event. There is nothing to force use to use the sensors for these events. There is even a mechanism for changing some of the labels, both on screen and in the data files. But sticking to the intended use for each channel eliminates some ways for things to go wroing!

Line "p" is for a DS2423 counter chip. It was intended to monitor rainfall
Line "q" is for a DS2423 counter chip. It was intended to monitor windspeed
Line "r" is for a DS2423 counter chip. It was intended to monitor lightning
Line "s" is for a DS2423 "battery monitor" chip. It was intended to monitor barometric pressure
Line "t" is for a DS2423 "battery monitor" chip. It was intended to monitor humidity
Line "u" is for a DS2450 ADC chip. It was intended to monitor wind direction.. but I've never got this working!
Line "v" is for a DS2423 counter chip. It is for an "On/Off"
Line "w" is for a DS2423 counter chip. It is for an "On/Off"

(The last two, the "on/offs" use a counter chip connected to a pulse train which is present when the monitored device is "on", absent when it is "off". (The device might be something a simple as a door, with suitable electronics, which delivers a pulse train when the door is open, doesn't when it is shut.)

<!--More on this at...-->

Lines "x","y" and "z":  at 11/09, not yet in use, but reserved for future enhancements.

Following line "z", the file can hold any comments you think will be useful to you.

SECOND, OPTIONAL INI FILE: Ds025ini2.txt ----------------------*****
                              N.B. ^  ... the "2" in the name


In addition to DS025ini.txt, with the main "set up" information, there is a second ini file, DS025ini2.txt. At 11/09, this needs to be in C:\DS025... sorry. The first file is mandatory. The second is optional.

That file has the following elements. They are all optional, defaults will be used if you don't specify a value for something which can be set in DS025ini2.txt. Indeed, the whole file is optional!

Lets start with something quite simple....

If your DS025ini2.txt has the following....

[FieldLabels]
;Do not put spaces after tture channel names to create gap
;    before (F) or (C) units designator...
;    Delphi will remove them.

;By the way: The keys have "f-ell" in them, not "f-one". You can
;    use FL, if you are worried that you might slip and use
;    "f-one" if the ell is in lower case, the way I have it
;    in most of the examples below.
p0FL=T0
p1fl=T1
p2fl=T2
p3fl=T3 
p4fl=T4 
p5fl=RF
p6fl=WS
p7fl=LT
p8fl=BP
p9fl=HM
;;;p10- wind direction- not settable by ini file
p11fl=OnOff1
p12fl=OnOff2

... then the labels in the "Numeric display" window on the screen when DS025 runs will be "T0", "T2", etc. These abbreviations are for...

Temperatures "0", 1,2,3 and 4,
Rainfall
Windspeed
Lightning
Barometric Pressure
and...
Humidity.

You can, of course, subject your sensors to different phenomenon... but if you consult these assignments, you will get a sense of the sort of software behind each channel. Rainfall, windspeed and lightning are monitored by counters, barometric pressure and humidity are monitored by a ADC inside a DS2438. The temperature channels are dedicated to chips dedicated to temperature sensing, like the DS1820, but they can also be attached to a DS2438... but boards carrying DS2438's often produce a little heat of their own, introducing errors into the temperature readings. However, for some purposes, the errors are not significant... usually, the board heating just introduces a small and regular offset from the "true" ambient temperature.

a) In DS025ini2.txt, ALL of the "switching", "initializing" of things setable via DS025ini2.txt file is done via the Windows ini file system of having "sections" and "keys". In this example, "[field labels]" defines the start and identity of the section. The squareds brackets do that. The name inside the square brackets was chosen by me, and is "set in stone" inside the code of the application.

Following each section header there are "keys"... in this case, "p0fl", "p1c", etc. And following the keys, an equals sign, and the value you want that key set to.

Note that regardless of whether the key has a numeric value, e.g. p0=38, or a string value, e.g. fwp=C:\, you do not enclose the value after the equals sign with any sorts of punctuation. Not quotes. Not single quotes. Nothing.

b) The example shows you the flexiblity of DS025. While I always use channel 5 for windspeed, you can connect different things if you wish to, Suppose you were monitoring the life of a hamster... you might put a sensor on the exercise wheel in his cage, and DS025 could display how fast the wheel was turning, in which case you might want the number labelled "EW", for "exercise wheel". (The "p", by the way, comes from "parameter", another way of saying "channel".

c) A line with a semi-colon at it's start is ignored by the Windows ini file system. This is very helpful, as it allows you to insert comments to yourself in your ini file. It also makes it easy to "switch off" something without deleting the whole reference.

d) Whatever you call them, the idea of channels, aka parameters is important to your mastery of DS025. Internally, at a fundamental level, the application doesn't care what is affecting the sensors attached to it. Internally, the application "thinks" in terms of channels. Each is set up to handle a certain type of sensor, so there are limits to the application's flexibility, but you can do a lot of messing about with the name on the display of the "things" being monitored.

Besides putting a graph of your sensors' readings on the screen, DS025 records the data in a file that can be read by a human, or passed to another program for processing. I once printed a graph of the outdoor temperature for the past three months from such a data file. Inside that file, for the moment, and likely future, the "names" of the channels are locked. So, for instance, data from channel 8 is "tagged" "hm", from humidity, although you might be looking at some other analog value on that channel. Sorry! There are reasons for the internal inflexibility. (See DatafileTags)

So, we're off to a good start, I hope you agree? Here's another section:

_______________________
Section [ChannelColors]

Sample from a working DS025ini2.txt....

[ChannelColors]
;Express color as 6 hex character, RGB
;E.g. FF8000 means full red, half green, no blue
;(FFFFFF is WHITE, 000000 is black)
;==Default values for p0-p4 are quite nice...
;==rem out the p0-p4 lines here to see them.

;(Before 18 Nov 09, the values had to be expressed
; in BGR terms. To facilitate things for existing
; customers, with ini2 files set up in the "old days",
; it is allowed to prefix a 6 character BRG value
; with an "s" ("special") to allow it to be used.
; I.e. BGR sFFC000 will be treated as RGB 00C0FF.
;(There would be no reason to use "s" values with
; a new ini2 file.... the feature is present JUST
; for the convenience of existing customers. They
; will have to edit their ini2 files, inserting
; "s"s.

;p0c=FF0000
;p1c=00FF00
;p2c=000000
;p3c=00FF00
;p4c=000000
p5c=000000
p6c=8000ff
p7c=ffff00
p8c=00ffff
p9c=804040
p11c=4444CC
p12c=88FF88

Note that the application has quite nice default values for the temperature channels, at least, which is why I "remmed out" the lines above for setting the colors on those channels. ("Remmed out" is explained in a moment.)

Before we look at more specifics, a general detail, and a little piece of advice:

The detail: The first line of the file must start "abDS025ini2"

(If you started using DS025 before the middle of 11/09, and you upgrade to a current version, you will have to edit your DS025ini2.txt file. Remember: All of the settings in that file are optional, so it won't be a Great Big Deal to make the edits. The application will prompt you to make the necessary edits.)

The advice: Use the first few lines of the file to describe what it is, and to keep a "version" id. So, for instance, you might want to put the folling in as the second and following lines...

secondary ini file for DS025, weather monitoriing program
version: {date}
See http://sheepdogsoftware.co.uk for further details.

I would also be inclined to include the following at the start of the file, to remind myself that DS025 only looks at the ini file once, while starting up, and the little "gotcha" that catches me again and again....

;Program (DS025) must be stopped, restarted if changes made to
;  this ini file... it is only accessed as the program launches.
;  (Eventually, it may be accessed as DS025 shuts down, too.)
;  If you are working on new ini2 settings, remember to SAVE
;  the file from your editor before restarting DS025!
;

(Semi-colons help distinguish "remark", or "comment", lines from the "active" lines in the ini file. They also, at the start of a line, "turn off" a key, turning it into a mere remark, so, while.....

p0c=0000FF

... would make the first channel display in pure blue....

;p0c=0000FF

... would be ignored by the program. The line has been turned into a remark, which is why putting in a semicolon like this is sometimes called "remming out" a line. Dreadful English! (The turning of a noun into a verb is bad enough... it weakens the language by introducing more ambiguity... but at least people who do it usually eschew an abbreviated version of the word they are impacting!) (Yes, I was being ironic in my choice of verb there.)

=============================

If you set up DS025 before 11/09, you may have, within your DS025ini2.txt, scraps from older, less tidy days.

Read what follows about "the old days", whether you are an long term user or not... it sets the stage for what follows.

The following lines, at first, look a little like Windows ini file section/ key data.... While the following has been written out of the current DS025, it remains here as an example of how things used to be done.

[wp1spa]0,0,799,370
[wp2spa]0,342,799,83
[wp3spa]0,249,799,270

The square brackets makes it look like we are using "sections" and "keys"... but we aren't, really. There are no keys.

These three lines were quite important. They determined the size of the windows when the display was launched. (The applicatoin doesn't "remember" changes you make by dragging things around, by the way.) "wp" derived from "window position". The "1", "2", and "3" refered to the three windows that the application puts on your screen. (The "sp" stands for "set position") Normally, the three windows overlap, and must do so in the right order to give a good result. Happily, you only needed.. and this still applies... to click on the "Restack" menu item to get things back to the layout defined within the application, or (if the relevant lines are present) defined within DS025ini2.txt.

The three windows (still) are:

1: The main graph and menu window.
2: The window displaying recent error messages.
3: The window displaying the sensors' most recent readings, as numbers.

What were the numbers in each of the configuation lines?

They were, in order, the x-coordinate (left-right) of the upper left hand corner of the window, the y-coordinate of the same corner, the width of the window, and the height of the window. All are expressed in pixels, the first two measured from the upper left of your screen, with the numbers rising as you go across the screen for x coordinate, and rising as you go DOWN the screen for the y-coordinate.

So far so good? Good! Because now we come to....

[wp1spb]50,0,300,280
[wp2spb]50,300,400,80
[wp3spb]50,500,500,80

Very like what we've just discussed, but note: The 6th character of the "key" is a "b" this time, whereas it was an "a" previously. If you've tried the "Restack" menu item, you should recall that it offered to restack the DS025 windows according to "Scheme A" or "Scheme B". So, I hope you can guess, the three lines above set the position and sizes of the windows under "scheme B" stacking.

(If you think it is a lot of work to grasp just to figure out how the ini file works, spare a thought for me and the work it took to make these features function!)

(By the way... lines like the above can be "remmed out" by putting a semi-colon(;) in front of them. This is like the remming out of Windows ini file elements, sections or keys, with a semicolon.)

Since mid 11/09, the two schemes, A and B, for the sizes and postions of the windows have been set with....

____________________
Section: [WindowPosnsAndSizes]

Sample from working DS025ini2.txt file. The numbers mean what they did before... aren't you glad you struggled through the above? The information is just "fed" to the application slightly differently.

[WindowPosnsAndSizes]
;Introduced 15 Nov 2009
;Two schemes of window layout... "A" and "B"
;Three windows in either case: Graph window, Errors list window,
;   readings as numbers window.
;Four numbers per window. Left side (x-coordiante), top edge (y-coord, measured
;     from top of screen as zero, bottom a larger number), width, height.
SchemeAW1=0,0,799,370
SchemeAW2=0,342,799,83
SchemeAW3=0,249,799,270

SchemeBW1=100,0,799,370
SchemeBW2=100,342,799,83
SchemeBW3=100,249,799,270

;(The old system based on lines like "[wp1spa]0,0,799,370" was cut out
; of the application in November 2009)


====
So! You've seen the two sorts of "stuff" that could once be present in DS025ini2.txt. And you have some idea about "channels", aka "parameters". Rejoice in the work I've done to write out the "old style" initialization codes... it means that a lot of what follows has been trimmed down...

Now we're going to look at some more DS025ini2.txt possibilities. These are more fun than the ones we've been looking at. And remember: the whole DS025ini2.txt file is optional, as are any of the things which can be in it.

Just before that, a little diversion....

Suppose that in a different application, a fully used ini file looked like...

[SetColors]
p0=red
p1=blue

[SetSpeeds]
p0=45
p1=85

[SetPaths]
p1=C:\
p0=MyDocs

And further suppose that someone came along who, starting from the above, wanted to go back to the default speeds. He/ she might just rem out the section heading, thus....

[SetColors]
p0=red
p1=blue

;[SetSpeeds]
p0=45
p1=85

[SetPaths]
p1=C:\
p0=MyDocs

Do you see the potential problem? When the computer comes to look at the [SetColors] section, it may well see TWO p0's, TWO p1's "under" that section. (If it does, it will pay attention only to the first one it sees.)

Moral of story: If you are going to rem out a section, it might be best to rem out all the keys in that section, as well as the section heading, e.g....

[SetColors]
p0=red
p1=blue

;[SetSpeeds]
;p0=45
;p1=85

[SetPaths]
p1=C:\
p0=MyDocs

(Although, if the key names aren't the same in different sections, in many cases you'll get away with just remming out the section header.)

There's never any harm in "leaving behind" a section header, even if all of the keys for it are remmed out, e.g....

[SetColors]
p0=red
p1=blue

[SetSpeeds]
;p0=45
;p1=85

[SetPaths]
p1=C:\
p0=MyDocs


===
Back to the Good Stuff.

The "scaling" and "offset" settings... 

These are tremendously useful. In the old days, commands like the ones for windows stacking were used. Again... read the "old days" stuff as a preface to "how we do it now".

Here's an example of the OLD way to set scalings and offsets:

[p0OffS] 45, .1

That would have affected the way the graph for parameter (channel) zero, usually called "T0", for first temperature, is displayed.

Change the 45, and you moved the whole graph up and down the screen. (Anything that spills over the top simply wraps around to the bottom, by the way.)

Change the .1, and you changed the expansion or compression of the graph. Use positive numbers only for this second number. The bigger the number, the flatter the graph will be.

At 11/09, I can't be sure that the new equivalent commands work for all of the possible channels, but I think it does, apart from the (non-working at 11/09, anyway!) wind direction channel. The general form of the old command was....

[pXOffS] n1, n2

... where X is replaced with a digit, and n1 and n2 are numbers.


(The offset and scaling factors are used for special purposes with some modes of OnOff displays, by the way.)

How it is done today (11/09 onward).....

The relevant section is [LineOffsetScale] and the keys, with example values, are....

p0m=10000
p0a=0

p7m=1000
p7a=1
p8m=2000
p8a=100
p9m=10
p9a=400

The digit(s) identifies the channel affected, the "a" key determines what to add to the y coordinate of any point before plotting it, and the "m" key (m for "multiply") determines whether the line should be "stretched" or "squashed" (in the vertical direction). If the "m" value is set to 100000, then the line will not be streched or squashed. A larger number stretches the graph out, a smaller number squashes it. Do not set an "m" value to zero. (That would squash any line FLAT, if you think about it.)

With the numbers shown, the channel 7 line would plot any zeros at the bottom of the panel, and "spread" the plot points (vertically) with no squashing or spreading.

The channel 8 line would plot any zeros farther up the panel, and squash the graph.

The channel 9 line would plot any zeros even higher up the panel, and spread the graph.

Put in some numbers, see what you get. Tweak your numbers. Remember that too big numbers will cause the graph to wrap, so what you see can sometimes be misunderstood. It does work.. with a little patience!

The "m" value, when applied to an OnOff channel (if the channel is in some plotting modes) designates the height of the step between the display of "on" and "off", and it is expressed IN PIXELS... i.e. 10 would be about the right value to use.

The OnOff display works PRETTY well at 11/09. You may get an inappropriate vertical line in the OnOff plot, under mode 0, which I think at 11/09 is the only one you can access.... an inappropriate vertical line at the time you boot the application. Happily, these false lines don't get into the datafile, so when you re-start the app later, the old false line won't appear... although you MAY get a (temporary) new one!

=========
Fancier and fancier, said Alice... or someone...

_______________

Section: [enis] Stands for "ENable Image Save". (Pronounced "En-iss", by the way.)

Permitted keys:

fwi, which stands for "Far Watch Image".

iri, which stands for "Image Resave Interval".

<a href="link" target="_blank">Elsewhere</a>, you can read about my FarWatch system. In a nutshell: It allows you to monitor a site with always on internet from anywhere you can get to an internet terminal... without having to pay for anything. Well, except the 1-Wire stuff you already have if you are reading this. (And FarWatch doesn't <i>need</i> that! But if you have it, you can see the graph produced by DS025... even if you're only running the demo version, I think.)

You don't need a "static IP address", by the way, if you know enough to worry about that. And if you don't, you don't need to worry about what the thing you don't need is.  :-)

If you aren't running FarWatch, you don't need the [enis] section. Just put a semi-colon in front of it any the keys, so you remember it is there, if you ever decide to use it.

If image saving is DIS-enabled, by the absence of an "iri" key in the [enis] section, or if iri=0. If iri is >0, then DS025 will, from time to time, save the graph it has produced, as a JPEG. That image can then be incorporated into a page of HTML. The page of HTML can even be "static", as long as the computer it is saved on is set up to be a web server. It achieves a crude "dynamic" nature through the changing of the contents of the jpeg it displays. (Not rocket science. And remarkably useful, for somehting so simple. That is all explained at my FarWatch page.) Although the PAGE may be static, when you change the contents of the image file that the page displays, your visitors see different things on different visits. Brilliant! (Can you say that in a Billy Connolly voice for me, please?)

For fwi, a value like DS025img.jpg is suitable. Any sensible file name is fine, you just have to coordiante the name you use here, and the name you put in the html that users will access. The folder where it will be saved is determined elsewhere. Read on.

For iri, you supply a number. That number determines the number of seconds between the re-saves of the image. I tend to set iri to 6000... which means one save every ten minutes. If you make the number too low, you cause unnecessary wear and tear on your disc, and you may make the system so busy that it doesn't have time for the other things going on. I wouldn't set iri below 60. Make iri too high, and some visitors to your site will see "outdated" information.... although it is hard to see why even 18000 would be too high. Do temperature changes in the past half hour really matter to any user? (As I mentioned earlier: Set iri to zero, and you switch image saving off. The system will set it to zero if you don't supply the key, or don't supply the whole [enis] section.)

_____________
Section [sfw] Stands for "Simple Far Watch"

Allowed keys:

hsi: Html Save Interval
fwp: Far Watch Path
fwh: Far Watch Html file name

What is "Far Watch"? See the notes in the [enis] section notes, just above here.

The presence of an "hsi" key turns on the saving of a small page of HTML from time to time. If hsi is set to 6000, that page is saved every ten minutes (6000 seconds) (The same considerations as discussed in respect of the [enis] iri key pertain to the "right" value to use for hsi.)

fwp will be set to something like....
C:\apache\httpdocs\
It should end with a backslash. It sets the path to the folder where you want the html file saved. It should point to the folder from which your web server serves html to members of the public who access your system. (Again, there is help with this in the FarWatch set up instructions.)

fwh will be set to the name of the html document you want created by DS025. It may well be best to specify "index.htm", as this will make it easier for users of your service to fetch the page.

The page that DS025 creates has, in addition to the graphic showing the most recently saved state of your sensor readings, a small table reporting the T0 and T1 temperatures over recent time. This is present so that a "FarWatch Watcher" can automatically monitor the Far Watch provided information, and sound an alarm if the temperatures get below what they ought to be. The temperatures are saved in C or F depending on what units the graph is using.

The next thing might seem like a trivial bit of cosmetics... but when you realize that you could have a separate application running concurrently in the FarWatch machine, an separate application which, like DS025, from time to time CHANGES the contents of a JPEG on the hard disk, perhaps you'll begin to see the possiblities the following opens up....

_______________________
Section: [SecondImage]

(The provisions of this section of the ini file are ignored unless you have purchased the "key" to unlock DS025's advanced features.)

Allowed keys, with sample values:

jpg2name=landscape.jpg
jpg2caption=The view from my office
jpg2alt=image of a view
jpg2width=85

The example above would give rise to two lines in the HTML page created by DS025 saying....

&lt;center&gt;&lt;p&gt;The view from my office&lt;/p&gt;&lt;/center&gt;
&lt;img src="landscape.jpg" alt="image of a view" width="85%"&gt;

That's it for Far Watch related things!

______________
Section [Control2405]

Allowed keys:

enable (should be set "y" or "n", for "yes" and "no"
id (should be set to a 1-Wire chip id ending in "05", the family ID of the DS2405 chip.


This section may appear in some demo ini files. The code to use the two values set by this section is not yet finished in any versions of DS025 released as of 11/09

____________________
Section [BarGraphs]

The applicaton will process any command in the form....

pNbg=on

"N" being a channel number. So the following are allowed...

p0bg=on
p9bg=on
p12bg=on

If an "=on" isn't present, the application will treat that as an "=off".

Only some of those commands will have any effect, however.

"The plan" was to have bar graphs, if the user wanted them, for the data from some sensors. At 11/09, I make no promises as to whether any of them work, and if they work, how WELL they work! MAYBE working... bar graphs for windspeed, rainfall, lightning. You might find that OLD data, re-plotted from a file, produces sensible bar graphs, whereas new data doesn't produce good bar graphs.

This is not a priority at the present time... sorry. Please do write me about almost anything else, but, unless for some reason you cannot make anything "bar graph" that you don't like "go away", don't write to me about bar graph things?

___________________________________
Section [VariousOne]

For setting... surprisingly enough... various things.
Can be set to whole numbers from 0-255 inclusive.
Default value, i.e. what the computer will use if you don't
put a key in for a given channel: 0

For channels 11 and 12, it sets the plot mode.
... Plot modes (ch11 and 12 only...)
    0: A "stepped" line, with vertical lines between "on" and "off" levels
             (Mode 0 is the default mode.)
    1: A "stepped" line, no vertical lines between "on" and "off" levels
    2: Like a simple counter channel, e.g. like rainfall.
    
(Mode 0 isn't working perfectly yet (11/09)... you get some false "counter changing" spikes around the time you boot, and sometimes some in the "reloaded history"... and maybe even some during data logging... but it works MOSTLY....)

It is a fact of the system's design that while you CAN detect a brief period of counter-value-change in a mostly not-changing counter, you CANNOT detect a brief period of not-changing in a mostly changing counter. If you are monitoring something that has extended "on" and "off" periods, and you have interspersed circuitry to feed a train of pulses to your counter when what you are monitoring is "on", then you should have no problems. However, if what you are monitoring has very extended periods in one state, and just brief interludes of being in the other state, you need to arrange the interspersed circuitry so that normally the pulses do not go to the counter, and only when the monitored device is in the rare conditions do pulses go to the counter. I have a circuit in prototype form to provide the pulse-train. PCB227. I've had a working PCB with that circuit on it playing nicely about 10 years, as of January 2020. There is no "ready-made" board for PCB227 at 1/2020... but you can see the sorts of boards I make at...

http://sheepdogguides.com/elec/pcb/PcbCatalog.htm

... and I might be encouraged to Get My Act together, produce a board for PCB27's circuit, with a little encouragement.

--------------
Key examples...

p11v1=2
p12v1=1

___________________________________
Section [VariousOne]

Again for setting... surprisingly enough... various things.

Can be set to whole numbers from -2147483648 to 2147483647.
Default to zero.

The code to init them, and to allow changing what they're
    set to has been in DS025 since 14Nov09... but the code
    to USE them is still to be written.
For channels 11 and 12, it WILL be used to set the 
    "ignore as random noise" threshold.


Key examples...

p11v2=-100
p12v2=49999

___________________________________
Section [WriteThreshold]  <<NOT YET (11/09) IN OPERATION

At 11/09, I don't think write thresholds have been made alterable via DS025ini2.txt, yet.... although some channels MAY have write thresholds in operation. A write threshold stops the program from writing a line to the data log every time the number from a sensor changes. In some cases, any change will be logged, but in others, the change must exceed a certain threshold before a new entry is made. (The graph will, however, display every change... until the OnOff channels, if in display mode 0, are given the mechanism I plan for them which will cause them to leave brief events unreported. To go another level "down", I must also explain that what I just said only applies to the graph for events since the application was last started. When the application is started, the graph panel is filled with lines drawn according to the numbers in the datafile. When those numbers have been kept manageable by the enforcement of write thresholds, the line of plotted-from-the-datafile may be less "fuzzy" than the line was when it was originally drawn. (A datum will be recorded for each channel for each "x" column of the graph, though, whatever the write threshold.) 

Allowed keys....

p0wt
p1wt
p2wt... etc.

As mentioned elsewhere, DS025 creates a datafile recording in machine readable form the data it reads from the attached sensors.

However, if every datum were recorded in the datafile, that file would rapidly become huge. So, taking the temperature sensed by T0 as an example, the temperature is written to the datafile if....

a) A certain amount of time has passed, even if the temperature is unchanged....
... or....
b) If the temperature changes by more than a certain amount, even if very little time has passed.


The plan for the [WriteThreshold] section is....

;If channel is measured to fractions, e.g. tture, the change
;      is expressed in thousandths. E.g. to get changes
;      of a half degree noticed, specify p0=499
;These values, after allowing for milli-units where relevant,
;     in the units used by the datafile... I think...
;     beware confusion over ttures, as they are recorded
;     in the datafile in centidegrees
;Be especicially careful over BP, as I didn't have a
;     BP sensor when working on this.
;PARTLY implemented... I think... 6 & 7 & 9 used in calcs.

______________________
Section [DatafileTags]

NOT YET IMPLEMENTED.... AND I DOUBT IT WILL BE... IT WOULD BE PROBLEMATIC, for one thing, in the complex coding which would become necessary for reloading recent history to the screen from the datafile.

SO WHY IS THIS HERE?

1)The "examples" below show you the tags hard-coded into the application at 11/09, and...

2)In case you have seen mention of a way to change the datafile tags in some old document floating around the net.

Besides putting a graph of your sensors' readings on the screen, DS025 records the data in a file that can be read by a human, or passed to another program for processing. I once printed a graph of the outdoor temperature for the past three months from such a data file.

Be careful, though. If you connect a wind speed sensor to channel 5, and set p5fl=EW in [FieldLabels], and p5=xx in [DatafileTags], you are going to confuse yourself! The computer will still read, display, and record the messages from the sensor... but the labels in different places will be confusing!


[DatafileTags] <<NOT YET (11/09) IN OPERATION
;Altering these puts you at risk of not being able to use
;     utilities which access the datafiles.
;Be sure all tags are unique, and only 2 characters long.
;Do not use: ss, cm, wo: reserved for other uses
;(Program checks that you have obeyed these rules.)

;The key names must end "f-ell", not f-one", by the way.
;They are case insensitive, so "P0FL=" will work, too, and
;   only the "zero" could cause problems. (It must be a zero,
;   not an "oh". Ah, the joys of the ambiguity in English!

p0dt=t0    <<tags on lines in datafile. (11/09)
p1dt=t1     (cannot be changed with ini2, or by
p2dt=t2         anything else)
p3dt=t3
p4dt=t4
p5dt=rf
p6dt=ws
p7dt=lt
p8dt=bp
p9dt=hm
p10=wd
p11dt=b1
p12dt=b2



===========
Thank you for your interst.
Further details at....

http://sheepdogsoftware.co.uk/ssds025.htm