Didn't see your question. opensprinkler.com seems like a verygood solution. I found it after starting working on my project so I bought a sainsmart 5v relay controller. Doing it again, I would probably buy opensprinkler for Pi
This is a great little program, but I'm curious why you're marketing it only for the Raspberry Pi? A low-memory system monitoring script could be useful in many other areas, and as far as I can tell, there's nothing RPi specific in the source.
Well, I'm not saying it is only for the Pi (took care of adding it into the FAQ recently), just that it's been run and tested on one for more than two weeks now - so I feel comfortable with saying it works great on the Pi.
But yes - I have been building and testing it on OSX and Linux alternatively, before deploying on the Pi for testing, so it is perfectly suitable for any unix device with low resources indeed.
Hope it works well for you anywhere you want to run it :)
Nice but I wish people wouldn't use names like "w", "tuple" or "string" for variables. Tuple of what? The analysis that is needed for the reader to figure that out, however short, is friction you are adding to the code readability. The shame of it is this kind of friction is totally unnecessary. Looking forward to giving this a whirl though.
Yup. Ironically, I'm a big advocate of good naming in production code.
Unfortunately what the git logs don't show is that some of that code was written very late at night (where my spare time lives), and sometimes I neglected to do that out of sheer tiredness.
I will definitely try to improve on that when needed, thanks!
Very cool! Looking forward to trying it out. My current solution had been a dead-simple crontab script that pushed some stats to a static html page every hour. It's ugly and a little dumb so I'd been looking for a better solution, and this looks perfect.
Hey, I have a project similar to groundcontrol but un Python, is called RaspCTL[1][2]. You add/execute commands thru a web interface, radio support (using mpd), can manage the daemons, dashboard with the memory usage/processes, processor temperature, etc...
And just right now I'm working on an alarm system, where you'll be able to launch any arbitrary commands or start/stop playing a radio. In a few days I'll release the new version.
BTW, for the ones who have a dynamic IP and want to use a Dynamic DNS service for being able to access to your RPi from the internet, you can check this out[3].
Thanks!
Librato also has a feature that lets you get alerts to your email if you set thresholds on metrics (disk space, temp, etc).
The free tier is OK for me too.
I wonder what the binary size, resource utilization, and performance difference would be if this was written in C. How would Go match up against C for embedded platform dev? I mean small/real embedded systems... not Android/iPhone platforms.
Go's standard library includes things needed for the Real World(tm) like HTTP server/client and serialization for example on a project like this one.
In C those functions would be provided by third party libraries like libCURL (or handwritten and likely insecure).
This is slightly irrelevant in terms of your question about performance, but in terms of dev it is very nice to avoid dealing with 3rd party packages, especially when programming for multiple architectures.
Yes, of course C doesn't have all the bloat that comes with Go. But still, my question was about performance (as you noted). :)
LibCURL is used (along with a TON of other 3rd party C libs) in a bunch of systems securely. Writing C code isn't __always__ insecure. It all depends on the developer/team. Just like writing Java isn't always portable.
It seems like it's all about saving dev time these days.
I was once pulled onto a project where some devs had used perl & python for an embedded system. They got a prototype system up pretty quickly, but performance just wasn't there and they were using WAY too much RAM/CPU based on what the system had to offer. They wasted many man-months trying to optimize their code. Eventually, they brought in some C devs and we rewrote in C and the system ran great. It turned out great for the Python/Perl devs too because they got to learn C and some of the benefits of using it.
"It seems like it's all about saving dev time these days."
It has always been about saving engineering time; otherwise, why aren't you handcoding things in assembler? Any reasonable development process involves at least a subconscious decision about how much hardware to give up in exchange for a manageable engineering cost.
For the problem domain, Go seems like a reasonable point in the continuum of efficiency and engineering costs.
Another part people overlook when they say "well, my low level language has a library for that, too" is that there is also a cost decision when adopting a library. How quickly can you vet libcurl has no buffer overflows or memory leaks? Compare that to Go's net/http? Does the library have enough public usage in your problem space that you can assume someone else has found and reported the bugs?
Dependencies are like puppies. They are cute, right up until they become your responsibility. The author might have felt more comfortable with his chances of updating and maintaining "net/http" and the lower chance that he would need to.
Until something happens to make engineering time limitless and free, it's ALWAYS going to be about saving dev time.
So they proved out the first version in a high level dynamic language and then someone reimplemented in C for performa performance reasons? Sounds like a solid process.
I actually deployed a production embedded system running a large chunk of code written in perl once (on a 180MHz FreeBSD/arm board). The performance was just enough, although the critical components were implemented in C.
Just to save some time for FreeBSDers, this does not run on Raspberry Pi's with FreeBSD out of the box: ELF binary type "0" not known (and branding it does not help - it needs the linux compat lib - anyone have that on a raspberry?).
Very cool! There are a wide range of applications for embedding devices like the RPi going places where they are installed and forgotten, often in very inaccessible places. Projects like this are a key part of making that happen.
I've been working on an open source project like this for JavaScript called Nitrogen. You can read about it here if you are interested in a node.js/JavaScript take on this: http://bit.ly/18k67ow
Thanks! the major selling point of Go over Node.js on the Pi for me was resource usage.
I definitely share your excitement for the internet of things, hope I can dig deeper into Nitrogen over the weekend :)
I’m all in for using Go and having fun, but is there an actual point in this daemon? I thought the Raspberry Pi is about making life easier and not about adding one more device to constantly worry about (i.e. check the stats every so often or get alerts)? :-)
This is probably made for fun, and in the spirit of the times where there's an app for everything. Whether or not it's useful is another point though..
* Scratching my own itch - I needed a way to remotely run commands though a nice UI, and a way to see how my Pi is doing when i'm not at home.
* For lack of better tooling - every thing I evaluated needed a combination of things, no other tool gave me all-in-one. This made the resources bloated. With GC, you get around 3-4MB RSS.
* To prove to myself that Go can be as great for development on the Pi as Python (which many people use there)
I already had everything working in an evening based on a concept I had, and it took additional few days of my spare time to get a nice looking UI, landing page, code cleaned up, supporting more reporters etc.
So all in all I invested that additional time on the premise that others may find it useful to make their own life a bit easier -- naively speaking, if it make your life harder please let me know why so I can improve it :)
I just released an alpha project for the Raspberry pi using Go for controlling your sprinklers.
Shameless plug: https://github.com/pothibo/irrigation