Being able to say « Ok Google, turn on the lamp, » which will send a message to Gladys to turn on this lamp.
https://github.com/GladysAssistant/Gladys/pull/631
Blocked due to lack of specifications / reflection.
Being able to say « Ok Google, turn on the lamp, » which will send a message to Gladys to turn on this lamp.
https://github.com/GladysAssistant/Gladys/pull/631
Blocked due to lack of specifications / reflection.
@pierre-gilles let’s discuss this here.
The Google Home and Smartthings services will allow Gladys to synchronize with known apps, particularly Google’s voice assistant, which understands us quite well. Today, on v3, I already control my devices with Google Home, but I have to manually scan new devices.
With v4 and OAuth, it would be wise for Gladys to manage the devices available in Google Home.
Once the OAuth connection is established, Gladys will convert the devices it knows into Google devices (a feature mapping) in order to take control with the voice assistant or mobile app.
We can even go as far as streaming camera video.
And in the Gladys Plus version, offer an integrated configuration, with a module in Google for Gladys (because for a personal account, you have to create your own Google developer account to enter the OAuth parameters).
Today, I am already able to capture updates on devices, I just need the creation and deletion of devices to stay as up-to-date as possible.
Got it! Thanks for the explanation ![]()
Indeed, in this case, a global « device created » event makes sense
Hello @AlexTrovato! I saw that you made progress on the PR, can we discuss here what your PR does?
I noticed that in the documentation you encourage the user to make their Gladys instance public on the internet.. Up to now, « making your instance public » is a concept that we don’t have at all in Gladys v4, and I don’t even know if it’s a concept we want to add.
In terms of UX, it’s really terrible and it means we would go back to all the pitfalls of v3 (self-signed https, opening the box ports, hacked instances, etc…). These are concepts that even for a tech person require initial time investment, maintenance, and technical skills.
I think there is a real reflection to be had on all this.
Could you start by describing the general flow of this service to me? And see if we could do without it ![]()
Hello @pierre-gilles,
Indeed, for this topic, I think there will really be 2 use cases: the expert mode with the drawbacks of the v3, and the Gladys Plus mode, turnkey.
I tried to make a small document (not perfect) to try to describe what is happening, what is designed with the ongoing PR, and a potential solution with Gladys Plus.
If you have trouble accessing the document, let me know.
But I think it will soon be « essential » to offer integration with Google Home / Alexa / Siri / SmartThings.
Well, exactly, is the expert mode with the flaws of v3 necessary? Can we do without it? That’s my question
Actually, for me, Gladys Plus users in the long run will represent 20-30% of Gladys users in general.
So that would mean that the majority will not use Gladys Plus (it’s normal, it’s the same with any freemium/premium product).
I find it a shame that these users have a terrible/buggy/very complicated experience, when we position ourselves as a « product accessible to all/no command line/no programming skills/etc… » product.
Frankly, self-signed HTTPS + port opening is a nightmare ^^
I’m afraid that, as a result, the forum/complaints will become like v3 if we make the same technological choices as v3.
Edit: And for me, we can’t talk about « expert mode ». The average Gladys user (the majority) will want Google Home, and won’t pay for Gladys Plus.
I share my opinion
It’s a bit of a general question. And expert mode doesn’t mean anything.
Yes, with Gladys Plus
It’s the user’s choice to take the complicated or simple path. Too many constraints aren’t good either. It’s up to us to say, here you take the complicated path, you risk this etc… We can make it complicated for the bearded ones but quality too. The end user isn’t a 3-year-old child either.
This will be an endless debate, but I think it opens doors and more users/developers.
And I mention this as an example
=> Amazon Alexa - Home Assistant
=> Google Assistant - Home Assistant
Of course! After that, I also want to encourage good practices for the majority of installations.
For now, all our integrations work without opening the ports of your box, I find it a shame to have to put all this process in place with its constraints just for these integrations.
I know that Home Assistant does it this way, and precisely, it’s not necessarily a good example.
They had many instances hacked because Home Assistant instances are listed on Shodan… I try to think about the end user and see the best and most secure option ![]()
It’s rather an open debate on possible alternatives to make the best choice.
The thing is that most third-party systems need an entry point on the Gladys instance.
For the certificate story, Docker could handle it, and for opening the port, most boxes allow opening from the local network with a bit of magic, but it remains an obvious flaw.
I’ll see if Google offers alternative modes, but I’m rather pessimistic on this point.
Or, are alternatives like using IFTTT good or not convincing?
Otherwise, we’ll do as you suggested @AlexTrovato, but indeed:
Using IFTTT doesn’t solve the problem; the external service, whatever it may be, still needs to send a message to Gladys to turn on the light. Therefore, the issue of exposing Gladys to the wider Internet remains.
Indeed!
Well, I guess we don’t really have a choice… ![]()
However, you can dockerize the cron job for certificate generation, offer dynamic DNS, dynamically open a port on the internet box… do something « complete » and force the request to open the network from Gladys, so that it is done voluntarily by the user.
@AlexTrovato indeed, in my opinion there is some development work needed before we can propose opening the instance on the internet
When you talk about a certificate, we agree that we are talking about a domain + a real certificate with something like Let’s Encrypt, right? (not self-signed)
I completely agree that we need a complete solution before proposing this ![]()
As for Let’s Encrypt, I use it on Gladys Plus and many other projects: nginx-proxy + nginx-proxy-lets-encrypt-companion
Two Docker containers that handle HTTPS for you and forward traffic to your instance
Hello,
On many projects I use traefik it’s rather nice when you want to manage this kind of thing (docker container, certificate).
Indeed, Traefik, or even simpler: Caddy
To get back on topic, there are several steps:
Hello everyone!
I worked today on this integration via Gladys Plus ![]()
I finished the entire OAuth 2.0 part, here’s what happens:
Step 1: In the Google Home app, click on « + »
Step 2: Click on « Setup device »
Step 3: Click on « Works with Google »
Here there will be an official « Gladys Assistant » application (here it’s the [test] Gladys application at the top)
By clicking on the application, Google will redirect you to Gladys Plus:
Once you accept, Google Home will receive an access_token/refresh_token to access Gladys Plus, and you will find your devices in Google Home:
You can control your devices via the Google Home app, or via Google Assistant whether on your phone, Google Home, etc… ![]()
@AlexTrovato I used the work you did for the local part:
The only difference is that the requests are proxied via the Gateway.
All devices? Even the ‹ Home made ›, Tasmota etc.?
Absolutely everything
Even 100% home-made.
What happens is that Google Home asks Gladys for the devices that Gladys manages locally, and Gladys returns a list of all the devices and their features.
Then, when you control a device in Google Home, Google sends a request to Gladys with the Gladys ID of the device to control, and Gladys takes care of the rest!