[feature] Add support for Fan about node-red-contrib-nora HOT 15 OPEN

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.

from node-red-contrib-nora.

I was thinking of adding a predefined list and the user can choose which ones are supported and to what values they map.
Like: low, medium, high, max and the user could choose to map to 30-50-70-100.
Not really sure how it would be most useful.

from node-red-contrib-nora.

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.

from node-red-contrib-nora.

Yeah, the problem is that you also need to provide translations for multiple languages and that would make the configuration a hell.

from node-red-contrib-nora.

Good point....

from node-red-contrib-nora.

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:
https://developers.google.com/assistant/smarthome/traits/fanspeed

I would actually really like this. and if you're still interested I could start working on a PR to add fan support in.

from node-red-contrib-nora.

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!

from node-red-contrib-nora.

@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?

from node-red-contrib-nora.

@rgerrans that would be super helpful

from node-red-contrib-nora.

@CapnScabby
No problem, anything to help. I only got as far as working on the nora-services files (thought I had worked on the nods as well but was probably trying to still think through how to handle the lo/med/hi configuration). Not sure if they will be helpful or not given that focus.

Here are the files I was working on (.txt added so I could upload them):

• nora-service\src\models\index.ts.txt

• nora-service\src\models\fan.ts.txt

• nora-service\src\models\states\fanspeed.ts.txt

from node-red-contrib-nora.

Great I will start taking a look at this

from node-red-contrib-nora.

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:

1. When the user goes to the node red front end, they can configure a new "Fan" Device, and when they configure the Fan device they will need to select the speeds supported from a list which will contain something like:
   ["S1", "S2", "S3", "S4"] (similar implementation to how users can select the thermostat modes)

2. Additionally, they will be able to select if the device supports percentage based speeds. If it supports percentage based speeds, then we will update the device on the nora-service side so that it sets "supportsFanSpeedPercent" to true on the google home side

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:
"speed_values": [{ "speed_synonym": ["low", "speed 1", ... ], "lang": "en" } , … ] },

I propose that we don't let users create arbitray modes. I suggest we support S1-S4, with speed_synonym of speed N as well as map of S1:low S2:medium S3:High S4:max

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)

from node-red-contrib-nora.

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

from node-red-contrib-nora.

This sounds like a reasonable approach. Thanks for moving it forward.

from node-red-contrib-nora.

@rgerrans @andrei-tatar so this took ages longer than expected, but I have the PRs ready to go for the back end:
andrei-tatar/nora-service#34
andrei-tatar/nora-common#2

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)

from node-red-contrib-nora.