support for digitemp temp (and other) sensors

[frollic]

1-Wire temp (and other values) sensor application, reads the temps of USB based thermometers.

there are three binaries - digitemp_DS2490
digitemp_DS9097
digitemp_DS9097U which are used for different kinds of serial port adapters. http://linux.die.net/man/1/digitemp

the adapters all have an unique ID (like a MAC address), and are (at least in my case) accessible via a /dev/tyyUSB? device.

The application only returns a temperature value, when ran with the option -o%.2F in Fareheit, and -o%.2C for Celsius.

[root@atlantis ~]# digitemp_DS9097 -c ./.digitemprc -q -s /dev/ttyUSB0 -t 0 -o%.2F 79.36 [root@atlantis ~]#

[root@atlantis ~]# digitemp_DS9097 -c ./.digitemprc -i DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane GNU Public License v2.0 - http://www.digitemp.com Turning off all DS2409 Couplers . Searching the 1-Wire LAN 28ECEDC7050000F6 : DS18B20 Temperature Sensor ROM #0 : 28ECEDC7050000F6 Wrote ./.digitemprc

[root@atlantis ~]# digitemp_DS9097 Error! Not enough arguements.

DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane GNU Public License v2.0 - http://www.digitemp.com Compiled for DS9097

Usage: digitemp [-s -i -I -U -l -r -v -t -a -d -n -o -c] -i Initalize .digitemprc file -I Initalize .digitemprc file w/sorted serial #s -w Walk the full device tree -s /dev/ttyS0 Set serial port -l /var/log/temperature Send output to logfile -c digitemp.conf Configuration File -r 1000 Read delay in mS -v Verbose output -t 0 Read Sensor # -q No Copyright notice -a Read all Sensors -d 5 Delay between samples (in sec.) -n 50 Number of times to repeat 0=loop forever -A Treat DS2438 as A/D converter -O"counter format string" See description below -o 2 Output format for logfile -o"output format string" See description below -H"Humidity format string" See description below

Logfile formats: 1 = One line per sensor, time, C, F (default) 2 = One line per sample, elapsed time, temperature in C 3 = Same as #2, except temperature is in F

2 and #3 have the data seperated by tabs, suitable for import

    into a spreadsheet or other graphing software.

    The format string uses strftime tokens plus 5 special ones for
    digitemp - %s for sensor #, %C for centigrade, %F for fahrenheit,
    %R to output the hex serial number, and %N for seconds since Epoch.
    The case of the token is important! The default format string is:
    "%b %d %H:%M:%S Sensor %s C: %.2C F: %.2F" which gives you an
    output of: May 24 21:25:43 Sensor 0 C: 23.66 F: 74.59

    The counter format string has 2 special specifiers:
    %n is the counter # and %C is the count in decimal.
    The humidity format uses %h for the humidity in percent

Seems you can't specify what sensor to read based on the hex address, only by serial port.

Would be great if this could be implemented into monitorix.

;)

TIA

[frollic]

... or a generic monitor that would allow execution of an user difined binary/script and simply interpret the returned data (for instance temps), and treat them like any other monitorix graph.

[mikaku]

@frollic,

I don't understand clearly how it works, sorry.

In the Digitemp web site there is a graph that shows temperatures from different parts of a house (office, basement, garage, etc.), how is supposed to extract such different values having only a /dev/ttyUSBn device?

Probably I'm missing something in your explanation.

Also, I can't have such binary here so it will be really difficult to implement it. Just let me know.

[frollic]

.... details :)

You're not. Monitorix would simply collect from the sensors attached to the system it was running on (but there are ways of extending USB over a LAN, if one would want to do that).

You don't really have to have the binary.

If you're creating a "generic" interface, just write a script that will return a random temp (or whatever numeric value) to monitorix when executed. Whatever is executed within the script isn't really of your concern, as long as you get your values back. Using that, you can monitor pretty much anything, as long as the return values can be used by Monitorix.

[generic] [list] 0 = ttyUSB1 1 = ttyUSB2 [/list] [desc] ttyUSB1 = temp A ttyUSB2 = temp B [/desc] [script] 0 = /usr/local/bin/tempUSB1.sh 1 = /usr/local/bin/tempUSB2.sh [/script] [alerts] max_0 = 50 min_0 = 10 max_1 = 10 min_1 = -10 alert_script = /usr/local/bin/email.sh [/alerts] [/generic]

Don't know if that made any more sense ;)

[frollic]

@mikaku:

Any more thoughts about this ?

thanks frollic

[mikaku]

@frollic,

Sorry I still don't understand how to start collecting values and from where. In all, I'm completely lost. Also, I don't know what type of values Monitorix will get; integers, percentages, with the sign character (or not), etc.

I don't even know from where to start. Perhaps if you can provide an example ...

[frollic]

:)

You're only collecting return values from script X you execute, whatever happens within the script is not of monitorixs' concern, as long as you get your value back in the correct format, and within preset limits, you shouldn't need to care ...

If you set clear rules around what to report back, separators, etc, you should be able to collect/log all kinds of numeric data, in my case, the boiler in our basement.

Ignore my first post, and just focus on the one from Sep 18th ;)

[mikaku]

Ah! :)

If I understand you correctly, what you want is a generic module to monitor your own project that consists of a set of values that Monitorix doesn't know what they are and which relationship have with each other.

I believe that this kind of generic module should be made using well known guidelines in order to be able to monitor whatever people want: temperatures, pings, hits of anything, etc. Of course this is not trivial because it involves creating some type of template where user defines the class of each value and its relationship with the rest in order to put them in the same or in separate graphs.

Well, I don't like the idea of start making graphs to monitor personal projects, I'd prefer to create graphs that can be useful for more than 1 person. You have the source code, so you should be able to make your own module. ;)

Anyway, in your case you could start thinking on an standard template that can be used for anyone to monitor anything, that would be indeed the base for this generic module.

If you success on this I'd be more receptive to create such a generic module. ;)

[WildPenquin]

Hi,

I just stumbled on this while looking for if there is any improvements made to sensor handling.

Just want to point out that you could already use the \<gensens> module for this in conjuction with another script / daemon you write yourself.

I.e. have the script poll (say, every 10 seconds; choose an interval that suites you) and write the results to files. Then point gensens to these files.

Hacky, but so would be having a separate command for each data. Indeed, writing a personal module would be more clean and approprieate for anything more advanced!

[mikaku]

@WildPenquin,

You're right, gensens module could read values from anywhere, as long as they are consistent.

I think that anyone can create a script that stores the values on a file and then configure gensens to read the results, all this without modifying any line in the Monitorix code.

I mean, people know better than me how works the device(s) they want to monitor. Moreover, they have the device(s) physically so it's easier for them to create the right script.

@frollic, you can take advantage on this. :smiley:

[frollic]

Big thanks goes to WildPenguin for pointing this out.

Didn't cross my mind to use the gensens module for this.

Since I already have a script logging the output from my boiler, it wasn't a big thing to have it drop the values it encountered in separate files as well :)

Everything works like a charm, only "annoyance" is the fact that the units cannot be changed from hz to kg w/o modifying the pm, but that's a 1st world problem, imho ;)

thank you both frollic

On 2 May 2018 at 11:24, Jordi Sanfeliu notifications@github.com wrote:

@WildPenquin https://github.com/WildPenquin,

You're right, gensens module could read values from anywhere, as long as they are consistent.

I think that anyone can create a script that stores the values on a file and then configure gensens to read the results, all this without modifying any line in the Monitorix code.

I mean, people know better than me how works the device(s) they want to monitor. Moreover, they have the device(s) physically so it's easier for them to create the right script.

@frollic https://github.com/frollic, you can take advantage on this. 😃

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mikaku/Monitorix/issues/103#issuecomment-385917604, or mute the thread https://github.com/notifications/unsubscribe-auth/AHFpMX8K7PVAqitq-seh8u2yugqskBshks5tuXtagaJpZM4FmA4V .

[mikaku]

@frollic, it looks to me you managed to solve your problem, can we close that one?

[frollic]

yeah,

it can be closed.

thank you.

[mikaku]

Perfect.