Did you test with the production Google Home integration on Gladys Plus?
Can you confirm that you ran the Docker image at home and that you were able to control your roller shutters (for real) from the Google Home app?
I tested it at home, and I can’t get it to work 
Bizarre …
I managed to do it: through my Google Home mobile app, via Gladys Plus, I sent a message that changed the position of a fake MQTT device of type curtain.
However, part of the Google Home integration will certainly need to be reviewed, because during this test a message was sent for curtain but also for the shutter feature on the same device, which generates an error in the logs and can cause confusion.
On Google’s side, curtain and shutter are under the « trait » OpenClose, so one Google feature is mapped to two Gladys features.
I may be doing something wrong — here’s what I see in the Google Home app:
Clicking does nothing.
Hmm not great indeed.
Did you try a « long press » on the « shutters » device from Google Home? For me it opens another panel with only 2 buttons « open/close »
Actually I think there might be a problem in the case where the feature « position » is only an indicator, and not an actuator!
We may need to dig deeper.
I’ll revise my draft.
No, it’s not a sensor! The control works locally
[quote="AlexTrov
Uh, it seems to me that I did indeed have the state change (behind it is Node-RED), but I needed the state change to trigger my actions on the Node-RED side.
Ok, maybe I’m the one who did something wrong then…
@AlexTrovato if you need any information, let me know 
@AlexTrovato I’m wondering if it was just me having a weird issue — if @spenceur confirms he tested it in a real environment and it works for him, we can merge, I think. What do you think? Did you have a fix in mind or not at all?
I’ve reread Google’s specs, and my developer wasn’t 100% correct.
I can redo the minimum so that it gets the job done, and refine the details later to unblock things. Or redo it properly but I can’t give a date for that.
In any case, my initial developer wasn’t correct. So we’ll need to retest once the fixes are made.
(after, if my first draft does the trick, we’ll go with that - changes and rollback on my PR -, and I’ll fix it later; since there’s no DB manipulation, the risk is low)
Whatever you feel like, tell me
I’ll make some changes, at least to follow Google’s specs.
Not all of Google’s features will be implemented, but at least we’ll be compliant.
I’ll get back to you when it’s ready.
I can try again, but I don’t know when on my end.
However, I’m surprised by the small number of testers given the number of posts where people have roller shutters ^^’
@pierre-gilles I improved the UI handling on the Google side by setting the correct attributes.
However, I think we have a bug here Gladys/server/lib/scene/scene.actions.js at e8bba476dcc880f2d38ca52279a6117c8ecf8b3d · GladysAssistant/Gladys · GitHub when the value = 0.
because when I close the shutter (value = 0), I get this error
2023-05-05T15:09:16+0200 <warn> scene.executeSingleAction.js:19 (SceneManager.executeSingleAction) There was an error executing action device.set-value
2023-05-05T15:09:16+0200 <warn> scene.executeSingleAction.js:20 (SceneManager.executeSingleAction) AbortScene [Error]: ACTION_VALUE_NOT_A_NUMBER
at Object.device.set-value (/home/alex/Gladys/server/lib/scene/scene.actions.js:63:13)
I’ll try a fix (and add a test), but I’m wondering whether it should be put in a separate PR.
EDIT :
proposed fix https://github.com/atrovato/Gladys/pull/77/commits/3baf53d8b42fc658466a5cf3168d969e82e19d3a
EDIT 2 :
a brand new docker image is ready
Tested with an MQTT device 
Small constraint, the feature only handles the « position » on shutters/curtains (in read only or read/write), and does not yet handle the « open / close » buttons.
Hello I suppose that’s because of the set to 0 you mention in your message?
Or is it because Google doesn’t send a negative value?
If I remember correctly 1 open 0 stop -1 closed, right?
@spenceur not exactly.
On Google’s side, everything is handled the same way, whether it’s the position as a percentage or simply the open/closed state (attribute discrete).
We, we have 2 features, so we’ll need to be « smart » on our side to know which actuator to use as soon as a message is received from Google, depending on the features and their attributes (ex. read_only) on the Gladys side.
But here, for the sake of simplicity, I simply took into account the feature « position » (percentage of opening/closing).
The more I progress on the GoogleHome part, the more I realize that some optimizations will be needed for this area.
For the moment, given the discussions here, I’m pushing this change through, but a major effort will come for GoogleHome, and very likely support for new devices.
I’m not sure I’m being clear.
Very clear to me in any case 
(after all, I’m a dev too, but your message isn’t « too » technical so it’s understandable for others)
Thanks for the answer
@AlexTrovato I was going through PRs this morning, just checking the status of this one?
As far as I’m concerned, we’re fine for the minimum required.
I haven’t received any feedback from other testers, so only my tests are considered valid.
I just tested it, and this time it works perfectly Well done 
I’m merging!