- This topic is empty.
-
Posts
-
Hello all,
I’m pretty excited to share my latest code that runs a network socket server to control stations: https://github.com/greencoder/ospi-neptune
This Python TCP socket server runs as a daemon and handles overlapping requests better than my last program. If a station is running when a second request comes in, the program will gracefully stop the first program, then start the second.
My design goal was to allow local clients to connect in any language that supports TCP sockets (any modern language). For example, you can use Ruby or PHP to operate the stations. Additionally, clients do not have to run with superuser privileges. (only the Python server does)
One caveat: The clients that connect to the server should be running on the Pi. By default, the socket only responds to localhost and has no authentication mechanism.It would be unwise to port forward to the socket server! (but you could forward to a web application running on the Pi that talks to the socket on the server side)
This is still a work in progress, but I’m actively testing it at my house. Once I’m satisfied it’s working really well, I’ll rewrite it in C.
Feedback is appreciated.
It’s great to see more development. Can you run two programs at once with this? Some sprinkler systems are designed with a master valve that has to be opened before the other valves will work.
That’s a great suggestion! I don’t know anything about master valves yet. I also saw some posts that lead me to understand that some people can run multiple stations simultaneously, so I’d better give some thought to both scenarios.
It sounds like in a master valve scenario, two stations would have to be opened at a time? If that is the case, I could create a configuration directive that allows you to designate which valve is master and then activate it along with the designated station.
Yeah, if you look at the interval program any of the first 8 valves can be designated as the “Master”. In the options screen you can specify the number of seconds that it opens before or after the desired valve opens (or at the same time).
Maybe a way to approach the master valve/concurrent waterings would be to allow any connection to give a list of valves that should be turned on. This way you don’t have to care about master valves, etc as it is the responsibility of whatever is sending the commands not you.
An added bonus would be to say turn this list of valves on for x seconds. That way they will turn off of their own accord if the turn off command never arrives. (remote wireless valves like this would be very cool. Commercial ones are extremely expensive!)
I was wondering the same but then thought that for remote connections SSH would probably be better. It’s far simpler to setup securely for the average person and using keys would mean password less authentication and encryption all in one.
@aradke – you’re spot on, and that’s how it’s designed. When a station runs, a background thread starts and loops until the time is up, then it shuts itself off. There’s also a safety mechanism in place that each station operation places a file on the filesystem with an expiration time embedded. I have a utility that you can run via cron every 5 minutes to look for these expired files. If one is found, it’s a sign that something went wrong and the system issues an “all off” command. You can’t be too careful when it comes to a water bill.
@salbahra – In this simple TCPServer setup, it’s a gaping hole and I wouldn’t feel comfortable opening it up to anything but localhost. I have more ambitious plans to create a cloud-based service that uses TLS-encrypted socket connections via ZeroMQ, and the connection must be made outbound from the Pi to the cloud – I don’t want anyone to have to poke a hole in their firewall just to get remote access.Aradke is right that SSH would be a pretty secure way to accomplish this, but it’s not a direction I want to go. If someone wanted to go that direction, I’d suggest replacing the TCPServer I wrote with one from the Twisted.Conch project. The learning curve is pretty steep, but the project is *very* well-established.
By the way – if you are reading this and my vision isn’t in line with yours, please feel free to fork my code from Github and do anything you want with it. I’m not in this to profit, I just want to work on a cool project that I both use at my home and enjoy.
Also, after I work on supporting multiple station operation and master valves, I want to focus my attention on creating a scheduler.
I thought about using a Google Calendar like the demo that is available, but I wanted to do it without having to rely on an outside service. Also, it seems that making your Google calendar public now puts it in search results, and I don’t like that.
It’s really important to me that the schedule can be modified at runtime and have the changes automatically picked up without having to “do” anything on the Pi. I’m also looking at modifying the schedule remotely, so it needs to be (eventually) able to send the changes “over the wire” and down to the device where it’s stored. One of my design goals is to have everything run off the local device and not require an internet connection to operate. The other big goal is that the components are modular so that you don’t have to use a cloud service if you don’t choose to.
I’ve consulted a few people and I’m thinking of making the scheduler run via a cron job that runs every minute to look at the local scheduler file and see if a job should start. It doesn’t feel very elegant, but it’s pretty bomb-proof and doesn’t rely on yet another network service.
I wrote a scheduling program for my sprinkler in PHP, but instead of using cron I used upstart. Upstart is cool because it actually makes it a daemon that you can start say when apache starts, and will restart it if something fails. I just put a loop in my php file that way it never ends. Plus with upstart running the PHP as a daemon you can make it check the database say every 15 seconds instead of every 15 minutes with less resources. Just my two cents 😉
- You must be logged in to reply to this topic.