NEW StrangeBrew Elsinore Thread

Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum

Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
... that thermowell is toast if the $3 sensor ever died.

I understand your apprehension. It's too bad that thermowells are so expensive. However, I have about a dozen DS18B20s monitoring the temperatures in my home that I have been polling every 3 seconds for the last seven years and have yet to see one fail.

On a related note, the BrewPi folks sell a nice-looking 1/2" NPT threaded DS18B20. At about $20 the price isn't too bad, but the shipping starts at around $22. Is there any interest in a group buy? If we get an order of at least 10, I'd be willing to take the initial shipment and redistribute to U.S. addresses. The cost would drop to about $21 each, and US Priority Mail shipping would be just $5.
 
Is anyone using a debian kernel newer then 3.14 with this project. I am using a beaglebone black with debian lxqt image that uses a 3.14 kernal. In this image the dto's use universal io and the /sys/devices/bone_capemgr.*/slots do not exist.

I am currently unable to load the overlay.
 
Is anyone using a debian kernel newer then 3.14 with this project. I am using a beaglebone black with debian lxqt image that uses a 3.14 kernal. In this image the dto's use universal io and the /sys/devices/bone_capemgr.*/slots do not exist.

I am currently unable to load the overlay.

http://dougedey.github.io/2014/03/22/BeagleBoneBlack-Setup/

Please read the documentation, do not use anything above 3.8 because of this issue, I have not been able to look into it further.
 
Please read the documentation, do not use anything above 3.8 because of this issue, I have not been able to look into it further.

I have other reasons for needing the newer kernel. I thought it was an open source project and I was asking if anyone had gone to the effort to make it work on a newer kernel. If no one has, I will do it myself.
 
I have other reasons for needing the newer kernel. I thought it was an open source project and I was asking if anyone had gone to the effort to make it work on a newer kernel. If no one has, I will do it myself.

The issue I found was the one wire was not supported on newer kernels, and it appeared that I was the only one looking for it.
 
Maybe I will try to write my own with the pruss? It is an easy enough protocol. I've looked at the code for the arduino. Maybe if I fall onto some extra time :)
 
I just found this

http://libbulldog.org/bulldog/

and will give it a shot in the next couple of days to see if I can write a driver for the DS18B20 probes. If anyone can see a reason it won't work, I am not an expert with the beaglebone, the earlier I know the better.

The interface can do I2C, so surely it can do the ds18B20.
 
I used the 6" thermowells from Duda Diesel with 1/2" male NPT threads and a cable retention. I screwed these into a camlock (type E, I think) which makes it really easy to remove the thermowell for cleaning my kettle.

I don't have any pics, but I could take some if you're interested.

I would absolutely be interested, especially to see your cable retention setup. Thank you for the great info!
 
I understand your apprehension. It's too bad that thermowells are so expensive. However, I have about a dozen DS18B20s monitoring the temperatures in my home that I have been polling every 3 seconds for the last seven years and have yet to see one fail.

On a related note, the BrewPi folks sell a nice-looking 1/2" NPT threaded DS18B20. At about $20 the price isn't too bad, but the shipping starts at around $22. Is there any interest in a group buy? If we get an order of at least 10, I'd be willing to take the initial shipment and redistribute to U.S. addresses. The cost would drop to about $21 each, and US Priority Mail shipping would be just $5.

Wow, those are perfect. I agree a bit steep, but they are purpose built to be in-line with wort flow and look great, are these new, I haven't seen them up there before?




Look on Ebay for tank sensors, like these: http://www.ebay.ca/itm/3m-Digital-T...361?pt=LH_DefaultDomain_0&hash=item35e6fb24f1

I use the 90 degree ones.

Doug, how are you connecting these in-line? The NPT threads appear to be on the opposite side (usually it's on the side with the thermowell). Are these directly in your kettles, or in the line of flow (using a T etc)?


Thanks again for the responses and great info!
 
Yes, the BrewPi sensors are fairly new (maybe on the market a month or so). I agree they look like the perfect sensor for a RIMs tube, and I could see myself using some to measure temps in and out of my plate chiller. Splitting the shipping with a group would make the price easier on the wallet.

Speaking of things from overseas that I'd like to get, I'm thinking of getting one of these boards:

https://www.abelectronics.co.uk/pro...--Raspberry-Pi-2-Model-B/60/66/1-Wire-Pi-Plus

This has several advantages over using the w1-gpio driver off a pin of the Raspberry Pi.

- 1-Wire bus is driven by 5v instead of 3v, providing a stronger signal
- The 2482 chip used by this board provides a robust 1-Wire network which reduces the chance of a bad temp read
- It's opto-isolated so a reduced chance of frying the Pi when connecting or disconnecting sensors.
 
I just found this

http://libbulldog.org/bulldog/

and will give it a shot in the next couple of days to see if I can write a driver for the DS18B20 probes. If anyone can see a reason it won't work, I am not an expert with the beaglebone, the earlier I know the better.

The interface can do I2C, so surely it can do the ds18B20.


One wire is not I2C, it's a bit bang interface.
 
One wire is not I2C, it's a bit bang interface.

I hope you were joking. I know enough to try to implement the onewire protocol in pru assembler they might even have a c++ sdk for the pru. The comment was meant to imply if the lib can handle timing for i2c it can handle the onewire for this thermometer. If they had the i2c board just posted for the beaglebone I would use that.
 
here are the error messages i can find in the java console
the bottom two error messages just keep on cycling upwards about once per second when i cut and paste the messages as you can see it i was up to 159 and 128 occurrences of that particular error


Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/.

2 http://192.168.2.8:8080/templates/static/js/jquery.js Failed to load resource: the server responded with a status of 404 (Not Found)

159 jquery.js:2 Uncaught Error: Syntax error, unrecognized expression: #triggerTableHLT_/_HEAT

128 jquery.js:2 Uncaught Error: Syntax error, unrecognized expression: #triggerTableHLT_/_HEAT


hope this helps

mike
 
I understand your apprehension. It's too bad that thermowells are so expensive. However, I have about a dozen DS18B20s monitoring the temperatures in my home that I have been polling every 3 seconds for the last seven years and have yet to see one fail.

On a related note, the BrewPi folks sell a nice-looking 1/2" NPT threaded DS18B20. At about $20 the price isn't too bad, but the shipping starts at around $22. Is there any interest in a group buy? If we get an order of at least 10, I'd be willing to take the initial shipment and redistribute to U.S. addresses. The cost would drop to about $21 each, and US Priority Mail shipping would be just $5.

Seems like you could do something similar if you already have the sensors with the ones at Brewershardware, but i think the shortest one they sell (2") would be too long to put in a T like that...It would have to go in one of the straight ends forcing your output to come out the bottom of the T(not necessarily a bad thing)...
 
I hope you were joking. I know enough to try to implement the onewire protocol in pru assembler they might even have a c++ sdk for the pru. The comment was meant to imply if the lib can handle timing for i2c it can handle the onewire for this thermometer. If they had the i2c board just posted for the beaglebone I would use that.

Yes I am. But unless you implement something that works on all kernels, I won't merge it into the main stream.

You may find your time is better spent getting the w1-therm module and/or owfs going outside of Elsinore.
 
here are the error messages i can find in the java console
the bottom two error messages just keep on cycling upwards about once per second when i cut and paste the messages as you can see it i was up to 159 and 128 occurrences of that particular error


Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/.

2 http://192.168.2.8:8080/templates/static/js/jquery.js Failed to load resource: the server responded with a status of 404 (Not Found)

159 jquery.js:2 Uncaught Error: Syntax error, unrecognized expression: #triggerTableHLT_/_HEAT

128 jquery.js:2 Uncaught Error: Syntax error, unrecognized expression: #triggerTableHLT_/_HEAT


hope this helps

mike

Remove the slashes from your names.
 
I like that board!

Yes, the BrewPi sensors are fairly new (maybe on the market a month or so). I agree they look like the perfect sensor for a RIMs tube, and I could see myself using some to measure temps in and out of my plate chiller. Splitting the shipping with a group would make the price easier on the wallet.

Speaking of things from overseas that I'd like to get, I'm thinking of getting one of these boards:

https://www.abelectronics.co.uk/pro...--Raspberry-Pi-2-Model-B/60/66/1-Wire-Pi-Plus

This has several advantages over using the w1-gpio driver off a pin of the Raspberry Pi.

- 1-Wire bus is driven by 5v instead of 3v, providing a stronger signal
- The 2482 chip used by this board provides a robust 1-Wire network which reduces the chance of a bad temp read
- It's opto-isolated so a reduced chance of frying the Pi when connecting or disconnecting sensors.
 
I did not see the I2C board.

I am also no longer actively going to be monitoring this thread.
 
I will continue to hang around this thread for the basic troubleshooting that I'm capable of assisting with. I've received a couple PMs for help with the software. Please post your questions publicly so that the solution will be visible to others with the same problem.
 
I'm looking for any input who has experience with both a network-controlled (tablet, phone, laptop etc) vs the panel controlled with physical buttons like TheElectricBrewery. Both seem to have their advantages, but I'd like to hear from people who have used both style systems and what your feedback is.

Thanks! :mug:
 
I'm looking for any input who has experience with both a network-controlled (tablet, phone, laptop etc) vs the panel controlled with physical buttons like TheElectricBrewery. Both seem to have their advantages, but I'd like to hear from people who have used both style systems and what your feedback is.

Thanks! :mug:

Network controlled is much cheaper (e.g. a panel with Doug's software, SB Elsinore can be built for around $4-500, the electric brewery panel costs $2-3k in many cases. The temperature probes which are used with SB Elisnore are especially cheap, and can be daisy chained. This makes your SB Elsinore system extremely extensible at a very low cost. For instance, now use my SB elsinore system to monitor and control my keg fridge, and plan to have it do the same for a fermentation chamber in the near future, in addition to running my electric brewery.

Tactile buttons and lights are nice, but they are also difficult to change. I would also say to wire up a panel like the electric brewery is more difficult than one that works with SB elsinore. The one drawback to using SB Elsinore or similar is that there is possible a small lag (0.5 sec or less) from the time you turn something on or off to when it actually occurs. I do not think this is a major concern for most people, and isn't noticeable most of the time.

More automation is possible with SB Elsinore software as you can set up procedures to wait, turn on/off pumps, change the temperature of PIDs (in the case of stepped mashes), etc (though this is not necessary). You can also log your system with the graphing capabilities in SB Elsinore (great for calibrating your system and for data obsessed individuals).

You can achieve comparable levels of safety through the use of fuses/breakers in either panel when you move between components rated at lower amperages, and with the use of basic master switch/relay (and element specific ones if you choose).

Either way, I would suggest reading theelectricbrewery.com as it provides a great description of the safety considerations with electric breweries, and how these systems work in general. This information is useful because SB Elsinore is essentially software that replaces certain hardware in the electric brewery - PIDs and switches especially - and most of the theory still applies.

I would suggest that you have some familiarity with or at least confidence approaching linux/beaglebone black or raspberry pi/electrical safety/git when deciding to use SB elsinore
 
I don't have experience with a physical panel, so I can't answer your question from experience. However, I can say that I miss having some physical buttons while I'm in the middle of brewing.

With the right software (or changes to Strange Brew Elsinore), you can have both. For instance, SB Elsinore allows you to toggle the status of your pump with an on-screen button. However, it wouldn't take a lot of work to make it monitor a physical button as well. Then, you could toggle the pump either way.

I've only worked with SB Elsinore, but there are some other projects that might already support a combination of on-screen and physical button control.

http://www.teensynet.com/
http://www.brewpi.com/
http://www.embeddedcontrolconcepts.com/index.html
 
I have been using ON-OFF-ON toggle switches... so i can have an off position, an on position, and an auto position for the wifi control aspect. This also gives you a quick and easy backup plan in case the controller dies on you.




I don't have experience with a physical panel, so I can't answer your question from experience. However, I can say that I miss having some physical buttons while I'm in the middle of brewing.

With the right software (or changes to Strange Brew Elsinore), you can have both. For instance, SB Elsinore allows you to toggle the status of your pump with an on-screen button. However, it wouldn't take a lot of work to make it monitor a physical button as well. Then, you could toggle the pump either way.

I've only worked with SB Elsinore, but there are some other projects that might already support a combination of on-screen and physical button control.

http://www.teensynet.com/
http://www.brewpi.com/
http://www.embeddedcontrolconcepts.com/index.html
 
I'm in the process of starting a new brewing blog and I've put up a couple posts on SB elsinore. Hope to answer some FAQs/organize information over there.

The first couple are on:
temperature probes
mash profiles
electrical safety
comparison to traditional control panels
introduction to strangebrew elsinore

http://onbrewing.com/?tag=strangebrew-elsinore-faqs
 
Last edited:
The buzzer is 3.3V-5V, check the RPi output voltage on the pin, it's probably 2.8-3V, you will need a logic level converter.
 
Amazing! This is the easiest to follow write-up I've seen on this, thanks! Now what about duty cycle time (the first block in the pid settings) ?

A shorter duty cycle time will probably wear out your SSR quicker... that being said I expect few brewers will wear out their SSRs for this reason.

A shorter duty cycle provides seemingly more consistent power to your liquid. This is most noticeable in your boil kettle, where a boil may appear to "pulse" with longer duty cycle lengths.

I use a longer duty cycle in my HLT (2-5 seconds is probably adequate) than my BK (1-2 seconds is probably quick enough to prevent boil pulsing) for this reason.
 
Most SSRs will only change state on zero-crossings of the mains voltage. This happens twice in a sine wave so for 60hz mains that would be 120 zero-crossings per second. However, since our control signals are not synched to the mains zero crossings, I recommend just using the mains frequency in the calculation. Also, for simplicity's sake, I'm also going to calculate based on the duty cycle percentages being rounded to the nearest 1% (which Doug informed me they are not) because it makes the math easier to understand. Since we would then have 100 points of resolution your minimum duty cycle times should be:

(1/60)*100 = 1.67 sec in the US
(1/50)*100 = 2.00 sec with 50hz mains

That's about the lowest I would go. With this method, using a 1.67sec a duty cycle time, a duty cycle of 1% would mean the element is activate once every 1.67 seconds for 1 cycle of AC power which is 0.0167 sec. Using a duty cycle time of less than that could give more non-linear activation times since a zero-crossing must occur for the relay to switch states. You could actually have a duty cycle setting of 1% actually be closer to 2%. I imagine there are rare instances where the element would actually be set to 1% for long enough for it to really matter for what we're doing. This is why 2-5 seconds is usually recommended. You want enough accuracy to prevent oscillations, but want to avoid undue strain on the SSR. Unless you're brewing every day, I think a 1.67sec duty cycle time will do fine for you for many years. My $0.02.

I hope I explained that well enough.

-Josh
 
Hi all, wondering if I can get some help w/ setting up the IO. (I did search the thread.)

I've got elsinore running on my BBB and a bunch of temp sensors happily reporting on Doug Edey's default 1w pin (P8.11). I'd like to set up my control pins on P8.12 and P8.15.

When I do this:

java -cp Elsinore.jar -Dgpio_definition=extras/beaglebone.json jGPIO.DTOTest GPIO1_12 GPIO1_15

jgpio creates the dto file and it has the P8.12 and P8.15 pins in there. I compile it per the instructions and I get no messages back, so I assume the compiled file has made its way.

However, when I then do this (to see what pins are available):
java -cp Elsinore.jar -Dgpio_definition=extras/beaglebone.json jGPIO.DTOTest

the p8.12 and P8.15 pins are are still listed as available. rebooting the BBB doesn't change this.

toggling the state of either pin via the web GUI and testing with a voltmeter yields no actual changes to the pin states.


I've noticed a few people are actually controlling things rather than just monitoring - would y'all let me know what I'm doing wrong? Any help would be much appreciated!
 
Hi all -

When I try to add a switch named "1" on GPIO8_12, the webpage tells me:

Could not add switch 1: GPIO8_12

Anyone getting something similar? What am I doing wrong?

Thanks-

___

(BBB running Ubuntu w/ 3.8kernel)

____

Code:
Mar 28, 2015 10:21:29 PM com.sb.elsinore.LaunchControl addSwitch
WARNING: Could not add switch: Permission denied to GPIO file: /sys/                                                        class/gpio/gpio268/direction (No such file or directory)
java.lang.RuntimeException: Permission denied to GPIO file: /sys/cla                                                        ss/gpio/gpio268/direction (No such file or directory)
        at jGPIO.GPIO.writeFile(GPIO.java:172)
        at jGPIO.GPIO.<init>(GPIO.java:111)
        at jGPIO.OutPin.<init>(OutPin.java:16)
        at com.sb.elsinore.Switch.<init>(Switch.java:54)
        at com.sb.elsinore.LaunchControl.addSwitch(LaunchControl.jav                                                        a:1018)
        at com.sb.elsinore.UrlEndpoints.addSwitch(UrlEndpoints.java:                                                        634)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Metho                                                        d)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodA                                                        ccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin                                                        gMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at com.sb.elsinore.BrewServer.serve(BrewServer.java:306)
        at com.sb.elsinore.NanoHTTPD$HTTPSession.execute(NanoHTTPD.j                                                        ava:920)
        at com.sb.elsinore.NanoHTTPD$1$1.run(NanoHTTPD.java:192)
        at java.lang.Thread.run(Thread.java:745)


Also, I have this in sys/devices/capemgr.9/slots

0: 54:pF---
1: 55:pF---
2: 56:pF---
3: 57:pF---
4: ff:p-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:p-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
7: ff:p-O-L Override Board Name,00A0,Override Manuf,w1
8: ff:p-O-L Override Board Name,00A0,Override Manuf,jgpio


One last thing, possibly related:

when I try to do:

sudo echo jgpio > /sys/devices/bone_capemgr.9/slots

bash: /sys/devices/bone_capemgr.9/slots: Permission denied
 
Hi all, wondering if I can get some help w/ setting up the IO. (I did search the thread.)

I've got elsinore running on my BBB and a bunch of temp sensors happily reporting on Doug Edey's default 1w pin (P8.11). I'd like to set up my control pins on P8.12 and P8.15.

When I do this:

java -cp Elsinore.jar -Dgpio_definition=extras/beaglebone.json jGPIO.DTOTest GPIO1_12 GPIO1_15

jgpio creates the dto file and it has the P8.12 and P8.15 pins in there. I compile it per the instructions and I get no messages back, so I assume the compiled file has made its way.

However, when I then do this (to see what pins are available):
java -cp Elsinore.jar -Dgpio_definition=extras/beaglebone.json jGPIO.DTOTest

the p8.12 and P8.15 pins are are still listed as available. rebooting the BBB doesn't change this.

toggling the state of either pin via the web GUI and testing with a voltmeter yields no actual changes to the pin states.


I've noticed a few people are actually controlling things rather than just monitoring - would y'all let me know what I'm doing wrong? Any help would be much appreciated!

Are you running bbb_setup.sh after? This needs to be ran after every boot as well before the pins will work.
 
thanks jangevaa - well, I hadn't, but now I have and I have the same result.

One other odd thing is that I can't seem to run elsinore as a service anymore, only by sudo ./launch.sh. Don't know if that's related.
 
The issue is you need to run the echo command as root

sudo su
echo ....

ah, thanks Doug. Well, I did that and now get:


root@arm:/home/ubuntu/SB_Elsinore_Server# echo jgpio > /sys/devices/bone_capemgr.9/slots
bash: echo: write error: File exists

my slots file is shown above.. it has an entry for jpgio, so maybe I already did it correctly some time ago.
 

Latest posts

Back
Top