49
IoT Layout
As in the other smart home example, all IoT devices were connected in the same net-
work, the only difference was in the IoT server being not connected to the home LAN.
This required that local WLAN router acted as DHCP server but, for IoT functions, device
were connected to the remote IoT server.
As previously all the devices were also sharing the same IoT username and password,
same credentials needed also to be used by the home owner in order to remotely con-
nect, via browser, to the IoT homepage.
As one can see in the below Figure 27, this simulation had already eight pre-configured
IoT Smart-devices: solar panel, battery, two AC units, humidity sensor, motion sensor,
webcam and a garden light.
Figure 27 - List of IoT device connected
Also two IoT simulations were pre-configured and visible from the main IoT homepage,
as shown in the Figure 28.
50
Figure 28 - Pre-set IoT simulations
First automation replicated a scenario where an IoT humidity sensor was installed in the
house in order to monitor the ambient humidity. In case the detected humidity exceed
the pre-set threshold value the AC unit was automatically power on, dropping the level
of humidity. Ambient level of humidity could be monitored from both the sensor or by
selecting if from the main IOT homepage.
To increase the complexity of the simulation, a solar panned and a smart battery were
also added and connected to the AC unit.
The concept was that, during the daytime when sun shone, the solar panel produced
electricity, charging the battery. At the same time however the sun increased the humidity
in the house causing the AC unit to start. Being the AC unit connected to the IoT battery
it was possible to observe that battery stored the electricity when AC unit was off, but
drained fast when AC was on.
It is worth to mentioned however that, due to Cisco Packet Tracer logic, the AC did not
stop in case battery stored power reached zero and also that battery did naturally loose
the charge even if AC was not on.
Both amount of electricity produced by the solar panel and remaining power in the battery
could be seen in real time from the main IoT homepage as illustrated in the Figure 29.
51
Figure 29 - Monitoring of power produced and stored by IoT devices
The second IoT simulation included in the exercise was similar to the previous Smart-
home alarm system. Main difference in this case was regarding the motion detector trig-
gering not a siren but, for a few second, a webcam broadcast if something was detected.
Simulation could be validated by pressing ALT on the keyboard and hoovering on the
motion detector sensor with the mouse, from the IoT home page the webcam then broad-
casted some images.
Figure 30 shows the case when no objects were detected and webcam was off, in Figure
31 is possible to see that sensor was triggered and webcam was showing images.
Figure 30 - Webcam off as no movements are detected by the motion sensor
52
Figure 31 - Webcam on as movements are detected by the motion sensor (ALT + mouse)
As mentioned earlier in the chapter, the smart garden light was also included in the con-
nected devices. The IoT light was an example of a smart device that incorporates own
sensors, and due to the complexity of its software, could function even without backend
pre-set conditions. The street lamp unit had in fact embedded a motion sensor and a
light sensor; these allowed the lamp turn itself on automatically if nearby object or a low
level of visible light were detected.
Along with the “SaaS” concept the second big difference, compared to the previous
smart-home simulation, was the use of specific environmental variable.
As briefly explained in the chapter 4.2, Cisco Packet Tracer offers variables in order to
create more realistic simulations, these in fact can help to influence the behavior of the
sensor but also validates the accuracy of the IoT device simulation logic.
In this exercise variables were used in order to influence the production of electricity, the
home humidity build up and the sunlight level for triggering the garden lamp.
53
Figure 32 - Environmental variable graph
As illustrated in the above Figure 32 the amount of sunlight, humidity and temperature
were tuned for representing a realistic hot sunny day. Behavior of the IoT rules could be
influence by adding or modifying these variables.
In Cisco Packet Tracer all the variables were set to follow a 24 hours pattern.
When following the simulation time, reported in the right corner of the main simulator
page, it was possible to monitor the different level of produced electricity between night
and day, or the level of the humidity, or even the automatic triggering of the garden lamp.
The below Figure 33 represents a day time scenario. It is clearly shown that solar panels
produced electricity and charged the battery, the AC unit was on, because of the high
humidity, and garden light was off. Figure 34 then represents the night scenario, with AC
unit off, no electricity produced and garden light turned on.
54
Figure 33 - Example of equipment behavior during daytime
Figure 34 - Example of equipment behavior during night time
| 