-
Notifications
You must be signed in to change notification settings - Fork 25
[feature] Add support for Fan #7
Comments
I started to work on this over the weekend basing it off your Light code. Unfortunately it looks like the way Google implemented this is to get specific named settings from the fan (S1, S4, Min, Max, etc) rather than being able to send a % value, with the intent that the voice command would refer to the named value. We might be able to map it in increments of 10% as a middle ground or just focus on the on/off part? I just mapped mine to switches for now and am ignoring the speed changes. |
I was thinking of adding a predefined list and the user can choose which ones are supported and to what values they map. |
I like that approach. Following that thought process you could actually let the user do mapping of both the key words and values. Maybe start with the defaults you identified but let them override them / add add'l ones for maximum flexibility. |
Yeah, the problem is that you also need to provide translations for multiple languages and that would make the configuration a hell. |
Good point.... |
Hi. coming out of nowhere on this one, but it looks like the google fan speed settings look like they support percentage fan speed now: I would actually really like this. and if you're still interested I could start working on a PR to add fan support in. |
Please do! |
@CapnScabby If it helps jump start it, I did start putting together the base files a few months ago around the lo/med/hi approach. Happy to share those if they help? |
@rgerrans that would be super helpful |
@CapnScabby Here are the files I was working on (.txt added so I could upload them): |
Great I will start taking a look at this |
So I have imported the files you sent over, and am partially set up in both nora-service and node-red-contrib-nora To clarify on the end goal/implementation:
If a user wants to map the speed modes ("S1", "S2"), to percentages, then we will leave them to do that in their own device code. For the supported speeds, the google home side allows the speed names to be whatever the user defines, and they expect each speed value to have some additional meta data: I propose that we don't let users create arbitray modes. I suggest we support S1-S4, with This will be a little bit limiting in terms of the voice integration, but I think that if the user wants more fine grained control they will still be able to use the percentage based implementation. Some fans support things like swing, which would be cool to to have, but I don't see a way to control that in the google device traits (may need some more digging), but I propose for the first implementation we only support on/off and the speeds as described above (though I definitely will want swing/oscillation control in the future) |
For the first implementation I will also only put in english support for the speed synonyms, and leave a not in a comment explaining how to add in other language support |
This sounds like a reasonable approach. Thanks for moving it forward. |
@rgerrans @andrei-tatar so this took ages longer than expected, but I have the PRs ready to go for the back end: Please let me know if there are any other changes you want. I am not very familiar with type script, and I included the node.js server code that I used for testing the fans (which can be removed I suppose, but I thought it might be helpful for the review process) |
https://developers.google.com/actions/smarthome/guides/fan
The text was updated successfully, but these errors were encountered: