Redundancy Heater Programming

[Jason Roth]

So I am trying to get my EL up and going. I have the probes installed and working. I want to get the heaters going now. I have my primary heater controlled with the inkbird plugged into the apex. And coded so that outlet shuts off if inkbird fails and heater fails high. See attached pictures. I have finnex titanium heaters with no internal stat. I’d like to setup the second heater as my backup but not sure on the proper coding when using the apex temp probe or if it’s possible.

So if I understand the primary coding. If communication is lost between brain and eb832 then the inkbird will have power with Fallback ON.

So I assume inkbird is on until temp is over 81*. Then apex shuts power off to that outlet thinking heater failed to on position and inkbird can’t shut it off. What happens when temps falls below 81? Does the outlet come back on? I assume no because I didn’t code it to, right?

I’m not sure how to program the secondary outlet. Picture is inkbird programming and backup programming. But how does backup know to come on when inkbird power is shut off to outlet? Do I need to buy a second inkbird for the backup or can it be coded? I would think as of now both heaters would be on with programming in attached pics. Do I need to include SET ON for the backup?

 

[rkpetersen]

I'm not familiar with the Inkbird, other than the name. With internal thermostat heaters, I set them so that they're just slightly higher than where I want the temp, and then use the Apex for primary control. That way, a stuck heater thermostat or Apex failure doesn't spell disaster. I don't know if you can do this with an inkbird though; it would require turning the inkbird on and off frequently, and I don't know if it's designed to handle that.

So if I understand the primary coding. If communication is lost between brain and eb832 then the inkbird will have power with Fallback ON.

That's correct.

So I assume inkbird is on until temp is over 81*. Then apex shuts power off to that outlet thinking heater failed to on position and inkbird can’t shut it off. What happens when temps falls below 81? Does the outlet come back on? I assume no because I didn’t code it to, right?

The way it's programmed there, the outlet does come back on when the temperature falls back down to 81 degrees, because of the Set statement.
Each Apex code stack is processed from the top to bottom (except for statements like Defer, which apply to the entire stack no matter where they're placed) every second or so.
If you want it to stay off after it's gone too high, either indefinitely or for a certain period of time, you can do that. What kind of behavior do you want to see?

I’m not sure how to program the secondary outlet. Picture is inkbird programming and backup programming. But how does backup know to come on when inkbird power is shut off to outlet? Do I need to buy a second inkbird for the backup or can it be coded? I would think as of now both heaters would be on with programming in attached pics. Do I need to include SET ON for the backup?

Programming an outlet to act based on the state of another outlet is straightforward. Just add the line
If Output [PrimaryHeaterName] = [ON/OFF] Then [ON/OFF]
to the code of the dependent device.

So, for example, you could have your backup heater be something like:

Fallback OFF
If Temp < 78.0 Then ON
If Temp > 79.0 Then OFF
If Output Heater1 = ON Then OFF


You should also consider what happens if the temperature probe fails. It's rare but does occur, and when it happens, the reading it gives is impossibly low. Which would turn the heater on and keep it on.
To avoid this, you can add the line
If Temp < 70.1 Then OFF
to each heater's code to disable it when the temp reading is obviously in error. (Also set temp alerts to tell you about this if it happens.)

Also I suggest enabling Logging for everything, by clicking on that checkbox in each output. You never know when you'll want to look back and see what happened.

It's also a good idea to add a small bit of hysteresis with the Defer statement to the code of each heater that is controlled directly by the Apex. Something like
Defer 001:00 Then ON
This keeps the heater from turning on for one minute after the outlet would otherwise turn on, and keeps the heater from rapidly cycling on and off if the temp is near a set point.

 

[Jason Roth]

I'm not familiar with the Inkbird, other than the name. With internal thermostat heaters, I set them so that they're just slightly higher than where I want the temp, and then use the Apex for primary control. That way, a stuck heater thermostat or Apex failure doesn't spell disaster. I don't know if you can do this with an inkbird though; it would require turning the inkbird on and off frequently, and I don't know if it's designed to handle that.

The way it's programmed there, the outlet does come back on when the temperature falls back down to 81 degrees, because of the Set statement.
Each Apex code stack is processed from the top to bottom (except for statements like Defer, which apply to the entire stack no matter where they're placed) every second or so.
If you want it to stay off after it's gone too high, either indefinitely or for a certain period of time, you can do that. What kind of behavior do you want to see?

Programming an outlet to act based on the state of another outlet is straightforward. Just add the line
If Output [PrimaryHeaterName] = [ON/OFF] Then [ON/OFF]
to the code of the dependent device.

So, for example, you could have your backup heater be something like:

Fallback OFF
If Temp < 78.0 Then ON
If Temp > 79.0 Then OFF
If Output Heater1 = ON Then OFF

You should also consider what happens if the temperature probe fails. It's rare but does occur, and when it happens, the reading it gives is impossibly low. Which would turn the heater on and keep it on.
To avoid this, you can add the line
If Temp < 70.1 Then OFF
to each heater's code to disable it when the temp reading is obviously in error. (Also set temp alerts to tell you about this if it happens.)

Also I suggest enabling Logging for everything, by clicking on that checkbox in each output. You never know when you'll want to look back and see what happened.

It's also a good idea to add a small bit of hysteresis with the Defer statement to the code of each heater that is controlled directly by the Apex. Something like
Defer 001:00 Then ON
This keeps the heater from turning on for one minute after the outlet would otherwise turn on, and keeps the heater from rapidly cycling on and off if the temp is near a set point.

I really appreciate the help. This is all new and im trying to do it right from the start. Tank is just now cycling and I have a lot of equipment to setup and program. Still need to setup the Icecap gyre, Tunze, ATO, lights, skimmer, return pump(I assume should just be on all the time) and I think I have a couple other things. My other powerheads are the sicce with the wavesurfer and is just on a power strip right now which I should probably put on the apex to control if power goes out. I will be getting a battery backup.

I tried figuring out how to quote reply like you did to sections but couldn't figure it out on here.

What is interesting is you mention it reads the code from top to bottom. A local guy said last night it reads it from bottom up?

So the inkbird is a heater/cooler controller and has its own thermostat you can calibrate. Another person I was talking to didn't want to rely on the apex relays to be switching so much. So I decided to kinda follow that but wanted to have the apex control the backup heater. So the inkbird will turn the heater on and off based on my high and low set points.

I am replying from my laptop. I will post again with a couple other screenshots from changes based on your recommendations.

So what I want and let me know if I am thinking about this wrong, but I want to inkbird as my primary controller which is plugged into my apex. It will control the heater and the apex will just control that outlet if the temp gets too high. So if it fails high I want to shut it down and then have the backup heater plugged into the apex to take over until I correct the issue with the primary. So the backup takes over and then maintains a temp around 78 degrees.

In regards to alarms, I am not sure what is correct here. I found two places that mention alarms. I will post screen shots of them as well. One is under the outlets actually. And the other is under inputs.

 

[Jason Roth]

Here is the inkbird and backup programming. And now I think I see the difference. Under the outlets that’s an actual alert that I get a text and email right? Or is that elsewhere?

The one under the inputs for the probe that’s an alarm on the unit I would hear. But it’s in my basement so doubt I hear it on first or second floor.

 

[homer1475]

You have it setup right and your understanding it correctly.

Only thing I would do different is delete the defer command. Your having the inkbird control the heater, the apex is just a fallback, if I understand you correctly?

Or is it 2 inkbirds for 2 heaters, or is it 1 inkbird for one heater, and backup heater is completely controlled by the apex? If the latter, I would leave the defer.

And yes base alarm is an alarm on the display(I'm not sure if the new apex has the alarm from the base, but the "old" apex has the alarm from the display), and the other is an email and/or txt message.

 

[Jason Roth]

You have it setup right and your understanding it correctly.

Only thing I would do different is delete the defer command. Your having the inkbird control the heater, the apex is just a fallback, if I understand you correctly?

Or is it 2 inkbirds for 2 heaters, or is it 1 inkbird for one heater, and backup heater is completely controlled by the apex? If the latter, I would leave the defer.

And yes base alarm is an alarm on the display(I'm not sure if the new apex has the alarm from the base, but the "old" apex has the alarm from the display), and the other is an email and/or txt message.

Thank you. And yes, inkbird controls primary heater. Only one inkbird. Apex controls inkbird outlet to shut off at high temp and then apex controls backup heater if it has to shut off inkbird outlet cause of its failure. So would you leave the defer command? Sounds like I should leave it based on petersen‘s reply. I didn’t add it to the inkbird because apex isn’t controlling that heater.

It is alarm for base. I don’t have a display yet.

 

[homer1475]

Yes, in that case leave the defer.

EDIT:
Put the if INKBIRD statement at the top, right below the fallback statement. That way it evaluates it first, and will leave rhe outlet off if that situation isn't met. And add a set off statement.

fallback off
set off
if inkbird = off then on


like above, then your temp statements.

 

[homer1475]

Edit above

 

[Jason Roth]

Yes, in that case leave the defer.

What do you and @rkpetersen recommend for return pump code? I only have one return pump and I do have leak detection. All I can think of is having it on all the time and then code something in regards to if leak detection is activated then shut the pump off.

For feeding right now I’ll msnuslly turn switch off on the dashboard.

 

[homer1475]

What do you and @rkpetersen recommend for return pump code? I only have one return pump and I do have leak detection. All I can think of is having it on all the time and then code something in regards to if leak detection is activated then shut the pump off.

For feeding right now I’ll msnuslly turn switch off on the dashboard.

Thats all I do with the exception I have a DC pump and turn the flow down during some feed modes, and off during a maintenance mode(feedD)

 

[rkpetersen]

What is interesting is you mention it reads the code from top to bottom. A local guy said last night it reads it from bottom up?

No, top to bottom. (Be careful who you listen to!) As I mentioned, except for commands like Defer and Min Time that apply to the entire stack no matter where they're placed.

So the inkbird is a heater/cooler controller and has its own thermostat you can calibrate. Another person I was talking to didn't want to rely on the apex relays to be switching so much. So I decided to kinda follow that but wanted to have the apex control the backup heater. So the inkbird will turn the heater on and off based on my high and low set points.

I run fairly complex heater programming that I came up with, that keeps extremely tight temp control of less than 0.5 degrees F variance per day, using two heaters to split the work and assist each other. To do this, the apex outlet relays switch on and off frequently. This works well with EJ heaters as I use. The mechanical relays on the Apex EB832 are rated for about a million activations. Of course nothing is guaranteed, but even turning them on and off 100 times a day that would give you around 27 years. But your logic of letting the inkbird do the work is also sound, if it's up to the task.

So what I want and let me know if I am thinking about this wrong, but I want to inkbird as my primary controller which is plugged into my apex. It will control the heater and the apex will just control that outlet if the temp gets too high. So if it fails high I want to shut it down and then have the backup heater plugged into the apex to take over until I correct the issue with the primary. So the backup takes over and then maintains a temp around 78 degrees.

That is what I thought you were aiming for. What I suggested should do that for you. Looking at your screenshots, the backup heater code is fine. The Inkbird heater code would also work, although I'm uncertain what state it would come back in if there were a system reboot or some other anomalous event. Because heater function is so critical, I'd probably do it a bit differently, using a set command to keep the inkbird on, and turning it off with a virtual outlet (VO), like this:

[Inkbird]
Fallback ON
Set ON
If Output TooHot = ON Then OFF

[Too Hot]
If Temp > 81.0 Then ON
Defer 000:10 Then ON

Because the TooHot VO has no OFF statement, anytime it comes on, it will stay on until it is manually turned to off, then back to auto. Again, a Defer is added to make sure that the temp increase is legit before the control is activated.

In regards to alarms, I am not sure what is correct here. I found two places that mention alarms. I will post screen shots of them as well. One is under the outlets actually. And the other is under inputs.

It's confusing because both locations can be used to set alarms and they will both function, although the ones that are least 'abnormal' will activate first. I prefer the direct naming of alarm conditions in the base email output and turning off the alarms under Inputs, to avoid confusion and because I like seeing a summary of all my alarm conditions in one place. Except for the power alarms, those are all still on the Inputs page as I haven't gotten around to switching those over (and may not bother at this point.)

What do you and @rkpetersen recommend for return pump code? I only have one return pump and I do have leak detection. All I can think of is having it on all the time and then code something in regards to if leak detection is activated then shut the pump off.

That's all I do for the return pump AC outlet:

Fallback ON
Set ON
If Output LeakDetected = ON Then OFF

The VO LeakDetected gathers all my leak sensors into one latching output with a Defer, similar to what I recommended for TooHot above.

If you have as variable voltage DC return pump, there are other tricks you can play with return pump output, but they aren't supported by EL without adding a VDM module.

 

[Jason Roth]

Thats all I do with the exception I have a DC pump and turn the flow down during some feed modes, and off during a maintenance mode(feedD)

Well the outlet doesn’t allow you to do custom code for the return pump for AC voltage I guess. I’m running a sicce 3.0. So basically it’s on and looks like only option is to setup feed modes A-D.

 

[rkpetersen]

Yes, in that case leave the defer.

EDIT:
Put the if INKBIRD statement at the top, right below the fallback statement. That way it evaluates it first, and will leave rhe outlet off if that situation isn't met. And add a set off statement.

fallback off
set off
if inkbird = off then on


like above, then your temp statements.

No, this would be not good. Think through the sequence of events. Your inkbird/heater fails and shuts off. Now the backup heater turns on. And then stays on until you notice the problem.

 

[Jason Roth]

No, top to bottom. (Be careful who you listen to!) As I mentioned, except for commands like Defer and Min Time that apply to the entire stack no matter where they're placed.

That is what I thought you were aiming for. What I suggested should do that for you. Looking at your screenshots, the backup heater code is fine. The Inkbird heater code would also work, although I'm uncertain what state it would come back in if there were a system reboot or some other anomalous event. Because heater function is so critical, I'd probably do it a bit differently, using a set command to keep the inkbird on, and turning it off with a virtual outlet (VO), like this:

[Inkbird]
Fallback ON
Set ON
If Output TooHot = ON Then OFF

[Too Hot]
If Temp > 81.0 Then ON
Defer 000:10 Then ON

Because the TooHot VO has no OFF statement, anytime it comes on, it will stay on until it is manually turned to off, then back to auto. Again, a Defer is added to make sure that the temp increase is legit before the control is activated.

That's all I do for the return pump AC outlet:

Fallback ON
Set ON
If Output LeakDetected = ON Then OFF

The VO LeakDetected gathers all my leak sensors into one latching output with a Defer, similar to what I recommended for TooHot above

Ok so either I misunderstood or he didn’t explain it fully but I asked. His response was “It reads the code top to bottom, but whatever is the last true statement on the list always takes over.“ So sounds like it’s what you are saying.

With the VO, I assume that code is all in same location under the inkbird outlet and I do not include the brackets or text in brackets. You were just showing the differences and what they reference?

And I have the Apex EL. And it does not show where I can go advanced and provide code. Do I need to set up a new outlet or select something else to allow that?

 

[Jason Roth]

@rkpetersen is there somewhere online that I could read up on all the different code options and what they mean/do? Instead of noobs constantly asking questions I’d like to learn a bit so when I ask questions I have some base knowledge. I took FORTRAN D back in college which probably ages me. Lol. And I hated it. What kind of code is this? I should just google if/then statement code.

 

[rkpetersen]

Ok so either I misunderstood or he didn’t explain it fully but I asked. His response was “It reads the code top to bottom, but whatever is the last true statement on the list always takes over.“ So sounds like it’s what you are saying.

Yes, that's right. Exactly. It's just a stack of logic, and whatever is true at the bottom, wins. Incidentally, the Apex doesn't 'do math' at all.

With the VO, I assume that code is all in same location under the inkbird outlet and I do not include the brackets or text in brackets. You were just showing the differences and what they reference?

No, you need to create a new output, a virtual output, not directly tied to any physical outlet. It's just a logic device. Go to the Outputs page, and at the upper right, select the Gear and Add a Virtual Output. The bracketed stuff is the name of the Output, by convention.

And I have the Apex EL. And it does not show where I can go advanced and provide code. Do I need to set up a new outlet or select something else to allow that?

After you've used the Wizard, now pull down the Control Type menu and select Advanced. All your preexisting code will be there, and you can now add more.
If you wind up doing a lot of Apex coding, you may wind up going straight to Advanced for many devices.

Let me look up the manual. I'll post again shortly.

 

[rkpetersen]

It's very out of date as far as hardware and there have been major software and programming improvements, but this manual is a good place to start, esp Chapter 4 onward:

https://www.neptunesystems.com/downloads/docs/Comprehensive_Reference_Manual.pdf

To get the latest programming info (last few years worth, lol), I'd go to the Neptune Systems forum and go through the various sticky threads under Apex Programming.

 

[rkpetersen]

oops double post!;Cyclops

 

[Jason Roth]

No, you need to create a new output, a virtual output, not directly tied to any physical outlet. It's just a logic device. Go to the Outputs page, and at the upper right, select the Gear and Add a Virtual Output. The bracketed stuff is the name of the Output, by convention.

Right, but the brackets and name don't need to be there do they? Just everything underneath

 

[rkpetersen]

Right, but the brackets and name don't need to be there do they? Just everything underneath

Right, that term isn't included in the actual code, and you can make the name whatever you want (within certain limits.)