The Farm Hack River of Activity

Nope - I think I came up with it around the same time that you did!

Anyway, I've been thinking about the protocol and how this could work and have the following proposal:

Fido will be programmable and reprogrammable by text message. You can text a bunch of different numbers separated by commas to program it all in one text (in some predetermined sequence so Fido knows what to do with it) or you can write some keyword followed by a number to change only a certain preference as RJ specified above.

I also think that I will implement some basic "usergroups". First off, Fido will answer any text message not started with '#' by telling the person the current time, UNLESS privacy is turned on (owner will be told that someone unauthorized is texting in this case). When privacy is on, only known numbers can ask for current.

Fido can remember up to 16 numbers plus the owner. Anybody can text '#' followed by the 4 number PIN determined by owner, followed by: - nothing or '0': they will be allowed to text for current even if privacy is on and they will get emergency text messages - '1': above, plus they will get daily summaries - '2': above, plus they will get updates throughout the day (ie: they get all the communications that owner gets)

Only owner can reprogram and remove users.

Anyway, I thought that incrementing of permissions made practical sense but let me know what you guys think. Also, let me know if you think anything is unclear or could be simplified!

Aaaaah buttons nice.

The 4 directional buttons plus select button allows basic control...

Keypads take up a lot of pins (which one were you thinking about using?), so with buttons on an RGB LCD Shield Kit and some (a lot?) programming, we might be able to drop the keypad altogether. In the interrupt mode the left and right buttons would move across the LCD and the up and down button would change the value of the number.

Anyways, cool ideas but the most important thing right now I think is getting a minimum viable product built whichever way is easiest. We can iterate later to improve things like cost, usability, and ... "buildability". So with that in mind, the reasons I suggest an RGB LED are as follows. 1) The RGB LED helps out with the pin issue. 2) The RGB LED + Keypad combo might be easier to program than the LCD + Keypad combo.

how do they know if they're reprogramming the bounds or the phone number or something else?

Inspired by decades of crappy electronics with one singular red light blinking out a primitive version of Morse code, we could deploy a similar technique with an RGB LED. The directions might go like something as follows.

To set the Phone number

1. Hold # until the LED blinks green.
2. Enter the phone number you would like to be sent text messages.
3. Hold # again and the LED will stop blinking green. Fido will now send you a confirmation text message.

To set the upper bounds

1. Hold * until the LED blinks red.
2. Enter the temperature you would like to be the upper bounds.
3. Hold * again and the LED will stop blinking.

To set the lower bounds

1. Hold 0 until the LED blinks blue.
2. Enter the temperature you would like to be the lower bounds.
3. Hold 0 again and the LED will stop blinking.

To see the current temperature

1. Hold 1 until the LED turns on. If you defined your upper bound as 95 degrees and your lower bounds as 75 degrees, you will see corresponding colors across the RGB spectrum for the following temperatures.

Red (95) - Orange (90) - Yellow (85) - Green (80) - Blue (75)

If implementing something like what I've just proposed sounds more difficult than what you had in mind, then don't worry about it. I'm not familiar with programming LCDs and using them in combination with keypads to do input so it's tough for me to estimate which way is more difficult. Maybe we'll come back to this idea at some later date if the cost/benefit of this starts to seem appealing.

Come to think of it, I think my first priority will be to set up a redirect from youngfarmers.org/forum to farmhack.net/forums.

The Adafruit RGB LCD Shield Kit is pretty cool in that it reduces your pins needed on the microcontroller to just 2 (6 are required on the LCD unit right?). As a last resort, what do you think of dropping the LCD display and incorporating an RGB LED like the Public Labs folk did with the Thermal Flashlight? In the interrupt routine a blinking green light would indicate it's ready for input of the phone number, a blinking red light would indicate it's ready for input for the upper bound, and a blinking blue light would indicate it's ready for input for the lower bound. When the unit is told to display the temperature, it would take the upper and lower bounds and display it somewhere between red-green-blue depending on where the current reading is in the upper and lower bounds. Am I missing anything else the LCD could be used for? The advantage here is that one RGB LED ($1.95 at the high end) is cheaper than an LCD screen but the drawback is user friendliness. My "advantage" is definitely in the spirit of "How cheap can we get this?" but the cost/benefit analysis may not hold up on this suggestion.

For those who aren't sure what a PTO is (I wasn't at first), it's a Power Take-Off.

I will see if I can get my brother inlaw to post. He has a brand new single horse treadmill which has a pto output which he has used for corn shelling and grinding - and another friend has one hitched to a thresher. He also has a belt driven grain grinder which is human powered based on a modified stationary bicycle. If nothing else I can get photos of the setup.

So if I am arriving at Farm Hack because I heard it could be a good place to find a solution to a problem on my farm, the default tool organization that I want to see would be tools by category, so I can find tools that are relevant to my farm or my problem (fruit growing tools aren't much use if I'm a dairy farmer, etc.).

I agree. It's also in the interest of Tool developers that the maximum amount of interested eyeballs find their tools quickly. According to Raymond's version of Linus's Law, "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone." So if we focus on building the search tools for Farm Hackers like myself who are interested in seeing where the action is, then a whole bunch of potential contributors might not be seeing what they are looking for. I think metrics like "# of wiki edits" and "# of forum posts" for a Tool are not first priority but second priority. After the user has somehow generated a list of results they are interested in, the participation metrics let the user know which ones are healthy.

At the moment though and probably for the next few months, I think most people visiting the Tools section will not find anything necessarily useful to them. I think it's important to prove to those folks that if they have a Tool idea and make the effort to post it, that there will be an active community ready to jump in. So for now I'm kind of happy just having the current sort mechanism of "Last Tool Wiki Update" and perhaps when we do get more participation metrics on the Tools page we sort by one of those. Again, this is my thinking for a short term strategy while we are bootstrapping this community. I could be convinced otherwise, prioritizing long term is not that crazy of an idea :P.

In response to

...it would be helpful that the first few tools people see are well documented with a lot of activity around them...

Check out my comment in the Maintainer discussion.

[It looks like a good way to start might just be a loose "Volunteer as a maintainer" function on each Tool page that allows users to say who they are and how they plan on contributing. This can be accomplished by just pencilling yourself onto the Tool's Wiki page but it could be massively helpful when sorting Tools to be able to have that extra metadata that shows where people have volunteered to answer questions and where no one has.](http://www.farmhack.net/comment/102#comment-102)

I also just added a "Last Tool Wiki Update" column on the Tools page. Now the Tool with the most recently edited documentation floats to the top. That is at least some kind of indication of activity. Another metric we could publish there might be "# of Tool's Wiki Updates" and "# of Tool's Forum topics". I started with what we have because that was a quick fix. The other two metrics will require an hour or so of coding.

Done, done, and done :).

I think that's a great idea Dorn. Using the same Wiki-Forum format we are using for physical tools can also work for our process tools. I vote for moving ahead on this and I want to mention two things to consider as we move ahead.

Before getting into the two considerations for this, a quick clarification on the functionality behind Tools. The "Tool" Entity, the thing with metadata like "Stage" and "Type", is the glue that holds together the relationship between a Forum and a Wiki page. In addition to Tool's holding metadata on the Tool and relationships to a Forum and Wiki, there is code I wrote to display all three things on a single page if you go to any one of those three things. Note that we could create a Forum and a Wiki page separately, put a link at the top of each to their counterpart, and the only thing we would be missing out on is the presentation of the Wiki and Forum on the same page.

• A "Best Practices" Wiki page and Forum may not be findable on the Tools list Perhaps it would be better suited to be in the General category of the Forum. We could reassign the "Best Practices" Forum fromt the Tools category to the General category.

• Does the data model (metadata like "Stage" and "Type") for our "Tools" concept fit something like this? Right now I don't see this as a big deal and it's not necessarily a big deal if we decide otherwise in the future. If down the line we decide that "Best Practices" is not a good fit for the Tool data model, then we delete the "Best Practices" Tool, the Best Practices Forum and Best Practices Wiki page stick around because they are separate entities, and then we create some other alternative to the Tool Entity type that we use to glue the Best Practices Forum and Best Practices Wiki together.

My analysis could be seen as a green light to shoehorn whatever we want into the Tools section right now, because after all, if decide something is not a Tool, we don't lose the Forum and Wiki page when we delete the Tool.

OK, I tried it and created a loose wiki for the hoophouse wheels, but I'm not sure if it works in the context of meta tool/secondary tool because the loose wiki doesn't have a tool forum attached to it for discussion. The wheels are something I'd really like somebody else's skull sweat on. I'd love them to have their own discussion. I do like Louis' vanity wiki though and it seems like the loose wikis would have a value as informational packets like that. But maybe a secondary tool needs its own entry on the tool forum? Tim