TeensyPi Networked Temperature Controller

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.
The Teensy 3.0 and RPi both have initialization routines that they have to go through. In the RPi's case it's a complete boot of a full LAMP stack in a Linux OS. It takes a finite amount of time to get that all up and running. Once the RPi is up and running, the cron program can take up to a full minute to start the teensypi_daemon program that initializes the serial socket between the Teensy 3.0 and RPi.

The Apache webserver comes online before the MySQL database is initialized and started. Any attempts to access the Teensy 3.0 board at that point will probably result in a "Database not found" error.

Attempts to access Teensy 3.0 prior to the teensypi_daemon starting will probably result in "socket error" or "file or directory not found" errors.

These items can be addressed, but to me they are currently lower priority since the system does work if given the opportunity to get it's house in order. This is also why I've left the error messages on the webpage instead of using "die" or logging the errors straight to a file.

If I'm starting up from a dead start, I normally power everything up, and then open an ssh connection to the teensypi.local address. Since openssl starts after both Apache and MySQL when I am successfully logged in, I am reasonably assured that the teensypi_daemon will start in a minute or less.

You could also use the ssh terminal to view the apache error log to see exactly when the teensypi_daemon comes on line. On the command line enter

tail -f /var/www/log/error.log

and press enter. Now open a web page to teensypi.local. If the teensypi_daemon isn't yet running, you'll see a running error trail that will show the time. When the time crosses the :59 second mark, the cron program should fire, the daemon should start, and the page should refresh with the chip data.

I realize that I'm more familiar with the process and perhaps accept some of its quirks more easily that the rest of you :cross: , but rest assured that I am more than willing to work with anyone that is trying to get their system fully operational.
 
For me that does not seem to be the problem. I can access everything on the TeensyPi (ssh, phpmyadmin, html pages, ftp, etc) just not pages with the MakeASocket.PHP include. I created some dummy .php pages to confirm it wasn't PHP. I have it hooked up to a monitor to confirm the boot is complete.
 
The Teensy 3.0 led is ON when serial communications with the RPi is enabled, and OFF when the serial channel is restricted. Serial communications are restricted during the times that chips are being interrogated or written to, or when EEPROM is being written to.

If you have a small number of chips on the 1-wire bus, the LED will probably be ON most of the time, as chip interrogation and writes take very little time. When I'm running the full complement of 36 chips, the LED is very dim.
 
For me that does not seem to be the problem. I can access everything on the TeensyPi (ssh, phpmyadmin, html pages, ftp, etc) just not pages with the MakeASocket.PHP include. I created some dummy .php pages to confirm it wasn't PHP. I have it hooked up to a monitor to confirm the boot is complete.

Open a ssh terminal and type

ps aux | grep teensypi_daemon | grep -v grep

and press enter.

You should get just one teensypi_daemon result. If you have more than one (this happens sometimes, though I'm not sure why yet) look at the PID value of each daemon and then kill both with

sudo kill -9 PID#1 PID#2

where PID#1 and PID #2 are the actual PID values. Then allow cron to restart the daemon.

Gotta go, SWMBO's giving me the stink-eye, and dinner's getting cold.
 
The COSM feed is redbenn's baby, so maybe he could chime in on that.

As for the onboard data collection, it only runs when the Action or PID is enabled. If it ran all the time, it would rack up a huge mysql database file in a fairly short period of time, and since I haven't yet provided a web page to allow the data to be removed from the database. I felt that was a prudent step to take.


Ran my rice cooker test last night and didn't have any issues with the onboard data collection. Ran it in the standard temp control mode so I'm anxious to test the PID tonight. Apologies for modifying the logo but I needed to make it family friendly (plus I impressed myself with figuring out how to do it....). I'll work on the COSM feed tonight as well. Looking forward to some sous vide eggs (148deg for an hour) as the first tangible (and edible!) output of my build, assuming the PID tuning goes well! I can't start my eKettle build until I have a working control system so I'll keep testing.

photo.jpg
 
Have you looked at using an Arduino Ethernet or wifi shield to post the data to a home server? As I have a NAS/media server running at my house, that seems to make sense. I was reading the installation wiki and noticed that the RPi communicates with the Arduino via the serial bus. I have put this on my project to do list, though notably without a date and will ultimately (and hopefully) get sufficiently familiar with the hardware and code to make the arduino-only config happen. Just curious if you had looked at any of that and had any initial guidance for me.

Great work! Spectacular project.
 
Have you looked at using an Arduino Ethernet or wifi shield to post the data to a home server? As I have a NAS/media server running at my house, that seems to make sense. I was reading the installation wiki and noticed that the RPi communicates with the Arduino via the serial bus. I have put this on my project to do list, though notably without a date and will ultimately (and hopefully) get sufficiently familiar with the hardware and code to make the arduino-only config happen. Just curious if you had looked at any of that and had any initial guidance for me.

Great work! Spectacular project.

I originally started this project using a Freetronics Ether10, and then a Freetronics EtherMega. I moved to the RPi since I could get a full linux / LAMP stack for what I was paying for a real arduino ethernet shield. When I found the Teensy 3.0 board, the project morphed into what it is now.

While I could serve a small number of web pages with an Arduino/ethernet shield combo, it drastically reduced the number of devices I could control and made changes and naming of devices problematic. The Teensy 3.0 / RPi configuration is scalable and highly modifyable (see redbenn's upcoming UI as an example).
 
Sorry--I don't know how I got the Teensy and Arduino boards swapped as I read the wiki and the thread. What I was really getting at was using my existing LAMP server with a controller board. The part that I haven't skinned, though, is the connection between the controller board (Teensy or whatever) and the server. More thinking to come on that topic, I suppose.
 
Sorry--I don't know how I got the Teensy and Arduino boards swapped as I read the wiki and the thread. What I was really getting at was using my existing LAMP server with a controller board. The part that I haven't skinned, though, is the connection between the controller board (Teensy or whatever) and the server. More thinking to come on that topic, I suppose.

You could use any Linux LAMP stack, you'd just need to control one of the serial ports via the teensypi_daemon, and use level shifters to get the TTL/RS-232 down to 3v3 for the TeensyPi or 5v for an Arduino Mega2560.
 
Just got my RasPi in the mail from Allied Electronics. Can't wait to set this bad boy up.
 
I've been investigating the reported problems in the new PID-based .ino file, and I think I've got it narrowed down.

It looks like a combination of EEPROM miscalculation and PID value recovery during power-up.

The way things look right now, I'm going to have to reduce the number of PID controls from 12 to around 8, and modify the PID setup on the Teensy 3.0.

I'll post a new .ino file for the Arduino IDE, hopefully in time for weekend testing. :eek:

UPDATE: Posted a new PidStatus.php and TeensyPiPidDebug.ino at my github account.
 
jimmayhugh said:
I've been investigating the reported problems in the new PID-based .ino file, and I think I've got it narrowed down.

It looks like a combination of EEPROM miscalculation and PID value recovery during power-up.

The way things look right now, I'm going to have to reduce the number of PID controls from 12 to around 8, and modify the PID setup on the Teensy 3.0.

I'll post a new .ino file for the Arduino IDE, hopefully in time for weekend testing. :eek:

UPDATE: Posted a new PidStatus.php and TeensyPiPidDebug.ino at my github account.

Thanks Jim, awesome.
 
doughaas said:
I checked all my solder points and checked voltages across the buses with my multimeter.

3v3 to ground is 3.3v
5v to ground is 5v
Data to ground is around 1.1v
3v3 to data is 2.2v

My buses are consistent.

When I scan for new devices with a sensor connected the teensy led stops blinking, becomes solid and 3v3 to data voltage becomes 3.3v.

It stays 3.3v as long as the teensy led is solid even once I disconnect the sensor.

Is this a problem with my pull up resistor?

I checked all my solder points and cleaned up a few but it didn't fix the problem.

What did fix the problem was switching to the pid ino.
 
Excellent!!

A couple issues with the new build:

After clicking PID Status, the PidStatus.php page loads and displays 4 lines of "Address Query Failed".

If I click the "modify" button I get a hex number populated in the Set Point text box. If I change it to an integer and attempt to SAVE, The page fails to update and I can no longer access the web server. Even after restarting apache and mysql I still need to reboot to access the web server again. The PID status fails.
 
Excellent!!

A couple issues with the new build:

After clicking PID Status, the PidStatus.php page loads and displays 4 lines of "Address Query Failed".

If I click the "modify" button I get a hex number populated in the Set Point text box. If I change it to an integer and attempt to SAVE, The page fails to update and I can no longer access the web server. Even after restarting apache and mysql I still need to reboot to access the web server again. The PID status fails.

Make sure that there are two new tables in MySQL, pid and pidGraph. If not, get the pid.sql and pidGraph.sql files from my github site and imports them using phpmyadmin.

I built a new TeensyPi over the weekend with the new files and everything was copacetic.
 
Make sure that there are two new tables in MySQL, pid and pidGraph. If not, get the pid.sql and pidGraph.sql files from my github site and imports them using phpmyadmin.

I built a new TeensyPi over the weekend with the new files and everything was copacetic.

Thanks, yes I downloaded everything today and did the sql import using both files. I'll keep looking around.
 
I'm also having trouble with the new PID build. I've downloaded and loaded it twice, including the RPI image and have the same issue. After loading the teensy I can update the chip names, read the temp sensors and manually turn the switches on/off. I can set an action and it seems to work fine. When I try to setup the PID, it will allow me to enter the variables but when I hit try to enable the LED on the Teensy goes from steady to off and my web interface freezes (tries to refresh but never gets a response). Rebooting the Teensypi doesn't unfreeze the interface. If I reload the Teensy with the PID Debug .ino, the LED immediately goes back on steady and remains on until I try to enable the PID.

Since updating the Teensy with the PIDdebug.ino, the LED no longer flashes rapidly/dims. It is either on steady and bright (even if the temps are updating just fine in the web interface) or it's fully off which coincides with the web interface hanging. I can still SSH/login to the TeensyPi so the RPi still seems to be operating at that point, wlan1 is operating, etc.

I again reloaded the MySQL files as suggested above but no change.

Any suggestions?
 
I'm also having trouble with the new PID build. I've downloaded and loaded it twice, including the RPI image and have the same issue. After loading the teensy I can update the chip names, read the temp sensors and manually turn the switches on/off. I can set an action and it seems to work fine. When I try to setup the PID, it will allow me to enter the variables but when I hit try to enable the LED on the Teensy goes from steady to off and my web interface freezes (tries to refresh but never gets a response). Rebooting the Teensypi doesn't unfreeze the interface. If I reload the Teensy with the PID Debug .ino, the LED immediately goes back on steady and remains on until I try to enable the PID.

Since updating the Teensy with the PIDdebug.ino, the LED no longer flashes rapidly/dims. It is either on steady and bright (even if the temps are updating just fine in the web interface) or it's fully off which coincides with the web interface hanging. I can still SSH/login to the TeensyPi so the RPi still seems to be operating at that point, wlan1 is operating, etc.

I again reloaded the MySQL files as suggested above but no change.

Any suggestions?

Try downloading the very latest TeensyPiPidDebug.ino file from my github, compile and upload it to the Teensy 3.0. You'll know you have the latest code if you go to the /var/www/htdocs directory and issue the command

Code:
php getCommand.php z

The TeensyPi should return a version string:

Code:
teensypi@teensypi /var/www/htdocs $ php getCommand.php z

Number of Arguments:2
getCommand.php
z
TeensyPiPidDebug Version 0.0.1

That should correct the problem.
 
Jim:

So I did the following (using Putty):

teensypi@teensypi ~ $ cd /var/www/htdocs
teensypi@teensypi /var/www/htdocs $ php getCommand.php z

...and got the response:

Number of Arguments:2
getCommand.php
z
TeensyPiPidDebug Version 0.0.1

No change in the behavior/performance. I also tried turning on the Debug messages (not that I would understand them) following the directions on the Teensypi website. Got the minicom running fine and got all the expected responses from the commands but no minicom traffic/messages on the PID, EEPROM or all debug messages options.

Setup an action setting and again that seemed to work fine but "Enabling" the PID froze/crashed it as described earlier.

Can you provide some entries for the PID settings that you have used successfully? I've used the one's in the website screenshots as well as, for example, Setpoint 148, P = 1100, I = 1, D = 1, Direction = Forward, Window = 5000. Wouldn't think that my entries would be crashing the Teensy but just to eliminate that possibility I'd like to try a "known good" setting.

Thanks...Jon
 
Jim:

So I did the following (using Putty):



...and got the response:



No change in the behavior/performance. I also tried turning on the Debug messages (not that I would understand them) following the directions on the Teensypi website. Got the minicom running fine and got all the expected responses from the commands but no minicom traffic/messages on the PID, EEPROM or all debug messages options.

Setup an action setting and again that seemed to work fine but "Enabling" the PID froze/crashed it as described earlier.

Can you provide some entries for the PID settings that you have used successfully? I've used the one's in the website screenshots as well as, for example, Setpoint 148, P = 1100, I = 1, D = 1, Direction = Forward, Window = 5000. Wouldn't think that my entries would be crashing the Teensy but just to eliminate that possibility I'd like to try a "known good" setting.

Thanks...Jon

OK, I was able to duplicate the problem, but I won't be able to investigate until the weekend. :mad:
 
Not sure if this is helpful but another piece of info on the lockup; on one occasion I had an action going where it was controlling my rice cooker set at 120 degs. Separately, I tried to enable a PID and it hung the interface as described earlier. The switch/relay continued to be on while the temp climbed well past 120 and when I rebooted the TeensyPi it continued to be on but was no longer associated with an action. I could see that the switch was "ON" but it wasn't tied to a temp probe so it would have stayed on until I turned it off. My learning from that, for what it's worth, is that it isn't solely a user interface issue as the control function failed/froze as well. Second learning was that I will need some type of safety mechanism in place that insures that when the Teensypi reboots itself (power failure?) it won't come on with the switches on but not tied to some control function.
 
Not sure if this is helpful but another piece of info on the lockup; on one occasion I had an action going where it was controlling my rice cooker set at 120 degs. Separately, I tried to enable a PID and it hung the interface as described earlier. The switch/relay continued to be on while the temp climbed well past 120 and when I rebooted the TeensyPi it continued to be on but was no longer associated with an action. I could see that the switch was "ON" but it wasn't tied to a temp probe so it would have stayed on until I turned it off. My learning from that, for what it's worth, is that it isn't solely a user interface issue as the control function failed/froze as well. Second learning was that I will need some type of safety mechanism in place that insures that when the Teensypi reboots itself (power failure?) it won't come on with the switches on but not tied to some control function.

Yeah, the Teensy 3.0 is set up to renew it's last known state before a power failure or reboot. This is a throwback to when its primary function was to monitor / control my coolers.

This PID bug is pretty insidious, but I think I've tracked it down. It looks like it's going to require changes to the .ino and some .php codes.

More later.
 
Great! Downloaded the fixes but if I want to stay married I probably won't get to implement/test until the weekend...

Thanks for the persistence!
 
Wife went on an errand so I did get to load the updates and SUCCESS! PID function is working. Now I just need to play with the tuning. Excellent work on the fix Jim!

PID Test.jpg
 
I've also loaded up the new files and everything seems to be working well.

I've noticed a change in the behavior of the teensy LED with this update - it's now constantly solid. Is that by design or should I reflash?

I've rebooted it a couple of times without any change but everything works well despite the solid LED.
 
I've also loaded up the new files and everything seems to be working well.

I've noticed a change in the behavior of the teensy LED with this update - it's now constantly solid. Is that by design or should I reflash?

I've rebooted it a couple of times without any change but everything works well despite the solid LED.

The LED is just an indication of the level of serial communication between the Teensy 3.0 and RPi. When the Teensy 3.0 is doing something that it doesn't want disturbed by a message from the RPi, the LED is off. This will vary with the number of devices, active actions and active PIDs. When I have all 32 devices on my test bed in active actions or PIDs, the LED is very dim. When I hit the Emergency STOP button, the LED is very bright.
 
I think I've nailed down the PID bug, and in the process did some general cleanup.

The new TeensyPiPidDebug.ino and *.php files are uploaded to my github account.

Thanks for your patience... :cross:

Excellent, once I get off shift in a couple days I'll reflash my Teensy, the other files are already uploaded to the RPi.
 
Been away for a while have the 1st version plugging away as just a remote temp monitor for now, got a new Pi and Teensy this week.

I am considering using the Pi locally with a screen to access the Teensy controls. If I were to use the Occidentalis distro and loaded a Apache/MySQL/PHP what else would I need to access the Teensy? Would there be enough power to run the GUI and TeensyPi functions?
 
I've run the TeensyPi on the 256MB version of the RPi with no problems, so if you wanted to run a GUI, it would probably be OK, if you ran a lightweight browser on a 512MB RPi.

The RPi has about the same computing power as a Pentium III.
 
I finally got my TeensyPi PC boards back from the fab shop, loaded one up and tried it.

IT WORKS :ban:

TeensyPiBoard.png


This replaces the Adafruit Prototyping Pi Plate.

I've uploaded the Eagle Light and Gerber files to my https://github.com/jimmayhugh/TeensyPi for anyone that would like to make their own.

I used Seeed Studio's Fusion PCB Service, got 10 bare boards for about $35, including shipping.

This is also posted at my web site.

What are the dimensions of the board? Thickness you used?
 
You could just as well put the boards two-up on the 10cm x 10cm boards, and get twice as many boards for the same price--you'd just need to cut them apart yourself. Looks very interesting! I may need to take the plunge...

Do I hear a group buy opportunity developing? I'm interested in 2-4 boards.

Thanks...Jon
 
I'm not 100% happy with the layout yet, the next iteration will have wider power and ground traces. I may also consider springing for the hobbyist verson of Eagle in order to do 4-layer boards.

I'm also not a vendor at this site, and don't want to imply that I'm trying to sell anything, which is why I made the Eagle and Gerber files available.
 
I'm not 100% happy with the layout yet, the next iteration will have wider power and ground traces. I may also consider springing for the hobbyist verson of Eagle in order to do 4-layer boards.

I'm also not a vendor at this site, and don't want to imply that I'm trying to sell anything, which is why I made the Eagle and Gerber files available.

Any thought of using that blank area for a bus to connect temp sensors and another for switches?
 
Also, did you ever figure out the LCD's? I got the Raspberry Pi LCD Plate from Adafruit (i2c and buttons) and cannot seem to get it to work. I'm not sure if it is because of a conflict with the Teensy... I am currently troubleshooting.
 
Back
Top