Upgrade from 3.3.2 to 3.7.1 issues

[Dallen Wilson]

I've run in to a problem with the new 3.7.1 release that I did not have with the previous version I was using, 3.3.2. The new version can see the 1-wire device on the network, but refuses to read anything from it. I've been unable to get it to display any useful debug or diagnostic messages.

The box in question is a sparc machine running an ancient, netgear-butchered version of Debian Sarge. I mention this because I've seen weird issues before in other software I compiled for it, so it may be relevant here.

The entire setup consists of the sparc box, a USB->Serial adapter from iButtonLink, and an MS-T sensor, also from iButtonLink.

So far with the 3.7.1 release I've tried:
Deleting and having the new version re-create the ~/.digitemprc file, with no change in results.
Increasing the read delay (-r #) up to 5000 ms, without a change in results.
Increasing the verbosity flag (-v, -vv, -vvv) gives no additional output.
Reading sensor 0 explicitly instead of all sensors (-t 0 vs -a) changes nothing.
Explicitly specifying the serial port (-s /dev/ttyUSB0) without result.
Unplugging and re-plugging the USB->serial adapter, as well as the sensor.

Below is a copy/paste from my ssh session to show what I mean when I say it sees it, but won't read it.

[warped@dark-core:~]$ cat .digitemprc
TTY /dev/ttyUSB0
READ_TIME 1000
LOG_TYPE 1
LOG_FORMAT "%b %d %H:%M:%S Sensor %s C: %.2C F: %.2F"
CNT_FORMAT "%b %d %H:%M:%S Sensor %s #%n %C"
HUM_FORMAT "%b %d %H:%M:%S Sensor %s C: %.2C F: %.2F H: %h%%"
SENSORS 1
ROM 0 0x26 0x3B 0x60 0x45 0x01 0x00 0x00 0xAF

[warped@dark-core:~]$ sudo /usr/bin/digitemp_DS9097U.3.3.2 -w -v
DigiTemp v3.3.2 Copyright 1996-2004 by Brian C. Lane
GNU Public License v2.0 - http://www.brianlane.com
Turning off all DS2409 Couplers
.
Devices on the Main LAN
263B6045010000AF : DS2438 Temperature, A/D Battery Monior

[warped@dark-core:~]$ sudo /usr/bin/digitemp_DS9097U.3.3.2 -a -v
DigiTemp v3.3.2 Copyright 1996-2004 by Brian C. Lane
GNU Public License v2.0 - http://www.brianlane.com
Oct 02 18:26:09 Sensor 0 C: 20.50 F: 68.90 H: 0%

[warped@dark-core:~]$ sudo /usr/bin/digitemp_DS9097U.3.7.1 -w -v
DigiTemp v3.7.1 Copyright 1996-2015 by Brian C. Lane
GNU General Public License v2.0 - http://www.digitemp.com
Turning off all DS2409 Couplers
.
Devices on the Main LAN
263B6045010000AF : DS2438 Temperature, A/D Battery Monitor

[warped@dark-core:~]$ sudo /usr/bin/digitemp_DS9097U.3.7.1 -a -v
DigiTemp v3.7.1 Copyright 1996-2015 by Brian C. Lane
GNU General Public License v2.0 - http://www.digitemp.com

[warped@dark-core:~]$

If anyone wonders why sudo is being used, Digitemp had some issues writing to /var/lock/ despite /var/lock/ being explicitly made user-writable, so I set my bash script to run under root's crontab until I could get around to finding and correcting the problem. That was almost five years ago now, but it's still on the todo list. /root/.digitemprc is identical to the file cat'd in the above log.

What puzzles me is that 3.7.1 can still walk the tree and report the ID of the sensor I'm using, but not read the same sensor. It's not a cabling, adapter, or sensor issue, since 3.3.2 works just fine. I've never had any issues or errors with 3.3.2, other than the initial teething problems when I first set everything up.

I upgraded entirely on a whim, I don't need anything (that I'm aware of) in the new 3.7.1 release. I'll carry on with 3.3.2 since that's what's working for me.

[Brian C. Lane]

On Mon, Oct 02, 2017 at 05:55:35PM -0700, Dallen Wilson wrote:
> I upgraded entirely on a whim, I don't need anything (that I'm aware of) in
> the new 3.7.1 release. I'll carry on with 3.3.2 since that's what's working
> for me.

Try passing -A and see if that makes any difference (likely not, since
3.3.2 is working for you). You could also try building the current code
on master, or this PR that I haven't had a chance to merge:

https://github.com/bcl/digitemp/pull/21

It's hard to tell what could be going on, it has been quite a while
since 3.3.2 -- but it is odd that -v isn't returning any of the debug
info. That means that something is failing early on. You might try
running it with strace or ltrace to see if that logs anything
interesting.

--
http://www.brianlane.com