What else has an LCD and a keypad that we already interface with Fido? A cell phone!
I think that the first run should be programmable via cell phone with an optional LCD display so that you can check temp without texting when you're physically near the device. The cell phone that initially texts Fido will become the "owner" and will need to confirm reprograms from different phone with an option of relinquishing ownership. A hard reset will also allow Fido to get a new owner.
A shield with keypad and LCD can be a later elaboration on Fido v1. Sound reasonable?
The RGB LCD Shield Kit not only reduces pins to the two I2C pins, which is the exact same as the I2C backpack we're currently using, but it also has buttons! The port expander used on the RGB shield seems like it could handle our keypad just as easily as it could handle those 5 buttons, plus it's not a surface mount device (SMD) so it's big enough for a hobbyist to wire up easily. It would probably end up costing the same if we build on our shield since we could then drop the I2C backpack since our shield will handle that too; downside is that it will be more difficult to make.
LEDs would work to let you know that the device is running and in alarm mode or not, but I think that it basically reduces the "reprogrammable on the fly" feature of our product to none since how can you input a temperature or a phone number using just an LED for feedback? It would require teaching users some kind of color code for numbers and that doesn't sound user friendly at all. Plus, how do they know if they're reprogramming the bounds or the phone number or something else? Stripping down the device to no LCD and no keypad is definitely a cheaper alternative though.
1 is pretty straightforward and requires no more development based on our current objectives.
2 is definitely an option, would require very little extra development but requires a lot of wire even if you want to hook up two neigboring greenhouses to one Fido since you basically have to find a relatively central location and then run three wires to each sensor - luckily these are digital sensors so the resistance in the wire isn't an issue as long the signal still makes it through.
3 is also technically viable but as you pointed out, is quite a big change on the development side. How do we tackle the "wireless" part of the sensors? Xbees? WiFi? something else? The money spent making these things wireless would probably be at least as much as simply building seperate Fidos. This is a type of architecture I am foreseeing for the wireless node system that relays data via internet, however!
I included an example on the Tool page of a project that I'm currently working on where I link to a wiki about myself (vain, I know).
I'll try to explain it here though. Currently, you can format your forum posts, wiki entries, and the main body of tools using Markdown Syntax or HTML - those are two common syntax that you may run into in lots of places on the web.
Markdown is especially convenient for links. This is how you do a link for Farmhack: [FarmHack](http://www.farmhack.net)
Now when you're pointing someone to other places on the site, there's an even shorter way to give links! Let's say I want to point you to the tool page like I did above, I wrote: [project](../tools/fido-greenhouse-monitoring-text-message-alerts). The "." prefix is basically a way of telling the browser to go from where I am (farmhack.net/forum) and adding another "." to it backs it up to the parent directory (farmhack.net). Then you continue to write the URL how you normally would.
I've noticed this issue too when uploading files although I was able to recover my text when I hit the back button. I tried multiple times until it went through and eventually it worked...
I have no idea what could be causing it but RJ might have an idea when he has a minute!
Well, FIDO may end up being the first product of Farm Hack, but I don't expect it to be typical. I imagine most tools will be mechanical thus a mechanical template will no doubt be useful.
So it seems like there is some interest in developing the framework of Farm Hack in several directions.
Right now, the site was developed with collaborative R&D and networking in mind. It seems that there is perhaps some interest in the following activities:
1) spreading out R&D costs: this could be like Kickstarter, except no need to give them a 5% commission. The reward structure seems like a great thing and it very much like a CSA in a way: you pay before the development process when funds are needed and as a result, you get a discounted product. I think we could very easily have a forum for this based out of the current infrastructure and see if it gets used. If it does, something a little more streamlined like Kickstarter might be justified. Also, if a project doesn't meet its objective within just our community, it might make sense to go to Kickstarter afterwards.
2) a marketplace: a place to buy kits and finished products. Once again, this could be done informally within the existing infrastructure until it proves necessary to tailor the site to this function; just create a section on the tool that offers where to buy said product.
In conclusion, all these things can be accomplished with the site as it stands; we have tool pages, a wiki, and a forum. Web 2.0 is about user contribution - the site is only as good as a community makes it. Nothing is to stop us from creating a wikipedia entry about ourselves and linking what tools we have to offer. Nothing is to stop me from creating the "Hackstarter" forum by creating a tool like I'm about to do. Once the site starts getting pushed in one direction or another, then maybe there will be a need for an infrastructure overhaul but these wikis and forums can be distorted to do almost anything you want - let's hack this site! (by hack this site, I do not mean attempt to take it down :P)
I agree with David's points:
1) Communicating the expectation that a new concept tool be followed up on (which could be done by the OP or anyone else) or generate active discussion should be communicated to a poster of a new tool
2) Different criteria should be used for tools at different levels of development. For example, perhaps only a concept or functional prototype needs no approval but needs to progress or generate discussion to stay listed. Meanwhile, DIY or commercial products might need moderator approval but become permanent fixtures
I came across this picture which I felt reinforced my reasoning above. The person in that picture obviously didn't have the alternative we do back in his time. I think Louis C.K. illustrates how artists today can create a business model today that circumvents the industry and one of the key features was the lack of DRM in his downloadable product. While that's not quite open-source, it's VERY progressive for the industry and makes a lot of customers happy since they feel like they are given the ownership they are entitled to when they buy something.
Anyway, I was just trying to illustrate my point of how important it is to pick your battles. By not caring about people pirating his product, Louis CK was able to cut out middle men, sell his product more cheaply, and make more money then he would have otherwise. Wins all around!
The main difference to me seems that public domain does not require downstream users to maintain the work under the same open license. In that way, the "iterate" part of your slogan fails.
I realize that my stance may seem contradictory since I stated that I didn't wish to enter legal battles over IP and I am effectively saying that one should have legal recourse should another mutate and patent one's work, but I think that the very existence of legal recourse should dissuade others from going closed with your R&D.
Also, imagine that someone mutate and patent my work, cutting off my own paths for future development?
What's the intention of the wiki? My assumption was that if I was writing a tutorial about how to assemble a tool, I might make a Wiki page for each component explaining more in detail what does what, how, and why, in case somebody had more questions or needed the info for troubleshooting... The logic being that, for example, an LCD screen, a keypad, or a sensor, is not a tool in itself.
Would that of been accurate or is that comprised in the tool pages somehow?
My takeaway from reading the public labs site was the following:
CC Share-alike has one potential weakness: people who build off of someone's original plans can see their work become closed, since the originator of the project can change his or her mind about licensing. Thus, it forces people downstream to make their development open while also allowing the potential for someone upstream to patent and close the project, taking downstream developers contributions along with it. CERN does not allow an upstream developer to do so.
My final position is that CERN is the way to go. Part of me did feel like the ability to close a project was a useful tool to use against corporations who may want to use my work, but further thought made me realize that that benefit would probably not pan out in practice.
If a corporation really wanted to keep using my work, they no doubt will find a way; waging patent war is not the battle I intend on fighting. Meanwhile, the cost of this ability is that downstream users are at-risk of my whims and this discourages their own development of a tool that I originated. In short, the benefit of being able to fight a battle that I don't want to fight isn't worth the cost of discouraging collaboration.
I can easily think of a dozen potential problems with so few rules, however, I fully agree the idea we shouldn't fix it until it's broken. I think that I'm just used to building things and trying to anticipate everything that can go wrong; I don't think the method works when building community.
Took me all day to cook this idea up apparently:
What else has an LCD and a keypad that we already interface with Fido? A cell phone!
I think that the first run should be programmable via cell phone with an optional LCD display so that you can check temp without texting when you're physically near the device. The cell phone that initially texts Fido will become the "owner" and will need to confirm reprograms from different phone with an option of relinquishing ownership. A hard reset will also allow Fido to get a new owner.
A shield with keypad and LCD can be a later elaboration on Fido v1. Sound reasonable?
The RGB LCD Shield Kit not only reduces pins to the two I2C pins, which is the exact same as the I2C backpack we're currently using, but it also has buttons! The port expander used on the RGB shield seems like it could handle our keypad just as easily as it could handle those 5 buttons, plus it's not a surface mount device (SMD) so it's big enough for a hobbyist to wire up easily. It would probably end up costing the same if we build on our shield since we could then drop the I2C backpack since our shield will handle that too; downside is that it will be more difficult to make.
LEDs would work to let you know that the device is running and in alarm mode or not, but I think that it basically reduces the "reprogrammable on the fly" feature of our product to none since how can you input a temperature or a phone number using just an LED for feedback? It would require teaching users some kind of color code for numbers and that doesn't sound user friendly at all. Plus, how do they know if they're reprogramming the bounds or the phone number or something else? Stripping down the device to no LCD and no keypad is definitely a cheaper alternative though.
Thanks for the summary RJ - this is all right on!
1 is pretty straightforward and requires no more development based on our current objectives.
2 is definitely an option, would require very little extra development but requires a lot of wire even if you want to hook up two neigboring greenhouses to one Fido since you basically have to find a relatively central location and then run three wires to each sensor - luckily these are digital sensors so the resistance in the wire isn't an issue as long the signal still makes it through.
3 is also technically viable but as you pointed out, is quite a big change on the development side. How do we tackle the "wireless" part of the sensors? Xbees? WiFi? something else? The money spent making these things wireless would probably be at least as much as simply building seperate Fidos. This is a type of architecture I am foreseeing for the wireless node system that relays data via internet, however!
I included an example on the Tool page of a project that I'm currently working on where I link to a wiki about myself (vain, I know).
I'll try to explain it here though. Currently, you can format your forum posts, wiki entries, and the main body of tools using Markdown Syntax or HTML - those are two common syntax that you may run into in lots of places on the web.
Markdown is especially convenient for links. This is how you do a link for Farmhack: [FarmHack](http://www.farmhack.net)
Now when you're pointing someone to other places on the site, there's an even shorter way to give links! Let's say I want to point you to the tool page like I did above, I wrote: [project](../tools/fido-greenhouse-monitoring-text-message-alerts). The "." prefix is basically a way of telling the browser to go from where I am (farmhack.net/forum) and adding another "." to it backs it up to the parent directory (farmhack.net). Then you continue to write the URL how you normally would.
I've noticed this issue too when uploading files although I was able to recover my text when I hit the back button. I tried multiple times until it went through and eventually it worked...
I have no idea what could be causing it but RJ might have an idea when he has a minute!
It seems that this bug has been resolved. Bring all your TXT, PDF, JPG, JPEG, PNG, or GIF that are 100MB or less!
Well, FIDO may end up being the first product of Farm Hack, but I don't expect it to be typical. I imagine most tools will be mechanical thus a mechanical template will no doubt be useful.
You seem to have a pretty clear idea of what a "Template Tool" would look like. You could pick some trivial, perhaps hilarious, example and do it up!
So it seems like there is some interest in developing the framework of Farm Hack in several directions.
Right now, the site was developed with collaborative R&D and networking in mind. It seems that there is perhaps some interest in the following activities:
1) spreading out R&D costs: this could be like Kickstarter, except no need to give them a 5% commission. The reward structure seems like a great thing and it very much like a CSA in a way: you pay before the development process when funds are needed and as a result, you get a discounted product. I think we could very easily have a forum for this based out of the current infrastructure and see if it gets used. If it does, something a little more streamlined like Kickstarter might be justified. Also, if a project doesn't meet its objective within just our community, it might make sense to go to Kickstarter afterwards.
2) a marketplace: a place to buy kits and finished products. Once again, this could be done informally within the existing infrastructure until it proves necessary to tailor the site to this function; just create a section on the tool that offers where to buy said product.
In conclusion, all these things can be accomplished with the site as it stands; we have tool pages, a wiki, and a forum. Web 2.0 is about user contribution - the site is only as good as a community makes it. Nothing is to stop us from creating a wikipedia entry about ourselves and linking what tools we have to offer. Nothing is to stop me from creating the "Hackstarter" forum by creating a tool like I'm about to do. Once the site starts getting pushed in one direction or another, then maybe there will be a need for an infrastructure overhaul but these wikis and forums can be distorted to do almost anything you want - let's hack this site! (by hack this site, I do not mean attempt to take it down :P)
Ah - it seems that the framework is there but that perhaps the 100 byte max from the test server is still around.
I would attach a Google Doc link until it gets straightened out.
Oh nice - I missed Saturday and this seems like a really cool device!
I agree with David's points: 1) Communicating the expectation that a new concept tool be followed up on (which could be done by the OP or anyone else) or generate active discussion should be communicated to a poster of a new tool 2) Different criteria should be used for tools at different levels of development. For example, perhaps only a concept or functional prototype needs no approval but needs to progress or generate discussion to stay listed. Meanwhile, DIY or commercial products might need moderator approval but become permanent fixtures
I came across this picture which I felt reinforced my reasoning above. The person in that picture obviously didn't have the alternative we do back in his time. I think Louis C.K. illustrates how artists today can create a business model today that circumvents the industry and one of the key features was the lack of DRM in his downloadable product. While that's not quite open-source, it's VERY progressive for the industry and makes a lot of customers happy since they feel like they are given the ownership they are entitled to when they buy something.
Anyway, I was just trying to illustrate my point of how important it is to pick your battles. By not caring about people pirating his product, Louis CK was able to cut out middle men, sell his product more cheaply, and make more money then he would have otherwise. Wins all around!
@danpaluska
The main difference to me seems that public domain does not require downstream users to maintain the work under the same open license. In that way, the "iterate" part of your slogan fails.
I realize that my stance may seem contradictory since I stated that I didn't wish to enter legal battles over IP and I am effectively saying that one should have legal recourse should another mutate and patent one's work, but I think that the very existence of legal recourse should dissuade others from going closed with your R&D.
Also, imagine that someone mutate and patent my work, cutting off my own paths for future development?
What's the intention of the wiki? My assumption was that if I was writing a tutorial about how to assemble a tool, I might make a Wiki page for each component explaining more in detail what does what, how, and why, in case somebody had more questions or needed the info for troubleshooting... The logic being that, for example, an LCD screen, a keypad, or a sensor, is not a tool in itself.
Would that of been accurate or is that comprised in the tool pages somehow?
My takeaway from reading the public labs site was the following:
CC Share-alike has one potential weakness: people who build off of someone's original plans can see their work become closed, since the originator of the project can change his or her mind about licensing. Thus, it forces people downstream to make their development open while also allowing the potential for someone upstream to patent and close the project, taking downstream developers contributions along with it. CERN does not allow an upstream developer to do so.
My final position is that CERN is the way to go. Part of me did feel like the ability to close a project was a useful tool to use against corporations who may want to use my work, but further thought made me realize that that benefit would probably not pan out in practice.
If a corporation really wanted to keep using my work, they no doubt will find a way; waging patent war is not the battle I intend on fighting. Meanwhile, the cost of this ability is that downstream users are at-risk of my whims and this discourages their own development of a tool that I originated. In short, the benefit of being able to fight a battle that I don't want to fight isn't worth the cost of discouraging collaboration.
I can easily think of a dozen potential problems with so few rules, however, I fully agree the idea we shouldn't fix it until it's broken. I think that I'm just used to building things and trying to anticipate everything that can go wrong; I don't think the method works when building community.