[snewman]

Thanks, mattguy. Running it as a daemon does have a few advantages that I’ll consider. Any lessons learned in writing your scheduler that you’d be willing to share? I’ll probably keep the persistence as a serializable file format so that it can be edited remotely and sent down to the device.

[snewman]

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.

[snewman]

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

[snewman]

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.

[snewman]

A big thanks to everyone who has chimed in. I think I’ve found a good software solution that will be ready in another day or so:

I’ve written a simple Python socket server that runs forever and acts as the controller/proxy for modifying valve status. It runs the station program in a thread and keeps a state chart of what valves are running.

If a request for a second operation comes in while a station is operating, the software sends a Queue message to the thread (basically saying, “wrap it up, new work is coming in”) and it stops the current run before starting the next operation. This solves that problem I had about the first job waking up and killing the second job.

I wrestled with doing this as a simple TCP server or as a web server, but decided on TCP. This gave greater flexibility for clients: You are free to write clients in any language that supports TCP sockets (any modern language should) and you aren’t forced to do anything else in Python if you choose not to.

This modular approach also keeps things simple and clean when writing advanced clients, schedulers, etc. If you want to write a pretty advanced web application, the low-level details of the hardware operation are abstracted away.

The other nice thing is that only this TCP server needs to run with superuser privileges.

Here are a couple example snippets that send a command to run station 1 for 2 minutes: (they immediately close after the command is sent, the client doesn’t stay connected during the run)

PHP

$fp = fsockopen("127.0.0.1", 9999, $errno, $errdesc);

fputs($fp, "1,2");

fclose($fp);

?> 

Ruby

require 'socket'



s = TCPSocket.open('localhost', 9999)

s.puts('1,2')

s.close

Python

import socket



sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

sock.connect(('localhost', 9999))

sock.sendall("1,2")

sock.close()

[snewman]

Andrew – your continued help is very appreciated!

Looks like a good solution is to write some kind of long-running scheduler/controller that is the only process allowed to manipulate the shift registers. It can also act as a state manager to keep track of the status of stations. I really don’t want to require people to set up task queues or other network processes, so I’ll probably do it as a simple HTTP-based system that uses threads.

[snewman]

Wow, thanks for taking the time to thoroughly answer my question!

Andrew – This helps quite a bit. It looks like my understanding was the same as what you sent.

Virtus – Correct; every time a command is received it first closes all valves then opens the desired one. This prevents multiple valves from being opened at a time but presents a challenge when the original valve is ready to turn itself off. I’ll have to come up with some better logic to manage state. (but I’m trying to keep this simple and not run task queues and databases)

Doczaius – I have looked at the interval program. It was written by someone who obviously knew what they were doing, but the code is a bit obtuse with short variable names and a lack of comments. Does anyone know who the original author was? Perhaps he/she can answer some questions so I can go through it line-by-line.

[Author]

Posts