My Neptune Apex web interface compatible DIY reef controller

I read the release notes, and I see Wire and SD libraries were updated in 1.6.6 and compiler was updated in 1.6.7.

do you remember the error you got in 1.6.7?

There is really nothing in the newer version that is needed by the code, so for now, just use 1.6.5. That is the version I am currently using.
 
1.6.7 Compile Errors

1.6.7 Compile Errors

Here is a text file as the list was long.
 

Attachments

  • 1_6_7_Compile_Error.txt
    54.5 KB · Views: 0
There seems to be a lot of problems reported with 1.6.7 in arduino forum and 1.6.5 seems to be the latest stable version.
I think the errors are due to using a different compiler in 1.6.7.
 
I started working on my LED board again this weekend. Last December when I worked on it, I could not get the esp-12 module to respond. I did not change anything, except perhaps reseat the teensy board into the socket. So this may just be a case of loose connection. I got most of the basic functions (temp, fan control, LED pwm, SD, network, RTC, etc.) to work and working on file handler code for webduino webserver. Download of large file works, but still working on upload of large file. I want this to work like the current chauvet code that you can upload new files using curl. Once I'm done with file handler, I can start working on the html/javascript code.
 
I will reuse a lot of hardware and software from led project.
it will use teensy 3.2 board and esp-12 wifi and I will get custom pcb so everything is packed into 100mm x 50mm board (about the size of an arduino mega).
functions would be essentially similar as before, outlets, ultrasonic ATO, doser, fan, pwm pump, probes.
 
DST bug fix.

I noticed on recent DST time change, I can see in controller log the time got updated, but on the web page, it still shows the incorrect time. Turns out the autoDST function did not update the tz variable. This explains why after rebooting the controller, the display becomes correct.

The function should look like this
Code:
void autoDST(time_t t) {
  if (IsDST(t)==isDst) return;
  isDst = !isDst;
  if (isDst) {
    RTC.set(t+SECS_PER_HOUR);
    tz = STDTZOFFSET+1;
  } else {
    RTC.set(t-SECS_PER_HOUR);
    tz = STDTZOFFSET;
  }
  setTime(RTC.get());
  logMessage(F("Auto adjusted DST time."));
  char buf[20];
  logMessage(F("Current time is "),getdatestring(now(),buf));
}

I'll update github with this change.
 
on led controller software, I'm still working on the webpage framework. I added code to use WebSocket protocol and works nicely, so now webpage update is really real time. Check out www.websocket.org if you are curious about this protocol (it is built in to all web browsers). This will be useful in displaying fan rpm, and display of light schedule simulation where time is fast forwarded 20x. I'm also using the latest jquery version, which supports the more modern looking sliding menu that is pretty much the standard user interface for mobile apps.

I still need to work on getting the esp8266 to run in Access Point mode, so it works like a wifi router. This will solve the current problem of not able to access the controller if there is no power or no internet service and the controller (and your tank) is on backup power. The esp8266 is quite stable so far with constant heavy use. I'm using firmware 1.5.2.
 
To get mine working, I didn't comment out anything like above, but you need to make sure you have changed the define max pwm fans to how many fans you are running ( //#define _PWMFAN

#define MAXPWMFANS 3 //maximum 3) in config

and have the correct temp sensor address in the code ( #define TEMPDEF) also in config then the fan should appear and can then be configured.

Thanks for the advise, that worked to get the FAN working. However, I am having one interesting issue. If I let it run on the set points provided in the sketch it will go on at the low point at low RPM and gradually increase to the MAX duty cycle at the high set point. However, if I manually change the set points through wifi (web server) it is not behaving correctly.

For example, if I change any settings and the temp is below the low set point, once the low set point is triggered the FAN stays at the low duty cycle despite going above the high set point.

Alternatively, if the starting temp is above the high set point when changes are made the high duty cycle is started but never decreases until turning off once 1 degree below the low set point. Essentially the ramp doesn't work once changes are made via the webwerver.

Any advise would be much appreciated
Sean
 
when you say

if I manually change the set points

do you mean you change the low temp and high temp values in controller setup page?
make sure you click the save button after setting the value and you hear the confirmation beep on the controler.

I reviewed the pwmfan code and did not find anything that looked like it will cause the issue you described. If you can email me screenshots and a bit more detail, I can look into it further.
 
I just got done with my taxes. With that out of the way, I can resume working on led controller software. I have yet to test the ACS712 current sensor, once I verify the circuit works (hopefully this weekend), I will order the chauvet v2 controller pcb, which will take a month to arrive. That will give me some time to continue on the led controller software, which will have a good amount of code that will be reused on the chauvet v2.
 
d0ughb0y, did you ever make any headway using the Teensy for the LED controller? I ask mainly cause I was planning on doing a similar build and was curious abbot your experience. Thanks!
--Chris
 
the circuit itself is final. I have ordered 2 rounds of pcb and do not plan to make any further changes. I have test code for individual parts of the controller so I know they work. the final software with all the interface is really the hard part of the project and is what I am currently working on.

I spent a lot of time developing the circuit/code to get the esp8266 wifi to work at max baud rate, which I think is essential in getting a decent response time in the web interface.

Let me know if there is anything specific you need to know.

BTW, the only thing of concern in making this a DIY is the soldering of pin headers to the bottom pads of the teensy. It may require a bit of fine soldering skills and is possible to damage the teensy if not done properly (say if pad is heated too much). I will try to write instructions on how to do this. It's should not really be too difficult to do, and I don't think any special tool is required, only a soldering iron.
 
Last edited:
I will order the pcb soon. I don't want to rush it like I did with the led controller pcb and ending up with a mistake and I had to order again.
 
D0ughb0y, how easy was the integration between the Ternsy and the ESP8266, and how stable has it been? (Sorry if this is off topic but RC won't let me PM you until I have 10 posts).
 
D0ughb0y, how easy was the integration between the Ternsy and the ESP8266, and how stable has it been? (Sorry if this is off topic but RC won't let me PM you until I have 10 posts).


The reason I had to change the led controller circuit and reordered new pcb is because I changed the esp8266 interface to teensy 3.2. I also changed from using esp-01 to esp-12 since esp-01 does not have RTS/CTS pins available. I also got a bunch of esp-03 only to find out they don't have RTS/CTS pins as well.

I won't say it is easy. I first wrote an esp8266 library (using esp AT commands) from scratch, then found out at speed of 115200, a very basic web page containing some javascript takes more than 30 seconds to load, which is too long. So I ended up writing a new Teensy 3.2 serial library that uses hardware handshake and it now loads in split second at 4.6 megabaud. I was a bit surprised to find out that 100% of tons of esp8266 code out there that use AT commands run at 115200 baud.

The serial1.c file was incorporated into teensyduino as an alternate serial1 driver. rename the file to serial1.c to use it.

https://github.com/PaulStoffregen/cores/blob/master/teensy3/serial1_doughboy.txt

For some reason, pjrc chose a "software" based implementation to hardware handshake. I tested that version on my led controller program and it failed miserably right off the bat. The true hardware based hardware handshake works 100% of the time and is stable.

I originally planned to make the libraries generic, but currently, it is specific to teensy 3.x and will work with teensy 3.x only. and it works with a slightly customized version of webduino.

I recently added websocket support to the webduino library that I plan to use in the controller web app.

It also supports running the esp8266 in both Access Point mode and Station mode simultaneously, so you can connect to the controller even if your wifi router goes down.

The only thing I wish the esp8266 AT commands support is SSL connection. The latest firmware claims it supports SSL in AT commands, but it does not work. I think espressif could hire a lot better firmware developers than what they have right now.

It may be too much trouble to make the libraries generic now, so I may just package and release them as teensy 3.x libraries.
 
Last edited:
Back
Top