Must-haves for EASY DIY controller?

Hi terahz

I have been reading this thread for some time and have learnt a lot - I am building a controller based on a Mega which, hopefully, will do most of the things that you guys are integrating.

From a previous post I note that you are using two Futerlec relay boards - I have bought the 8 channel SSR board - https://www.futurlec.com/SSRAC.shtml.

terahz said:
Relays don't take pins. They are on the I2C bus.
Click to expand...
In previous posts you mentioned the I2C bus but IIRC you also had a photo showing 10 wires going to the relay board. Can you please explain how you are using the bus to control the relays? Is it that the port expander is on the bus but then have the 10 wires going to the relay boards?

The documentation which comes with these boards is a bit deficient although it does make mention of the 10 pin I2C connection.

From what I can see, you are not actually using the Hydra-THz sketch to control the relays at this stage??

Any assistance will be greatly appreciated.

Cheers
 
The board accepts a 5v signal to activate the relays just like a standard transistor. He has ports 0-7 connected to each relay input on the relay board. By sending the proper bit code to the port expander it causes the port to go high activating the relay.
 
MagicJ said:
I have bought the 8 channel SSR board - https://www.futurlec.com/SSRAC.shtml.
Click to expand...
Welcome to RC MagicJ...

That's a nice board! it doesn't require additional 12V PSU and is all solid state! But it is more expensive.

MagicJ said:
In previous posts you mentioned the I2C bus but IIRC you also had a photo showing 10 wires going to the relay board. Can you please explain how you are using the bus to control the relays? Is it that the port expander is on the bus but then have the 10 wires going to the relay boards?
Click to expand...
That's exactly how it happens. The MCP port expander is on the I2C bus and, as DustinB said, the main AVR just sends bit to the port expander which in turn sends 5V to the relays to turn them on or off.

MagicJ said:
The documentation which comes with these boards is a bit deficient although it does make mention of the 10 pin I2C connection.
Click to expand...

For the board you have it is basically the same as the ones I have, just without the extra 12V power that I need to power the relays. The SSRs you have are powered directly from the 5V signal, so no need for additional power.

The 10 pin connector is probably 8 relay connections, 5V and GND. That's not really I2C.

MagicJ said:
From what I can see, you are not actually using the Hydra-THz sketch to control the relays at this stage??
Click to expand...
There is some very basic code that can turn relays on and off, and that's pretty much it. However I don't use them at the moment.
 
terahz said:
There is some very basic code that can turn relays on and off, and that's pretty much it. However I don't use them at the moment.
Click to expand...

MajicJ: I am expanding the relay code, if you need some examples let me know.

On a side note. I finally got my modified sketch loaded and everything is functioning. I just need to calibrate the pH probe and add temperature functionality. Did you experience erratic button behavior with the remote TeraHz? Like having to hit the button several times?
 
DustinB said:
Did you experience erratic button behavior with the remote TeraHz? Like having to hit the button several times?
Click to expand...

Only when I enable debugging (serial prints etc.) my IR becomes slow, but in regular mode, I rarely have to press twice. You might want to press and hold for 1/2sec instead of quickly pressing and releasing, but overall I've had no problems with the remote.
 
I'll check out and see if anything is running. I did have a bit of trouble with nothing wanting to display after the startup screen, but that apparently was from the time not being set.

BTW, I double checked again tonight and verified the original ENC chip was indeed fried.

Here's a couple pics of what I got so far on my setup:


 
Thanks DustinB and terahz - you have confirmed my understanding of how the relays work.

terahz - I have been lurking around this forum for over 10 years but never had the need to post. I heard about the Arduino a few months ago and now I spend all my spare time working on it!!

One thing with this relay board - 0v is on and 5v is off, so I have had to change a fair bit of my sketch to reflect this scenario.

I know that there has not been much work done on the sketch at this stage, but I have set up a few macros which I find useful e.g. press the 'Water change' button and the skimmer pump, return pump and wavemaker pumps turn off and the sump light turns on - you might want to consider something like this??

Anyway, back to the main project - keep up the good work.

Cheers
 
There has actually been quite a bit done to the sketch. I implemented a cleaning and feeding mode.

I don't know how we are planning to handle a "standard" sketch for the project, but that's the good thing. Anyone willing to learn a bit should be able to add just about anything they want.
 
Dustin or terahz, do you guys want full access to the svn repo on the site so you can post your code there?

I'm really floundering to come up with a solid plan for a "baseline" sketch, and software development (at this level at least) isn't my strong suit. Any thoughts welcome.

That said, I feel like the base sketch should accomplish the following:

1) Direct support for the basic onboard hardware, i.e. it should talk I2C to the RTC and LCD, include a function to read pH, and so on - right out of the box. People shouldn't have to worry about that. Functions to do these things should be abstracted, so the user doesn't have to even know that the LCD is controlled via an MCP23008 on I2C - they should be able to call a function that prints to the LCD.
2) A framework to build functionality for other hardware - the second AVR, Ethernet, external MCP23008 to control relays, and so on. In other words, it may not include a web server out of the box, but we provide the libraries/examples to implement one.

I feel like terahz's sketch is pretty close to these high level goals already. Any thoughts? Once we have concrete high level goals, we can divide and conquer to fill in any gaps.
 
If you want, maybe an examples folder with folders of our names inside. I would think this would just be for reference though. Might be a good idea in the end to have our sketches there for those who might need examples to expand later. I do plan to comment my code heavily.

I agree, at least everything onboard should be functional in the sketch. Actually, with the second AVR running the ethernet now we could even have a sketch to collect onboard data and display it.

I was working on specific code to control my relay functions and timers, but TeraHz was actually talking about building a customizable task scheduler of sorts. Might be kinda tricky for us all to work on a base sketch with our current code so different. Maybe one person could take all the code in the end and simplify it?

I figure support out of the box for pH, Clock, Temp, Ethernet, Relay Control would be good. We can always post examples on the google site for how to interface with relays, build temp sensor, etc... I built my relay control board a couple days ago, you can see it in the pics. I was thinking about making a board in eagle at least to explain the layout, so that would be just one example of how to do it.

No matter what we do, in the end we are going to need a good number of examples and a decent guide online or we will be getting tons of questions. Well, the questions will come anyway I'm sure. I was also thinking about the boards. I don't know if someone wants to "stock" some of them where a user could buy one. Don't know how cheap or easy the average user could have these boards made or how much real interest there will be in the end.
 
Before we post code on the official site we MUST have some guidelines, otherwise we'll get in trouble with me posting my IR code, and someone else overwriting it with their keyboard code, then Dustin adding his MH code and me overwriting it with my LED code...

I suppose, the best way would be to put all separate functionality in ifdefs and have a bunch of defines on top that enable/disable parts of the code. That will make the code pretty modular, but also pretty big and confusing.

The other way would be to try and maintain a few major "branches" that would have the same main code, but different 'AUX' code (lights, handling of ATO, water changes, etc).

There are other ways as well, but we need to decide before we try and put all the code together in one place.

For me, the core code would include support for the hardware that has a silkscreen on the PCB and nothing else (that means lights are not part of the core code).
 
Another option would be to have a display, light, temp, ph, ATO, etc. modules. We would have to define an core set of function for each one. Then the user could look at the example and pick the best one and modify it. This might make is timpler since each person could add the module they need as the understand them.
 
terahz said:
I suppose, the best way would be to put all separate functionality in ifdefs and have a bunch of defines on top that enable/disable parts of the code. That will make the code pretty modular, but also pretty big and confusing.

The other way would be to try and maintain a few major "branches" that would have the same main code, but different 'AUX' code (lights, handling of ATO, water changes, etc).

There are other ways as well, but we need to decide before we try and put all the code together in one place.

For me, the core code would include support for the hardware that has a silkscreen on the PCB and nothing else (that means lights are not part of the core code).
Click to expand...

It strikes me that the "ifdefs" approach would probably be more seamless to a newcomer - they only have to load/keep track of a single sketch, and they can change a few obvious variables to activate or remove functionality. If we tried to branch it, how would someone easily combine different chunks of aux code to get what they wanted? I don't want to rely on people cutting/pasting into a single sketch, and even if we split aux code out into libraries they'd still have to do some coding in their sketch to use it all.

I like your concept of the core code, but we'd need to be more explicit in the definition. For instance, would the core code include some sort of event scheduler? There's no explicit hardware on the board for that but it seems like an obvious core component to me.

I think we clearly have to come to some sort of high level agreement on exactly what we're delivering, too. Are we building a "Hydra IDE?" Or, are we delivering (a) sketch(es) that will literally be plug-and-play assuming you want some basic set of functionality? Or somewhere in the middle?
 
I don't really think there's a lot to the average functionality.

pH, Temp, Relay Control, Ethernet

pH & Temp as standard functions. If TeraHz does his task scheduler that would really handle most everything as far as light timers, dosing timers, etc... Then the ethernet as a separate sketch to either load or not load to the second AVR.

It would be pretty simple to have a base sketch for all this. Anything further than that will likely be LED control or something custom like a feeding or cleaning mode. It might just be simpler to have a couple different sketches with or without features.

Really, anything beyond the base sketch we are looking at is beyond the scope of the project. I think at least part of this should really be DIY. Not just assemble our kit with our code for everything you can imagine. That could end up being a lot of work and I imagine we may end up hitting either flash or ram limits with a large amount of customizable features. TeraHz's sketch is already what 22k? That's without a lot of things. My stripped down sketch with a few small things added is at 19k, and I still have a ways to go.

IMHO I would shoot for a base sketch with maybe a few extra features, but add examples to the site as users implement their own things to keep in the spirit of DIY. There's several of us here to answer questions from time to time and I doubt we will see tons of people building this, just imagine what this looks like to someone to has never touched a soldering iron.

EDIT: We might also consider if a keypad/remote is going to be a standard feature or not. I imagine almost everyone is going to want the ability to edit settings.
 
Last edited:
Not familiar with the Arduino build environment, but I pictured a module for everything and a dummy module if not implemented. So you drop the appropriate C file into the build location and compile.

I think a scheduler should probably be standard.
 
I'm using an IR remote for everything like TeraHz. Were you thinking of a keypad or directional buttons or something? Digi-key has some nice ones you can slide a printed card into.
 
yeah keypad , they are cheap , im looking for some company that can do custom prints. it shouldnt be too expensive. if not a simple 4x4 would do, id just print and laminate some codes for feeding or auto etc..
 
that seems a bit expensive for something that simple. The 16 button ones on ebay go for 6 dollars shipped. the same ones reefprojects.com is using
 
You must log in or register to reply here.

Similar threads

A
Aquarium Temperature Control: How I Hacked My Air Conditioner to control my tanks temperatures
Replies
6
Views
325
Naso180
N
R
DIY AI-coded ESP32 based aquarium controller
Replies
0
Views
674
ronnyking
R
E
Neptune DDR diy question for AWC
Replies
3
Views
356
Reefing102
Reefing102
J
Heater controller
2
Replies
23
Views
1K
Dustin07
D
B
Question on Mean Well 3-1 dimming
Replies
15
Views
567
bmichaelb
B
Back
Top