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!
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!