Week 3: Integrating New Hardware, Data Storage & Visulisation

My issue in re-wiring the components was in the software definitions of the pins. Where the code in the Arduino IDE for the Arduino Uno specified in Code Block 3.1 “5” the VSCode specification for the same pin in the ESP8266 in Code Block 3.2 was “D5”. This had taken some time in realising there was a coding difference between the two and then applying that difference.

From here connecting to MQTT was required. To do this I integrated the libraries nad code from our group work applied to the temperature and humidity sensor with the code depicted in Code Block 3.3

As I would like to possibly add more features to my IoT device in the future I decided to make my code modular. I input my credentials to connect to Mosquitto MQTT and initiated a callback and reconnect functions in a separate .cpp file. This also requires a separate header file to be included in a .cpp files that call any function in the separate header file. Image 3.1a, 3.1b, 3.1c and Code Block 3.4 show how these work. The same idea was implemented for my Wifi setup and initilisation for the load cell.

// Include libraries below:
// Standard Library
#include <cstdlib>

// Open Source Libraries
#include &quot;HX711.h&quot;
#include <ESP8266WiFi.h>
#include <PubSubClient.h>
// #include <BlynkSimpleEsp8266.h>
#include <Blynk/BlynkTimer.h>

// Open source library section aplicable to application requirements
#include &quot;Wifi_Setup.h&quot;
#include &quot;MQTT.h&quot;
#include &quot;secrets.h&quot;

// Private header 
#include <secrets.h>

I then took our implementation of NodeRed and Influx DB from the temperature/humidity sensor we had previously set up. I changed the node configurations for the MQTTin, function and InfluxDBout nodes to match my VSCode and pipe data to the InfluxDB database.

var partsLoadCell = msg.payload.split("\n");

msg.payload = {
    Sensor_Name: partsLoadCell[0],
    Curr_Weight: partsLoadCell[1],
    Curr_Average_Weight: partsLoadCell[2],
    Prev_Weight: partsLoadCell[3],
    Prev_Avg_Weight: partsLoadCell[4],
    Difference: partsLoadCell[5]
}
return msg;

I had trouble connecting my load cell acquisition device to NodeRed via MQTT to on-flow to InfluxDB. As our group had issues deploying to NodeRED and deleting flows from other group members we set different instances of NodeRED to different ports. This stopped other members’ flow deployment wiping our individual flows and continuing our individual work. 

I could not identify why my instance of NodeRED (or NodeRED port connection to the Vultr server) would not connect to Mosquitto MQTT. I imported my flow to my colleague Michaela’s NodeRED instance which worked and backed up my working flow as a JSON download.

Once I had connected MQTT I had problems inserting my new table named “weight” into our group InfluxDB database to store my weight data. I had tried copying working nodes from other team members instances of NodeRED unsuccessfully. I decided I would test my flow by importing it to our original group instance of NodeRED which was successful in connecting to MQTT and creating my “weight” table for storing my weight data in the InfluxDB database.

From here I wanted to show my data through Grafana which worked well. As we had differing data it was recommended we find a way of accessing our data iva a means other than purely using a serial connection via PuTTY. For this we found InfluxDB’s visualising program Cronograf. This enabled us to access our data tables easier and see how we can manipulate our data.

I then wanted to dive a little deeper into the software side by first storing the difference in weights from the newest weight record and the previously stored to give me the amount of weight added or removed from the load cell. This represents the amount of liquid removed from a bottle. From knowing the amount of “liquid” displaced from the weight I can with further calculation know how much would need to be charged to a customer.

//
// For calculating the difference in weight
 long calcDifference(double firstNum, double secondNum){
    return firstNum - secondNum;

  }

As the load cell can be quite sensitive I have added a tolerance level to be calculated for each weight with a nominal value of
+/- 3% the value being weighed. This means only change in weight data smaller or larger than 3% of the value of the previous amount being weighed will be recorded as a weight or liquid “transaction” to a customer. In other words a weight displacement value worthy of being charged as a monetary transaction.

if(currentWeight < lowTollBound || currentWeight > upTollBound){
      // Publish data to mqtt
      if (now - lastMsg > 2000) {
        lastMsg = now;
        ++value;
        snprintf (msg, 50, &quot;%s\n%.1lf\n%.1lf\n%.1lf\n%.1lf\n%.1lf&quot;, sensor_Name, currentWeight, currentAvgWeight, prevWeight, prevAvgWeight, difference);
        snprintf (diffMsg, 50, &quot;%.1lf&quot;, difference);
        // Serial.print(&quot;weight &quot;);
        // Serial.println(msg);
        client.publish(&quot;weight&quot;, msg);
        client.publish(&quot;diff&quot;, diffMsg);
        // Store the weight data collected 
        prevWeight = currentWeight;
        prevAvgWeight = currentAvgWeight;

        // Find the weight tollerence boundaries
        upTollBound = prevWeight + ((prevWeight/100)*tolPercent);
        lowTollBound = prevWeight - ((prevWeight/100)*tolPercent);

        // print boundaries for test
        printBoundaries(upTollBound, lowTollBound);
      }

  }

    printReadings(currentWeight, currentAvgWeight, difference, tolPercent);
}

I had then decided I would like to display to my mobile device from the influxDB database and write data from a mobile device to my acquisition device. I really wanted in my first instance to add some functionality enabling a user to adjust the tolerance level of weights being recorded (and therefore charged to a customer). I know i have to do this via a client.subscribe to a MQTT topic but I am not sure as to how to make that topic subscribe change the calibration value. I will continue to work on this functionality next week.

For my next session:

I would like to work on the following:

1. Changing calibration of weight tolerance via mobile interface
2. Display weight change data on mobile interface.
3. Contact a company called H&L. They are a Point Of Sale (POS) company that we use in the bar I work at. I would like to ask the following questions:
   1. Do they use an API to interface with their systems?
   2. How do the interface with other service related software and software companies such as XERO and resDiary?
   3. How do I pull pricing data from their POS database and write to their DB to charge to tables?
   4. Does their POS have the capability for IoT Devices to possibly write to tables automatically?
4. Research how to implement a bottle identification system or stock management system from barcodes and mobile cameras to track bottles in the POS system. 
   1. This could involve identifying resolute stock management in automation (or partial automation) from warehouse to customer.

I realise there is a fair bit of research to undertake in a system such as the one I propose for the time I have allocated to this task. Digging deeper into the full breadth of this project is my last priority until I have my proof of concept in pouring a glass of wine registering that has been poured and coming up with a price associated with the displacement of the liquid.