[Question] Is there a way to link Google Home and/or IFTTT

[DexLuther]

WinHue version : 3.0.4334.0
Bridge api version : Not Sure how to check that.
Light model : Phillips Hue Lights (Model ID: LCT016)

I found Winhue while looking for ways to control my lights from my PC and looking for a replacement for Stringify.

Winhue seems really powerful and useful already, but there's a couple questions I haven't been able to answer.

Is there a way or are there plans to link Google Home/Assistant and/or IFTTT?

With Stringify with a little IFTTT mixed in I used to have a number of Flows that were triggered through custom voice command VIA IFTTT. I would love to be able to recreate them.

[Hyrules]

No and no. There is no way to use WinHue with google home nor IFTTT. You can connect google home directly to the bridge and IFTTT. There has been really few request to implement MQTT. There is a feature request further down in the forum but I might or might not implement it at some point. Anyway it's not in the short term plan at the moment. It might change in the future if I receive more request but note that i'm the only main dev on the project (thanks to Banksio who's helping me with the site and images and is helping to get the theming working in his free time and as a side project) and I do so much as I can in my free time and when I feel like it. I know some people have had success in the past using WinHue keyboard shortcuts command triggered by voice with the help of some 3rd party app and I know that you can use Node-Red to program flows easily. I use it with Home Automation.

[banksio]

👍 I second Node Red, it's great with Home Assistant and they're basically designed to be the answer to your questions. I actually run them in Termux on an old Android tablet. Bit of a learning curve, but it's worth it.

[Hyrules]

I will implement à MQTT client. I don't know how long it will take though.

[Hyrules]

If I am to implement a MQTT client into the app I will need some kind of input on how you would use the client. #11 was the reference I was talking earlier. @SyBernot might also want to have an input on this.

[SyBernot]

Node red is awesome.

So MQTT is a messaging protocol with channels, subscription and publications.

Imagine a room with a loud speaker, you broadcast to a room (publish to a channel) and and anyone in the room (subscribed to the channel) hears the message. The channels are essentially like a URL or path. I haven't revisited this in awhile because much of my at work development around MQTT is rock solid and still just works after a couple of years of setting it up.

Essentially what I was envisioning for winhue was a subscriber to a MQTT channel that would pass the message along to the HUE bridge. There may be a few ways to do it like listening to a winhue channel or listening to something like home/+/lights then relaying the on or off or color or light % to the appropriate light or in the case of the winhue channel firing the right action or scene.

The way I use it at work is for storage telemetry
I have servers publish to server.name/storage/size
server.name/storage/state
server.name/storage/alarm

Then I have other applications that subscribe to the channels +/storage/alarm and forward the message via slack or email, another app subscribes to +/storage/state and +/storage/size and updates a web page.

There's really no right or wrong way to do it, you just need to think a bit ahead and not paint yourself into a corner when your devising how you want your channels to be. On your end though you could just make that bit configurable and leave it up to the user.

I made extensive use of MQTT.fx when I was doing all my MQTT stuff at work and needed to debug.

[Hyrules]

so for example for a light this message would be something like

light/1/state/bri for brightness and the value would be the message.

Working on this right now. I was imagining the gui for this. Somehow would you subscribe to the channel and the client would do the rest of would it be better if you chose the action ? Otherwise I would have to invent a MQTT to WinHue kind of language / url system.

[SyBernot]

I think the easiest most flexible way would be to let the user configure what topics to subscribe/publish to and also what actions to perform/watch.

If a user subscribed to light/1/state/bri
then the action could be configured to set brightness of light1 to $msg% but they could also decide to subscribe to rooms/living/lights/state/bri and have an action of set all_livingroom lights to $msg%

If the brightness state of the living room light changed then you would publish to that topic instead keeping the state of the bridge and the state of the MQTT channels in sync.

Not everyone is going to decide on the same structure of their topics and you can get a lot of bang for your buck with a well structured system
i.e. turn off all the lights in all the rooms
publish "off" rooms/+/lights/state
turn on all the things in the bedroom
publish "on" rooms/bed/+/state

[Hyrules]

It's quite interesting although I have to somehow convert the message received to a message WinHue understand. I have somehow to analyse the payload and convert this and pass it to the bridge. The subscription channel I can let the user choose without any problem. Introducing some kind of variable add a level of complexity to the client.