Quby is hardly a household name. Nevertheless, many Dutch people would have come across a smart thermostat called the Toon, sold by Eneco, one of the largest suppliers of gas, electricity and heat in the Netherlands (there were about 120,000 of these devices installed in the Netherlands in 2015).
This thermostat is a Quby product: the Dutch startup designs the hardware, runs the software and basically does everything regarding this tablet-like device.
The Toon is a little bit more than a thermostat: it also displays energy and gas usage. The device hooks into the home WiFi network and integrates with the central heating system, electricity meter and/or solar panel (so that you can check your yield). It also connects with Philips Smart LED lighting, Smart Plugs, and also exposes all of its functionality via mobile apps for phones and tablets. The apps let a user do everything from analyze a visual graph of energy usage to turn off your central heating from outside the home.
Speaking for Quby, Michiel Fokke drilled down into the workings of these mobile apps. The app connected over a secure connection to the Mobile Backend – essentially, a reverse proxy; this in turn integrates with their asset management system to figure out the device login credentials, and once this is done the app is given a live connection to the display in your home
However, said Michiel at WSO2Con EU, they had a few problems with this architecture.
One, Quby had no information on alternative uses of that API they use for the connection. Someone made a Windows Mobile app for their platform, and someone else reverse-engineered the API to write a Python framework: they had no measurements on any of these uses. Thus, they could not account for capacity or predict it.
Two, there was a proprietary login involved, which means storing encrypted credentials on the device itself.
Three, their API was undocumented and unsupported, making it difficult for them to open up their platform to third parties even if they wanted to.
When they started looking for an off the shelf solution to fit their needs, they had a wishlist: it had to support OAuth2, it had to be open source with affordable support – because they wanted to look under the hood – and it had to be extensible enough that a small team like Quby’s could innovate with it. WSO2’s API Manager was an ideal fit for this.
According to Michiel, they went with WSO2 over MuleSoft – which was the other candidate considered – because of the open source nature of the product, the ease of using it – “You can download a zip file and unpack it and just run the start script; basically you’re ready to go!” – and also because of the clearly defined pricing model for support.
The new architecture has the WSO2 API Manager sitting between the connection, the Mobile Backend, the Asset Management system and the Authentication Service. The proprietary login has now been moved into the API Manager, so that both the device app and the backend can be standards-based. A couple of additions were needed – plugin to interface with Eneco’s authentication web service and JSON web tokens to pass user claims.
“We did a pilot implementation and organized a hackathon at the beginning of March: I have to say that was quite successful – over the weekend we had 14 working apps: we had complete Windows Mobile app; we had a working prototype of Apple Watch app; and a couple of students had figured out how to use a Smart Plug to measure the energy usage of a single individual. They had created a complete portal and a web app over the weekend.”
Quite a success, we’d say.
What’s next for Quby? Michiel, at WSO2COn EU 2015, outlined plans to migrate their own apps to the new API and start using WSO2 API Manager to provide internal APIs. The WSO2 API Manager, he said, is perfectly fit for that use case, too.
For more detail, watch Michiel’s talk at WSO2Con EU here.
At WSO2, we’re constantly working on improving our products – so to see what’s new with WSO2 API Manager, drop by here.