Differences

This shows you the differences between two versions of the page.

--- en:iot-open:remotelab:sut:generalpurpose2:u8 [2019/08/10 23:55] – pczekalski
+++ en:iot-open:remotelab:sut:generalpurpose2:u8 [2020/07/20 12:00] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+==== U8: Visualising and sending flap state ====
+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).
+=== Target group ===
+Undergraduate / Bachelor / Engineering Students
+=== Prerequisites ===
+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 [[https://github.com/eclipse/paho.mqtt-spy/releases|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.
+<note important>Note - information present in source code samples can be not up-to-date - remember to refer to the VREL node documentation for the latest information on IPs, users and passwords for both ''internal.IOT'' network access and for the MQTT Broker.</note>
+<note important>Note - Analog input in ESP8266 measures voltage on the pin A0, ranging from 0 to 3.3V (in reality somewhere from 0.1-0.2V to 3.2V) using 4096 distinguishable values - the A/D converter resolution is then 12bit and return values you may expect, range from 0 to 4095 - in fact they're much more narrowed.</note>
+=== Scenario ===
+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.
+=== Result ===
+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. <note tip>Note - flap position refers to the airflow: you may need to control it using VREL2 and VREL4 for VREL1 and VREL3, respectively. Airflow in nodes 2 and 4 can be controlled twofold: using PWM to control fan rotation speed and using the flap to open/close air duct.</note>
+=== Start ===
+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.
+=== Steps ===
+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.
+== Step 1 ==
+Include all necessary libraries. We use PubSubClient library to contact MQTT broker. The minimum set here is:
+<code c>
+#include <Arduino.h>
+#include <ESP8266WiFi.h>
+#include <PubSubClient.h>
+#include <LiquidCrystal_I2C.h>
+...
+</code>
+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:
+<code c>
+#define wifi_ssid "internal.IOT"
+#define wifi_password "IoTlab32768"
+#define mqtt_server "192.168.90.5"
+#define mqtt_user "vrel"
+#define mqtt_password "vrel2018"
+...
+</code>
+== Step 2 ==
+Declare some identifiers, here MQTT messages' topics, MQTT client ID and payloads for the status notification (on / off).
+<note important>Use unique names for topics and for the MQTT client, do some random, use your MAC as part of it. It is important because MQTT broker identifies client using its name thus if your device shares name with some other that is already working, you may not get information about connection lost because another device with the same name is still active on the network. Unique topics are also essential: if you accidentally overlap, you may get an invalid reading with someone that is using the same topic but different payload.</note>
+<code c>
+// 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"
+</code>
+== Step 3 ==
+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.
+== Step 4 ==
+Prepare MQTT publishing code, here we publish periodically one value (flap position, relative), i.e. like this:
+<code c>
+void mqttPublish()
+{
+  flap = analogRead(A0);
+  if(client.connected())
+  {
+    client.publish(analogOutTopic, String(flap).c_str(), false);  // Do not retain
+                                                                  // messages
+  }
+}
+</code>
+<note important>Reading analogue input is pretty easy: all you need to do is to use ''analogRead(A0)''. Note, ESP8266 has only one analogue input A0.</note>
+== Step 5 ==
+Your ''loop()'' function should include call to the aforementioned ''mqttPublish'' and printing on the LCD screen once every 5 seconds.
+<code c>
+void loop()
+{
+  if (!client.connected()) {
+    reconnect();
+  }
+  client.loop();
+  mqttPublish();
+  sprintf(buffer,"Flap is %d ",flap);
+  lcd.setCursor(0,2);
+  lcd.print(buffer);
+  delay(1000);
+}
+</code>
+<note warning>Mind to keep a ''delay(...)'', not to saturate MQTT broker and communication channel. Minimum reasonable delay between issuing consecutive MQTT messages is about 200ms.</note>
+<note tip>The ''flap'' variable is a global one, set in the ''mqttPublish'' using ''analogRead(A0)''. This way you have it set for ''sprintf'' formating function.</note>
+=== Result validation ===
+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).
+=== FAQ ===
+**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.