In this scenario, you will use to monitor the voltage of the unbalanced resistance bridge connected to the analogue input. Voltage level reflects the flap inclination via the light level, reflected from the flap (compared to the reference one).

Undergraduate / Bachelor / Engineering Students

We assume you already know how to:

• handle LCD screen to present information (refer to the scenarios B1 and B2 when in doubt),
• connect to the existing WiFi network: internal.IOT,
• publish to the MQTT broker available in your network,
• additionally, we will ask you to install and use an MQTT client of your choice. We suggest using MQTT Spy, but any MQTT client that will let you subscribe to the MQTT messages is OK. You connect it to the public IP of the MQTT broker (see below).

MQTT broker present in the internal.IOT network is also visible under public address. So whenever you publish an MQTT message using VREL node that is connected to the internal.IOT network, you may subscribe to it using other devices connected to the internal.IOT, i.e. other VREL node or if you're physically present at SUT in the IOT laboratory room 320, then you can connect your mobile and laptop to the internal.IOT network and use “internal” IP address. However, if you're in a remote location, you can access the same broker under public IP as stated in the node description. Same messages published on the internal network are also visible on the public side. Mind, to access MQTT broker you need to use IP, user and password (applies to both public and private IPs of the MQTT Broker). Refer to the node documentation for the latest information.

I this scenario, once you get connected to the WiFi as AP and then to the MQTT server to publish data, you will periodically read A0 (analogue) input of the ESP8266 and publish its RAW value to the MQTT server. You will also visualise the RAW value of the A0 input reading on the LCD screen.

You should be able to read data stream via MQTT message, presenting flap position. Parallel, data should be displayed on the LCD, along with connection status.

Define some identifiers to separate and update AP's SSID and passphrase easily. To format lines for the LCD, we suggest using a char buffer of 20 characters (one full line) and some 2-3 integers for iterators. Remember to declare the LCD control class in your code. You do not need to instantiate WiFi communication class - as you have only one interface here, it is singleton class you can refer directly using WiFi. Reading analogue input brings you an integer value.

Following steps do not present full code - you need to supply missing parts on your own! We do not present here how to connect to the WiFi AP. If you're in doubt, rever to the U1 scenario. Please refer to scenario B1, if you need a recall on how to handle LCD screen. In case you're in doubt how to handle MQTT messages communication (here publishing/sending), please refer to the U3 scenario.

Include all necessary libraries. We use PubSubClient library to contact MQTT broker. The minimum set here is:

#include <Arduino.h>
#include <ESP8266WiFi.h>
#include <PubSubClient.h>
#include <LiquidCrystal_I2C.h>
...

There is no need to use a special library to read analogue input representing relative flap position here.
Declare some identifiers to let you easier handle necessary modifications and keep code clear:

#define wifi_ssid "internal.IOT"
#define wifi_password "IoTlab32768"
#define mqtt_server "192.168.90.5"
#define mqtt_user "vrel"
#define mqtt_password "vrel2018"
...

Declare some identifiers, here MQTT messages' topics, MQTT client ID and payloads for the status notification (on / off).

// MQTT messages
#define MQTTClientName ...<your client name>...         
#define analogOutTopic  ...<some topic for flap>... // give it some unique topic 
                                                    // i.e. including your name
 
//MQTT last will
#define lastWillTopic ...<some topic for exposing state and last will>...   
                                                    // give it some unique topic
                                                    // i.e. including your name 
#define lastWillMessage "off"
#define mqttWelcomeMessage "on"

Declare WiFiCilent, PubSubClient, initialise, instantiate and connect to the network. If in doubt, refer to the scenario U3 on how to prepare networking code for your solution.

Prepare MQTT publishing code, here we publish periodically one value (flap position, relative), i.e. like this:

void mqttPublish()
{
  flap = analogRead(A0);
 
  if(client.connected())
  {
    client.publish(analogOutTopic, String(flap).c_str(), false);  // Do not retain
                                                                  // messages
  }
}

Your loop() function should include call to the aforementioned mqttPublish and printing on the LCD screen once every 5 seconds.

void loop()
{
  if (!client.connected()) {
    reconnect();
  }
  client.loop();
  mqttPublish();
  sprintf(buffer,"Flap is %d ",flap);
  lcd.setCursor(0,2);
  lcd.print(buffer);
  delay(1000);
}

Observe connection progress on the LCD via video stream. Once WiFi and MQTT are connected, you should be able to see analogue input readings on the LCD, and additionally, those should be sent over the MQTT messages to the MQTT broker. Connect your MQTT client and subscribe to your messages (you may do it using a wildcard character), i.e. with means of the MQTT spy application. Remember to connect MQTT spy to public IP address unless you're a student physically present in our laboratory room and you have direct access to the internal.IOT network. Observe data on the LCD screen the same as over MQTT messages (note, there may be a delay because of the network bottlenecks and MQTT broker load).

I want to implement PID controller of the position of the flap, using TX air pushing node (VRELS 2 and 4). 200ms latency between consecutive reads seems too large, to implement efficient loopback. What to do?: In this case, you should drop MQTT communication and communicate directly between nodes, i.e. your RX node (VREL1 and 3) can send a UDP message over the network. Our WiFi internal.IOT is a pretty efficient one, and should handle it with ease.