Tag Archives: owfs

Arch Linux and 1-Wire on a Seagate DockStar

Outline for now. This is currently improcess, but I’ve made much more progress than shown below – I now have all but the data logging/graphing set up and everything autostarts with new systemd service files. Yay!

Reinstall latest Arch following instructions.

Modifications to that installation process:

  • Create the system partition as ext3 instead using mke2fs -j /dev/sda1 and make sure the boot loader knows to use ext3:/usr/sbin/fw_setenv usb_rootfstype ext3
  • Perform the fw_setenv mods for rootdelay and an additional stop/start on usb drive/bus (figured this out the last time, required to ensure the usb drive will come ready before the DockStar tries to boot from it) /usr/sbin/fw_setenv usb_rootdelay 10 (should experiment to see if this can be reduced with the next item in place) and /usr/sbin/fw_setenv bootcmd 'usb start; usb stop; usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset'. Otherwise the DockStar may boot into the original PogoPlug OS instead.

Change root password. Update hostname and locale per instruction at Arch Beginner’s Guide (HW reboot required for hostname to take effect)

update system: pacman -Syu

Install owfs, lighttpd, FastCGI and PHP: pacman -S owfs lighttpd fcgi php php-cgi (digitemp not available as a package yet, see AUR)

Set up lighttpd (including PHP and fcgi support, but DO NOT make the first set of mods shown right under the FastCGI heading, this is to enable Ruby on Rails but is incomplete and will bork the server start-up)

Set up passwordless login via key:

On your local machine, copy over your local public key to the new server using
user@localmachine ~ $ ssh-copy-id root@remotemachine
root@remotemachine's password:
Now try logging into the machine, with "ssh 'root@remotemachine'", and check in:


to make sure we haven't added extra keys that you weren't expecting.

Modify /etc/ssh/sshd_config to disable password authentication (without this, the passwordless authentication will work, but others could still try to log in with the root password):
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes

and restart the sshd service:
systemctl restart sshd


  • Get owfs suite working and create the proper config and daemon files to have it autostart and keep running [DONE, details to be added here – but all the magic happens via /etc/systemd/system].
  • Create web page(s) to autodisplay the local 1-wire sensors data as well as interesting data from a chosen wunderground feed [DONE, using the json API for wunderground, details to be added here].
  • Automate the data collection and graphing for sensors. [PENDING]

1-Wire/owfs on Seagate Dockstar under PlugApps Linux

This post is currently just a set of notes as I blaze the trail to get this working. Ignore for now, unless you like just reading random technical thoughts from someone puzzling their way through something they don’t know a lot about… I’ve started a true step-by-step description at the end below as I make my way through this for a second time. Hopefully this will be completed and cleaned up shortly.

PlugApps is based on Arch Linux, follows their start-up sequence – which is loosely based on BSD’s. The file /etc/rc.conf is where a lot of the main settings are made. Daemons are initiated based on an array entered at the bottom of that file. The daemons exist as bash scripts in the directory /etc/rc.d . Config files and similar stuff appear to be are normally set/stored in /etc/___. See here and here for the Arch info.

The owfs package now created for PlugApps includes the owfs core application/commands PLUS temploggerd but only creates the related option and template files for temploggerd. No similar files are created for the core owfs stuff. Currently have verified that owserver and owhttpd can be started with the applicable options from command line and those basically work.

Next steps:

  • figure out the option/config files for owserver, etc. under PlugApps based on prior work with NSLU2 (these were in /opt/etc/owfs there)
  • does my application require FUSE and the sensor array to be mounted as a file system? (A: YES, it is handy and by using owserver as a front end it does not cause a burden.) if not, skip owfs itself, otherwise script creation of /tmp/1wire and do related stuff to make the array available (A: will need to script this, it will be part of the rc.d script).
  • figure out temploggerd operation – can it be verified without web server access at start? (A: Yes, but web server is now set up)
  • determine what web server to use – thttpd? something light weight but secure! (A: Cherokee is available, installed easily and works well with little load on server. Plus is it has a GUI for admin!)
  • generate temploggerd templates (reclaim from NSLU2 installation?), or do I want to use another prettier graphing toolset like http://dygraphs.com/? (A: stay with temploggerd for now)
  • make the system survive a power outage -> install (what?) to NAND? or simply configure a static IP locked to MAC address on router and reboot from pogo OS if stuck?

Misc. Info:
From default installation of the owfs package on PlugApps:

[root@chicago /]# find . -name *emplog*
[root@chicago /]# find . -name owfs*
[root@chicago /]# find . -name owft*
[root@chicago /]# find . -name owht*
[root@chicago /]# find . -name owse*
[root@chicago /]#

How to Install PlugApps Linux on a Seagate Dockstar and Enable owfs and temploggerd

  1. Obtain ssh access for your Dockstar
  2. Perform basic installation of PlugApps
  3. Update pacman itself:

  4. [root@Plugbox ~]# pacman -Syu
    :: Synchronizing package databases...
    core 35.5K 172.4K/s 00:00:00 [######################] 100%
    extra 382.1K 457.7K/s 00:00:01 [######################] 100%
    community 371.6K 489.2K/s 00:00:01 [######################] 100%
    aur 5.9K 146.4K/s 00:00:00 [######################] 100%
    :: The following packages should be upgraded first :
    :: Do you want to cancel the current operation
    :: and upgrade these packages now? [Y/n] Y
    resolving dependencies...
    looking for inter-conflicts...
    Targets (1): pacman-3.5.1-1.2
    Total Download Size: 0.79 MB
    Total Installed Size: 2.72 MB
    Proceed with installation? [Y/n] Y
    :: Retrieving packages from core...
    pacman-3.5.1-1.2-arm 804.7K 583.5K/s 00:00:01 [######################] 100%
    checking package integrity...
    (1/1) checking for file conflicts [######################] 100%
    (1/1) upgrading pacman [######################] 100%
    >>> The pacman database format has changed as of pacman 3.5.0.
    >>> You will need to run `pacman-db-upgrade` as root.
    !!!!!! SERIOUSLY! Run pacman-db-upgrade or PACMAN WILL NOT WORK! !!!!!!
    [root@Plugbox ~]# pacman-db-upgrade
    ==> Pre-3.5 database format detected - upgrading...
    ==> Done.

  5. The Dockstar does not have a hardware clock, so it will always be off at start up unless you take action to fix that. The easiest way is to set up a network time protocol client. Install openntpd (automatic time sync client) and start it before the password change below, to avoid lockout due to password aging (30+ years will seem to have passed between the default date in 1970 and now).
  6. Change ssh login password for security (optional: install ssh public key in ~/.ssh/authorized_keys for more security [+ disable password authentication in /etc/sshd_config for even more security & to avoid having to type in your (long, strong) password])
  7. Install ddclient if you are going to want to access the machine over the internet with a DHCP address.

Now that we have the Dockstar basically set up and functioning under PlugApps, we can move on to the 1-Wire and owfs related items. (more to come…)
[root@chicago ~]# owserver -F -s 4304 -d /dev/ttyUSB0
[root@chicago ~]# owhttpd -F --readonly -s 4304 -p 3001
[root@chicago ~]# mkdir /tmp/1wire
[root@chicago ~]# owfs -F -s 4304 /tmp/1wire
[root@chicago ~]# ls /tmp/1wire

Post-install: disable telnet under pogoplug os, in case of PlugApps reboot failure (provide details here – did enabling ssh via pogoplug portal already do this?)

Fun with 1-Wire Devices in Linux using Digitemp and owfs

I’m currently working on a Christmas present for my new in-laws.

The goal is to be able to remotely monitor the temperature and humidity at another location over the internet. I want to do this at a reasonably low cost, using very little power and not taking up a lot of space in the target location.

To meet these goals, I’ve designed a solution using Dallas/Maxim 1-Wire devices. These are low cost sensors that interface using a very simple parallel bus, wired (with, despite the name, 2-3 wires) over either a standard cat-5 ethernet cable or RJ-11/RJ-12 style cable. I’m going to drive them using a small embedded Linux system for silent and low power operation.

The sensors and adapters arrived a couple of days ago. I had other projects under way, so playing with them had to wait until today. I’m posting the following because the adapter I’m using is relatively little known, meaning that almost everything I could find for software usage examples did not cover this adapter. After several hours, I have now found the secret sauce and I’m going to pass along the recipe to you (and me, in case I forget!).

Here’s the parts I’m using:

  • Linksys NSLU-2 Network Storage Link, hacked to run Unslung 6.8 (a modification of the original embedded Linux provided by Cisco on this unit, which allows running many other SW packages)
  • iButtonLink LinkUSB-SD 1-Wire Bus Adapter
  • iButtonLink T-Sense-SD Temperature Sensor
  • and, eventually, a AAG TAI-8540 humidity sensor

I’d planned to use a DS-9490R adapter, which is very well documented for SW use, but was finding them sold out wherever I looked. Same deal for the TAI-8540 (but we could always add the humidity sensor later). Looking for alternatives so the gift would be available on time got me to iButtonLink. Their LinkUSB series are supposed to be superior performing masters, and they were available.

My first task was to determine and get the required software installed. My original desire was to use the oww (1-Wire Weather) package, which was developed to work with a dedicated hobbyist weather station product that Dallas once had available. It has since expanded to support other standalone sensors and is available in the Unslung ipkg feed, so it can be installed and used without needing to be compiled. It has a bunch of great features, including the ability to upload/push data to a server for viewing, so no firewall and DNS shenanigans would be involved. This all would be great, but I’ve not yet been able to get it to work with the LinkUSB adapter. So searching on… I landed on two other packages: owfs (1-wire file system) and DigiTemp. Again, both of these are available as native ipkg feeds for Unslung (the selection is impressive).


I tried owfs first, as there were many on-line comments about DigiTemp being limited to temperature measurement only, and I knew we wanted to do humidity too. I installed the software according to the instructions on the owfs site. Here is what I did, running as root:

ipkg update
ipkg install owfs
ipkg install owshell owcapi

This automatically installed the start-up scripts too, so owfs would be there after a reboot. Unfortunately, the parameters it used were not compatible with this adapter and no sensors showed when viewing the resulting summary page via . I also found the output on that web page to be very confusing at first glance and not made plain on their site, so I couldn’t figure out why I wasn’t seeing any sensors and temps. I poked around using lsusb, etc. but couldn’t find the 1-wire file system entries that were supposedly created by this package. After a frustrating period, I punted and moved on to DigiTemp. But I’d be back later… mere SW can’t beat my persistence!


DigiTemp is a package designed to do just what it sounds like, grab temperatures from digital devices. In this case, 1-Wire sensors. Some people have gone all out with it. We had more modest goals, and it turns out that the humidity sensor I wanted to use is actually supported under DigiTemp with a serial (not USB) adapter. There might be hope yet…

So I install DigiTemp following instructions on the NSLU2-Linux site, but run into the problem with using a non-DS9490-R adapter once more (all examples were for that one). It turns out there is no single actual digitemp command, but rather a different one based on each adapter type, and mine isn’t listed as one of them. Out of frustration, I decide to try all of them. Amazingly, the last one works! I can see devices!

# digitemp_DS9097U -w -s /dev/ttyUSB0
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
Devices on the Main LAN
280097A702000098 : DS18B20 Temperature Sensor
28848BD50200005C : DS18B20 Temperature Sensor

So here’s my commands to install, configure and use DigiTemp with the LinkUSB adapter:

# digitemp_DS9097U -i -c /etc/digitemp.conf -s /dev/ttyUSB0
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
280097A702000098 : DS18B20 Temperature Sensor
28848BD50200005C : DS18B20 Temperature Sensor
ROM #0 : 280097A702000098
ROM #1 : 28848BD50200005C
Wrote /etc/digitemp.conf
# digitemp_DS9097U -q -c /etc/digitemp.conf -a
Dec 03 18:55:38 Sensor 0 C: 19.50 F: 67.10
Dec 03 18:55:39 Sensor 1 C: 21.19 F: 70.14

Yay, we see sensors and actual temperatures! It works. Now from this, I get some clues that I think might help with owfs. So back to crack that nut.

OWFS Redux

From the above, I know I have a device that looks like a DS9097U to software, and it appears to be seen on /dev/ttyUSB0. Armed with this, I poke around owfs and force it to use other settings than the default start-up scripts supply. This means killing all owftpd, owhttpd and owfs processes (via ps -ef and kill -9). I then restart them using /dev/ttyUSB0:

owfs -F -d /dev/ttyUSB0 -m /tmp/1wire
owhttpd -F -p 3001 -d /dev/ttyUSB0

Note: I’d actually installed a second adapter and sensor in-between activities here, so I modified those commands to add the ttyUSB1 as well (you will see those in the output below). And finally I see something in the /tmp/1wire directory!

# ls
28.0097A7020000 28.75BAA7020000 28.848BD5020000 alarm bus.0 bus.1 settings simultaneous statistics structure system uncached

You can then get some data from a sensor by treating it as a normal text file under Linux, e.g.:

# cat 28.75BAA7020000/temperature

And when I look at the web interface, I can finally browse these devices as well!

Other Magic

There is one other thing I did a couple of times along the way, but I can’t now remember in what exact order I did it for the last time. This may or may not impact the above for you. I got the clue from this oww page. In there is a bunch of info on using the NSLU-2 with oww, which of course includes that more standard adapter but listed other possibilities. From that, I installed the kernel modules that I thought applied to the LinkUSB:

ipkg install kernel-module-usbserial
ipkg install kernel-module-ftdi-sio

After doing so, I then had to load those modules:
insmod usbserial
insmod ftdi_sio
(note the underscore instead of dash here, tricky!).

After this, the NSLU-2 reported via dmesg seeing the LinkUSB adapters (which are connected via a USB hub):

hub.c: new USB device 00:01.0-1, assigned address 3
Device descriptor:8 bytes received.
Device descriptor:18 bytes received.
hub.c: USB hub found
hub.c: 4 ports detected
hub.c: new USB device 00:01.0-1.1, assigned address 4
Device descriptor:8 bytes received.
Device descriptor:18 bytes received.
usbserial.c: FTDI FT232BM Compatible converter detected
usbserial.c: FTDI FT232BM Compatible converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
hub.c: new USB device 00:01.0-1.3, assigned address 5
Device descriptor:8 bytes received.
Device descriptor:18 bytes received.
usbserial.c: FTDI FT232BM Compatible converter detected
usbserial.c: FTDI FT232BM Compatible converter now attached to ttyUSB1 (or usb/tts/1 for devfs)
hub.c: new USB device 00:01.0-1.4, assigned address 6

So this was most likely required for DigiTemp (and/or owfs) to see these devices on ttyUSBn. I will verify this later when I have more time to set up the rest of this project, meaning to: collect the sensor output, create pretty information from it and make it available for remote access.

Off to dinner, but more to come!