Avior.API allows the access to Avior family devices from the Web, by means of a simple set of REST web services, to manage units through a completely open platform.
Devices belonging to Avior family are general purpose units that you can use to build your specific "vertical" solution:
Use your knowledge and our devices to bring ideas to life.
Critics of the Internet of Things say that it will not scale. Trying to support billions of devices individually connected to the cloud will overwhelm networks, slow responsiveness, and create latency that will make systems incapable of supporting any form of quick-reaction feedback and control.
Imagine for a moment that your device depends entirely on cloud computing for its operation. Commands would have to travel through the network to the cloud server and be interpreted, then back to the device. With all the switching and routing delays a typical data packet faces, there could be a perceptible pause between your action and the system's response. If the cloud server needed to receive and act on millions of such signals at a time, that pause could become quite long.
Such a pause might go unnoticed for some applications, but it would be devastating where a reliable service is required. Our solution is to have most of intelligence built into the edge devices controlling the process, whether or not the network is working.
Security loopholes can occur anywhere in the IoT.
Many smart meters, for example, don't push their data directly to a web service, they send collected information to a local data collation hub – often another smart meter in a neighbor's house – where the data is stored until later uploaded in bulk.
And it's not just security: it's privacy, too.
Placing sensitive data in insecure locations is never a good idea. Yet some early devices of the IoT incorporate this very flaw into their designs.
It's often an attempt to compensate for a lack of technological maturity where network connectivity isn't available all the time or is too expensive.
IoT devices communicate using Application Programming Interfaces. APIs are the glue that links the IoT together. If an attacker wishes to hack an IoT device, they will attack the API. Therefore, the key to securing the IoT is securing APIs.
Securing everything, everywhere, forevermore is the ultimate pipe dream, and it may not even be feasible.
The safe must be suitable to protect the content, you do not ever would use a bank vault for storing coins or a shoe box to store diamonds.
The protection should be appropriate to the asset to be protected.
Our APIs are completely dependent from device, the account is created by device, so the same is for the WEBID.
Trying to access an existing account without correct password produces no result, insisting with the wrong password will cause the account removal and it can be reactivated only from device side.
For basic application you may use the simple interface where data is transferred "as is" in the easiest possible way.
For increased security you can use the encrypted interface, device identifier and password are secured against snooping or tampering.
For many IoT products, you will need to have separate wireless adapters plugged into the wall because many of these devices works on a different kind of wireless network. It's not just WiFi, there is Zigbee, Zwave, Insteon, ISM, and more. Because devices are using different wireless networks and protocols, they need a specific wireless adapter. Now imagine having five or six wireless adapters plus your WiFi router in the house. Yes, ridiculous, and ugly, too.
For that reason our products will never require an additional wireless adapter to access the cloud.