This version adds Realtime readings from the Android App (Mobile client). Compared to the previous version, where readings in the LCD and the Mobile phone where not sincronized (due to the Firebase Cloud Messaging latency), in this video and product version we can see how they are showing the same values all the time. (The only delay is due the fact that we are sending readings to the cloud every five seconds, thus the Mobile App updates the readings every five seconds also. This is not a problem since actually reading a Bluetooth Low Energy sensor in a loop takes seven seconds for each).

This version adds Realtime readings from the Android App (Mobile client). Compared to the previous version, where readings in the LCD and the Mobile phone where not sincronized (due to the Firebase Cloud Messaging latency), in this video and product version we can see how they are showing the same values all the time. (The only delay is due the fact that we are sending readings to the cloud every five seconds, thus the Mobile App updates the readings every five seconds also. This is not a problem since actually reading a Bluetooth Low Energy sensor in a loop takes seven seconds for each).

This is the first prototype. In this one there is still no connection with the cloud. It just binds a service with each of the Bluetooth Low Energy sensors, reads the temperature and displays it on the screen. Later project revisions improve this and send the temperature / sensor readings to the cloud).

At present stage, the project counts only with the IoT part, beeing a hardware with LCDs that connects to the sensors.

Moving on, the project will let set the on/off swiching of the heating system based on the temperature at different sensors. For example at night the relevant temperature will be at the bed room and during the day at the studio or living room. Using pushbuttons the user will define at what point of the day her/his preferences change and these will be taken into account when creating a custom machine learning model. On following days similar temperature changes will lead to related confort temperatures in the house leting the system adjust the temperature switch trigger in a smart way, not just by defining threshold levels at different points of time, but leting the user define behavious over time.

Even it is obvious that one display could do the job to display the readings of three sensors it was decided for clarity purposes to associate one LCD to each of the BLE sensors. The extra cost of this seems at the design phase paid off by a better user experience. It is for this reason that the design uses three displays instead of one, making clear to the user which display reflects information of which sensor.

An Android Things app driving General Purpose Input Outputs (Gpio) to display data on three external 16x1 LEDs and connecting to an undetermined number of Bluetooth Low Energy (BLE) sensors to read their sensors.

On top of the standard Android Things architecture it was needed a driver for the LCD, seting the Register Selector (RS) signal and the Read / Write (RW) one to select the operation to perform by the LCD.

The LCD display is built in a LSI controller with two 8-bit registers, an instructions register (IR) and a data register (DR). The IR stores instruction codes, such as display clear and cursor shift. The IR can only be written from the MPU. The DR temporarily stores data to be written or read from DDRAM. When address information is written itno the IR, the data is stored into the DR from DDRAM. By the register selector (RS) signal, these two registers can be selected.

This is an old type of LCD superseded by 2, 3, 4 and more lines LCDs that lacks some clarity in the documentation available. The instrucutions available were not matching the LCD behaviour and required to model the behaviour of the hardware with some trial / errors..

BLE sensors use a client-server model where each sensor gets linked to the Android App with a bound service. Having three sensors requires to bind this service for each of them every time that we want to make a reading. Different alternatives have been considered, like having three services ruuning and just binding a service to each of the sensors.

This approach has been rejected since the mobile phone has only one Bluetooth Low Energy driver and use it to connect to multiple servers would have required an apparently too complicated architecture and software programming.

The alternative has been to connect the service to each sensor every time we wanted to make the reading. This is from a time perspective not an issue, since we can have multiple readings per minute for each of the sensors. Nevertheless it is considered that other approaches could save battery and they shall be considered at latter stages of the project.

The sensor tags used were purchased in year 2014 and can not be reflashed with an updated firmware. Two of the sensors count with one Firmware verson and the other one with an older one. After some headaches it has been found out that some Bluetooth connection issues were not related to the Software running on the client, but running on one of the sensor tags with the oldest firmware revision. The work around has been to restart the sensor tag every time the connection was lost and this worked well with the rest of the solution.