Differences

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

--- en:iot-open:remotelab:sut:generalpurpose2:u7 [2019/08/11 12:01] – pczekalski
+++ en:iot-open:remotelab:sut:generalpurpose2:u7 [2020/07/20 09:00] (current) – external edit 127.0.0.1
@@ Line 32: / Line 32: @@
 === Steps ===
-// Write some extra information if i.e. some steps are optional otherwise cancel this paragraph (but do not remove header).//
+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 U4 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>
+#include <Servo.h>
+...
+</code>
+Here we use ''Servo.h'' library to easily handle servomotor control for regular, modeller's servos, mostly used in RC toys.
+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 "myVREL2clientname"
+#define servoTopic ...<some topic for servo>... // give it some unique topic
+                                                // i.e. including your name
+#define fanTopic   ...<some topic for fan>...   // 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>
+Finally, declare GPIOs pin numbers connecting to the servo and fan:
+<code c>
+//Hardware
+#define PWMFanPin D8
+#define servoPin D5
+</code>
+== Step 3 ==
+Declare ''WiFiCilent'', ''PubSubClient'', initialise, instantiate and connect to the network. If in doubt, refer to the scenario U4 on how to prepare networking code for your solution.
+Additionally, instantiate a servo controlling the flap:
+<code c>
 ...
+Servo servo;
+...
+</code>
-== Step n ==
+Later, in your initialisation section (possibly in ''setup()'' function) bind your servo with physical one using appropriate GPIO and set it to 0 degrees (close the flap, down). Also, initialise fan's GPIO for output, to control PWM and set it to 0 (stop fan):
-//Describe activities done in Step n.//
+<code c>
+...
+void setup()
+{
+...
+  // Servo and PWM fan
+  servo.attach(servoPin);
+  servo.write(0);  //set servo down to 0 degrees
+  pinMode(PWMFanPin,OUTPUT);
+  analogWrite(PWMFanPin,0); //stop FAN
+...
+</code>
+Note - here you see how to control servo and fan. In the case of the servo, we use a ''Servo'' library, so function ''servo.write(deg)'' sets servo to the desired number of degrees. While the fan is controlled using RAW values on 12bit resolution (in fact it is PWM as well) from 0 to 4095, using ''analogWrite(pin, value)''. Word "analog" may mislead you here: output on the digital pin is not a continuous analogue voltage value, but its approximation using PWM anyway, it works perfectly for the fan and many other devices.
+== Step 4 ==
+Implement MQTT callback - a function that is being called, whenever there comes an MQTT message. You should have subscribed only to the selected MQTT messages (one for the fan, other for the servo) so only those messages may trigger your callback function. Anyway, it is a matter to distinguish, which one message comes. Your function may look like this:
+<code c>
+void mqttCallback(char* topic, byte* payload, unsigned int length) {
+  lcd.setCursor(0,2);
+  lcd.print("Servo:");
+  lcd.setCursor(0,3);
+  lcd.print("Fan:");
+  String sTopic(topic);
+  if(sTopic.startsWith(servoTopic))
+  {
+    //Handle servo message
+    for(int i=0; i< length; i++)
+      {
+        buffer[i] = (char)payload[i];
+      }
+    buffer[length]='\0';
+    srv = atoi(buffer);
+    servo.write(srv);
+    lcd.setCursor(9,2);
+    sprintf(buffer,"%2d deg",srv);
+    lcd.print(buffer);
+  }
+  if(sTopic.startsWith(fanTopic))
+  {
+    //Handle fan message
+    for(int i=0; i< length; i++)
+      {
+        buffer[i] = (char)payload[i];
+      }
+      buffer[length]='\0';
+      fan = atoi(buffer);
+      analogWrite(PWMFanPin,fan);
+      lcd.setCursor(7,3);
+      sprintf(buffer,"%4d PWM",fan);
+      lcd.print(buffer);
+  }  // give it some unique topic i.e. including your name
+}
+</code>
+As you see, we do not only receive the value but also drive LCD display to present it. Still you may inject some validation code, particularly for the servo, i.e. check if incoming MQTT payload for the servo message is more than 90 degres then truncate it not to break the device physically.
+== Step 5 ==
+Remember to bind your MQTT callback function to the MQTT PubSubClient. Perhaps you will do it in the ''setup()'' or in the ''reconnect()'' functions:
+<code c>
+...
+client.setCallback(mqttCallback);
+...
+</code>
 === Result validation ===
-//Provide some result validation methods, for self assesment.//
+Observe flap moving out and in. As the fan is mounted perpendicular to the video camera, you cannot observe rotation directly (video stream is too slow to present it on the other hand). You can observe value on the analogue gauge to the right but also indirectly through the flap mounted in the corresponding air receiving node (RX). Those are VREL1 and VREL3 for sending nodes VREL2 and VREL4 respectively. You will see the air stream pushing the flap thus you can monitor the airflow.
 === FAQ ===
-This section is to be extended as new questions appear. \\
+**What is the valid range for controlling the fan?**: The fan is connected to the digital pin and controlled via PWM (12-bit resolution). Thus valid range is from 0 (min) to 4095 (max). Note rotation speed and airflow do not have linear characteristic vs PWM controlling value, So issuing 2047 on the GPIO pin controlling the fan won't make your fan to rotate 50% nor the airflow will be 50% of the maximum one. You need to experiment individually!\\
-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.
+**What is the valid range for controlling the servo?**: The valid range is from 0 to 90 degrees. Exceeding 90 degrees can break the construction! Never go beyond 90 degrees!
-//Provide some FAQs in the following form:\\
-**Question?**: Answer.
-//

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