I have two SIP controllers and I am trying to set one up as a master controller and the other as its slave. I cannot get the slave controller to run in slave mode.
Question: Besides correctly setting the parameters in the relevant plugins pages, do I need to modify any python scripts in order to let the master control the slave? If no script needs to be modified, could someone please point out the errors in my parameters setup or in the assumptions I make below?
My setup: Two Raspberry Pi Zero WH’s, one for the master, controlling 16 channels, and the other for the slave also controlling 16 channels. Both rPi’s run on "Raspbian GNU/Linux 10 (buster)" SIP software version: 4.1.20 I use 32 LED’s to represent the 32 valves to facilitate troubleshooting. I use four shift registers, each controlling 8 channels by following the wiring instructions here: https://github.com/Dan-in-CA/sip/wiki/Relay-interface
Here is a picture showing the master on the right controlling blue LED’s; the slave on the left controls green LED’s. The two controllers are assembled on the same breadboard but there is no electrical connection between the two controller circuits. --Fig A: two controllers with labels
I verify the hardware works as expected by setting up identical programs on the two controllers and run both first in auto mode to verify. Both sets of LED’s switch on and off according to a simple program schedule described further down.
Fig B: Blue LED turns on indicating master circuit works properly in auto mode
Fig C: Green LED turns on indicating slave circuit works properly in auto mode
The program schedule runs in sequential mode, turning on each LED for 2 seconds, lasting 16*2 = 32 seconds. Then repeat every minute from the first minute of day to the last minute of day.
--Figure D: Both controllers run the same program schedule
To set up the master-slave communication, I follow the instructions in the MQTT slave docs, found here: http://192.168.0.114/static/docs/plugins/slave-docs.html, where 192.168.0.114 is my slave ip address. (This link is accessible by pressing the HELP button under the page MQTT Slave Plugin.)
The two figures below show parameters of the Base MQTT plugins
--Figure E: Top: base mqtt of the master Bottom: base mqtt of the slave
The broker mqtt runs on the master (localhost in Figure E; and 192.168.0.135 in Figure F). In other words, the broker runs at 192.168.0.135, which is the master’s ip address.
In addition to the above base_mqtt, an mqtt_zone plugin is also installed at the master:
--Figure G: mqtt_zone plugin at the master controller
Likewise, in addition to its base_mqtt, the slave controller has a slave_mqtt plugin. I understand these two additional plugins are complementary, allowing the master to publish, and the slave to subscribe, to the same “Zone topic” -- “sip/zones” in my case.
--Figure H: mqtt_slave plugin at the slave controller
The master and the slave each control 16 channels. I suppose the function of the parameter “First station number” is to map Channel 17 on the master’s program schedule to Channel 1 on the slave’s schedule.
So when Channel 17 on the master is activated on the web UI display, the green LED should light up at Channel 1 on the slave controller. But I am not observing this mapping, leading me to take my own hypothesis with a palm of salt.
The total number of channels on the master’s schedule is 32. The total number of channels on the slave is 16.
--Figure I: Left: Master controls 16 channels, but its program schedule contains 32 channels, with the latter 16 (channels 17-32) acting as placeholders, to be mapped to the slave’s 16 channels. Each channel turns on for 2 seconds. In this figure, channel 12 is just about to expire. Right: the slave controller is set to manual mode, a necessary setting for the slave controller
To verify I have properly installed the paho-mqtt package, I run the following script in the ssh terminal of the master ip address. This script is derived from post #10 in this forum thread (https://nosack.com/sipforum/showthread.php?tid=174). It turns on channels 3 and 5 for 2 and 3 seconds respectively. I observed the green LED turn on correctly so paho-mqtt must have been properly installed. ######### #!/usr/bin/python # -*- coding: utf-8 -*- from __future__ import print_function import paho.mqtt.publish as publish
def pub(): """ Send an MQTT message to SIP. """ host='192.168.0.135' # URL of system running mosquitto topic = 'slave01/schedule' payload = '{"S01":2, "S05":3}' # payload as Python dictionary (JavaScript object)
Of course, the mqtt_schedule plugin must be installed beforehand on the slave controller in order for this paho-mqtt verification to work. Since I run the script from the master’s ssh terminal, and the LED correspondingly lights up in the slave unit, I know the paho-mqtt must have been properly installed in both controllers.
--Figure J: mqtt_schedule parameters at the slave controller with Scheduling topic matching the publication topic in the script above.
We finally reached the bottom of the “slave-docs.html”: Test your setup: “With your master and at least one slave set up and running, You can switch the master to manual and you can test individual stations.”
So: I switched the master to manual. I leave the slave in the manual mode. -- Shouldn’t I? I turn on Channel 1 on the master schedule for two seconds. The green LED lights up at Channel 1 of the master, as to be expected. I turn on Channel 17 on the master schedule for two seconds. No blue LED lights up at any channels of the slave. I would expect Channel 1 of the slave to light up.
--Figure K: Top: the master log showed two channels turned on manually Bottom: the slave log did not register any channel activity If you reach here, thanks for your patience.
I've been building an irrigation system over a period of years using a Beaglebone Black as controller, and using simple bash scripts to operate GPIO pins that turn relays on and off. Having finally gotten the bugs out of my entire system, not just hardware and software, but plumbing, wiring, electro-hydraulics, and tweeking sprinklers and drips, its time to think about a more friendly user interface. I like the SIP web user interface, it is very easy to use and fully functional.
It was not difficult to get this SIP app to run on my beaglebone, but I noticed in in the relay_board plugin
Code:
#### define the GPIO pins that will be used ####
try:
if gv.platform == u"pi": # If this will run on Raspberry Pi:
...
else:
print(u"relay board plugin only supported on pi.")
So I get it that there is little interest in running SIP on BBB. Beaglebone Black is really overkill for this app. And I've considered just buying an RPi. I could easily spare $35 for a RPi, but then I'd have to rewire and remap things, so I thought I'd have a go at making this work on BBB first, and I thought I'd post here before I get too much farther to see who is out there.
24,30c23,28
< # ~ if gv.use_pigpio:
< # ~ import pigpio
< # ~ pi = pigpio.pi()
< # ~ else:
< # ~ import RPi.GPIO as GPIO
< # ~ pi = 0
< import Adafruit_BBIO.GPIO as GPIO
---
> if gv.use_pigpio:
> import pigpio
> pi = pigpio.pi()
> else:
> import RPi.GPIO as GPIO
> pi = 0
And I had to add my GPIO pin list here:
Code:
#### define the GPIO pins that will be used ####
try:
if gv.platform == u"pi": # If this will run on Raspberry Pi:
if not gv.use_pigpio:
GPIO.setmode(
GPIO.BOARD
) # IO channels are identified by header connector pin numbers. Pin numbers are
relay_pins = [
...
]
for i in range(len(relay_pins)):
try:
relay_pins[i] = gv.pin_map[relay_pins[i]]
except:
relay_pins[i] = 0
pin_rain_sense = gv.pin_map[8]
pin_relay = gv.pin_map[10]
else:
print(u"relay board plugin only supported on pi.")
...
I think it is immaterial, but I will mention that I took a shortcut by listing the pin names directly, "P8_xx", instead of doing this pin_map lookup like in the original code:
Code:
for i in range(len(relay_pins)):
try:
relay_pins[i] = gv.pin_map[relay_pins[i]]
And though it is a peripheral issue, I will also mention that I disabled the cpu temperature check, which fails on BBB:
to stop cluttering my logs with error messages about "/sys/.../hwmon0/... file not found".
So with that it is basically working, but with a few bugs still to sort out, and I haven't yet tested all the settings and options.
The "Log" feature does not work. At first it was almost working, reporting events and time, but would always report the same station number. Now the log shows nothing at all.
The other weirdness I've noticed is that when I am running sip.py on my BBB and I will have multiple ssh logins open to monitor things, when sip.py crashes or when I click "Restart SIP" on the web interface, all of my ssh sessions are summarily terminated.
So, I don't know if this is interesting to anyone else on this forum. Having gotten this far, I am encouraged to go ahead with making this SIP app work on BBB.
I've noticed recently that the water percentage varies throughout the day(s) despite there being no rain. As an example, last night the percentage was 150%, yet the system only ran for 87% this morning (back up to 150% at the time of this post). No rain for the last week nor is there any for the next week. Is this normal? Am I missing something?
Edited for clarity - what broke that made this not work - want to fix but not looking to start from scratch
Html snippet:
Code:
<option value="-1" ${"selected" if 'dkeyfn' in settings and settings['dkeyfn'] == '-1' else ""}>None</option>
<option value="0" ${"selected" if 'dkeyfn' in settings and settings['dkeyfn'] == '0' else ""}>Start Manual Station</option>
<option value="2" ${"selected" if 'dkeyfn' in settings and settings['dkeyfn'] == '2' else ""}>Set Water Level</option>
<option value="3" ${"selected" if 'dkeyfn' not in settings or settings['dkeyfn'] == '3' else ""}>Set Default Manual Station Time (minutes)</option>
<option value="4" ${"selected" if 'dkeyfn' in settings and settings['dkeyfn'] == '4' else ""}>Set Default Rain Delay Time (hours)</option>
<option value="5" ${"selected" if 'dkeyfn' in settings and settings['dkeyfn'] == '5' else ""}>Start Rain Delay (hours)</option>
option value 1 is omitted but found in the python code:
Code:
# Value functions
FN_NONE = -1
FN_MANUAL_STATION = 0
FN_MANUAL_PROGRAM = 1
FN_WATER_LEVEL = 2
FN_MANUAL_STATION_TIME = 3
FN_RAIN_DELAY_TIME = 4
FN_START_RAIN_DELAY = 5
# Function text must be 9 chars or less
FUNCTION_TEXT = {FN_MANUAL_STATION: u"Station",
FN_MANUAL_PROGRAM: u"Program",
FN_WATER_LEVEL: u"Water Lvl",
FN_MANUAL_STATION_TIME: u"Sta Time",
FN_RAIN_DELAY_TIME: u"RDly Time",
FN_START_RAIN_DELAY: u"Rain Dly"}
and later in the same keypad.py:
Code:
elif self.selected_function == KeypadPlugin.FN_MANUAL_PROGRAM:
programID = value
# Execute program and provide feedback
return programID >= 0 and KeypadPlugin._set_runonce_program(programID)
First of all, thank you for your hard work.
I have a question. It would be possible to add a naming option for irrigation programs? Now it has a number: Program #1. I think it would be helpfull, for different wheather conditions created programs, to recognize it with name.
Hi,
Thanks for a wonderful system and all the hard work that has been put into it. SIP has been truly great, even managing our watering in Australia from onboard a cruise in Norway, truly amazing. Obviously pre COVID.
I had a problem with my raspi installation so had to start again. SIP installs and runs but the web UI but does not respond to button presses. Fortunately I had a copy of SIP folder from before the problems so I was able to copy it back and all is well.
Current Versions:
Raspian Buster
SIP 4.0.2
SIP fails on current version downloaded today May 29, 2021
I would like to thank Dan for the creation of SIP which provides an solid and extendable platform for a custom sprinkler controller.
I’am located at Austria (Europe) nearby Vienna and using SIP to control the irrigation system of my private backyard. The installation has 5 zones for lawn watering supplied by the public water supply and 2 zones for flower beds supplied by an rainwater cistern and a submersible pump. The controller and master valve is located within the basement of my house.
Hardware:
• Beaglebone Black
• Wired Ethernet
• Custom BBB IO Board
o 5V Supply Regulator for BBB
o Realtime clock with backup battery
o 8x 24V Valve Driver Outputs (SolidState, galvanic isolation)
o 4x 24V Digital Inputs (galvanic isolation)
o 24V Output (galvanic isolation)
o 2x 12V Relay Drive Output
o 1x12V Safety Relay Drive Output (GPIO has to be toggled to keep output active)
o 4-20mA Sensor Input (galvanic isolation, switchable 24V sensor supply)
• 1x Cistern Pump Relay
• 1x Relay for 24V transformer supply (controlled by safety relay output)
• 1x Master Valve (Rainbird)
• 7x Zone Valves (Hunter)
• 4-20mA Liquid Level Pressure Sensor (mounted inside cistern)
• 12V DC supply for BBB IO Board
• 24V Comatec Transformer
• Buttons on control box and within the backyard to enable the master valve and cistern pump (connected to 24V digital inputs)
Software: • Custom minimal buildroot linux image, stored on BBB eMMC • rootfs within RAM , only the SIP data directory is stored on an eMMC ext4 partition • NTP time synchronisation • Custom SIP GPIO control modul based on libgiod • HTTPS webinterface access by using HAProxy (running on firewall)
Added Features • Physical buttons to pressurize the backyard water-tap (master valve/cistern pump) for 90min • Display cistern water level on SIP web interface (value in %) • Watchdog functionality within custom SIP Python GPIO control modul to disable 24V valve supply in case of software fault
My SIP is working fine, but when I activate the 'Water Level' adjustment, irrigation does not start.
I have the 'Weather_level_adj' plugin installed, and the fail occurs with both the plugin enabled and disabled.
I finally needed to replace the old sprinkler controller that has been in service for about 60 years. I had been using this dinosaur of a controller for over 20 years, and it's limitations finally prompted me to update. Of course I reviewed prices on new digital controllers from the leading irrigation controller manufacturers, but price and usability led me to this open source solution. I've included some pictures of the circa 1960 controller for your enjoyment.
The old controller had a nice weatherproof hardened enclosure, so I decided to remove the guts of that controller and use the enclosure for my SIP installation. The controller consists of a Raspberry Pi 4b with 3 amp USB-C modular power supply paired with a Huayao 8 Channel Optocoupled 5VDC Relay Module. Interfacing the Pi to the Relay Module was straightforward. I did not split the 5VDC supply on the Relay Board, choosing to drive the relay board entirely from the Pi 5VDC supply. I used the first 6 relays for the 6 existing stations in my existing irrigation configuration. I used the 7th relay as a Master for the 24VAC common line so that the solenoids are completely isolated from the 24VAC transformer when not activated.
I hardwired the Ethernet instead of using WiFi, mostly because my chosen enclosure is effectively a Faraday cage.
I salvaged the 24VAC transformer and 3A circuit breaker from the old controller. I used the existing 110VAC main running to the enclosure for the 24VAC transformer. I may add a extension cord socket pigtail to the 110VAC to plug my USC-C power block into; it's plugged into the GFCI quad outlet next to the enclosure now.
I 3D printed the white bracket to mount the Pi and Relay Board. I used long machine screws (M3) to mount the circuit boards to the bracket, with the head of the screw on the top side of the circuit boards, a nut on the back side of the circuit board, then sandwiched the bracket to the screw with another pair of nuts. So 8 M3 screws and 24 M3 nuts. The mounting holes on the Relay Board are 3mm. The mounting holes on the Pi are 2.5mm. The M3 screws installed on the Pi with a tight fit, tapping threads into the circuit board with the screw didn't appear to damage the circuits or components and the head and nut have adequate clearance from the components on the board, although less clearance than the appropriate M2.5 screws and nuts would have. I used metal screws and nuts. If I was less anxious to assemble this project, I would have purchased the appropriate size screws for the Pi, and probably would have used nylon instead of metal.
My wife is the primary user of the system. She's happy with it so far. She likes the interface. She says it intuitive. She asked a few questions about manual operation and she wants to be able to set the start time relative to sunrise. The manual operation was simple to explain. I've responded to a separate thread about setting start time relative to sunrise. I'm guessing it's going to take me a couple of weeks part-time to resolve that issue. Maybe there'll be another plugin available once I get it implemented.
I'm also looking at adding a water meter pulse interface to the Pi so I can set the station ON DURATION based directly on measured water volume instead of time.
I'm also looking at automatically adjusting station time/volume based on additional environmental inputs besides rainfall. In the desert southwest we have drastic shifts in humidity that effect evaporation rates. I want to be able to reduce water time/volume when the humidity is high resulting in less evaporation.
I'm excited about my new controller based on the Sustainable Irrigation Platform documentation and software. It was an easy build and setup.
My short term concerns with the new installation:
1. Will the Pi survive the heat? It gets up to 120°F in the shade here. My Pi has head sinks attached, but no fan. The enclosure is in the shade 100% but has no ventilation, although it is large and not air tight on the bottom. Will I need to add a fan and vents for circulation?
2. Will it be durable? My last controller was 60 years old and still functioning as designed. I don't expect that type of durability on this setup, but it would be nice to get 20 years out of it.
I have a setup where I am controlling a light for my seedling starting area. During the time that the light is on (roughly 14 hours a day) I would like to be able to turn an aquarium pump on to water. With the light on, when I turn the pump on the light program turns itself off. I have unchecked the sequential box and have experimented with the individual duration option, but each time I turn the pump on during the time the light program is running the light program is cancelled. I am using the an exact version of the 74HC595 Shift Register DIY relay interface described in the Wiki to control my solid state 12 volt relays.
Is what I am attempting to do even possible with the SIP Software? It may be that the output to the shift registers does not include the already running program bit, in which case might this not be a new feature that allows better flexibility as a controller?