# Thinger.io: An Open Source Platform for Deploying Data Fusion Applications in IoT Environments
## 5 A Case of Use of Meteorological Information Service Modeling
### Modeling Devices  
In this section, we will show how to model the behavior of physical devices so that they send the information to their corresponding data bucket. In this way, once the platform has been configured to support the connection of a new device, and a data bucket has been created to store the data, it is necessary to program the device to connect to the platform, read the information of the sensors, and write in the data bucket. The programming of the device will be done through the Arduino environment, for which it is necessary to carry out some adjustments to use the ClimaStick libraries, and allow the programming of the ESP8266 microcontroller on which it is based. This initial process is documented in detail within the platform documentation at [[http://docs.Thinger.io/hardware/climaStick/](http://docs.Thinger.io/hardware/climaStick/)]([http://docs.Thinger.io/hardware/climaStick/](http://docs.Thinger.io/hardware/climaStick/)) (in the environment configuration section), and it is similar to the process of adding any other board within the Arduino environment.  
We only need to model the Climastick device in order to send the information to the data bucket that we have defined in the Thinger.io platform. The way to model is through the simple programming language incorporated in Thinger.io and it has been described in the previous section (Figure 21).  
Figure 20: Data bucket configuration in Thinger.io.  
In this code example, the following parameters are being defined:  
* **USERNAME** It is the username that we have chosen in the process of registering our account.
* **DEVICE_ID** It is the identifier of the device that we use in the registration process, in our example 'climastick'.
* **DEVICE_CREDENTIAL** It is the credential of the device that we use in the process of registering the device, in our example h4 Pxg!a!a!a!DEX.
* **SSID** It is the name of the WiFi network to which the device will be connected; the one used in this example would be 'Meeble'.
* **SSID_PASSWORD** It is the password of the WiFi network to which the device will be connected, which would be 'MeebleLabs' in the example.  
With the USERNAME, DEVICE_ID, and DEVICE_CREDENTIAL parameters, a variable called thing of type ClimaStick is being initialized, which represents our device, on which we can configure the WiFi connection, as well as read the information from the sensors. Subsequently, within the Setup method (which is executed only once at the beginning of the program), it is being done:  
* [noitemsep,topsep=0 pt]
* Initializing the WiFi connection of the device with the SSID parameters, and SSID_PASSWORD through the thing.add_wifi method.
* Initializing the sensors of the device through the call init_sensors ().
* Defining a resource within the device called Environment, which will contain the meteorological information that we want to store, which in this case is temperature, humidity, altitude, pressure, and luminosity.  
Finally, within the loop method, which is executed indefinitely, after the setup, the following is being done:  
Figure 21: An example of modelig a device in Thinger.io.  
* The management of the connection of the device to the platform through the call thing.handle (), where it checks whether the device is connected to the Internet, authenticates the device, and keeps it connected when necessary.
* The writing of the Environment resource defined in the setup, to the MeteoBucket data store previously registered in the platform. For this, the thing.write_bucket () method is used.
* Pause the device for a certain period of time (in this case, 1 minute, but can be adjusted as necessary) through the thing.sleep () method. This method does not delay the execution of the next iteration; it basically sleeps the device, the sensors, and the wireless connection radio. The device restarts after the specified time. In this way, the device can be powered through a battery.  
In Figure 22, a screenshot of the console of Thinger.io is shown with the values that have been stored by each of the declared resources.