Mattgsa 315 gallon build

[mattgsa]

One of the smaller additions I’m working on right now is actually one of the more interesting telemetry ideas so far: load sensors under the skimmer waste container.

At first glance it probably sounds unnecessary, but the goal is not just “know when the bucket is full.” I already have float shutoffs for overflow protection handled through the PLC.

What I’m really after is trend data.

By continuously tracking the weight of the skimmate over time, Jarvise can start learning what “normal” skimmer production looks like for this system.

For example:

• skimmer suddenly producing much wetter skim than normal
• production rate dropping unexpectedly
• unusually rapid increases after feeding or maintenance
• long-term export trend changes over weeks/months

That kind of telemetry becomes surprisingly valuable once it’s correlated with other data like:

• feeding events
• reactor behavior
• pH
• ORP
• water changes
• fish behavior
• camera monitoring

The interesting part is that this is actually one of the cheaper sensors in the system. The load cell setup I’m experimenting with right now was only around $10 on Amazon for the sensor kit and HX711 amplifier board.

Obviously this is prototype-level hardware and probably won’t survive forever in a salty fish room environment, but it’s cheap enough to experiment with and learn from before moving to more industrial-grade sensors later.

That’s honestly a big part of this whole project:
trying ideas, gathering telemetry, and figuring out which signals actually provide useful insight into how the system behaves over time.

 

[tharbin]

One of the smaller additions I’m working on right now is actually one of the more interesting telemetry ideas so far: load sensors under the skimmer waste container.

At first glance it probably sounds unnecessary, but the goal is not just “know when the bucket is full.” I already have float shutoffs for overflow protection handled through the PLC.

What I’m really after is trend data.

By continuously tracking the weight of the skimmate over time, Jarvise can start learning what “normal” skimmer production looks like for this system.

For example:

• skimmer suddenly producing much wetter skim than normal
• production rate dropping unexpectedly
• unusually rapid increases after feeding or maintenance
• long-term export trend changes over weeks/months

That kind of telemetry becomes surprisingly valuable once it’s correlated with other data like:

• feeding events
• reactor behavior
• pH
• ORP
• water changes
• fish behavior
• camera monitoring

The interesting part is that this is actually one of the cheaper sensors in the system. The load cell setup I’m experimenting with right now was only around $10 on Amazon for the sensor kit and HX711 amplifier board.

Obviously this is prototype-level hardware and probably won’t survive forever in a salty fish room environment, but it’s cheap enough to experiment with and learn from before moving to more industrial-grade sensors later.

That’s honestly a big part of this whole project:
trying ideas, gathering telemetry, and figuring out which signals actually provide useful insight into how the system behaves over time.

I'm usually rather skeptical of tank automation projects for a number of reasons but I also like the thought processes that go into solving the issues. I also think we could do much more to monitor and predict issues with our tanks.

I'm only on page 7 of your build thread so far but I like a lot of what I see. From this post I like it even more. The idea of using PLC for accident prevention/remediation, data collection, and automation tasks and then using AI for analysis and prediction makes sense to me. I don't think I would ever go there as a project for my tanks but I do like the design aspects of the endeavor.

I also like the DIY approach to much of it as I don't know of an aquarium automation/monitoring solution in the market that doesn't have as many flaws as features. Every time we automate a task on our tanks we reduce our manual labor and potentially increase repeatability and accuracy but introduce a potential failure point that we then need to mitigate.

Some of the areas you are investigating would be very useful, especially to newer reefers. Things like checking the skimmate production and quality is ingrained in a seasoned reefer but not so in the average new reefer and certainly not in any of the current crop of aquarium controllers. Your use of industrial-quality components is also very refreshing.

I look forward to reading the rest of your thread to better understand where things are currently and where you are planning to take them.

 

[mattgsa]

One of the smaller additions I’m working on right now is actually one of the more interesting telemetry ideas so far: load sensors under the skimmer waste container.

At first glance it probably sounds unnecessary, but the goal is not just “know when the bucket is full.” I already have float shutoffs for overflow protection handled through the PLC.

What I’m really after is trend data.

By continuously tracking the weight of the skimmate over time, Jarvise can start learning what “normal” skimmer production looks like for this system.

For example:

• skimmer suddenly producing much wetter skim than normal
• production rate dropping unexpectedly
• unusually rapid increases after feeding or maintenance
• long-term export trend changes over weeks/months

That kind of telemetry becomes surprisingly valuable once it’s correlated with other data like:

• feeding events
• reactor behavior
• pH
• ORP
• water changes
• fish behavior
• camera monitoring

The interesting part is that this is actually one of the cheaper sensors in the system. The load cell setup I’m experimenting with right now was only around $10 on Amazon for the sensor kit and HX711 amplifier board.

Obviously this is prototype-level hardware and probably won’t survive forever in a salty fish room environment, but it’s cheap enough to experiment with and learn from before moving to more industrial-grade sensors later.

That’s honestly a big part of this whole project:
trying ideas, gathering telemetry, and figuring out which signals actually provide useful insight into how the system behaves over time.

I'm usually rather skeptical of tank automation projects for a number of reasons but I also like the thought processes that go into solving the issues. I also think we could do much more to monitor and predict issues with our tanks.

I'm only on page 7 of your build thread so far but I like a lot of what I see. From this post I like it even more. The idea of using PLC for accident prevention/remediation, data collection, and automation tasks and then using AI for analysis and prediction makes sense to me. I don't think I would ever go there as a project for my tanks but I do like the design aspects of the endeavor.

I also like the DIY approach to much of it as I don't know of an aquarium automation/monitoring solution in the market that doesn't have as many flaws as features. Every time we automate a task on our tanks we reduce our manual labor and potentially increase repeatability and accuracy but introduce a potential failure point that we then need to mitigate.

Some of the areas you are investigating would be very useful, especially to newer reefers. Things like checking the skimmate production and quality is ingrained in a seasoned reefer but not so in the average new reefer and certainly not in any of the current crop of aquarium controllers. Your use of industrial-quality components is also very refreshing.

I look forward to reading the rest of your thread to better understand where things are currently and where you are planning to take them.

I really appreciate the thoughtful response. Honestly, a lot of your concerns are the same ones I’ve had over the years with automation in this hobby.

I think one of the biggest mistakes people make is treating automation itself as the goal, when in reality every automated task introduces new failure modes that have to be understood and mitigated. That’s actually a big part of why I started moving toward PLCs and industrial-style controls instead of relying entirely on traditional aquarium controllers.

The AI side is honestly the part people focus on the most, but the deterministic safety layer underneath it is the part I care about the most. My goal is not to let AI directly “run the tank,” but more to use it as a supervisory layer that can learn what normal system behavior looks like over time and identify when something starts drifting before it becomes obvious to me.

You also touched on something I’ve been thinking about a lot lately: experienced reefers subconsciously monitor hundreds of little signals all the time. We notice things like:
- skimmer behavior changes
- fish acting differently
- water clarity shifts
- reactor instability
- algae growth changes

A newer reefer often doesn’t know what those subtle changes mean yet. One of my long-term goals is seeing if some of that pattern recognition can eventually be modeled and surfaced through telemetry and analysis.

Will it ever replace experience? Probably not. But if it can help catch problems earlier or help newer hobbyists understand what their systems are trying to tell them, I think that could be genuinely useful.

And honestly, I’m still learning as I go here too. Some ideas will probably work great, some will probably fail completely, but the experimentation and architecture side of the project has been a lot of fun so far.
Thanks Matt

 

[That Crusso Kid]

One thing I’ve realized while building this system is that I’m not really trying to create a “smart aquarium controller” anymore. What I’m actually building is a layered automation and monitoring platform that happens to run a reef tank.

That may sound overkill for a home aquarium, but after seeing enough failures in this hobby — from stuck valves to failed sensors to missed alerts, I started thinking about reef systems more like industrial process systems than hobby equipment.

The biggest shift in my thinking has been this:

AI should not be the first safety layer.

The PLC handles deterministic control and fail-safe logic:

• overflow prevention
• leak response
• pump shutdowns
• interlocks
• emergency states

Jarvise handles the higher-level intelligence:

• telemetry analysis
• trend monitoring
• anomaly detection
• predictive behavior
• long-term learning

The goal is not “AI controls everything.” The goal is teaching the system what normal behavior looks like over time so it can recognize when something no longer makes sense.

For example:

• a valve reports closed but flow never changes
• skimmer production suddenly doubles overnight
• reactor pressure drifts slowly over days
• fish behavior changes before chemistry swings become obvious

Those are the kinds of things humans often notice instinctively, but traditional controllers usually don’t.

That’s the direction I’m trying to push this project toward:
not replacing reef keeping, but building a system that becomes better at understanding the environment over time.

Honestly, even if this never becomes fully autonomous, the process of building it has already changed the way I think about reef automation entirely.

I wish I knew more about these things as I'd truly love to be able to jump in and contribute.

That’s honestly a big part of this whole project:
trying ideas, gathering telemetry, and figuring out which signals actually provide useful insight into how the system behaves over time.

This sort of data could prove to be very useful and invaluable.

I really appreciate the thoughtful response. Honestly, a lot of your concerns are the same ones I’ve had over the years with automation in this hobby.

I think one of the biggest mistakes people make is treating automation itself as the goal, when in reality every automated task introduces new failure modes that have to be understood and mitigated. That’s actually a big part of why I started moving toward PLCs and industrial-style controls instead of relying entirely on traditional aquarium controllers.

The AI side is honestly the part people focus on the most, but the deterministic safety layer underneath it is the part I care about the most. My goal is not to let AI directly “run the tank,” but more to use it as a supervisory layer that can learn what normal system behavior looks like over time and identify when something starts drifting before it becomes obvious to me.

You also touched on something I’ve been thinking about a lot lately: experienced reefers subconsciously monitor hundreds of little signals all the time. We notice things like:
- skimmer behavior changes
- fish acting differently
- water clarity shifts
- reactor instability
- algae growth changes

A newer reefer often doesn’t know what those subtle changes mean yet. One of my long-term goals is seeing if some of that pattern recognition can eventually be modeled and surfaced through telemetry and analysis.

Will it ever replace experience? Probably not. But if it can help catch problems earlier or help newer hobbyists understand what their systems are trying to tell them, I think that could be genuinely useful.

And honestly, I’m still learning as I go here too. Some ideas will probably work great, some will probably fail completely, but the experimentation and architecture side of the project has been a lot of fun so far.
Thanks Matt

I have believed, for a long time, that there are too many shortcomings of the existing automation platforms in our hobby. Especially so at their price points.
However, is something better than nothing? I am inclined to think so as long as it doesn't make the user less "smart" or lazy in the same way that "smart" phones and devices have seemed to impact people.

Speaking of contributing, let me know if there is any way I can help.

 

[mattgsa]

I wish I knew more about these things as I'd truly love to be able to jump in and contribute.


This sort of data could prove to be very useful and invaluable.


I have believed, for a long time, that there are too many shortcomings of the existing automation platforms in our hobby. Especially so at their price points.
However, is something better than nothing? I am inclined to think so as long as it doesn't make the user less "smart" or lazy in the same way that "smart" phones and devices have seemed to impact people.

Speaking of contributing, let me know if there is any way I can help.

If anything, I want Jarvise to help surface and explain the kinds of subtle signals experienced reefers already notice instinctively but newer hobbyists often miss entirely.

Things like:

• why skimmer behavior suddenly changed
• why reactor pressure drift matters
• why a fish acting differently might matter before parameters shift
• why long-term trends are sometimes more important than a single test result

To me, good automation should increase understanding, not replace it.

And I completely agree with you on current controller ecosystems. Most of them do some things very well, but they also tend to be closed, rigid, or heavily focused on simple threshold automation instead of understanding system behavior over time.

That’s honestly a big part of why I started moving toward industrial controls and AI-assisted telemetry instead of trying to endlessly extend traditional hobby controllers.

As far as contributing, honestly just engaging in the discussion and challenging ideas is already incredibly valuable. A lot of the best ideas in projects like this come from people asking:
“Have you considered what happens if this fails?”
or
“Would this actually provide meaningful insight?”

That kind of feedback is honestly just as important as hardware or software development.

 

[tharbin]

However, is something better than nothing? I am inclined to think so as long as it doesn't make the user less "smart" or lazy in the same way that "smart" phones and devices have seemed to impact people.

I would say yes as well, except I fear it actually really plays out that many reefers think the controller is their safety net instead of they are the controllers safety net.

There is a strong tendency, especially with newer reefers to think nothing can go wrong because they have a bazzion sensors, monitors, and testers on their tanks that take care of turning everything on and off and sending them text messages and giving them pretty graphs; all from an SBC that could croak at any moment. Almost all of the current devices fall far short of what would be acceptable in an industrial situation and a lot of tanks cost as much as a small home business.

For instance the Red Sea ReefControl Power Pro, that isn't even out yet, is the ONLY power center I know of that I would consider and until I know more I wouldn't consider it. Relying on an app or website or even a macro is just plain dangerous in an emergency situation. I want a dedicated, individual power switch for every powered outlet that is in series with the relay solution. No program no finding my phone, no wanking the power to the whole system. If my return pump starts spitting 3000 gph of saltwater at the wall outlet, I want to be able to shut it off, no laptop, no phone, no program that might decide to fart. A simple switch that overrides the controller. That's safety.

Why don't the power controllers have built-in GFCI and dedicated connections for grounding probes? Many tanks are placed in family rooms where you don't necessarily want to GFCI the whole circuit, just the tank. Why make a new user learn about power safety. Build it in. It isn't hard or expensive.

Why make everything rely on WiFi, and the internet, and a smartphone? Make it function first as a standalone isolated device and then make the connectivity a feature instead of a requirement?

 

[mattgsa]

I would say yes as well, except I fear it actually really plays out that many reefers think the controller is their safety net instead of they are the controllers safety net.

There is a strong tendency, especially with newer reefers to think nothing can go wrong because they have a bazzion sensors, monitors, and testers on their tanks that take care of turning everything on and off and sending them text messages and giving them pretty graphs; all from an SBC that could croak at any moment. Almost all of the current devices fall far short of what would be acceptable in an industrial situation and a lot of tanks cost as much as a small home business.

For instance the Red Sea ReefControl Power Pro, that isn't even out yet, is the ONLY power center I know of that I would consider and until I know more I wouldn't consider it. Relying on an app or website or even a macro is just plain dangerous in an emergency situation. I want a dedicated, individual power switch for every powered outlet that is in series with the relay solution. No program no finding my phone, no wanking the power to the whole system. If my return pump starts spitting 3000 gph of saltwater at the wall outlet, I want to be able to shut it off, no laptop, no phone, no program that might decide to fart. A simple switch that overrides the controller. That's safety.

Why don't the power controllers have built-in GFCI and dedicated connections for grounding probes? Many tanks are placed in family rooms where you don't necessarily want to GFCI the whole circuit, just the tank. Why make a new user learn about power safety. Build it in. It isn't hard or expensive.

Why make everything rely on WiFi, and the internet, and a smartphone? Make it function first as a standalone isolated device and then make the connectivity a feature instead of a requirement?

I think you nailed one of the biggest problems with modern aquarium automation: too many systems are designed around convenience first and failure tolerance second.

That’s honestly a huge part of why I started moving away from the traditional “app-connected controller” mindset and more toward industrial control concepts.

The more I looked at large reef systems, the more I realized they really should be treated more like process systems than smart home devices.

I completely agree with your point about physical overrides too. One thing I’ve been trying to keep front and center in this build is that connectivity should enhance the system, not become a hard dependency for operating it safely.

If something catastrophic happens:

• I don’t want to unlock my phone
• open an app
• hope WiFi is working
• hope the cloud service is up
• hope the controller didn’t lock up

I want deterministic local control and hard overrides that still function even if higher-level systems fail completely.

That’s also a big part of why I keep separating:

• deterministic control
  from
• supervisory intelligence

The PLC layer should still behave safely even if Jarvise disappears entirely.

Honestly, I think a lot of hobby automation today accidentally encourages people to become less observant because the system creates an illusion of safety through dashboards and alerts. In reality, most of these systems are still extremely fragile compared to what would be considered acceptable in industrial environments.

One of my long-term goals with this project is actually the opposite:
using telemetry and analysis to help reefers become MORE aware of subtle system behavior instead of less engaged with their tanks.

 

[That Crusso Kid]

I would say yes as well, except I fear it actually really plays out that many reefers think the controller is their safety net instead of they are the controllers safety net.

There is a strong tendency, especially with newer reefers to think nothing can go wrong because they have a bazzion sensors, monitors, and testers on their tanks that take care of turning everything on and off and sending them text messages and giving them pretty graphs; all from an SBC that could croak at any moment. Almost all of the current devices fall far short of what would be acceptable in an industrial situation and a lot of tanks cost as much as a small home business.

For instance the Red Sea ReefControl Power Pro, that isn't even out yet, is the ONLY power center I know of that I would consider and until I know more I wouldn't consider it. Relying on an app or website or even a macro is just plain dangerous in an emergency situation. I want a dedicated, individual power switch for every powered outlet that is in series with the relay solution. No program no finding my phone, no wanking the power to the whole system. If my return pump starts spitting 3000 gph of saltwater at the wall outlet, I want to be able to shut it off, no laptop, no phone, no program that might decide to fart. A simple switch that overrides the controller. That's safety.

Why don't the power controllers have built-in GFCI and dedicated connections for grounding probes? Many tanks are placed in family rooms where you don't necessarily want to GFCI the whole circuit, just the tank. Why make a new user learn about power safety. Build it in. It isn't hard or expensive.

Why make everything rely on WiFi, and the internet, and a smartphone? Make it function first as a standalone isolated device and then make the connectivity a feature instead of a requirement?

We are in agreement, once again, Tom.

I have long believed that each outlet on a power controller should have its own, independent GFCI. I do not know why this is not available. It is a simple and quite inexpensive solution to provide.

 

[mattgsa]

We are in agreement, once again, Tom.

I have long believed that each outlet on a power controller should have its own, independent GFCI. I do not know why this is not available. It is a simple and quite inexpensive solution to provide.

I have had very bad luck with GFCI, they seem to pop for no reason, and it always happens when I'm out of town, and I'm having to call family and friends to come reset the GFCI, and just hoping it was caught in time.

 

[tharbin]

I have had very bad luck with GFCI, they seem to pop for no reason, and it always happens when I'm out of town, and I'm having to call family and friends to come reset the GFCI, and just hoping it was caught in time.

Are you using GFCI outlets or an inline GFCI? I've been using inline GFCIs for decades and have never had a phantom pop. What I used to have was forgetting I was on a GFCI, cutting power and then when I turned it back on stood there wondering why everything was off. Finally learning about self-restting inline GFCIs fixed that.

 

[tharbin]

I think you nailed one of the biggest problems with modern aquarium automation: too many systems are designed around convenience first and failure tolerance second.

That’s honestly a huge part of why I started moving away from the traditional “app-connected controller” mindset and more toward industrial control concepts.

The more I looked at large reef systems, the more I realized they really should be treated more like process systems than smart home devices.

I completely agree with your point about physical overrides too. One thing I’ve been trying to keep front and center in this build is that connectivity should enhance the system, not become a hard dependency for operating it safely.

If something catastrophic happens:

• I don’t want to unlock my phone
• open an app
• hope WiFi is working
• hope the cloud service is up
• hope the controller didn’t lock up

I want deterministic local control and hard overrides that still function even if higher-level systems fail completely.

That’s also a big part of why I keep separating:

• deterministic control
  from
• supervisory intelligence

The PLC layer should still behave safely even if Jarvise disappears entirely.

Honestly, I think a lot of hobby automation today accidentally encourages people to become less observant because the system creates an illusion of safety through dashboards and alerts. In reality, most of these systems are still extremely fragile compared to what would be considered acceptable in industrial environments.

One of my long-term goals with this project is actually the opposite:
using telemetry and analysis to help reefers become MORE aware of subtle system behavior instead of less engaged with their tanks.

I would say we have very similar philosophies, the main difference is you're doing something about it. I'm just a harpie that complains about the current state of affairs hoping someone else will fix it.

 

[That Crusso Kid]

I would say we have very similar philosophies, the main difference is you're doing something about it. I'm just a harpie that complains about the current state of affairs hoping someone else will fix it.

I do think we both would do something more about it if we truly wanted to and had the time. I am often intimidated by how much time I think I would need to invest to get proficient with it all. Maybe I should spend less time on here and get to work learning. Then, again, I am still learning CAD design for 3D printing and that's taking forever. More lack of time thing.

 

[mattgsa]

Are you using GFCI outlets or an inline GFCI? I've been using inline GFCIs for decades and have never had a phantom pop. What I used to have was forgetting I was on a GFCI, cutting power and then when I turned it back on stood there wondering why everything was off. Finally learning about self-restting inline GFCIs fixed that.

I think it was just the wall socket. I had honestly never even heard of inline GFCIs until now. I'm just not sure I can wash the acrid taste out of my mouth from my last GFCI experience. LOL

 

[mattgsa]

NEPTUNE APEX SUCKS!!! REALLY SUCKS!!!
I seriously cannot emphasize it enough. Why I was convinced to spend this much money on this system, I honestly will never know.

I’m getting really tired of how normalized instability has become with Apex systems.

We’re not talking about a cheap gadget controlling a desk lamp. We’re talking about thousands — sometimes tens of thousands — of dollars worth of reef equipment and livestock depending on this ecosystem. Return pumps, skimmers, UV, ozone, heaters, monitoring, alarms, leak detection, all tied into one controller stack… and yet random failures, disconnects, module issues, network weirdness, and unexplained behavior are somehow treated like “just part of owning an Apex.”

That should not be acceptable at this price point.

What frustrates me most is the lack of deterministic behavior when something goes wrong. You change a router, reboot a network, lose communication for a minute, or update firmware, and suddenly you’re left wondering:

• What outlets are actually running?
• Did the EB832 lock up?
• Did the Apex brain lose communication?
• Are modules still syncing?
• Did fallback states trigger correctly?
• Is Fusion wrong or is the tank wrong?
• Do I trust the dashboard or do I physically verify everything myself?

And the answer almost always becomes:
“Go check everything manually.”

At that point, what exactly did all this expensive automation buy us?

I’m not saying Apex can’t do amazing things. It absolutely can. But there’s a huge difference between:

• advanced automation features
  and
• industrial-grade reliability.

And honestly, after tonight, I don’t think those two things are the same.

The reef hobby has reached a point where controllers are no longer just convenience devices. They’re life-support infrastructure. That means reliability, failure behavior, diagnostics, and predictability matter more than flashy features and cloud dashboards.

Because when an Apex system goes sideways, it’s not just annoying — it can put an entire ecosystem at risk.

 

[That Crusso Kid]

NEPTUNE APEX SUCKS!!! REALLY SUCKS!!!
I seriously cannot emphasize it enough. Why I was convinced to spend this much money on this system, I honestly will never know.

I’m getting really tired of how normalized instability has become with Apex systems.

We’re not talking about a cheap gadget controlling a desk lamp. We’re talking about thousands — sometimes tens of thousands — of dollars worth of reef equipment and livestock depending on this ecosystem. Return pumps, skimmers, UV, ozone, heaters, monitoring, alarms, leak detection, all tied into one controller stack… and yet random failures, disconnects, module issues, network weirdness, and unexplained behavior are somehow treated like “just part of owning an Apex.”

That should not be acceptable at this price point.

What frustrates me most is the lack of deterministic behavior when something goes wrong. You change a router, reboot a network, lose communication for a minute, or update firmware, and suddenly you’re left wondering:

• What outlets are actually running?
• Did the EB832 lock up?
• Did the Apex brain lose communication?
• Are modules still syncing?
• Did fallback states trigger correctly?
• Is Fusion wrong or is the tank wrong?
• Do I trust the dashboard or do I physically verify everything myself?

And the answer almost always becomes:
“Go check everything manually.”

At that point, what exactly did all this expensive automation buy us?

I’m not saying Apex can’t do amazing things. It absolutely can. But there’s a huge difference between:

• advanced automation features
  and
• industrial-grade reliability.

And honestly, after tonight, I don’t think those two things are the same.

The reef hobby has reached a point where controllers are no longer just convenience devices. They’re life-support infrastructure. That means reliability, failure behavior, diagnostics, and predictability matter more than flashy features and cloud dashboards.

Because when an Apex system goes sideways, it’s not just annoying — it can put an entire ecosystem at risk.

Preach it, Matt!

This was one of the two contributing factors as to why I was so stoked when you started building your own. The other reason is because I geek out about this kind of thing. One would think that with my level of enthusiasm toward PLC, and the like, that I would take the time to learn it. Although, admittedly, I had been geeking out about 3D printers since 2018 and just bought one last year.

 

[tharbin]

NEPTUNE APEX SUCKS!!! REALLY SUCKS!!!
I seriously cannot emphasize it enough. Why I was convinced to spend this much money on this system, I honestly will never know.

I’m getting really tired of how normalized instability has become with Apex systems.

We’re not talking about a cheap gadget controlling a desk lamp. We’re talking about thousands — sometimes tens of thousands — of dollars worth of reef equipment and livestock depending on this ecosystem. Return pumps, skimmers, UV, ozone, heaters, monitoring, alarms, leak detection, all tied into one controller stack… and yet random failures, disconnects, module issues, network weirdness, and unexplained behavior are somehow treated like “just part of owning an Apex.”

That should not be acceptable at this price point.

What frustrates me most is the lack of deterministic behavior when something goes wrong. You change a router, reboot a network, lose communication for a minute, or update firmware, and suddenly you’re left wondering:

• What outlets are actually running?
• Did the EB832 lock up?
• Did the Apex brain lose communication?
• Are modules still syncing?
• Did fallback states trigger correctly?
• Is Fusion wrong or is the tank wrong?
• Do I trust the dashboard or do I physically verify everything myself?

And the answer almost always becomes:
“Go check everything manually.”

At that point, what exactly did all this expensive automation buy us?

I’m not saying Apex can’t do amazing things. It absolutely can. But there’s a huge difference between:

• advanced automation features
  and
• industrial-grade reliability.

And honestly, after tonight, I don’t think those two things are the same.

The reef hobby has reached a point where controllers are no longer just convenience devices. They’re life-support infrastructure. That means reliability, failure behavior, diagnostics, and predictability matter more than flashy features and cloud dashboards.

Because when an Apex system goes sideways, it’s not just annoying — it can put an entire ecosystem at risk.

So I'm guessing you think Apex could use another bell and whistle or two?

I think that reefers are to blame in large. You never see an Instagram post talking about how the reefers heater is protected to avoid frying their fish. The posts are always about how all the pipe colors match or how they can look at the tank while sky diving in Mozambique. It seems to escape the attention of many that it isn't really about seeing your tank stats at work or turning something on or off remotely. It is really about not needing to turn something on or off remotely. Most of today's controllers are more fidget toys for reefers than serious life support systems.

 

[mattgsa]

NEPTUNE APEX SUCKS!!! REALLY SUCKS!!!
I seriously cannot emphasize it enough. Why I was convinced to spend this much money on this system, I honestly will never know.

I’m getting really tired of how normalized instability has become with Apex systems.

We’re not talking about a cheap gadget controlling a desk lamp. We’re talking about thousands — sometimes tens of thousands — of dollars worth of reef equipment and livestock depending on this ecosystem. Return pumps, skimmers, UV, ozone, heaters, monitoring, alarms, leak detection, all tied into one controller stack… and yet random failures, disconnects, module issues, network weirdness, and unexplained behavior are somehow treated like “just part of owning an Apex.”

That should not be acceptable at this price point.

What frustrates me most is the lack of deterministic behavior when something goes wrong. You change a router, reboot a network, lose communication for a minute, or update firmware, and suddenly you’re left wondering:

• What outlets are actually running?
• Did the EB832 lock up?
• Did the Apex brain lose communication?
• Are modules still syncing?
• Did fallback states trigger correctly?
• Is Fusion wrong or is the tank wrong?
• Do I trust the dashboard or do I physically verify everything myself?

And the answer almost always becomes:
“Go check everything manually.”

At that point, what exactly did all this expensive automation buy us?

I’m not saying Apex can’t do amazing things. It absolutely can. But there’s a huge difference between:

• advanced automation features
  and
• industrial-grade reliability.

And honestly, after tonight, I don’t think those two things are the same.

The reef hobby has reached a point where controllers are no longer just convenience devices. They’re life-support infrastructure. That means reliability, failure behavior, diagnostics, and predictability matter more than flashy features and cloud dashboards.

Because when an Apex system goes sideways, it’s not just annoying — it can put an entire ecosystem at risk.

So I'm guessing you think Apex could use another bell and whistle or two?

I think that reefers are to blame in large. You never see an Instagram post talking about how the reefers heater is protected to avoid frying their fish. The posts are always about how all the pipe colors match or how they can look at the tank while sky diving in Mozambique. It seems to escape the attention of many that it isn't really about seeing your tank stats at work or turning something on or off remotely. It is really about not needing to turn something on or off remotely. Most of today's controllers are more fidget toys for reefers than serious life support systems.

What I was trying to say earlier is that Apex needs a higher level of reliability and quality. It’s difficult to feel comfortable trusting a multi-thousand-dollar reef system to a controller platform that still feels like it’s running on technology equivalent to MSDOS. If I hadn’t happened to be out in the garage and noticed everything that stopped working, the outcome could have been very bad. My goal is by the end of the day have everything transferred over to PLC. The stuff that’s always on constantly isn’t my priority. It’s just stuff that has to be controlled.

 

[mattgsa]

Well… timing is everything, right?
Following up on my rant from yesterday about how unacceptable the reliability issues are with the Neptune Apex. If you saw that post, you know how frustrated I was with the constant instability and the lack of deterministic behavior when things go wrong.
Well, as if on cue, my main Apex EB832 power bar just completely died today. Every single plug just turned off. No warning, no obvious reason, just dead.
That was the last straw. I've officially started migrating my entire system over to an AutomationDirect CLICK PLUS PLC. For those unfamiliar, a PLC (Programmable Logic Controller) is the same industrial hardware used in factories, water treatment plants, and manufacturing lines — built for one thing: absolute reliability. If the network goes down, it doesn't care. It just keeps executing its logic. No cloud dependency, no communication timeouts, no wondering if the fallback state triggered correctly. It does exactly what you tell it to do, every single time.
Today, I took the first major steps in the migration. I already had my skimmer running on a CLICK relay output module, and today I wrote the ladder logic to bring my ozone generator and ozone dryer online.
I set it up using the PLC's internal real-time clock system data registers:

• Ozone runs on a timer from 10 PM to 4 AM.
• The dryer runs from 11 PM to 7 AM — starting before the ozone to ensure dry air going into the generator, and running after to purge any remaining moisture.

It's running flawlessly right now. When the Apex power bar died, my critical pumps were already moved to a plain power strip to keep the tank safe, and my skimmer, ozone, and dryer didn't skip a beat because they were already running on the PLC.
The next steps are moving the return pump and UV sterilizer over to the CLICK, and adding a 16-point 24VDC input module so I can run all my float switches and sensors through it properly. Eventually, I'll be tying the whole thing into Node-RED via Modbus TCP so I can have a proper, reliable local dashboard — one that just reads data without relying on a proprietary cloud server to make decisions about my tank.
It's a learning curve for sure — ladder logic is a whole different world if you've never done it. But knowing that my livestock are being controlled by industrial hardware instead of a finicky consumer gadget is already giving me real peace of mind.
I'll keep updating this thread as the build progresses. If anyone else has made the jump from Apex to PLC, I'd love to hear how you set up your panels!

 

[mattgsa]

Given the amount of new wires I have elected to add a new piece of equipment. I'm sure in time it will pay for itself.

 

[That Crusso Kid]

Well… timing is everything, right?
Following up on my rant from yesterday about how unacceptable the reliability issues are with the Neptune Apex. If you saw that post, you know how frustrated I was with the constant instability and the lack of deterministic behavior when things go wrong.
Well, as if on cue, my main Apex EB832 power bar just completely died today. Every single plug just turned off. No warning, no obvious reason, just dead.
That was the last straw. I've officially started migrating my entire system over to an AutomationDirect CLICK PLUS PLC. For those unfamiliar, a PLC (Programmable Logic Controller) is the same industrial hardware used in factories, water treatment plants, and manufacturing lines — built for one thing: absolute reliability. If the network goes down, it doesn't care. It just keeps executing its logic. No cloud dependency, no communication timeouts, no wondering if the fallback state triggered correctly. It does exactly what you tell it to do, every single time.
Today, I took the first major steps in the migration. I already had my skimmer running on a CLICK relay output module, and today I wrote the ladder logic to bring my ozone generator and ozone dryer online.
I set it up using the PLC's internal real-time clock system data registers:

• Ozone runs on a timer from 10 PM to 4 AM.
• The dryer runs from 11 PM to 7 AM — starting before the ozone to ensure dry air going into the generator, and running after to purge any remaining moisture.

It's running flawlessly right now. When the Apex power bar died, my critical pumps were already moved to a plain power strip to keep the tank safe, and my skimmer, ozone, and dryer didn't skip a beat because they were already running on the PLC.
The next steps are moving the return pump and UV sterilizer over to the CLICK, and adding a 16-point 24VDC input module so I can run all my float switches and sensors through it properly. Eventually, I'll be tying the whole thing into Node-RED via Modbus TCP so I can have a proper, reliable local dashboard — one that just reads data without relying on a proprietary cloud server to make decisions about my tank.
It's a learning curve for sure — ladder logic is a whole different world if you've never done it. But knowing that my livestock are being controlled by industrial hardware instead of a finicky consumer gadget is already giving me real peace of mind.
I'll keep updating this thread as the build progresses. If anyone else has made the jump from Apex to PLC, I'd love to hear how you set up your panels!

I don't think the timing of the EB832 could have been more perfect.

That seems like a pretty fancy labeler. Although, it's been many years since I last bought one.

If you wouldn't mind, if you haven't already, could you keep a running total on the cost of going full-PLC?