Hi together,
As I finally received the hardware I’m now diving a bit into this topic.
I could not yet test @michbeck100 s plugin as I’m still on the road but I had some time for research.
As far as I have understood the current plugin it uses fake WEMO devices which the Echo can discover and switch within tho local network.
However my current research tells me that the echo can currently support max. 16 on/off switches with this method (could not test yet). Another “problem” I see is that WEMO currently doesn’t have any dimmers or thermostats which we could emulate this way.
There seem to also be other devices which the Echo can directly interface with.
- WEMO (currently used) --> Supports outlets
- Philips HUE (might be the best options for lights) --> Should support on/off, dimming, color, color-temperature.
- NEST (could not yet confirm if it works locally) --> Should support thermostat, temperature and humidity
- Others… Thermostats, Starter Kits, Outlets
Looks like the top row when checking a category of supprted devices are the ones that according to the description “work directly with Echo”
If we go this approach further we would need to emulate these devices in addition. If we are lucky there will be a hub supported directly which offers various kinds of devices ande we would only need to emulate this hub.
The other approach would be via the cloud.
I think I have not fully grasped the concept yet but my current understanding is that we would need some kind of pimatic-cloud. I think it could be a very “slim” service which basically authenticates to amazon via OAUTH2 and then asks the user to enter address, user and password or maybe some kind of token, then the requests will be mapped to the pimatic api and “simply” forwarded.
However we would have the following “problems”
- How do we secure the user secret/password/address on this service?
- I think if we limit the source for the alexa requests to amazon IP-Adresses and the fact that outh2 is used should be ok for the incoming security at first.
- Still the userdata needs to be encrypted in a way that if someone hacks the server he can’t take over all the “connected” pimatic instances.
- Who maintains it? (@pimatic-team ?)
- How will the hosting be paid?
With this cloud usecase we would not need a plugin at all. But maybe one option to take storing userdata out of the equation would be to still have a plugin which “tunnels” back to the “pimatic cloud” and keeps a socket connection alive, there we could also filter and limit access to only devices we want to have available for alexa.
Most likely the last solution is the best but it also is the most ambitious with the most effort.
- Very basic pimatic cloud
- Pimatic-cloud plugin which exposes a filtered number of devices to this cloud service and connects from pimatic side (no storing of userdata)
- Alexa skill vor mapping alexa requests to API of pimatic (or pimatic cloud but I would suggest to keep the same but filtered api) and authenticates with the cloud via OUTH2
The cloud we create in this way could later on also be extended to connect with various other webservices (IFTTT etc.)
Would be great to hear the opinions of everybody here.
Have a nice Sunday
x
. I know of all these implementations. Its just a matter of time, as always.