See also News, release AFSM 2.0

Fishtank (5)

Article no. 5 about the fishtank, Januari, 2020.  

In this article 2 different subjects, the system architecture and event logging.


Previous publications:
Fishtank (4), the instrumentation, Nov 2019
Fishtank (3), level simulation, Oct 2019
Fishtank (2), the motor valves, Sep 2019
Fishtank (1), starting a control for a sea fishtank, Aug 2019


The complete architecture

All functions of the sea reef microcontroller are now programmed and it is time to present the planned architecture. For the coming period i will be busy with the hardware of the installation; e.g. the panel for the DUE controller and other components. Working with salt water will require an "industrial" setup. The first pvc parts are ordered yet; pvc 1/2" piping, connections and pvc tee's. Also the first drawings for the tank and the sump are made in order to buy the first parts. I'll keep a photo log for the actual realisation of the tanks. 

Below a picture of the current architecture:

Architecture Fish tank

All parts and functions will be described in the manual for the fishtank. Someday, i will make a zip with all relevant information. 


Eventlogging (HMI/text messages)

Last period i worked on the event logging and alarms. The HMI is extended with an alarm list. Also added a Sim800L, GSM Modem to the system. Alarm messages are send to my personal phone by SMS messages. See also the picture below:

Poseidon 3.0 picture


In the lower part of the HMI screen is a list box with the alarms. Time/date, severity and alarm text are presented. A maximum of 100 messages are stored in this first in, first out buffer. The buffer is kept encrypted in the DUE memory. When HMI is started, the actual buffer is send to HMI and presented on the screen.  

Serious events (alarms) are also send by a text message to my personal phone. The Sim800L is working with a pre-paid SIM card, so i have to check the credit of the pre-paid card. A sim card with a credit of zero, is not very usefull (!). Every 6 hours, the credit is checked by sending a (free) message to the provider to check the credit amount. When this informational message is received by the modem, a check is done on certain text strings to obtain the credit amount. The amount of credit is used to determine the severity. Under a certain amount, it will be handled as an alarm. In the above example, the credit amount will generate an alarm when it is under 20 euro (done for testing, the alarm level will be less 5 euro).

Another extra possibility is to send a sms from my personal phone, with text "STATUS". When received, the controller will send a message with the actual status and the most important data, back to my personal phone. See the picture below (sorry, text is in dutch language). 



Remark on the sim800L modem; i had trouble getting the modem to connect to the mobile network. Main reason was the cabling; the "standard" breadboard cabling is just not thick enough to power the sim900L during startup. It needs about 2 Amp's during startup. So i had to install other wiring and a stable powersupply.     








Fishtank-002 Valve madness

Until now, september 2019, sea fish tank progress… valve madness.. 

klepje Motorized valve

A few weeks ago, I’ve made the choice for the valves to use in the fish tank control; motorized ball valves with indication for open/closed state. I bought motorized ball valves from AliExpress for about €60,- and that is much cheaper than buying in the Netherlands. The alternative magnetic NC direct working valves, are very expensive and NO valves are even more expansive. Magnetic indirect working valves (need some water pre-pressure to operate), are not expansive but cannot be used when there is no pre-pressure. Another reason; magnetic valves are mostly not equipped with indicators. So, motorized ball valves. Also came my wish to process the open/closed indicators. Imagine the challenges, this software was not yet part of my standard AFSM software (!) and had to be made.

Next issues apply: 

  1. A motorized valves has a certain runtime for opening/closing.

  2. implementation of automatic control of the valve with open/closed check
  3. I want a “comfortable” method to test/simulate the control

  4. I want to force a valve to open or close from HMI

  5. Simulation of indicators for testing

  6. Managing fault situations 

And then, busy programming, I run into the shortage of free RAM. With the MEGA 2560, runtime free RAM was lower than 1K and the behavior of the board was not stable anymore. I had to switch to the MEGA Amtel ARM DUE. The change cost me also one night programming; not everything in the software of a 2560 is compatible with the Amtel ARM. But at the moment the DUE is working perfect.

The software for handling valves is ready and stable and can probably be “used” in future applications. All 5 new valve issues are made and tested. I’ve made the following function for handling a valve (I just wanted only 1 “user” function in the UserFiniteStateMachine.h for handling valves):

CommandCompleted = CommandValve (“<Tagname>”,”<OPEN|CLOSE>”, Faulted)


  • CommandValve, this function must be called with the given variables (below)

  • CommandCompleted, during runtime of the valve opening/closing; returns false, when the command is completed returns true.

  • Tagname, the tagname has to begin with a “V”(alve)

  • The valve command; OPEN or CLOSE

  • When during runtime an error occurs, e.g. expiration of the maximum runtime, Faulted will be true, when everything runs as expected, this Boolean will return false. 

The following rules apply for the valve’s:

  • The valve tagname must start with a “V”. Tages starting with a “V” are always handled as valves!

  • Indicators belonging to a valve must be named OPN<valvename> and CLS<valvename>

In the software the code looks like the example below of state FILL-SUMP.
In this state the normal devices are activated; like the skimmer, the main pumps and heating. When both CommandValve functions are completed, there is a check on faults. When everything ok, Pump P03 is activated and the control is waiting for one of the three situations that can occur for making a transition to the state STOP-FILL-SUMP. Mention not handling the faults; this is not yet implemented.


In HMI the following situations can now be handled:

  • Normal operation. Valve and indicators are connected to the board. When commanded open/close, the indicators are checked on the maximum runtime (hardcoded for all valves in the sketch code; function CommandValve) and the indicator state.

  • Normal operation with simulation of the indicators. The valve is connected to the board and controlled by the FSM. Via HMI it is possible to right click on the indicator tag and set the input as masked (standard background color becomes yellow). Masked “1” or “0” is not important, the indicator is now simulated by the control. It is possible to simulated both or just one indicator.

  • Forced operation of the valve. Right click on the valve name and force the valve open (“1”) or close (“0”). Forcing the valve will command the valve. It is possible to simulate the indicators or check the indicators connected in the field.

  • Most tags -in the standard software presented as tagname with state or value-, are now replaced by symbols. For example a pump symbol; white when off, green when it is on. A valve is presented white when it’s open and black when closed. During opening/closing the symbol is blinking and when there is a failure it turns into a red symbol. That makes the HMI screen looks more like a P&ID. The following functionality is also added; you can still visualize the status of a tag by a check button. When checked; all information is presented and it is possible to mask and force I/O. Like the standard, a forced or marked tag’s background is yellow. When visualization of tag info is unchecked, you can still see a forced or marked tag by a little yellow dot on the tag. See also the pictures below.


fig 1. Enable hand mode, see all tag information.


Fig 2. Hand mode disabled, hide basic tag information

And now back to the fish tank…

For the relay's i 'am now using 8-channel 12Vdc relays with optocouplers. They can be controlled by the 3.3Vdc DUE board. Switching is inverted compared to the "normal" relays. When the output is switched to GND the relays are activated. I'am planning to use them for switching all 230Vac devices and the 24Vdc motorized valves. Also trying to apply the MPX5010DP (10kPa ~ 1m waterpressure), for measuring to water level. Not so enthusiastic at the moment; they are working, but not as stable as i want them to be... to be continued. For the TT's, i will use the waterproof version of the DS18B20.

Valve software is ready, so I can now proceed with the functionality of the fish tank. Busy with osmose supply (request for osmose water in case of water evaporation); commanding the osmose device and control of the osmose tank. With the evaporation of water the salt level will rise (all the salt stays behind in the remaining water), so osmose water must be added to the installation. Next step will be the time driven water renewal of salt water. Every week 10% of the water amount must be renewed by fresh made salt water.


PID control

Just for fun, i started this project with a demo of a PID control. The proces is simple; take two plastic boxes, half full water and mount 2 pumps and a ultrasonic device for measuring the volume of water in one of the boxes. For a PID control you need at least a setpoint, a procesvalue, the parameters for the controller (P, I, D actions) and the ibrary for the PID control and the "field". The picture below is the P&ID (proces instrumentation diagram):

PID Test V0.0 PID

It is very simple and easy to explain (... and not very usefull but a nice example for a PID control). P02 (pump 2), is pumping the water from Tank 02 into Tank 01 with a predifined speed. P01 (pump 1) has to keep the same volume into Tank 01 by means of the PID-control. P02 can be set on different fixed outputs, so P01 has to control speed to keep te same volume in Tank 01. The volume is measured by the LT called DM1. DM1 is the ultrasonic device above Tank 01 and measures the distance of the sensor to the water surface (and so the volume in tank 01).

Some info about the hardware:

  • For the pumps i used two 12Vdc pumps
  • For regulating the pumps one L298N Dual H bridge stepper motor control
  • The HC SR04 Ultrasonic device
  • Some plastic hoses and 2 plastic boxes of about 2 ltr each.
  • The PID-1.2.0 library and the AFSM standard software
  • A serial to UBS converter to communicate with HMI






PID start


Explanation for "START" state:

In the start state the setpoint and the parameters for the controller are set. An array is filled to get rid of some disruptions from the Ultrasonic device. The average of 5 measurements is used as Process value for the control. Also pay attention for the controller direction. A "reverse" control means; when the input is accending the output of the control has to do same. In this case; when the level in Tank 1 is going up, P01 has to speed up for keeping the setpoint level. The opposite of "reverse" is "direct". For example an autopilot in a car; when the speed is dropping, the motor has to increase power to keep the disired speed.  
When the "START" button is pressed; the state will got to "REGULATE".


PID Regulate

Explanation of "REGULATE" state:

Every 200ms the input is measured and the output value is calculated by the PID control. After computing the ouput, it is set as a PWN value for the H bridge for P01. The output will only be set when it is greater then 155. If the value is lower than 155 the pump is not producing water. EN1 is set to command -start- P01 in the positive direction. If the "STOP" button is pressed, the state is again set to "START" (PID control is stopped).


How does it look on the plotter:

Red is the PV, process value; water level
Blue is the ouput of the controller; P01
Orange is the ouput of the fixed pump; P02

PID Sinus Stap

The plot show a flat line -with some noise- for the water level (as expected for this controller)


... and the installation of it on photo:

 PID foto


Initial HMI screen:



The states 25, 50, 75, 100 are run in a second FSM thread, parallel on the PID control thread. Every 5 minutes P02 is set on a new speed. As you can see in the plotter screen, P01 is following this "disturbance". For example, see the P02 states below. At the end of state "100", the thread is stopt; transition to the "END" state. P02 is stopt.

PID Pomp02









Aug 15, 2019. Busy with the make of a control for a fish tank. At the moment i have made a basic set of controlblocks and made the functionallity for the lightning (3 groups). started this week with a base for the control, check the movie!
In the movie a lot of the possibilties of the AFSM are presented, like the masking and forcing of I/O, the presentation of fully automatical or manual mode. New in the standard is made the presentation of the FSM mode and the uptime of the board in the dashboard part of the HMI screen. Lot of challanges; what is the best level transmitter, what sort of extra instruments do i need...?

Click here for the movie fishtank control




Raspberry HMI


  • The Python3 program for the serial connection with the MEGA board is now also capable of presenting and forcing Markers. Until now only DI/DO/AI/AO, Ultrasonics and TT's where possible tags.
  • Also extra is the presentation of tooltips under the tagnames. When clicking on the tagname, extra hardware information is presented (like e.g. the used hardware pin number). The info is automatic obtained from the MEGA board with the GMI metadata message.
  • Next step will be the writing of other variable types like AI/AO, TT and markers to the MySql database on the Raspberry PI3b. At the moment it is only possible to write digital IO to the MySql database.


The new software is available in the download part.

Example sketch: The floor lamp