Tag Archives: 1-Wire

DIY Crock Pot Sous Vide System

On a visit to some friends I became aware of the whole topic of Sous Vide “under vacuum” (SV) cooking, the concept of using a controlled water bath to cook food (particularly meats) at low(er) temperatures for more consistent and desirable results. High end restaurants have been doing this for a while. At the time, Sous Vide systems were quite expensive but some home cooks were doing ingenious hacks to simulate a professional SV cooker by using hot water in beer coolers, etc. In that discussion, I mentioned that I thought one of the small computers I was toying with for home automation (HA) could make a simple & cheap SV system with some other basic parts.

It took me some time to come back around to the whole SV idea myself. Not too long ago I came across a great deal on some London Broil at Market Basket and that served to get me going on setting up my own SV system using parts I had already at the house from my previous HA projects. While there are now some SV immersion systems on the market for under $200, I thought I had everything needed to make one on hand. I figured I could try it out and see what I thought of SV cooking without spending any more money. Here’s what I came up with.

DISCLAIMER: This post is just to document what I did. I’m a hobbyist and know almost nothing above my tinkering. I DO NOT MAKE ANY ASSURANCE THAT THIS IS APPROPRIATE FOR HEALTH OR SAFETY CONSIDERATIONS. YOU ARE RESPONSIBLE FOR YOUR OWN FOOD HEALTH DECISIONS AND FOR USING ELECTRICITY RESPONSIBLY. I WILL NOT BE HELD LIABLE FOR ANY ACTION YOU TAKE TO FOLLOW THIS SAME PATH AND ANY DAMAGE THAT MAY RESULT. YOU HAVE BEEN WARNED! But should you make some delicious food as a result please comment to let me know!

OK, with that out of the way, here’s a photo of my solution:

My DIY Sous Vide System

The major parts here are:

  • standard Crock Pot slow cooker
  • Programmable Power Controller, consisting of:
    • CAI WebControl PLC (Programmable Logic Controller) unit
    • DS18B20 1-wire temperature sensor, embedded in a stainless steel probe
    • AC to 9v DC power adapter
    • 5v “Arduino” relay board
    • Misc. breadboard wires, low voltage wires and a PC 12v fan connector
  • 110v home wiring components:
    • Light switch
    • Power outlet
    • Appliance power cable
    • Misc. wires and connectors

Update 5/29/2016:

I’ve now been using this set up successfully for nearly a full year. Today I’m doing a SV Leg of Lamb for later finishing on the BBQ grill. Other meals have included lots of chicken, pork and beef – each one has turned out really well (I’ve yet to do fish, but will try it soon). I’ve not posted my PLC code up to now because I was awaiting it becoming stable – which I think I can now consider it, as it’s pretty much worked unchanged since day1 – so here it is. A bit of explanation:

HEAT_ON is a subroutine to energize the power relay, HEAT_OFF does the opposite.
HEAT_MAIL informs me of changes in state of the power relay.

Using the WebControl PLC’s General Setup page, various values can be set to control the program:
UROM1 is the desired set point (degF *10), so 1360 is 136.0 deg
UROM2 is the lower offset (degF * 10), so 8 is 0.8 deg – this controls the amount of swing in the actual temperature and will need to be tweaked for a given crock pot. This determines the actual point at which the heat will be turned on.
UROM3 is to enable or disable the power relay. 1 enables.
UROM4 is to enable or disable the email notices. 1 enables.

START
SET VAR1 0
TSTEQ TS1 0
EMAIL EM1
SUB UROM1 UROM2 VAR1
TSTLE T1 VAR1
CALLSUB HEAT_ON
TSTGE T1 UROM1
CALLSUB HEAT_OFF
END

HEAT_ON:
TSTEQ OP2 0
SET VAR4 -1
TSTNE UROM3 1
SET OP2 0
TSTNE UROM3 1
RET

SET OP2 1
SET VAR2 T1
TSTEQ VAR4 -1
CALLSUB HEAT_MAIL
SET VAR4 0
RET

HEAT_OFF:
TSTEQ OP2 1
SET VAR4 1
SET OP2 0
SET VAR3 T1
TSTEQ VAR4 1
CALLSUB HEAT_MAIL
SET VAR4 0
RET

HEAT_MAIL:
TSTNE UROM4 1
RET

TSTEQ VAR4 -1
EMAIL EM2
TSTEQ VAR4 1
EMAIL EM3
RET

I’ve also set up a script on a Raspberry Pi on our network which I use for data logging of each batch. At 10 minute intervals it captures the relay state and current bath temperature into a .csv file via a URL get from the WebControl. I can use this data for tweaking the UROM2 value above and for modifying my recipes going forward.

I’m very pleased with the system now and may be extending it to control more than one bath. For instance, today I was wanting to do both a pork loin and the lamb leg at the same time. There’s not enough space in the crock pot for both, despite the temperatures being able to be the same (but duration differing). With some code changes and multiple probes & relays I could control several baths.

I may also be creating an internal web portal on the pi which could provide real-time graphing and settings management for the SV set up, so I don’t have to look up what UROM values mean what each time! 🙂 This will be more important if/when I extend it to multiple baths, as only the UROM values have a built-in web interface on the WebControl unit.

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:

~/.ssh/authorized_keys

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

Future:

  • 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*
./usr/share/temploggerd
./usr/share/temploggerd/templates/README.temploggerd.templ
./usr/bin/temploggerd
./usr/lib/temploggerd
./usr/lib/temploggerd/temploggerd.conf.wrt54g
./usr/lib/temploggerd/temploggerd.conf.coldfire
./usr/lib/temploggerd/temploggerd.conf.default
./usr/lib/temploggerd/temploggerd.conf.ewrt54g
./usr/lib/temploggerd/temploggerd.conf.openwrt
[root@chicago /]# find . -name owfs*
./usr/include/owfs_config.h
./usr/share/man/man5/owfs.conf.5.gz
./usr/share/man/man5/owfs.5.gz
./usr/share/man/man1/owfs.1.gz
./usr/bin/owfs
./var/lib/pacman/sync/aur/owfs-2.8p7-1
./var/lib/pacman/local/owfs-2.8p7-1.2
./var/cache/pacman/pkg/owfs-2.8p7-1-any.pkg.tar.xz
./var/cache/pacman/pkg/owfs-2.8p7-1.2-any.pkg.tar.xz
[root@chicago /]# find . -name owft*
./usr/share/man/man1/owftpd.1.gz
./usr/bin/owftpd
[root@chicago /]# find . -name owht*
./usr/share/man/man1/owhttpd.1.gz
./usr/bin/owhttpd
[root@chicago /]# find . -name owse*
./usr/share/man/man1/owserver.1.gz
./usr/bin/owserver
[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 :
    pacman
    :: 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).

OWFS

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 http://192.168.15.77:3001/ . 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

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
etc.

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
65.525
#

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!