Open-Source Professional-Grade Aquacontroller
- Thread starter GT_Engineering
- Start date
streaming DIY (IoT)data....so cool.. just dont want my toaster and toilet demanding I do it before they turn on.
I teach RPI mosquitto w/ thingspeak publishing MQTT weather station data. Though I never used thingsboard, I was thinking their secret sauce were the easy custom skins/dashboard. Got to have bling.
You have everything but one large " Bottle of Wiring Install and Software Config " w/ convenient spray-on applicator in the BOM.
This may be one of the best in class since I built (and still use) a quaint Jarduino Led controller (with manual bypass pots).
I'm pondering what a valuable minimalist DIY P1AM-100 starter might look like. 1. A catastrophic boiling(temp) animals and house flooding internet(IoT) alert. 2. AC !!!! or DC soft start and variable (PWM) pump control/ timer (wave maker) with manual toggle feed mode.
tag: reef, IoT, Arduino, P1AM, DIY
I teach RPI mosquitto w/ thingspeak publishing MQTT weather station data. Though I never used thingsboard, I was thinking their secret sauce were the easy custom skins/dashboard. Got to have bling.
You have everything but one large " Bottle of Wiring Install and Software Config " w/ convenient spray-on applicator in the BOM.
This may be one of the best in class since I built (and still use) a quaint Jarduino Led controller (with manual bypass pots).
I'm pondering what a valuable minimalist DIY P1AM-100 starter might look like. 1. A catastrophic boiling(temp) animals and house flooding internet(IoT) alert. 2. AC !!!! or DC soft start and variable (PWM) pump control/ timer (wave maker) with manual toggle feed mode.
tag: reef, IoT, Arduino, P1AM, DIY
I'm actually running all of the MQTT data on a private network only between the Apex, P1AM, and thin client. The thin client is bridged to the internet for external communication, but the MQTT only runs on the local machine network.
Thingsboard is cool, but it's ultimately going to be up to the end user. I'm not a web engineer, so I don't want to relegate myself to a single platform (that would be antithetical to why I started this project to begin with). I'm going to define an MQTT API with well-defined RPC's such that it could communicate with any end-platform people wanted to integrate it with.
Check out my BOM I posted earlier - It got up to $1500, but that's including a $500 enclosure + subpanel and another $200 in pushbuttons/signal tower, which most people probably won't want. If you're just wiring the appliances directly into the PLC (Not separating field and cabinet IO with terminal blocks) you could do the whole setup with just the PLC at ~$350.
Reliability and failsafes are being built in from the ground-up. Heaters should already have a thermistor on them, and they're being connected to NC relays (such that the PLC will be able to catch stuck thermistors and turn the heater off, but won't hold the heater off and potentially get the aquarium too cold in case the electronics fail). I'd also recommend at least one powerhead wired directly into mains power such that, if the unit goes into Fault mode, you're not worried about one side of the tank getting hot while the others get cold (in stagnant water). Either way, you'll be notified immediately as the "heartbeat" handshake will time out within 10s of a fault.
Building a stable, failsafe system is my #1 priority, which is why I'm not doing anything too fancy with the web interface right now. The web interface is going to be an auxiliary system that interfaces with the unit without affecting the core life support systems. I'm testing it on my tank, which I wouldn't do if there were any chance of something bad happening (i.e. if the controller goes down, all of the livestock will be fine). That's why I included the pushbuttons (start, stop, reset) and light tower (Red, Green, Amber, Blue), and the system will be 100% controllable from these buttons/indicators 100% of the time.
New Update - After 24 hours of non-stop operation, 15,000 MQTT messages for 13 continuously monitored parameters, and one reef aquarium that has been neglected for water changes, it looks like things are coming along...
(and don't worry, neither the pH probe nor the thermometer is calibrated. I definitely don't run my tank at a pH of 9!)
(and don't worry, neither the pH probe nor the thermometer is calibrated. I definitely don't run my tank at a pH of 9!)
New Dashboard!
I'm definitely not a web designer...
Would anyone be interested in giving it a hack?
I'm definitely not a web designer...
Would anyone be interested in giving it a hack?
New Update!
Really liking how easy thingsboard integration was. Backend integration was NOT something I was looking forward to. Still, the MQTT API is pretty universal, so integrating it into another platform like ReefPi wouldn't be too difficult.
Added the "P1-08SIM" module as an onboard master control switchboard and I've actually liked it a lot more than I thought.
Added the Chronos.h library back in for the scheduling alarms
Moved all of the IO declarations into their own file (IO.h)
Now with schedulers in place for lights, dosers, autofeeders
Weird little "hello world" application in the ATO task that pulses the front LED indicator a specific number of times
New task in place for autofeeders (hasn't been compiled, much less tested). Same for dosers.
New task for "power equipment"
Now logging levels can be set on an individual task basis! (i.e. log verbose on a new program while only warning and above on the others)
Now Thingsboard Telemetry and RPC's are in two separate tasks.
New task for lights
Added the IO Mapping file
Really liking how easy thingsboard integration was. Backend integration was NOT something I was looking forward to. Still, the MQTT API is pretty universal, so integrating it into another platform like ReefPi wouldn't be too difficult.
Added the "P1-08SIM" module as an onboard master control switchboard and I've actually liked it a lot more than I thought.
Added the Chronos.h library back in for the scheduling alarms
Moved all of the IO declarations into their own file (IO.h)
Now with schedulers in place for lights, dosers, autofeeders
Weird little "hello world" application in the ATO task that pulses the front LED indicator a specific number of times
New task in place for autofeeders (hasn't been compiled, much less tested). Same for dosers.
New task for "power equipment"
Now logging levels can be set on an individual task basis! (i.e. log verbose on a new program while only warning and above on the others)
Now Thingsboard Telemetry and RPC's are in two separate tasks.
New task for lights
Added the IO Mapping file
Attachments
I have no idea what happened with that last post. Anyways, here's the github repo URL:
And, of course, pictures
And, before anyone asks... no, that pH probe is not calibrated.
Check
Is this some new hip lingo reference I'm missing? then man... I just started saying yeet like not that long ago, you're going to have to bring me up to speed.
I know it seems like there's not a lot of comments after your posts. But I for one am following along. I really like what you're doing so far!
I am still a ways away from having my new tank up and running and have a newer version Apex to get me started. I could definitely see myself transitioning to this type of system control in the future.
As I set my new system(s) up the Apex going to have a minimum of 1 EB832, 3 EB8's, 1 EB4 and at least 8 modules running things in the beginning. I'm also going to be able to have an electronics cabinet that is not under an aquarium or near any water. I'm still working the details in my mind as to how I want to locate things but it would sure be nice to lose some of those power bars.
I have several questions that I'll list below so they don't get lost in a paragraph that may run on & on like I tend to do.
1) I see you're using a couple Neptune modules, PM1 & FMM. How easy was it for you to incorporate them into you're design and do you plan on replacing them in the future?
2) I plan on getting a Trident or two at some point down the road. Do you think you'd also be able to add one, or multiples, into this? Or is something like that a little too complex?
I don't see how something like that could be replaced via DIY at this time. Do you think it's possible?
3) Would you be willing to come over to my house and take a look at what I've got planned for my new tank and fish/sump room?
Adam,
TYVM for the shout! let me try to answer some of your questions and give some feedback (this may take multiple posts) but these are excellent questions!
Space was a big consideration in this design, and it's one of the reasons I chose to strip and ferrule all of the 120V cabling instead of using the standard 120V wall socket. What you've spec'd up there is 36 relay outputs. That's a lot of electricity, and you should really take that into account when designing your system.
For PM1 (pH, ORP, Digital Inputs), the unit I got from DFRobot.com (~$40) took the same BNC probe. Right now, I've reconnected that probe into the Apex because that's where I last calibrated it. The pH probe that came with it had a cable that was too short, so I've ordered a new one. The AI unit I'm using (P1-4ADL2DAL-2 ) is 0-10V (external 24VDC supply), but the DF robot unit I'm using is 0-5V, so I tied the 0V of the 5V and 24V supplies and it gives excellent accuracy/precision.
For the FMM - right now I have it active. The Digital Output unit I'm using (P1-08TD2 ) can actually drive that PMUP pump directly, so I'll be able to use that.
The IR optical sensors that determine the water level are 3-wire npn sensors, which will work with the sinking/sourcing digital input card I'm using (P1-08ND3), will drive the states.
I'm actually going to get at least 3 IR optical sensors, and here's why - the top will be a "redundant" to the middle, and the bottom will be a "safety check", so if I've accidentally knocked it off of its spot and all 3 are out of water, I don't want the ATO pump to turn on. That's one of the reasons I wanted the Red/Green/Blue indicator lights - to always err on the side of "failsafe", and make sure that it's not the "chokepoint" of the system. That's why I added the Input simulator modules (P1-08SIM ) - they give you as close to a "hard-wired" system as possible, so if your HMI/webpage isn't reloading, you have always have a way to control the system.
I have the AFS module as well. In the next revision of my code, there will be a DO mapped to a DI channel on the Apex, and tie the Autofeeder signal to the digitial input on the PM1 module and keep the Apex jr. running.
Is it possible? yes. Am I going to have time to spearhead the project? probably not.
Neptune took years and years to develop this module, and it only works with the Apex Neptune aquacontroller. And since it's a proprietary system, there's no feasible way to tie directly into the low-level signals and readings. What is possible, however, is to integrate the data from the Trident in with the data from this into the same cloud platform.
TYVM for the shout! let me try to answer some of your questions and give some feedback (this may take multiple posts) but these are excellent questions!
Space was a big consideration in this design, and it's one of the reasons I chose to strip and ferrule all of the 120V cabling instead of using the standard 120V wall socket. What you've spec'd up there is 36 relay outputs. That's a lot of electricity, and you should really take that into account when designing your system.
For PM1 (pH, ORP, Digital Inputs), the unit I got from DFRobot.com (~$40) took the same BNC probe. Right now, I've reconnected that probe into the Apex because that's where I last calibrated it. The pH probe that came with it had a cable that was too short, so I've ordered a new one. The AI unit I'm using (P1-4ADL2DAL-2 ) is 0-10V (external 24VDC supply), but the DF robot unit I'm using is 0-5V, so I tied the 0V of the 5V and 24V supplies and it gives excellent accuracy/precision.
For the FMM - right now I have it active. The Digital Output unit I'm using (P1-08TD2 ) can actually drive that PMUP pump directly, so I'll be able to use that.
The IR optical sensors that determine the water level are 3-wire npn sensors, which will work with the sinking/sourcing digital input card I'm using (P1-08ND3), will drive the states.
I'm actually going to get at least 3 IR optical sensors, and here's why - the top will be a "redundant" to the middle, and the bottom will be a "safety check", so if I've accidentally knocked it off of its spot and all 3 are out of water, I don't want the ATO pump to turn on. That's one of the reasons I wanted the Red/Green/Blue indicator lights - to always err on the side of "failsafe", and make sure that it's not the "chokepoint" of the system. That's why I added the Input simulator modules (P1-08SIM ) - they give you as close to a "hard-wired" system as possible, so if your HMI/webpage isn't reloading, you have always have a way to control the system.
I have the AFS module as well. In the next revision of my code, there will be a DO mapped to a DI channel on the Apex, and tie the Autofeeder signal to the digitial input on the PM1 module and keep the Apex jr. running.
Is it possible? yes. Am I going to have time to spearhead the project? probably not.
Neptune took years and years to develop this module, and it only works with the Apex Neptune aquacontroller. And since it's a proprietary system, there's no feasible way to tie directly into the low-level signals and readings. What is possible, however, is to integrate the data from the Trident in with the data from this into the same cloud platform.
Yes
I moved into a new house last fall and am in the process of finishing the basement. Space is not something I'm going to be lacking in this go around. I've got a 500 gallon display being delivered in a month and the sump room is around 450sf.
I didn't think the Trident could be incorporated but the fact that you believe the data values can be pulled is great. I don't mind running two systems for control & monitoring. In fact I'd prefer it, I think it would be a robust level of redundancy. I like this IT aphorism and I'll repeat it over and over. "One is none and two is one."
I'm running the electrical wiring now and with your automation experience I'd love to hear your thoughts on my layout plan for the control systems, especially at this stage before the drywall is up. I see your in Suwanee. I'm a little north of you in Flowery Branch and I'm off work thru Monday. I'll shoot you a PM with my info.
Official V1.0 Release!
Demo Video-
Link to Repo.-
https://github.com/JohnnyG89/SeaDragon
Updates:
Put the Physical IO declarations and alarms (output scheduler) into "IO.h"
Pre-compile Macro for whether or not to use the PubSub.h library directly (prgMQTT, prgRPC) or use the ThingsBoard Wrapper (Thingsboard.h). Use one or the other.
Each task with network comms has its own EthernetClient() instance
Global "Fault Word" for transferring, recording machine faults
Put the IO modules into their own structure to make it easier to make functions for common functionality
Hourly alarms for the powerhead and wavemaker
Autofeeders and equipment now have their own tasks. (prgATO was replaced by prgEquipment)
2x SIM input modules for hard-button control
Re-initialization of hardware if power is lost
Raw, smooth, and scaled calculators for the analog sensors (pH, 2x Temp)
Lights now have their own task.
prgMQTT - sample and send telemetry values in chunks
prgRPC - catch RPC calls and manage the commensurate IO
New pre-compile macro's so you're not including tons of objects that aren't being used in your current configuration (i.e. including both prgMQTT/prgRPC and prgThingsBoard_Telemetry/prgThingsBoard_RPC will eat up all of the SRAM!)
StorageManager and CommManager are now wrapped into "program.ino" bc you can only fit so many tabs in the Arduino IDE before it gets clunky.
Some memory optimizations
Powerhead/wavemaker control
200 samples for smoothing average for analog sensors
Separate MQTT clients and topics for telemetry and RPC management
Demo Video-
Link to Repo.-
https://github.com/JohnnyG89/SeaDragon
Updates:
Put the Physical IO declarations and alarms (output scheduler) into "IO.h"
Pre-compile Macro for whether or not to use the PubSub.h library directly (prgMQTT, prgRPC) or use the ThingsBoard Wrapper (Thingsboard.h). Use one or the other.
Each task with network comms has its own EthernetClient() instance
Global "Fault Word" for transferring, recording machine faults
Put the IO modules into their own structure to make it easier to make functions for common functionality
Hourly alarms for the powerhead and wavemaker
Autofeeders and equipment now have their own tasks. (prgATO was replaced by prgEquipment)
2x SIM input modules for hard-button control
Re-initialization of hardware if power is lost
Raw, smooth, and scaled calculators for the analog sensors (pH, 2x Temp)
Lights now have their own task.
prgMQTT - sample and send telemetry values in chunks
prgRPC - catch RPC calls and manage the commensurate IO
New pre-compile macro's so you're not including tons of objects that aren't being used in your current configuration (i.e. including both prgMQTT/prgRPC and prgThingsBoard_Telemetry/prgThingsBoard_RPC will eat up all of the SRAM!)
StorageManager and CommManager are now wrapped into "program.ino" bc you can only fit so many tabs in the Arduino IDE before it gets clunky.
Some memory optimizations
Powerhead/wavemaker control
200 samples for smoothing average for analog sensors
Separate MQTT clients and topics for telemetry and RPC management
Also, here's an update IO Mapping schema
I didnt think about adding a status light to my homemade "apex" build but i will now. Ill grab a light today while im at work.
I ALWAYS add hard-wire control and indicators. Not going to risk ruining my tank while I'm trying to debug a web server! Since making that list above, I've actually added another P1-08SIM for manual toggling the autofeeders and dispense pumps.
