4. 29/04/14 429/04/14 4
CURRENTMARKETSITUATION.
independent, single solutions available QIVICON – open eco-system
actuators/
sensors
hardware
backend
software
QIVICON
homebase
basic client
actuators/
sensors
QIVICON: standardized platform for the mass market.
“The time is right”
applications
stand alone
solutions
premium
solutions
Do-it-Yourself
solutions
6. 29/04/14 629/04/14 6
OURVISION.
single offerings product offerings based on the
QIVICON platform
homeappliances
mood
management
sunshadingsystems
heatingcontrol
6
7. 29/04/14 729/04/14 77
DEUTSCHETELEKOM: ARELIABLEAND
TRUSTEDPARTNERFORASMARTHOME
ECOSYSTEM.
Which is the most trusted company to deliver a smart home solution from a single
source?
Smart Home –
future chances for different
industries
8. 29/04/14 8
ANOPENPARTNERECO-SYSTEMBASED
ONTHEQIVICONPLATFORM.
QIVICON – the platform for the Smart Home
Partner-Ecosystem
B2C
Relationship
Home Base
• SDK• Portal incl. Shop
• Installation Assistant • Backend
End-Customer
Platform
Partner Solution (HW / SW)
Platform
Usage
B2B
Relationship
• Basic Control
8
Services-, Hardware Manufacturer- , Development- & Consulting Partner
9. 29/04/14 99
PARTNERSTATUS
ACCORDING TO INDUSTRIES (OCTOBER 2013).
agreed partnership agreed partnership
security, monitoring
window, door
home appliances
home automation
sales channel
lighting
health, AAL
consumer
electronics
photovoltaics
energy provider
awning, shading
* multiple mention due to activity in different industries
** grey boxes to reflect companies that do not want to be shown at the moment
others
1 X
in discussions
1 X
1 X
*
**
**
1 X
1 X
*
*
**
**
**
10. QIVICONPLATFORMARCHITECTURE.
QIVICON – Architecture
QIVICON
Platform
QIVICON UI
Portal/
Shop
Partner
Cloud
Services
At Home
Local
App
Local
App
Home Base
Local
App
§ QIVICON Home Base is the central control unit
§ Devices are connected via ZigBee, HomeMatic (popular radio
protocol in Germany) and IP (further in-house technologies can be
added – via USB sticks)
§ Apps are running locally – and can be controlled remotely
§ Backend provides
§ QIVICON UI (e.g. for pairing)
§ Remote access capabilities
§ End customer portal/shop
§ Customer support interfaces
Customer
Support
SDK
Internet Router
Remote
Apps
IP
2nd
option
1st
option
15. QIVICONSDK.
SIMPLEAPPLICATIONDEVELOPMENT.
§ QIVICON Services exposed via
RemoteAccess API
§ DeviceAbstraction, RuleEngine, EventAdmin
§ permission for external applications required
§ Common API for local access AND
access via QIVICON platform
§ e.g. for SmartPhone applications connecting
locally and via Internet
§ Reliable communication between backend /
QIVICON Box
§ Push Notification
§ WebSockets, Long Polling
§ Exposure of application services
supported
§ locally, via Internet
Jochen Hiller / QIVICON SDK Overview 15
Device Abstraction
(Home Device Manager)
RuleEngine
Application
OSGi
EventAdmin
2012-10-09
QIVICON
Platform
RemoteAccess
(Pull/Push)
RemoteAccess
(Pull/Push)
16. 20 June 2013QIVICON Developer Training
QIVICONCLIENTAPI.
USE CASES.
Connection
Management
• Discovery
• Transparent
Authorization
• OAuth2
• Basic Auth
JSON-RPC
• Backend
• Home Base
Events
• WebSockets
• Long Polling
QIVICON Client API
16
17. QIVICONANDOSGI
29/04/14– confidential – 17
§ OSGi Concepts provided to QIVICON developer
§ OSGi Framework 4.2
§ Application management (based on PAR files, predecessor of Subsystems)
§ LogService, ConfigAdmin, EventAdmin, HttpService, Declarative Services
§ Java/OSGi Security concept
§ OpenSource tools, e.g. Felix WebConsole (for development)
§ OSGi Concepts used internally in QIVICON
§ Remote Management using TR-069
§ Dynamic installation and update management of OSGi bundles
§ DMTAdmin for abstracted hardware access
§ HttpService, WebExtender alike concept
§ UserAdmin
18. SOMELESSONSLEARNED
29/04/14– confidential – 18
§ JavaSE Embedded 7 rocks
§ Security concept to complex for „normal“ developers
§ Even if simplified by QiviconManifest
§ (OpenSource) Libraries not ready for OSGi security model (JSON, GSON, Apache
HttpClient)
§ OAuth is simple, but adds some complexity
§ Platform reliability must be ensured
§ Careful Timeout/Thread handling of core OSGi services (framework, event handling, ...)
§ Review process of developer applications (automated static/partially dynamic analysis)
§ Device Abstraction: really lot of detailed work
§ Backup/Restore service needed
§ Higher-Level Platform State needed
§ HttpService from OSGi 4.2 lacks essential features (filters, listener, authn)