Raspberry Pi based controller using node-RED

[Daniel W]

Hello all,

if you are interested in a Kickstarter / Open Source projects as I describe it here please feel free to comment.

I just finished my a prototype of my aquarium controler (V2.0) and I would like to share that here.

In the past i made the experience that commercially available controllers are often very unflexible and you end up with different system that are not synchronised. Therefore I already developed 4 years ago my first raspberry pi based controler. Now I reworked it and made it much more robust.

It contains:
8 switchable sockets
5 dosing pumps
5 digital Inputs (I use them for several floating swichted and an ultrasonic level measurement)
5 digital logical outputs (I used them to control my LED lights via PWM)
2 12V, 1A Power Outputs (for pumps)
1-wire bus (for serval temperature sensors)

I was careful to design a robust mechanics. With my first versions I always had problems with cabeling and fixing the cables.

The main feature is that the whole control software is based on node-RED running on a Raspberry Pi. This is very flexible and very easy to use. Flexibility is very important because all like to have some unique DIY stuff in the tank. For visualization I use a webAPP. This can be put in the Raspberry, but I run it as a cloud service (IBM bluemix) and I use it everywhere in the world via a phone or tablet.

To me this concept is more modern and more flexible than other DIY platforms for aquarium controllers.

I am evaluating to do a Kickstarter project. The hardware needs some inests to produce it for someone else. The software on node-RED I would publish then as open source so that the community can work on it.

Let me know your thoughts.

Daniel

 

[Chriss614]

Looks like a cool project, I have a question about the software that runs everything. Is the software that runs everything actually on the Pi or is it cloud based? I ask because I prefer to have my software run on the computer and have the visualization portion in the cloud because in the case of wifi failure the controller wouldn't fail.

Sent from my ONEPLUS A3000 using Tapatalk

 

[Daniel W]

Hello Chriss,

I agree, the system should be running completely autonomous on the Pi.

The control software always runs locally. I put the visualization and manual setup over cloud (e.g. switch off pump for water exchange or calculate new dosing volumes after a chemical test, reboot) on the cloud to have always remote access even when I travel.

There is no problem in deploying in locally neither. I am wrapping it in a docker container.

Daniel

 

[Chriss614]

Hello Chriss,

I agree, the system should be running completely autonomous on the Pi.

The control software always runs locally. I put the visualization and manual setup over cloud (e.g. switch off pump for water exchange or calculate new dosing volumes after a chemical test, reboot) on the cloud to have always remote access even when I travel.

There is no problem in deploying in locally neither. I am wrapping it in a docker container.

Daniel

Sounds cool. Following along.

Sent from my ONEPLUS A3000 using Tapatalk

 

[Gorgok]

After two DIY controllers, i have to say spread it out as much as possible is the way to go.

Putting all that stuff in one box, while doable, is annoying as hell. If you ever want/have to work on something, everything is down.

Instead, make a box for dosers, even if its just fed direct power from relays (from the actual controller box) and has no brains in it. Make a box for outlets, maybe just locate a relay module in its box, and signal wires coming from the controller. Sensors can go to the controller box...

I was thinking of going i2c for all the boxes at some point, though then i would have to think about the signal length or some such (plus my current solution isn't broken yet). All wifi, or bluetooth, would be fun too now with really cheap wireless built-in micros, but i don't know how that would work in practice (code wise). Master (pi) sending some sort run now command and the slave just acknowledge?

 

[Daniel W]

Thanks Gorgok,

i agree with you that you have to be careful about how to maintain the controler. My new device has now a professionally soldered SMD PCBA. So no problems with redoing anything there.

I appreciate your idea about decentralization. I am professionally working with IoT solutions and we proclaim a lot of decentralized architectures to gain flexibility. So naturally I thought on it as wenn when I designed this aquarium controler. I result of that is the split between cloud computing and a local computer as well as a software achitecture that separates all the functions so that you can change only one function without shutting everything down. Nevertheless, breaking it down in too many small packages ends up in tremendous development and integration work, up to stability of communication protocols etc. In theory you might do that with Bluetooth but a lot of work.

Daniel

 

[jrhupp]

After two DIY controllers, i have to say spread it out as much as possible is the way to go.

Putting all that stuff in one box, while doable, is annoying as hell. If you ever want/have to work on something, everything is down.

Instead, make a box for dosers, even if its just fed direct power from relays (from the actual controller box) and has no brains in it. Make a box for outlets, maybe just locate a relay module in its box, and signal wires coming from the controller. Sensors can go to the controller box...

I was thinking of going i2c for all the boxes at some point, though then i would have to think about the signal length or some such (plus my current solution isn't broken yet). All wifi, or bluetooth, would be fun too now with really cheap wireless built-in micros, but i don't know how that would work in practice (code wise). Master (pi) sending some sort run now command and the slave just acknowledge?

I will second these sentiments. Dividing the hardware functions into separate devices is a very good design strategy for our type of applications.

 

[karimwassef]

The best systems are modular and redundant.

 

[fsamir]

Hi there,
I've been working on a similar project for a while, it is called DOSEmate.
It isn't open source, it may become one day...

It is a Custom PCB, that controls a bunch of devices, including 4 dosing pumps. It does have an easy to use management UI, but everything can be reprogrammed using node-red.

All the best with the kickstarter campaign.

Sent from my iPhone using Tapatalk

 

[fsamir]

You can check it out http://www.inventmarine.com


Sent from my iPhone using Tapatalk

 

[Daniel W]

You can check it out http://www.inventmarine.com

Hello fsamir,

looks really cool. Do you actually sell it or are you before that stage?

Daniel

 

[karimwassef]

Nice

 

[mprygh]

I poked around with a DIY Raspberry PI controller for a while.
I had issues:
1) Some GPIO toggle annoyingly during boot.
2) My router was slow to boot, so on a power failure I had issues getting the PI to reconnect properly.
3) Delays when my internet is down.
Not a hang, but delays during timeouts. Can cause issues with dosers if it happens
at just the wrong time.

Not easy to fix without fancy multi-threading, which then leads to all sorts of
other fun problems.
Similar issues with Particle Photon.

Went back to Arduino, then eventually tired of it and bought an Apex.

 

[Gorgok]

I assume you could fix 2 with using some of the network tools in linux, like wicd. I run that on my BBB.

Not sure what you mean by fancy multi-threading. My controller is just running specific programs at set times to do one task and then stop. It may be running many things at whatever time, but each thing is its own thing... One program to record temps. One to run dosers. One to set light dimming. Etc. Any one of those doing something stupid because of pebkac will not affect the others unless i create such a mess that the processor locks up. I don't know if thats fancy or multi-threading, but it seems to work just fine (considering most programs run in under 1/4 second or whatever...).

I am natively compiling them from c++ though, and using cron to run them at set times.

 

[mprygh]

I assume you could fix 2 with using some of the network tools in linux, like wicd. I run that on my BBB.

Not sure what you mean by fancy multi-threading. My controller is just running specific programs at set times to do one task and then stop. It may be running many things at whatever time, but each thing is its own thing... One program to record temps. One to run dosers. One to set light dimming. Etc. Any one of those doing something stupid because of pebkac will not affect the others unless i create such a mess that the processor locks up. I don't know if thats fancy or multi-threading, but it seems to work just fine (considering most programs run in under 1/4 second or whatever...).

I am natively compiling them from c++ though, and using cron to run them at set times.

The "fancy" comes in when you share the same hardware.
In my case, the I2C port for both doser relays and water level inputs.
It would not work easily with multiple threads.

My main plan was to have two threads, one for all real control, and one for
internet connectivity.
Even the IO toggle on boot was supposedly fixable.
But when a hobby becomes too much like work....

 

[TokiHacker]

I poked around with a DIY Raspberry PI controller for a while.
I had issues:
1) Some GPIO toggle annoyingly during boot.
2) My router was slow to boot, so on a power failure I had issues getting the PI to reconnect properly.
3) Delays when my internet is down.
Not a hang, but delays during timeouts. Can cause issues with dosers if it happens
at just the wrong time.

Not easy to fix without fancy multi-threading, which then leads to all sorts of
other fun problems.
Similar issues with Particle Photon.

Went back to Arduino, then eventually tired of it and bought an Apex.

Those network issues can be taken care of by running powerline adapter for direct access. No drop or hang in timeouts.

If you build out the software to run locally on the Pi, and remote control the system from lan or wan vs running software cloud based, can fix the issues with delaying of pumps running and etc in that format because it will then run continuous regardless of connection to the internet for control.

 

[Daniel W]

You can check it out http://www.inventmarine.com

Very cool system fsamir. Is it available or are you not in that stage yet?

Daniel

 

[fsamir]

Hey Daniel,
The device is ready and running my tank for a while, but not available for purchase.
I am about to get 5units in the hands of beta testers, if anyone is interested just pm me.



Sent from my iPhone using Tapatalk

 

[Dxpert]

Fantastic project! How is the reliability of the raspberry pi been? I have had trouble with my PI's crashing at irregular intervals. I'm not sure I would fully trust t as a life support system, but looking for your input.

 

[Daniel W]

Fantastic project! How is the reliability of the raspberry pi been? I have had trouble with my PI's crashing at irregular intervals. I'm not sure I would fully trust t as a life support system, but looking for your input.

Hello Dxpert,

this depends a little on the system setup. I am running my tank since 3 years on my old DIY controlle also based on Raspberry Pi. I never had any problems with the stability of the system (even if I was sometimes a bit worries when going on a 3 weeks vacation to the other end of the world.)

What broke down sometime was the wireless internet connection. I would not design a system that needs this for basic function. I only use cloud computing for efficient history data storage and for the human machine interface.

Daniel