This is the third attempt to make friends with the smart home android, I remind you that the first attempt to control android devices via HTTP, was using the Paw Server application. This application allowed using the BeanShell language to embed your code in the xhtml page and interact with it, retrieve data or manage it. To integrate with the smart home server ( ioBroker
), a driver was written, but for its first configuration, you had to manually load the scripts. Then, already through the driver, scripts were updated, which allowed adding new functions and correcting errors, but also imposed a number of restrictions in trying to deviate from the methods introduced in the Paw Server to implement new functions.
The second attempt was to build your source-based application from the Paw server. The main goal was to simplify the user configuration process, as well as add new features that could not be implemented in the previous version.
In the same version, it was decided to completely abandon the Paw server and rewrite the application and driver for ioBroker. Add new connection methods, besides the existing HTTP, also MQTT. Add more settings for the selection of events, both from the system itself and from the built-in sensors. Of course, the first thing the application will be optimized for ioBroker, but can easily be integrated into other systems.
The application allows:
- Get the status of the system settings (backlight brightness, screen status, volume, battery, etc.)
- Receive data from incoming calls, speech recognition
- Receive data from embedded sensors.
- Get location coordinates.
- Get a list of installed applications and run them.
- Manage system settings (backlight brightness, volume level, etc.)
- Make calls.
- Create notifications and "dialog" windows.
- Send text to speech synthesis.
- Interact with tasker.
- Send files to devices (HTTP only).
The appearance of the application is not final and may vary. Much would like to change or add, but all this with time.
With navigation through the application, I think, there should be no difficulties. When you first start the application briefly informs about the current changes in the new version and will offer to use the "assistant". Going to the application settings, you can change the basic work settings, select the connection type, select events to be transmitted to the server, and also allow or deny access to some data (phonebook, messages, call list and photos)
On the main screen, you can see the "tiles", while this is a trial version, but over time I plan to expand their capabilities. Of the available "tiles" at the moment, there is: a button, dimmer, time, list, color, information. The main task of the “tiles” is to send or receive data (commands) from the server or control other devices. There is no general picture of how everything should work, so I will not describe all the nuances right now.
Now, about connections and control commands, the application has two options for connecting via HTTP and MQTT. Each method has its advantages and disadvantages, which connection method you decide to choose.
This method involves connecting via Wi-Fi to a local network. The application “raises” its web server (ip-address and port can be viewed in the notification when connecting) and gives access to manage it.This can be done either directly (through the browser), or in integration with the server of the database, using POST or GET requests.
Answers from requests will be returned in JSON format, in the response body the device name, ip address and command status are transmitted. Some requests call for an additional “callback”, for example, when sending text for speech synthesis, the application will send a request to the server to start speaking the text and its completion. In the same way, the application transmits data about events and indications of embedded sensors to the server. Therefore, to complete the work, it is required that the UD server is able to handle them.
The MQTT protocol is quite popular and supported by various CA systems; this makes it easy to integrate the application into them. When choosing this connection method, you can use both local and external MQTT broker.
When connecting to the MQTT broker, the main branch /PAW/
is created, followed by the name of the devices (for each device it should be its own), which in turn are divided into two branches of the topic /info/
, from the name you can guess that the info (information) branch publishes all incoming information from the device, and the comm (command) branch contains topics for managing it. This is done for clarity, to better understand which topic is responsible for what.
Also in the main branch there is /all_devices/
in this branch there are topics on which all devices subscribe, which allows you to manage all devices at once.
For universality, in those topics whose values can be true (true) or false (false), they can take on different values, that is, 1, on, auto, true
is the true value, and 0, off, false, manual
is false. Another feature of the application is that to verify the execution of the command, if it is successful, the same topic is published null. And if the value after publication has not disappeared, it means that an error occurred while executing the command or the value does not correspond to the correct one for this topic. For example, if you change the volume level, if the value does not match the number or goes beyond the maximum, for this type of volume level, it will return an error.
Also in this version, the set of commands for notifications and “dialogues” has been expanded, they allow you to display more detailed information and also interact with the user if the device is used as an informer. When constructing them, a large number of parameters are required, therefore it is necessary to publish the value in the corresponding JSON format in the appropriate topic.
For notifications, the topic /comm/notification/create
(below is an example of the value)
"noti": "Any text",
"title": "Title 2",
"info": "Any text",
For “conversations”, the topic is /comm/notification/alert
. The response from the "dialogs" comes in JSON format and is published in the topic /info/alert/response
"alert": "Turn the lights off?",
Embedding into the application the ability to work through the MQTT protocol, I just wanted to simplify integration with the system and get rid of writing a separate driver.But some functions cannot be implemented via the MQTT protocol and for this reason we cannot do without a driver.
The structure of driver objects is similar to the structure of MQTT, and is also divided into two branches /info/
, has similar commands for managing and the same reaction to incorrect data. I will not describe the driver setup and operation here, all relevant information will be updated on GitHub
Regarding the management of system settings (backlight brightness control, waking from sleep, etc.) - different devices will react differently, or not respond, to commands. Due to the wide variety of devices, SDK versions, firmwares, it is difficult to set one model behavior per command. Here you need to select the action according to your device, for example, for most devices turning off the screen (send it to sleep) just change the timeout for the backlight, but on some devices it will not work. The same situation is with other system settings, for most devices changes will occur immediately, but for others it is necessary to send the device to sleep and then wake it up so that the changes take effect. The smallest problems of this kind arise with the SDK 19 (Android 4.4), but this is not accurate.) Just do not forget that there is support for Tasker, and if you lack a function, you can add it and interact through the application.