here is a rough list of "features" of the kegerator. i'll try to keep the list updated as things move along.

• 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.

an experimental front-end to the kegerator has been written in PHP, and it talks directly to the kegbot's database. because a lot of the fun of this system comes from the analysis of different users' drinking habits, this front-end has a lot of fun features!

• leader board for all major stats. users are sorted and ranked on one page by a number of factotrs: top drinkers (all time, by volume), recent drinkers, top BACs observed, longest binges, and so on.
• binge rankings. a small but useful algorithm has been added to sort groupings of drinks into "binges". from these sets, it is possible to quantify how much a user drinks per session, how often he pours just a single drink with dinner, and so on. this data could even be used to discourage an abusive drinker from pouring!
• graphing. graphs are generated for recent temperature and fridge power activity. (these graphs are generated with a shell script -- and not php -- so alternative interfaces can make use of the graphics scripts or the cached images they generate.)
• account-specific features. known users may login an update their account data, view their personal drink histories, and so on. the front-end is fully aware of the multi-user scheme and keys used by the kegbot.
• admin features. the expected set of admin features are integrated in this frontend: adding users, adding and removing permissions, and so on..