Differences

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

Link to this comparison view

--- en:iot-open:remotelab:sut:generalpurpose2:u8 [2019/08/10 20:55] – pczekalski
+++ en:iot-open:remotelab:sut:generalpurpose2:u8 [2020/07/20 09:00] (current) – external edit 127.0.0.1
@@ Line 17: / Line 17: @@
 === 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.
+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. 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.
+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 ===
@@ Line 28: / Line 28: @@
 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 ==
-//Describe activities done in 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 n ==
+== Step 5 ==
-//Describe activities done in Step n.//
+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, how MQTT messages change their values once you
+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 ===
-This section is to be extended as new questions appear. \\
+**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.
-When using the printed version of this manual please refer to the latest online version of this document to obtain the valid and up-to-date list of the FAQ.
-//Provide some FAQs in the following form:\\
-**Question?**: Answer.
-//

en/iot-open/remotelab/sut/generalpurpose2/u8.1565470508.txt.gz · Last modified: 2020/07/20 09:00 (external edit)