A while ago I made a very basic survey on what’s missing in cloud part for these who wish to access openhab through such service. Few of observations did surprise me, especially the obvious and not obvious access without exposing OH ports.
My intention there was really to validate my own observations. Over time I got my own view thanks to participation in few openhab related events, after using openhab cloud and also after working for company which pretend to maintain it and running it for a while myself. All above lead me to believe that it could be improved. In order to address that and also open additional layer to serve our commercial projects several months ago we (read ConnectorIO) started working on new cloud service based on completely new principles. These principles are:
-
Interactive device authentication based on oauth/jwt tokens (instead of copying over “secret” and “uuid” to service admin panel).
This part reduces verbosity of the setup and makes it an online process based on standard (oauth 2 + device flow) which could be combined with any compatible identity provider. -
Lightweight communication transport used to integrate with cloud, without VPN or connection forwarding.
Thanks to that retrieval of latest states through applications is possible in milliseconds as it does not involve round trips. It also allows to track connection state in a bit more reliable way. - Support for access to more than just one openhab instance.
Given that for quite long time this was repeated issue of existing cloud service which also pushed less experienced users to fight with serial port forwarding, mqtt bridging or ask multiple times about master/slave setups just to overcome basic limitation imposed by existing cloud connector. -
Cloud persistence of accumulated data to reduce writes to your SD cards.
Most of setups (per earlier survey I posted back in 2018) is based on rather small computers which do suffer from stability of storage. This again pushes less experienced users into a trap of using their brand new rpi as database host which quickly turns to be a bad idea.
Obviously some of above features require rather big and managed infrastructure which is maintained and monitored. Recently we started our move to make our deployment available for wider test audience (see app.connectorio.cloud).
Early in November (2020) I’ve published on github our cloud connector which covers points from 1 to 3 (device auth, mqtt event bridge, many OH instances). If you wish to use it with your own MQTT broker and separate device authentication - feel free to use it with no obligations.
There are more things to come. From authentication and authorization point of view we introduced a notion of “organization” and “asset” which span a bit above openhab semantic model. Role of above functionalities is bilateral - both are there to improve management capabilities and wide deployments involving many buildings. Because each authorized openhab instance must be assigned to an “asset” it allows us to serve additional aggregation layer which does not involve extra configuration on the device side.
Given that we currently support read-only access (writes are on the roadmap), have limited resources to work on user interface we are looking for people who feel comfortable with API level access or wish to adopt existing openhab client applications (androd, iphone etc) to work with openid connect (OIDC)/JWT.
So far our service is invite only. Currently it requires additional setup for accounts (assigning of organization mentioned above) in order to onboard new users. If you are free with “UI-free” access and/or are able to squeeze value out of openahb API subset being online all the time please contact me.
All users - are welcome to share their thoughts on above.