Newest Threads

**helibrewer** · 11-29-2012, 10:58 PM

So it appears one needs to choose between the native w1 kernel module or OWFS. From the reading I have done, the GPIO cannot present itself as a physical bus connection required for OWFS. W1 kernel and OWFS are not compatible.

The OWFS direction seems more practical for I2C since I2C is a serial implementation and that's what OWFS likes.

I have been using the DS18x20's on GPIO4 using the native w1 kernel implementation.

OWFS should work with a USB 1-wire adapter since the USB device can act as the physical bus master for OWFS...if you just want to run the sensors to GPIO4 then the kernel implementation works great.

brewman ! · 11-29-2012, 11:01 PM

Quote:

Originally Posted by helibrewer

So it appears one needs to choose between the native w1 kernel module or OWFS. From the reading I have done, the GPIO cannot present itself as a physical bus connection required for OWFS. W1 kernel and OWFS are not compatible.

The OWFS direction seems more practical for I2C since I2C is a serial implementation and that's what OWFS likes.

I have been using the DS18x20's on GPIO4 using the native w1 kernel implementation.

OWFS should work with a USB 1-wire adapter since the USB device can act as the physical bus master for OWFS...if you just want to run the sensors to GPIO4 then the kernel implementation works great.

a) Thanks for looking into this and reporting it. The "gotyas" are what make these projects difficult.

b) I'll take your word for your decision(s) until I get a chance to dig in. Others are welcome to joint the fray.

c) Initial impression, I like the thought of doing OWFS with the USB adapter. I think I'll prefer the USB adapter to doing it with the kernel.

Carry on !

BoxBrewer · 12-01-2012, 05:30 PM

This might be a good link for good info on some Linux stuff for people searching this thread.

**helibrewer** · 12-02-2012, 10:56 PM

My latest dilemma is getting data from the GPIO displayed on javascript gauges. Javascript executes on the client side, I use python to pull GPIO data. Python runs on the server...connecting the two is the the challenge....assuming you want to serve your temperature readings real time over a webpage.

I found a promising little app called pico (not the text editor) which acts as a very simple RPC between JS and python. You can basically call a python script through a javascript in your html page.

I'm no js expert so if anyone knows a better way to pull the data, process it, possibly store it, then serve it up on a webpage, I'm all ears. It looks like the data needs to be pulled with a loop, or possibly through edge triggering to reduce cpu load on the Raspi.

brewman ! · 12-03-2012, 12:05 AM

I have not looked at this in any detail at all. I can't make a meaningful comment until I do.

tob77 · 12-03-2012, 04:16 AM

I hacked the hmiPhpExampleData data widget from JMWidgets (http://www.jmwidgets.com/index.php/docs/data-widgets-api/hmiphpexampledata/) It works pretty good. I can read and send data to the python server by using any of the JMWidgets embedded in html. It could be cleaned up a lot as I am no js expert. I am willing to share my efforts if anyone is interested. Does anyone know of a good way that we could share code with each other?

**helibrewer** · 12-03-2012, 04:57 AM

Quote:

Originally Posted by tob77

I hacked the hmiPhpExampleData data widget from JMWidgets (http://www.jmwidgets.com/index.php/docs/data-widgets-api/hmiphpexampledata/) It works pretty good. I can read and send data to the python server by using any of the JMWidgets embedded in html. It could be cleaned up a lot as I am no js expert. I am willing to share my efforts if anyone is interested. Does anyone know of a good way that we could share code with each other?

Nice, more reading to do

This seems more elegant than what I found.

brewman ! · 12-03-2012, 05:35 PM

I love the contributions I see in this thread. Everyone does things differently. More ideas = better outcome.

I'm working on my stand itself today. I'll join the fray when I get a chance.

wdevauld · 12-06-2012, 07:21 PM

Sorry I'm late to the party.

I'd like to help out around here, as I'm in the same boat. Assembling a new rig, and planning on using a pi to keep things in check. Here are a couple of thoughts I had when ripping through the pages:

- There is a One-Wire patch for the rPi, as helibrewer pointed out. This will allow you to use the GPIO pins on the board to poll the bus, as well as freeing up a USB port. It is too late for Brewman !, but it could save future readers $17 for the USB adapter. Furthermore because it is exposed at the kernel level as a file handle you can use epoll/select type programming to watch levels without having to busy wait your CPU or riddle it with sleep(1) s

- I rolled my own temperature sensors. I picked up some DS18B20s and some 'protection tubes' from http://www.brewershardware.com/Straight-Tubes/. I then used some binary thermal adhesive from Arctic Silver (http://www.arcticsilver.com/arctic_silver_thermal_adhesive.htm) to seat the sensors in the end. Testing against a Spectrum industrial sensor I was 0.2 degrees off at 70 Celsius. Considering that is the error tolerance for the 'industrial' sensor at that point, it was good enough for me.

- Those Canvas Steel gauges are sexy. Thanks jimmayhugh, I will be using those in the future. Yes, I think that visualizing data can be sexy.

- I agree with Yorg, use python. It's a bloody elegant language, and most of the libraries are written in python themselves, so no problems porting to the ARM processors on the rPi

- I agree with Brewman ! that a full LAMP stack is way overkill for this purpose. I do like pyWeb, although there seems to be more web servers these days than there are homebrewers. I personally like making the clients do most of the heavy lifting which means that all you provide is static HTML/JS/CSS and then serve up data on demand. I'm not even sure you need to venture outside of Python; you could use the built in SimpleHTTPServer to watch port 80, serve up static files and data and then use the built in pickle as a super simplistic 'database' of historical information. If you can keep your external requirement to just Python, it keeps installation (and customization) very easy.

Let's keep the ideas rolling.

brewman ! · 12-06-2012, 07:38 PM

Welcome to the party. wdevauld.

I love where this is going.

I disagree with the one wire kernel driver versus the USB one wire adapter, but I haven't played with either of them yet, nor am I set on either one. So we'll see where this goes.

Here is a one wire open collector (drains) driver (DS2408) that could be use to drive typical brewstand relays, among other things.

http://www.digikey.com/product-detail/en/DS2408S%2B/DS2408S%2B-ND/1197414

This device would be handy for people using the One Wire interface for temperature measurement and wanting to drive more relays than the GPIO port on the RPi board will allow directly.