EmonCMS Inputs and Feeds

Further info on the wireless weather station and the logging app/site EmonCMS.  EmonCMS is fantastic for logging and displaying your sensor data.  I have setup a server on a Beagleboard XM, as I mentioned in previous post.  It works flawlessly if you treat it right.  What I mean is that messing with inputs and feeds can stop your flow.  After finally figuring out how to do the multiple graph (you have to set up ‘Visualization’ tab first), everything was logging like a champ.  Then I thought I would rename some feeds.  The graphs show what is in the feeds, as far as name is concerned.  My mistake is I didn’t see the change immediately happen after I changed names.  So I thought I had to change the Input name as well.  I did see the graph update with new names and thought it was working great.  It wasn’t.  Woke up next day and saw all the logging for sensors where I changed names were stopped – hadn’t updated in 11 hours.  Turns out I wasn’t waiting for feed timing to update graph, so jumped to conclusion it was Input name as well.  You can change names as long as it is just on Feed setup page.  To get sensors updating again, I had to redo the Input Sensor page (delete changed inputs), and let the inputs update by what the WeMos board was sending.  Then I re-established feed logging.  Then I corrected the bogus feeds in Feed page, and changed names to what I wanted.  All works now with sensor names I chose in Dashboard page.

Another thing to realize too…….when feeds are deleted, they are deleted from MySQL database.  At least I couldn’t find them again.  So, be careful deleting feeds, as you may nuke your logged data up to that point.  I was fine with it, as I just got this setup working for about a week.  Renaming a feed is fine, the data remains and is a continuous log record.

Posted under Sensors

Wireless Weather Station Update

There are tons of weather station how-to sites on the Web.  I am not going to run through the how’s and why’s of setting one up.  I will add some info that has helped me get it where I wanted it.  First a little background…….

I had started this project about a year ago.  In between building and moving into a new house, it got sidelined a few times in favor of more pressing projects.  It was first based on an Arduino Nano, and would use NRF24L01 modules to communicate.  That was all well and good, but realized that having an Arduino connected to PC to receive the data was not what I really wanted in the end.  By that time, I had assembled all the sensors and components onto a wooden board to put out in the shed 35ft from the house.  The anemometer, wind vane, and rain bucket was purchased at Switchdoc Labs, but is the same set that can be purchased from Sparkfun.  The base sensor module was the WeatherPi board from Switchdoc Labs (the older version without grove connectors).  This included a Realtime Clock and BMP280 sensor with an I2C interface.  My other sensors assembled were DHT22 for temp/humidity, and an AS3935 lightning board from PlayingwithFusion.

By this time, I had planned on a new setup.  I had purchased a NodeMCU development board based on ESP8266, which looked to be the best compact, all-in-one solution.  WiFi was built-in.  This board was perfect for testing sensor components and the C++ code in the Arduino IDE.  For the lightning detector board, I found using the EmbeddedAdventures 1016 lightning library the easiest.  The code is agnostic towards how the lightning board is hooked up to microcontroller.  All that is required is naming IRQ pin in the code.  The PlayingWithFusion board is great because you do not need to make any physical changes to use SPI or I2C.  No traces to cut or resistors, caps to add.  I chose I2C due to limited digital pins available with ESP8266.  Depending on how you attach the SI pin of lightning board, communication interface is chosen.  This is how it is connected for I2C:

SDA             SDA
SCK             SCK
SI              VCC
IRQ             D6
CS              GND
GND             GND
VCC             VCC

All sensors were tested with code individually on Arduino IDE, to make sure they worked.  That was all good.  Then came putting the code together and getting digital pins to play nice together.  The ESP8266 has a lot fewer digital I/O than Atmel 328P boards like UNO, etc.  It has only one analog input.  The pinouts can be confusing with multiple versions of RX/TX and SPI printed on the boards themselves.  To get everything to work together, I assumed only one of each.  I2C comes to the rescue by sharing communication port.  Just have to make sure the addresses of your sensors do not overlap.  Using the Adafruit sketch for scanning attached I2C devices clears that question fast.  next I wanted to test the WiFi capability of NodeMCU from my shed.  I don’t know if it was the fact it got power from USB port or that particular unit had antenna issues, but it had spotty connectivity and would lose signal often.  I decided to get a WeMos board, which still uses ESP8266, but has an UNO footprint and standard power connector.  I figured with larger capacitors, and fact I could feed it 9V, it might have steady power to deliver the data over WiFi.  Long story short….the WeMos has connected and delivered data consistently.


As with the NodeMCU, you have to name your pins by what they are (like D5, D7, and A0) due to pin mapping.  Everything works as it should when that is done.  Due to the lower number of GPIO on ESP8266, uploading and running firmware can be a little more difficult.  One example is I could not sync during upload with IRQ using D4 or D8.  I ended up using D7 and that was fine.  All kinds of reset occurrences can happen with ESP8266.  Most cases, it can be one line of code referring to a library.  I learned that I would only make one change to code at a time and between each change, upload firmware and test with serial monitor.  In the end, I narrowed down most resets and continuous reboots to use of interrupts.  In the final code for this weather station, there are 3 sensors that use interrupts: Lightning board, anemometer, and rain bucket.  What was happening ended up coming from sending data to server over WiFi and interrupts would blow it up.

The key to getting everything running smoothly was to turn off the interrupts right before connecting and sending data to the emoncms server.  After the send, you perform attachinterrupts again for the IRQs.  Here is how the sequence would go in the code – the data transfer to webserver happens between the detach and re-attach interrupts as shown here:

  //added these
  Serial.print("Requesting URL: ");
  // This will send the request to the server
  client.print(String("GET ") + url + " HTTP/1.1\r\n" +
               "Host: " + host + "\r\n" +
               "Connection: close\r\n\r\n");
  unsigned long timeout = millis();
  while (client.available() == 0) {
    if (millis() - timeout > 5000) {
      Serial.println(">>> Client Timeout !");
  // Read all the lines of the reply from server and print them to Serial
  while (client.available()) {
    String line = client.readStringUntil('\r');
  Serial.println("normal closing connection");
  attachInterrupt(digitalPinToInterrupt(IRQ_pin), alert, RISING);
  //added these
  attachInterrupt(intAnem, serviceInterruptAnem, RISING);
  attachInterrupt(intRain, serviceInterruptRain, RISING);

I decided to use the OpenEnergyMonitor platform for recording and logging my weather.  This is a great way to display your sensors.  The widgets are already created and the graphs and display can be customized to your satisfaction.  The platform runs on a server of your choice (I chose my Beagleboard-XM running Ubuntu 12.04) and is PHP-based and uses MySQL as storage for data.  Here is an example of the emonCMS custom web view:

Open Energy Custom Interface

Open Energy Custom Interface


Posted under Sensors

NodeMCU (ESP8266) upload sketches wirelessly

More on the NodeMCU (V1)…..  This little booger is great!  I have tried all kinds of wireless upload solutions with Arduino (Olimexino with ESP8266, Nano with various wireless devices) and the end result of actually uploading the sketch never succeeded.  It all had to do with the reset aspect which causes the bootloader to accept code and overwrite existing code.  I tried all kinds of elaborate methods: softserial, trigger words that closed reset pin, and a few others I can’t remember now.  I just wanted a way to be able to update firmware/sketches while the device was far away and locked up without having to hookup to a usb cable to do updating.

Enter the NodeMCU version of the ESP8266.  Out of the box it works with the Arduino IDE.  No need to mess with LUA.  Once I got the latest ESP8266 code from Github to replace what was in the IDE, everything worked like a charm.  On my Windows 7 PC, that library went into appdata\local\arduino15\packages\ESP8266.  The version that really worked was 2.3, as the version 2.2 that came with IDE didn’t really work with wireless upload.  The key is the ArduinoOTA library that was fixed and updated.  The key for me getting it to work was with the reset.  In the default code, the reset is called when the OTA function failed.  To get it to really work, you do the reset after the upload and Bingo! it all works.

OTA port selection

OTA port selection

After your first USB sketch upload with the OTA library and code in place, you have to close down Arduino IDE, and then restart IDE for the OTA port to show up.  Not doing this step at first made me think the library was not working.  The image above shows the OTA port under ‘network ports’.  This capability all comes from Arduino Yun wifi procedures, so anyone with that board would be familiar with the network port in the list.

There really isn’t much more to it than that.  The only downside as far as I can tell is the serial monitor falls out of the mix. You cannot use network port with serial monitor because it relies on Yun firmware that asks for SSH password.  You can still use the USB port powering the nodeMCU board if you use another terminal program (like Putty) to see what is coming over serial.

My solution was to hookup an OLED screen to the board and display anything I needed to monitor.  The beauty of using an I2C OLED panel is it only uses 2 wires.  I have a TFT LCD panel which is SPI, and still may use this in the end as it has SD card storage as a bonus.  But for testing, the OLED is easy and just works.

OLED panel on nodeMCU

OLED panel on nodeMCU

Here is the sketch code that grabs a static IP address and allows over-the-air uploading.  It also has the OLED bits for variable monitoring and feedback.

#include <ESP8266WiFi.h>
#include <ESP8266mDNS.h>
#include <WiFiUdp.h>
#include <ArduinoOTA.h>
#include <Wire.h>
#include “SSD1306.h” // alias for `#include “SSD1306Wire.h”`
SSD1306  display(0x3c, D2, D1);

const char* ssid = “your_local_ssid”;
const char* password = “your_wifi_password”;
const char* host = “ESP-OTA”;

#define led_pin BUILTIN_LED
#define blu_pin D4
#define beat 450
IPAddress ip(192, 168, 1, 196); //Node static IP
IPAddress gateway(192, 168, 1, 1);
IPAddress subnet(255, 255, 255, 0);
void setup() {

  // Initialising the UI will init the display too.


  pinMode(led_pin, OUTPUT);


  WiFi.begin(ssid, password);
  WiFi.config(ip, gateway, subnet);
  while (WiFi.waitForConnectResult() != WL_CONNECTED) {
    WiFi.begin(ssid, password);
    Serial.println(“Retrying connection…”);
  ArduinoOTA.onStart([]() { // switch off all the PWMs during upgrade
    analogWrite(led_pin, 0);

  ArduinoOTA.onEnd([]() { // do a fancy thing with our board led at end
    for (int i = 0; i < 80; i++)
      digitalWrite(led_pin, HIGH);
      delay(i * 2);
      digitalWrite(led_pin, LOW);
      delay(i * 2);

  ArduinoOTA.onError([](ota_error_t error) {

  /* setup the OTA server */
  Serial.print(“IP address: “);
  Serial.println(“Now Online!”);

void loop() {
  // clear the display
  float power = WiFi.RSSI();
 String strpower = String(power, 1);
  display.drawString(0, 18, ssid);
  display.drawString(0, 32, “POWER: ” + strpower);
  analogWrite(blu_pin, power);

void heartbeat() {
  digitalWrite(led_pin, HIGH);
  digitalWrite(led_pin, LOW);

Posted under Applications,Sensors

Notes on the AS3935 Lightning Sensor

I finally got around to testing this sensor (two actually).  The AS3935 is IC sensor created by AustriaMicroSyetems.  There are a few breakout boards available out there with the chip installed.  The first one I got from Tautic on Tindie is no longer available.  The second breakout board I got was from PlayingWithFusion.  I never really got the Tautic board to work, hence my picking up the second.  I don’t know if it was a bad sample, or I cooked it when soldering on the pins.  All the sketches I ran on it, no matter what I did said the ‘noise floor was too high’.  I haven’t thrown it away, so I may have a go at resoldering the pins (in case one of the connections was wonky) and retrying sketches I know work on the Fusion board.  Ultimately, it would be cool to have two of them working and I could triangulate some kind of directional attribute.  Because they are using different capacitors and arrangement, it may not be a good idea.  If anything, two could eliminate false positives.

Now on to the Fusion board.  This board comes with a capacitor value in picoFarads, which you can apply to the sketch from the company’s website.  I tried the sketch that came from the company, and I got lots of local disturbers and no lightning indicators.  The terminology that is used with this board is ‘Disturber’ for a local man-made type of signal in 500kHz range.  The lightning algorithm also uses this frequency range, but filters and automatically identifies lightning over other signals.  It is not foolproof and there are many adjustments you can make through software registers.  If I were to rate this particular board version with AS3935 chip, I would say about 8 out of 10.  The reason I did not choose 9 or 10 is because I have gotten false positives.  Like I said, there are a bunch of adjustments one can make, and it may be that I need to step up a threshold (or two).  Thresholds for this chip are Watchdog, Spike Rejection, and Noise Floor values.

AS3935 with Olimexino

The connection for this particular board is SPI.  The difference between this board connections and the Tautic is for that one, you are supposed to connect SI to GND.  On the Fusion board it is connected to D9 on Arduino 328 type board.  The other connections are standard SPI.  IRQ is on pin D2 for the 328-based Arduino.

I have tried a number of sketches for this chip and the one that works (in my situation) is the one from ThunderAndLightning.  The automatic calibration may be the key.  It starts off the process with values zeroed out and finds the capacitor value closest to 500kHz.  I made a few modifications to work with my particular setup.  Since I had tried other libraries and sketches, I wanted this library to unique, so I changed header name and corresponding entries in the CPP file.

#include <SPI.h>
#include "TL_AS3935.h"
// #define A_MEGA_1280
#define A_PRO_MINI

Also, for the 328 Arduino, you want to insert interrupt as 1.  This line is an example:

AS3935IrqTriggered = 0;
attachInterrupt(1,AS3935Irq,RISING); // 1 for 328

I used the ‘Log’ sketch because I wanted to use Processing to access the chip and record the activity.  This sketch logs the activity as a CSV file.  I also hooked up a blue LED to indicate lightning.  The code for this is also in the script.  Change it to the pin you will use for your LED.

I must admit, I was surprised that about a half hour after I setup the board and ran the sketch, the blue LED flashed.  I looked at the CSV file and it actually recorded 2 strokes with a minutes time.  The interesting thing is, I am finding that it rarely signals a disturber, but is pretty good with indicating lightning.  I am in Florida and this summer there has been much rain and lightning – perfect testing ground for this.  As I mentioned before, I think I may have to tweak here and there – maybe the spike rejection or watchdog threshold.  I have had a few false positives.  Once I saw the blue LED flash and I went outside and there wasn’t a rain cloud in site.  Just small cumulus clouds scattered about.  the clue it was false was that it said 1Km away – so I couldn’t miss that if it was there.

All-in-all I am happy with this little sensor.


Posted under Sensors

Back to Sensing

Finally had some time to tinker again.  This time working on the distance sensing function of eventual autonomic robot.  I turned to a good ol’ Arduino for the physical IO.  I got a Nano, and this is a sweet little microprocessor.  All the functions of an Uno crammed into a little DIP from factor.  For testing things out it is stellar.  Just plug into USB port of PC and run your IDE of choice and your off.  I decided on a Seeed Studio ultrasonic rangefinder.  This is pretty much the same as a Parrallax Ping sensor, or the SRF-05 rangefinders.  This Seed studio unit has 1cm resolution and pretty inexpensive.

My goal is to get the forward focal point more resolution (like a telescopic lens vs. a fisheye).  Ultimately I could and should use a laser rangefinder, but this approach is quick & dirty and ripe for tinkering.  My thinking was that perhaps I could narrow the dispersion of the ultrasound at least on the transmitting side.  I knew that because the sensors are separated by about an inch, narrowing the input or receiving side would reduce the amount of echo reception perhaps too much and give haphazard results.  Ultrasonic waves travel in a more focused pattern compared to audible waves in the first place.  So by creating a smaller source of waves, I believe the “beam” will be narrower.  My thought was to cover up the exposed area of the transmitting speaker  – they are little speakers in there (like whizzer cones in old automobile full-range speakers).

Nano-focused SONAR

Upon testing, I found that the stream of data (microsecond time) was pretty consistent with stray numbers that were off the chart determined to be the reflected ultrasound inside the chamber getting out through the hole.  By filtering that out in the Arduino sketch, I could get reasonable results.

SONAR Output

Since the above output was centimeters, I think the resolution is decent enough.  Before the lens mask and filtering, I had all kinds of values in a pretty wide range.  My guess it was from the transducer dispersal pattern catching an object behind or to the side of what I thought was in front of the rangefinder.  I will modify the code to test output in a graph to test the narrowness of the beam on real world objects.  I will either grab the values and put in Excel or write some code using Processing  (www.processing.org) to show the graph realtime.

Speaking of Processing – I love that software suite, platform, IDE or what ever you want to call it.  It uses the same format and syntax as Arduino sketches right down to the graphic interface.  So if you know “C like” sketches, using Processing will come to you quickly.  I found this awesome sketch by Lucky Larry in the UK who wrote a sketch for his pan-tilt rig using a rangefinder.  He wrote a graphical radar-like realtime screen output from the rangefinder and it is pretty slick.  I modified it a bit for my purposes, but kudos to him for the original sketch.

Graphic SONAR output (Processing)

So that is the screen you see while Processing is running the sketch.  Basically, you run your rangefinder sketch on the Arduino – make sure the serial output screen is not open.  Then you run the Processing sketch which reads the serial stream.  I modified the code to show “ping” reflections as dots instead of polygon areas.  I also changed it sweep only 4 degrees on either side of 90 degrees.  I can see a lot of potential with Processing and the Arduino family of processor boards for physical computing feedback.

Posted under Robotics,Sensors

Pan-Tilt and Video Figured Out….

After much trial and error and success with PWM and the neck servos (Hitec), I found I was having problems getting the servos to work together using basic pulse width in the Arduino code. Each servo worked perfectly when singled out, but trying a pan-tilt at the same time caused servos slamming to the ends and losing all coordination. I finally found that downloading the MegaServo library did the trick. It was supposed be included with version 17 of IDE (which I have). Anyway, this library works great! The key is that it will allow all the pins to be used for servos, not just 9 & 10. My Arbotix board stops at 8, so I was out of luck with the default Servo.h library.

I had planned on interfacing a Panasonic CX161 board cam (have one already) to the STPC main board for the vision processing, but that would require a frame-grabber board or a composite vid 2 USB connector. After almost going with that 2nd choice, I remembered I picked up a $12 webcam at Staples around Christmas for goofs – I actually thought I could use it in a project somehow. This choice will cut out the video capture component because it is already built in! I mounted it to the pan-tilt neck assembly and will test interface to the Atlas STPC PC/104 board (with Win2K).


Posted under Robotics,Sensors