HeaterMeter + LinkSys WiFi Router = LinkMeter


 
I changed out the Irl510 to a NTE2987(could not find 2985), after I tried a Heatsink on the 510. So far, all is good.

Edited: Since I have made the change to the 510 mosfet, I have had no lock up's. So, if people want a bigger blower, N-channel, Logic level Mosfets(nte2987,nte2985, RFP30N06LE) would be needed.
 
Nice work, John. That NTE2987 is a monster. Up to 20A continuous drain? Wow! Did you change the fan capacitor at all? I experimentally had selected the 22uF part because it made the fan quieter without sacrificing too much control over the voltage. With that massive blower you have, I was wondering if the cap does anything at all.
 
Nope, i just changed the mosfet, it does seem quieter with the new mosfet. The Cap, I have no idea. the arduino forum said I just needed the logic level mosfet to fully turn on the Mosfet. I don't think it would hurt anything. The mosfet does not even get warm to the touch, the IRL510 got very warm with the bigger fan,im not sure if it did with the 6.7cfm fan.

The bigger fan, does help alot as I can use the ball valve to control what goes into the smoker, as the blower creates more pressure.
 
It does sound pretty sweet. I was thinking on the plane back from Washington that I should try making a damper control that uses a stepper motor to slide the damper door open or closed to regulate the temperature. It would remove the need for the big 12V high current section, but then the design is a lot less portable to other BBQs. Also, stepper motors take 4 digital pins sooo that would mean adding another microcontroller. Just another thing to try someday!

I've spent all morning this morning working on the interprocess communication from the web server process to the linkmeter daemon. Currently we're still using the hack of having the daemon drop files into /tmp and the web server process just reads those. With the new system the web process can actually interact with the service to do more advanced queries.

I ran into a huge snag where the client couldn't receive any data back from the server. I tracked this down to the LuCI nixio implementation of recvfrom() from an unnamed UNIX domain socket returning a garbage source address. I've got bidirectional communication now working with an autobound abstract namespace UNIX domain datagram socket! I've also sent the patch to the LuCI folks too, so LinkMeter development (slightly) contributes to yet another project.

The full client-server communication is still a little ways away so don't expect to see any pushes until it is done. I am still working though!
 
Thanx Bryan!!

I followed your instruction with a fresh copy of Backfire and Linkmeter, but still get

/backfire/staging_dir/target-mipsel_uClibc-0.9.30.1/usr/lib/liblua.so: undefined reference to `crypt''

when compiling linkmeter in Backfire, but it's probably UTS on my part (user too stupid).

So I set that aside and built it under the Attitude Adjustment trunk. With ease ;-)

Then, I spent a few hours tweaking it for an ADM5120 target with a 2meg flash. A six pack of highly caffeinated beverage later, and I've got it up and running, at least the gui portion. I need to tweak a little more, then I'll see if I can get a 2meg WRT54g version.

Ed: I'll cleanup my post here shortly, once I have completed my work enough to warrant starting a new thread
 
I ran into a huge snag where the client couldn't receive any data back from the server. I tracked this down to the LuCI nixio implementation of recvfrom() from an unnamed UNIX domain socket returning a garbage source address. I've got bidirectional communication now working with an autobound abstract namespace UNIX domain datagram socket! I've also sent the patch to the LuCI folks too, so LinkMeter development (slightly) contributes to yet another project.
Click to expand...


can you translate that, lol. j/k

I have seen a damper control like that on another forum. He used a weber damper attached to a servo from the likes of a model airplane.
 
Originally posted by Brian Hilgert:
/backfire/staging_dir/target-mipsel_uClibc-0.9.30.1/usr/lib/liblua.so: undefined reference to `crypt''
Click to expand...
Doh! I'll blow away the directory and try it again from scratch and see if I can reproduce it. Can you verify that your heatermeter/openwrt/package/rrdtool/patches/140-fix_lua_detect.patch contains -lcrypt on the 4 lines that start with +?

Also, you squeezed it down to 2MB? Whoa! You musta removed some serious amounts of packages to get it that low. I think the lowest I've had it was around 2.3MB. Tell me more!

Haha yeah John, well, you see it is complicated. I'll explain it though because someone may find the design interesting or inspirational.

As we all know, inside LinkMeter there is a HeaterMeter board which is connected via serial inside the router. There is a daemon running on the router that reads serial data as it comes in, then builds a "current snapshot" file used to display the current data on the web page. It also keeps the database up to date with the latest info. The web pages have to use these external files to see what's going on because they can't read the serial port directly without messing up the running daemon. That's ok because some of the data (such as RFM12 status information) only comes every once in a while so the request would just hang for a very long time waiting for the right info to come through the serial port.

For setting values from the web pages, I currently do a Very Bad Thing and something that really shouldn't work at all. I open the serial port a second time from the web server and write the configuration directly without involving the daemon. Again, I am shocked this even works properly and I have to be careful to not issue any reads because this would mess with the daemon process. I can't "talk" with the HeaterMeter because of this lack of ability to get feedback from the device.

This is a pretty common problem in programming where you have multiple things that want to access a limited resource. The solution is obviously to have one thing that handles talking and everybody else talks to that. The big question to consider is how everybody will talk to the arbitrator. You can't just make function calls from the client into the server because they're in different processes and therefore protected from each other.

The quick and dirty method is to do what we're doing now, files. The server drops out some files and the clients read the ones their interested in. For talking back to the server this gets more complicated if there is more than one client active at a time (a possibility because the web server can handle multiple requests simultaneously). It also has a high overhead, reading and writing files, as well as high latency due to the server and clients polling directories for these files.

For getting data into and out of a process, there is nothing better than a pipe. You use pipes all the time to tunnel the output from one program to the input of another, for example `ls -l | grep myfile` starts two processes and links them via a pipe. Pipes are also called FIFOs because the data coming through them arrives in the order it is sent. In addition to input and output pipes, processes can create "named pipes" which have filenames and exist in the filesystem under Linux. Because a single FIFO is unidirectional, a server which needs to "talk" with a client would need to create two named pipes, one to read from the client and one to write back to it. Pipes are great super-lightweight way to communicate from one process to another.

Their downfall is because the data that goes in and out of pipes is "single instance" such that there's only one copy of any bit of data sent down it. Therefore if client B opens the pair of named pipes and asks the server a question while client A is still waiting for a response, whoever is able to read data faster will get all the responses. Client A may get client B's answer and discard it leaving client B waiting for a response indefinitely.

So now we can see to serve data to many clients in different processes, we need a bidirectional channel per client. The answer to this is to use a socket. We could use a TCP/IP or UDP socket but under UNIXes there's a special type of socket that doesn't rely on a network connection at all called a UNIX-domain or AF_LOCAL socket. These can be unidirectional or bidirectional, can have names, and each client can have its own connection. This is the most common method used for communication to Linux daemons, used in small things like wpa_supplicant all the way up to bigger things like a MySQL connection.

Instead of connecting like a TCP/IP socket, with an IP address and a port, a named UNIX socket can live in one of two places. It can have a filename in the filesystem like /var/run/mysql/sock (pathname UNIX socket) or it can exist in the abstract namespace which is sort of like a virtual filesystem that is just in kernel memory. Abstract namespace sockets still have names so clients can find them, but are automatically deleted when the last socket referencing them is closed. Generally, you'll want to expose your server's interface on a pathname socket because A) it is visible B) the permissions of the file provide security over who can connect to it. There's also a third type of UNIX socket address which is called unnamed. This is a socket which has not been bound to a pathname or a abstract name. An unnamed socket has no "address" where pathname and abstract sockets do.

For the client's end of the socket you can't use a fixed pathname for all clients, because if more than one tries to connect, they'll conflict on who has the name. Usually, the programmer creates these in the abstract namespace so the client doesn't have to worry about cleaning up pathname files left on the filesystem or uses an unnamed socket.

Now that we know we want a pathname UNIX domain socket for the server, we need to decide if it is connection-oriented (stream) or connectionless (datagram). For larger amounts of data, stream sockets are best, but for our simple query-response structure datagrams are fine. They have less overhead and don't require you to keep track of a separate socket descriptor for each client you're talking to. Also because we're using a 2.6 Linux kernel, UNIX datagram sockets have guaranteed in-order delivery and have atomic writes for up to 4k (any write of less than 4k of data completes in one call). This means no reassembling or reordering packets like you'd experience using a standard network UDP socket.

That's how the client talks to the server, but how does the server talk back? Well if we used stream sockets, the server could just write back on the same socket descriptor that it read from. However, we're using datagram sockets so we need to direct our write back to the correct client. The way to do this is to use recvfrom() on the server socket, which will receive data *and* tell you who it is from so you can use sendto() to talk back to them.

Remember how I said that unnamed UNIX domain sockets have no address? Well now you see where the problem arises. If the client creates an unnamed datagram UNIX socket, the server gets no address from recvfrom() and can't write back to it. This is where the bug was in OpenWrt's LuCI nixio package. If you recvfrom()ed an unnamed datagram UNIX socket, you'd get an address back, it was just garbage off the stack. If another client connected with a named UNIX socket, the unnamed recvfrom() would coincidentally return the name of the named socket so the unnamed client would never get any data back and then named client would get extra data.

So what I ended up doing, in addition to fixing the bug, was to verify that every client had a named UNIX socket. I use a feature of Linux called "autobind" which says if you try to bind a datagram UNIX socket to a blank name, it will figure out a unique name for your socket in the abstract namespace.

So there you have it, bidirectional communication working with an autobound abstract namespace UNIX domain datagram socket. The web server process(es) can now talk to the LinkMeter daemon and have live bi-directional communication without the need for relying on temporary files like we do now (e.g. /tmp/json).
 
Also, Brian, my new backfire build just completed without any errors. Check to make sure your build_dir/target-mipsel_uClibc-0.9.30.1/rrdtool-1.4.5/configure.ac is being patched correctly to include the -lcrypt. Check the patch in the heatermeter tree first to make sure it is there, then check the above path to makes sure it applied.
 
Bryan;

Tried a fresh build of backfire; smae issue. I verified that the patch contained the -lcrypt, as did the configure.ac on ~line 763.

Probably a newb observation, but my rrdtool compiles fine, It the actual linkmeter package that throws the error...

Also, can any one direct me to some documentation on the arduino side of things?
 
Also, stepper motors take 4 digital pins sooo that would mean adding another microcontroller
Click to expand...

Time to look at a Mega? Or just the raw Atmega 1280? This would also give plenty of pins for driving displays without the shift register which has be problematic for some.....
 
Originally posted by Bryan Mayland:
There's some information about it in the wiki
https://github.com/CapnBry/Hea...er/wiki/Installation
Click to expand...

That's what I was looking for. Sorry, I was a little sleep deprived yesterday
icon_frown.gif
 
Originally posted by Brian Hilgert:
That's what I was looking for. Sorry, I was a little sleep deprived yesterday
icon_frown.gif
Click to expand...
That's ok, it wasn't there yesterday
icon_smile.gif
I added it this morning from John's outline.

RJ, that does look pretty cool. I love it when people pull things apart and find that the whole, even discarding some of the parts, has more value than trying to build the same thing yourself. I dunno about the bigger atmega though. It would be nice to have more pins to do more things but I also don't want to change much on the hardware side that takes away all backward compatibility.
 
Just wanted to start off by saying thanks to Ed and Bryan and everyone involved for documenting this awesome project!

I'm interested in building one as well for my BGE, but want to try it with my Buffalo WHR-G125. As an open firmware router, it's been amazing over the years and just as reliable (slightly better actually) than the wrt-54g's I've worked with.

Firmware/Software aren't an issue for me, but i'm afraid the hardware schematics are a bit confusing. Has the topic of using non-linksys routers been discussed and if not, is there any resource I can take a look at to try it out?

Thanks!
 
From the beginning this has been just a Linksys router build. I know Brian Hilgert is using another router, he is the only other person I know of that is using a different router/printer server.

The router you have does have a serial connector |
| rx o
| tx o
| gnd o
| vcc o
-------------
vcc not used

So, I would imagine if you are able to load and get the software to work on the router it should be able to communicate with the heatermeter, brian or Ed will have to verify that though.

Building the Heatermeter from the schematic is not difficult but, if your soldering skills are lacking, like mine were, then it could be frustrating.
 
Originally posted by RoyL:
I'm interested in building one as well for my BGE, but want to try it with my Buffalo WHR-G125. As an open firmware router, it's been amazing over the years and just as reliable (slightly better actually) than the wrt-54g's I've worked with.

Firmware/Software aren't an issue for me, but i'm afraid the hardware schematics are a bit confusing. Has the topic of using non-linksys routers been discussed and if not, is there any resource I can take a look at to try it out?
Click to expand...
I agree with you that the WHR-G125 is a pretty great device. I had one a while back and never had any problems with it needing to be rebooted or dropping off the network for no reason. It does have a serial port in it, the necessary 16MB of RAM and 4MB of flash, and a compatible Broadcomm chip. The problem is that the power supply appears to be 3.3V. We actually use the router's power supply to run the blower motor directly, so only devices with 9V or 12V power bricks can work really unless you want to add a second power supply to the device.

I've actually got two different other devices sitting in my HeaterMeter Lab with the idea of converting them as well. One is an Atheros device that doesn't even run DD-WRT without hanging so that's probably garbage (but hey it only cost $10 and came with a 12V power supply so not a terrible loss). The other has a lot more promise as it has a faster CPU, twice the RAM, and a much smaller form factor but I haven't been able to get OpenWrt to boot on it. DD-WRT works fine though so clearly it is an option. I haven't spent much time on it though other than to try packing an ASUS firmware for it. It is I think the last thing on my TODO list.

The schematic may seem a bit daunting I'll agree, but even I had almost no experience in building circuits a year ago when I started this project so how hard can it be, right?
 
Originally posted by Bryan Mayland:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by Brian Hilgert:
That's what I was looking for. Sorry, I was a little sleep deprived yesterday
icon_frown.gif
Click to expand...
That's ok, it wasn't there yesterday
icon_smile.gif
I added it this morning from John's outline.

RJ, that does look pretty cool. I love it when people pull things apart and find that the whole, even discarding some of the parts, has more value than trying to build the same thing yourself. I dunno about the bigger atmega though. It would be nice to have more pins to do more things but I also don't want to change much on the hardware side that takes away all backward compatibility. </div></BLOCKQUOTE>

For those of you that have rolled your own solution and have put a bootloader on your Atmel, how is this done (FTDI, JTAG)? Do you think there is any likelyhood that I could get the arduino bootloader on the echo-6 device? I know the chances that the display uses a shift register and that the buttons are compatible are Zero but for $17 I may just get one to see.

Also, this one has a metal case and appears to already have a U?SB interface:
http://www.hobbyking.com/hobby...r_w_accessories.html

Look at the middle picture.
 
You must log in or register to reply here.

 

Back
Top