Multiple Master stations (pump sources) possible?

[dpd]

Hello!

I am looking at different open source sprinkler options for an irrigation/fertigation installation, for an indoor growing facility.
SIP looks pretty awesome, and the MQTT integrations and data logging etc. make it look a lot more flexible than commercial controllers.
And I am an RPI enthusiast so it's a big win

I have plants at different growth stages at the same time, with different nutrient formulations for different zones.

So I will have around 6 "master" stations that will be triggered for pump activation, for around 16 zones. Each zone will have a single master (source tank).

I haven't had a chance to set up SIP yet, I'm still planning the system. So forgive me if this is an easy question to answer once browsing the app, but I couldn't see the feature in the documentation....

- Is it possible to have more than one master station, and to select the master station for a zone in the UI?
- If it's not explicitly supported, has this challenge come up before, with a reasonable workaround?

I am not planning on using any hardware, just MQTT plugin to control PLCs around the facility that will work valves. So physical relays aren't a limitation.

Thank you, and great work developing this platform!!!

[dan]

What you describe should be possible.

When you say "multiple masters" that implies that there will be other stations on at the same time. This can be accomplished by setting SIP to "concurrent mode": From the options  page under Station handling, uncheck Sequential.

You can then program multiple stations to be on at the same time.

Good luck with you project. Let me know if I can be of further help.

Dan

[dpd]

Hi Dan, thanks for your reply. I may not have explained the question clearly.

I am not concerned with running any 2 stations at the same time.
As far as I understand, concurrent mode does not help me.

Rather, for example:
I would like to fire up pump1, drawing from reservoir 1, to irrigate zone 1.
Then run pump2, from res2, to irrigate zone 2,3.
Then run pump3, from res3, to irrigate zone 4,5,6,7,8, ....

This example requires multiple different pumps mapped to zones.
So, 3 "master" zones. They can run sequentially or concurrently, no matter at this point.

Is this possible? Commercial irrigation controllers would call them pump1,pump2,pump3 and allow assignment to zones. 
Each pump is assigned to 1..n zones. Each zone has only one pump assigned.

Hopefully that is more clear!

---

On further thought, I wonder if you mean that I should "cheat" by running in concurrent mode?

For example, designate zones 31,32,33 as masters (not in the UI, just in my mind)
Then run concurrent zones:
1,31
2,32
3,32
4,33
5,33
6,33
7,33
...

Sounds like this will achieve the effect I want, thank you.
Not as elegant as assigning zones to one of 3 master options, in the UI, but should be a perfectly good workaround.
After I give it a go, I'll file a feature request

[astrogerard]

Since you are a RPi and mqtt enthousiast (like me  ) you could also add Node-Red to the Pi and add/modify the mqtt traffic. I do the same to interface SIP with my home automation system. Works great.

--Gerard

[dpd]

Since you are a RPi and mqtt enthousiast (like me  ) you could also add Node-Red to the Pi and add/modify the mqtt traffic. I do the same to interface SIP with my home automation system. Works great.

--Gerard

Certainly, point taken! I'll be diving into node-red soon to work with the mqtt traffic, and I might do the zone-to-pump assignments there.

For the moment, I'd like to do as much config in SIP as possible, since I have a nice interface here.
But in the end, I might set up a node red / grafana control panel to do the assignments. Still working it out.

A commercial irrigation controller will have a zone config page, where a zone can be assigned to one of multiple pumps.
That would be cool in SIP, but if I'm the only one that cares about it, I will figure it out elsewhere, like node red

[dan]

Since you are a RPi and mqtt enthousiast (like me  ) you could also add Node-Red to the Pi and add/modify the mqtt traffic. I do the same to interface SIP with my home automation system. Works great.

--Gerard

Certainly, point taken! I'll be diving into node-red soon to work with the mqtt traffic, and I might do the zone-to-pump assignments there.

For the moment, I'd like to do as much config in SIP as possible, since I have a nice interface here.
But in the end, I might set up a node red / grafana control panel to do the assignments. Still working it out.

A commercial irrigation controller will have a zone config page, where a zone can be assigned to one of multiple pumps.
That would be cool in SIP, but if I'm the only one that cares about it, I will figure it out elsewhere, like node red

I'm not clear on the difference between assigning a "station" in SIP to a pump versus an irrigation valve.
SIP can be use to control pumps , lights, etc.

If there is an application that SIP can't support -- That's what plugins are for. Can you describe the what you are after in more detail?

Dan

[dpd]

Sure, I'll try to describe. I appreciate you taking the time!

The concept of pumps and stations, differs from simply running stations, because of concurrency of pumps and stations (without full concurrency of everything at once).
Each watering-station will always have one of the pump-stations running at the same time, but these pairs must be separated in time (sequential).

In a commercial irrigation installation, you might have physically distant areas that need pumps to provide pressure.
In my case, I have different nutrient tanks with different formulations, requiring separate pumps to feed the irrigation zones when they are triggered.

In a commercial controller, you might have as many as 6 pump connections. They differ from regular zones, as they are triggered at the same time as zones. So zone 1 runs as pump 1 runs, zone 7 with pump3, etc. Zones are assigned to pumps in a static manner, i.e. zone 7 will *always* come from pump 3. This is a limitation that I'm happy SIP might not have.

Simply choosing sequential vs. concurrent doesn't cover the use case, as I don't want to run all stations at once, for the power requirement and other reasons.

I've been playing with the Combine-Stations plugin, and this comes close, but the limit of 8 virtual stations is limiting

It would be great to be able to assign e.g. 6 extension boards, and choose 8/16/24/32/40/48 virtual stations to come out of that total.
This would allow me to do just about anything I can think of (now).

---
You asked about the actual problem I'm trying to solve, I'll try. It is complex.

The facility has 4 flowering rooms, 2 vegetative rooms.
Each flowering room has 8 irrigation zones (valves). Veg has 3. Total is ~38 zones.

The facility runs a weekly planting cycle, with an 8 week duration in the flower room, which means that in a single flower room has 8 different developmental stages.
There are approximately 3 different nutrient formulations, e.g. Formula 1: weeks 1-3, Formula 2: weeks 4-6, Formula 3: weeks 7-8.

So in this example I have 3 reservoirs with 3 pumps.
I have 8 zones * 4 rooms = 32 zones.

With combine-stations, I can create 8 virtual stations, which will cover the first flower room nicely.
Zone -> Pump:
1->1, 2->1, 3->1, 4->2, 5->2, 6->2, 7->3, 8->3.

For the second flower room, I would like 8 more virtual stations for 9->1, 10->1, etc.
But I ran out!

So, I think a modification to the combine-stations plugin that allows me to choose 8,16,24,32,40,48,.... instead of being fixed at 8 virtuals would cover my use case perfectly.

Make sense? Am I missing another option with the existing code?

Thanks so much for listening!
I would dive in to modifying the plugin myself, and I might, but I have zero python experience

[dan]

Thanks for the additional details. That makes things clearer.

It has been a while since I wrote the combine stations plugin but I just took a quick look at the code. The limit of 8 virtuals was because of the particular use case that prompted the creation of the plugin and no extension boards were being used.

It looks like it would be easy to increase the number of virtual stations, just a change to line 108 in the file combine_stations.py should do it.

It would also require a modification of the set-up page. Also not a big deal.

It is also possible to control multiple Pis from a "master" Pi using the mqtt_slave plugin. This may or may not be a good solution due to a lack of feedback from the slave Pis.

Dan

[dpd]

Thanks again for your reply!

I think this project will be the catalyst for me to learn python, to work on SIP plugins.
I have had good success getting MQTT into node red, so far so good! But I'm just getting started....

There is another complication, and that is that the physical irrigation zones (valves) 1..8 in a flower room, must rotate their program weekly.
For example, valve 1 will water for a week-1-duration this week, and a week-2-duration next week, and so on (as the plants age in place).
Valve 8 will shift to week 1, as the plants get moved to harvest workflow and a new crop is put in. Basically barrel shifting program duration values, across stations, every Monday.

I think this is enough of an edge case that it's to be implemented in node-red, not addressed in SIP!
Since I'll need a controller for the week#->valve# assignment shifts anyway, it may be that a node-red controller is also the best place to designate pumps/sources for week#s.
I'll keep the forum up to date on my progress if you like, I think this is going to be fun!

The hardware aspect just in case you're interested, is that the MQTT will be caught by node-red, turned into s7/modbus, and sent over ethernet to Siemens LOGO! PLCs to drive the irrigation valves, proximal to each growing station.
The LOGO! units will have RS485 (modbus/TCP) soil moisture sensors that will interrupt (or ignore entirely) the valve actuations once a certain soil moisture level is reached.

If I implement this at the SIP level, it will require an MQTT message to originate with the PLC, to node-red, to SIP, to interrupt a single station. I don't think this is implemented in SIP yet but should be straightforward with a plugin.

However I am considering another topology / approach for SIP integrating with the rest of the system, and that is: to export the irrigation programs from SIP (not possible with the HTTP or MQTT yet AFAIK), parse the program config with node-red, and send each PLC its own individual daily watering schedule to store in PLC memory, to run without supervision. So SIP will provide a beautiful interface for entry and visualization of programs, which are then parsed and distributed to the PLC network to provide functionality regardless of the RPI's up/down status.

My favourite idea might be a hybrid of the two. Program the PLCs with SIP's programs as a failover, and only run the local-PLC schedule if modbus tells the PLC that the controller (RPI) is down. When the controller is up, ignore the local program, and follow SIP's instructions. So any time the RPI/SIP is down, the PLCs follow the last-known-program and I don't have to drive in to work to troubleshoot. Best of both worlds! I have to say, my first dive into node-red is blowing my mind for what's not only possible, but incredibly simple to implement, things that would have been a nightmare in the past!

So a quick question, if you made it this far
Is there an existing way to output the programData.json info from SIP? I see nothing in the HTTP spec or MQTT plugins, but I figured I'd ask that there's nothing new and undocumented, before making that a plugin project.
Thanks again!

[dan]

Yes please keep us updated on your progress.

You can now post questions and update info to the brand new Discussions list at SIP's GitHub repository. Just click the "software" link at the bottom of any SIP page then click the Discussions tab on GitHub. (Not sure if you need to sign into GitHub to post there.)

As far as exporting the programsData.json file from SIP, it would only require copying the file into the SIP/static folder and then SIP's web server could serve it over the network. A simple bit of Python code could (1 or 2 lines) could copy the file. Then it would just be a matter of accessing: [URL of SIP]/static/programData.json. EDIT: All you need to do is:
[URL of Pi]/jp
That will give you the program data.

It should be a simple customization to add a copy function for when a program is saved/updated.

FYI: you can download a PDF file of HTTP commands for controlling SIP over the network at:
https://github.com/Dan-in-CA/SIP/wiki/SI...mmands.pdf

SIP has some functionality for communicating with plugins via a message signaling system using the Python blinker module. There was a resent addition to the built-in blinker signals that broadcasts a message just after midnight each day. Python has some easy methods for figuring out what day it is. This could make for fairly painless plugin development for a rotating schedule like you describe.

The full list of implemented signals can be found in the file SIP/plugins/signaling_examples.py

Dan