@andrew wrote:
@doczaius: I don’t believe that it’s polling anything, and this is the point I was making above. The interval program keeps a variable in memory that represents the current state of the stations. When a station is “turned on” the bit for the station in that variable is set to a 1 (or a 0, not sure which) and then the program calls the set_output function, which then takes the values for all of the stations and sends it out through the GPIO to the shift registers on the controller board. There is no polling of or feedback from the controller board that I’m aware of. The program just assumes that whatever *it* last sent out to the shift registers is what the current status of the controller is. If you’re running the interval program, and then in a separate process send some new values to the shift registers, thereby changing the state of the controller, the interval program will be completely unaware of the change, and still think that the controller’s state is whatever it had previously set it to.
That being said, if some is running the interval program exclusively, they can indeed use http://xxx.xxx.xxx.xxx/snX to obtain the state of the stations (as far as the interval program is aware). I believe, however, that snewman was intending on writing/running his own program and would not, therefore, be making direct use of the interval program.
I was afraid of that — the reason I mentioned was because the previous version of the interval program did not accurately reflect whether zones were on or off if a command was sent via get. I assumed the GUI was referencing a variable where as the GET commands were not (unless of course there are two sets). I have the interval program installed but I don’t use the built in scheduler because I need multiple zones to open/overlap. So I have crontab set up to execute manual commands with cURL. If I wanted to know the true status, I would have to manually goto /snX to view. The new version of the interval program seems to have fixed this issue however.