I started out to write a post about an article I read in the Denver Business Journal titled "Going with the (beer) flow. It's about TrenStar a Colorado based company that specializes in mobile asset management. Specifically they put RFID on beer kegs and other containers. The story is interesting so be sure and read it.
On a lighter note while reading other beer related articles I ran accross Kegbot a fun use of technology that lets you know how much beer is left in the keg, who drank the most out of it etc. A huge list of features follows but before that I want to know where I can buy one and why didn't any of my college buddies think of this?
presence-based access-control. ibuttons were selected as the underlying keying system for the kegerator because they can be checked for presence. compare this to a barcode or worse, a magnetic stripe: once a card is swiped, we have no automatic way to tell if the user is still near the kegerator. as soon as the ibutton is inserted, beer is available; as soon as it is removed, the flow stops.
flexible access control. currently, access is granted by requiring a user to present his iButton to the kegerator, but other mechanisms are easily supported: barcodes, magnetic stripes, username/password pairs.
comprehensive drink and user tracking. every drop of beer that comes out of the kegerator is tracked. this data can be analyzed and aggregated into drinks, costs, and so on.
cost-based access control. a kegbot system, as part of its multi-user access control, may be configured with many pricing brackets and access conditions for dispensing beer. in turn, these may be assigned at different granularities: one user may be allowed free beer, where the site-wide default is to charge the actual cost. it is therefore possible (and easy) to express complex billing policies with just a few clicks. (a more comprehensive look at the beer ACL and billing system will be filled out here, time permitting.. it's really cool..)
lowest-cost pouring. because a user's account stores a set of granted policies, there may be more than one way to pour a drink. for example, a user may have permission to pour up to 16 ounces for free, and another grant for beer at cost. the kegbot, at pour time, will select the lowest-cost way to pour the drink. this should always be what the user desires. further, this selection is adjusted in realtime, so if those free 16 ounces are used while beer is still pouring, a new permission will be used without interruption. (if no more permissions remain, the flow stops.)
software fridge thermostat. see the thermo page for why this is a very good thing.
double watchdog alarms. if the embedded microcontroller fails to activate the fridge (or stops reporting), the host computer may activate alarms, such as paging me on my cellphone. similarly, if the microcontroller does not hear from the host in a while, it may activate its own alarm.
public (XML-RPC) interface. when keg 1 was installed, the kegbot already had a publicly accessible RPC interface, so that other clients could learn the status of the kegerator. in this manner, i was able to monitor the keg's temperature while at school, in case anything when wrong in the early days of testing.
AIM chatterbot interface. as of late 2003, the kegbot now has an online presence via AOL Instant Messenger. this aimbot uses AIML, a reduction language for building apparently intelligent bots. when online, the bot responds to questions such as 'what is the beer temperature?', 'who had a drink last?', and can be trained to do more. in the future, it is expected that an extension will be added to this bot to allow it to pester known drinkers. "mike, you had a drink 45 minutes ago, and i'm currently ice cold. want another?"
hardware is 'default deny'. in the absence of permission from the controlling computer, the hardware of the kegerator will not dispense beer. (basicaly, the solenoid valve is normally closed.) thus, the physical security of the valve power lines needs to be assured.
LCD status. the kegbot is equipped with a 20x4 character LCD, which is just perfect for displaying rotating statistics and, during a pour, a live flow graph.
separate web interface. a web site supporting a kegbot (for instance, mine) is a component completely isolated from the kegbot itself. though it does use the same back-end as the kegbot, it otherwise does not interfere with the operations of the kegerator. this abstraction also means that you are by no means bound to using the php+mysql mechanism that we are.
all plastic fittings. you would not believe how hard it is to get the right fittings for this thing in anything other than brass. dan spent about 2 months (in his free time) looking for samples and distributors of fittings to connect the beer line to the flowmeter and solenoid. we wanted all plastic fittings because we think the metal ones used previously gave the beer a funny taste.
guest access and sponsoring. for a large gathering, it might be convenient to just have a bucket of keys available for anyone to use. these keys should naturally be set to expire (after, say 4 hours) or be limited to a certain amount of beer. this is all possible. a planned feature (yet to code as of 4/04, but very easy) would be to allow one user to clone his key or sponsor a guest in his name, allowing that guest to drink using the sponsor's grants and credits.
optional key PINs. like an ATM card, a user can optionally assign a PIN to his ibutton, such that entry of the PIN is required as an additional check whenever the ibutton is inserted.