Homey Community Forum

Guide to Connecting gBridge to Homey for Google Assistant

#1

This guide was put together with the help of @HarriedeGroot, @Camelen, @xAPPO, @scanno and others. All I am doing is collating everything below this post to help others.

First Step - gBridge
Go to gBridge.io and open a free account. (http://gbridge.io/)
With in the Account Settings you will see you username - uXXX and the connection information:

Second step - Homey Side
Install MQTT Client - https://apps.athom.com/app/nl.scanno.mqtt
Install via Hub - https://apps.athom.com/app/nl.hdg.mqtt

Third Step - Set up Connections

in MQTT Client Settings

In MQTT Hub Settings:


REBOOT HOMEY

Choose just one device for now… on the devices tab, you can add more later.

Go to settings and click broadcast once

Go back to gBridge.io and create a device

note in the above screenshot how the ACTION and STATUS topic have been amended to match what homey is sending outwards —>gBridge

Also note - the change from brightness to dim
So my light was called Front Door Lights in Homey. MQTT Hub amended that to front-door-lights and sends it out. You want to catch that on the gBridge side.

Last Step
Say - Ok, Google, Sync Devices
after that you should have something similar to this

You may need to scroll to the bottom to see them

4 Likes

GUIDE - Google Home på svenska med gBridge och RPi
MQTT Hub/Gateway
Google home/assistant + Homey 2.0
MQTT Hub/Gateway
#2

I will try to connect the gBridge to my mosquitto broker that I have on my rpi. Hopefully I can get it to work this way.

The broker works fine with 2.0 but is on separate hardware.

Well see if I might get a local version of gBridge to work as well.

0 Likes

#3

I’ll try the same tonight

0 Likes

#4

Ok I have some news, after a lot of testing.
I’m really not very knowledgeable of Linux but I am pretty good at googling. Just putting that out there to make people know that there’s probably a lot of things I haven’t thought of, managed or tried.

So first of all my setup is the following:
Homey Pro
-MQTT Client
-MQTT Hub
RPi 3
-MQTT Broker, Mosquitto

I managed to connect gBridge to my mosquitto broker by using the guide on their documentation page:
https://doc.gbridge.io/firstSteps/mqttServer.html (at the bottom)

And I also followed the steps shown on their page on how to connect Google Home to gBridge the normal way.
In my broker I saw some topics getting added. However I had a bit of a problem, homey got added like this:
homie/homey/items
while gBridge had the following:
gBridge/{userID}/items

And I had no control of the gBridge broker (i tried to install it locally but I didn’t manage. My skills ends there and I have given up on that, which means I’m bound to the gBridge service).

What I did was in the MQTT Hub i changed Root Topic and Device ID to match the things added to gBridge. And when I added the item in gBridge i put it like this:

And it actually works right now.
I have only tried a simple switch, no dimmer or anything else. But a simple switch, on/off works with google. home now without adding any flows to homey :slight_smile:

Maybe I’m flooding his server. I’m not sure actually.

2 Likes

#5

I’ve tried adding dimming possibility but I can’t really get it to work out of the box.
The value showing from homey is 0.1 for 10% while gBridge has the value 10 for 10%.

I’m not sure if this is changeable, maybe in the MQTT Hub? Is this controlled by the Homie-convention? And is this something that is chosen by @HarriedeGroot?

0 Likes

#6

@Camelen It’s not chosen by me, but by Athom. I just forward the capability values.
To overcome this problem I intend to include a ‘property scaling’ option in the hub.

0 Likes

#7

That would be great and flexible!

Edit: although it would be better if there would be a standard for this for compatibility between all devices/services.

0 Likes

#8

gBridge and MQTT-Hub (homie3) direct link for on/off devices - really easy using nodeRED.

Device ‘eating’ directly mapped to ‘kitchen-table’.
louey is the name of my Homey.

image

If you use level (dim) devices you can link their level topic with a *100 and a /100 to match with MQTT-Hub’s use of 0-1.0 in dim .

The default range of 0 - 1.0 used by Homey is powerful in that it doesn’t mandate the upper range value or the gradation involved. cf. a value like 0.98765 with 0-100 (integer ) which limits you to 101 steps and 0-100. 0-1.0 is very flexible although it doesn’t directly translate naturally to the value for things like temperatures or a 0-255 device or negative values.

0 Likes

#9

Looks very easy and straight forward.

The positive thing with my solution is that we require one less application for this to work. The great thing about having node red in between seems to be that we can adjust for every possible scenario or mismatch.

0 Likes

#10

I don’t understand how your solution works with the required dim level conversion ?
You’re requiring others to adapt to your needs.

0 Likes

#11

Right. No it doesn’t work with dim, only on/off. But MQTT Hub is getting an update that manages this. So yeah, right now dimming needs node red. On off doesn’t.

For the record. I haven’t required anything.

1 Like

#12

There’s going to be a lot of similar situations.
MQTT-Hub being a Homey app should publish capability values as Homey presents them … or it becomes a translation layer - which is not it’s role.

Until homie3 or ‘another’ defines a way of matching value ranges this is a problem that will require massage by middleware.

0 Likes

#13

I agree. That’s basically what I said in my edit above, but I am not the developer and it wasn’t my idea to do the transformation.

0 Likes

#14

@Camelen scaling percentage values to the 0…100 range is implemented on the ha branch by now.

1 Like

#15

Thank you! Is there anything else that differs with the HA-branch that could break anything? (except unforseen bugs ofcourse)
Or is the HA-branch more of an alpha of HA-implementation to the beta-branch? =)

I appreciate that you add this since I’m not very hopeful that a standard for this will emerge in a close future.

0 Likes

#16

I updated to HA-branch and now dimming works with google home by setting percentage format int. :+1::+1::+1:

1 Like

#17

I’m running into the same problem as @KonradWalsh and was wondering if anyone had made any progress yet?

  • I’ve linked my gBridge-account to Google Assistant and added a device
  • I’ve installed the MQTT Hub on Homey and configured the Root Topic and Device ID. It should send the commands in the format gBridge is expecting, e,g: “gBridge/u796/Slaapkamer_dimmer/onoff”. I can see these commands show up in the logs of the MQTT Client, which is also running.

The problem is connecting the MQTT Client to the gBridge-broker. I keep seeing this in the logs:

20190220-20:52:32 Broker not connected, attempting connection
20190220-20:52:32 Broker URL: mqtts://mqtt.gbridge.io:8883
20190220-20:52:32 keepalive: 60
20190220-20:52:32 clientID = homey_b80fc642
20190220-20:52:32 rejectUnauthorized: true
20190220-20:52:32 getLogLines called
20190220-20:52:32 MQTT error occured: Error: Connection refused: Unacceptable protocol version

I’m kinda stuck here. Any ideas? @HarriedeGroot @scanno

0 Likes

#18

As a workaround I installed Mosquitto on my Home Server and hooked it up to gBridge as a bridge. I feel like I’m really close to getting it working, but not quite there yet.

When I try to switch on Slaapkamer_dimmer in the Google Home app, I see this in my mosquitto logs

1550696457: Received PUBLISH from local.gbridge-u796-sdjlnsdbkdshjsd (d0, q0, r0, m0, ‘gBridge/u796/slaapkamer-dimmer/onoff’, … (1 bytes))

So it seems the command is sent to my broker. I would then expect a sending publish message, just like happens here

1550696285: Sending PUBLISH to local.gbridge-u796-sdjlnsdbkdshjsd (d0, q0, r1, m0, ‘gBridge/u796/toon/meter-power’, … (4 bytes))
1550696285: Received PUBLISH from local.gbridge-u796-sdjlnsdbkdshjsd (d0, q0, r1, m0, ‘gBridge/u796/toon/meter-power’, … (4 bytes))

With my basic knowledge of MQTT it seems like the command is correctly received from gBridge, but isn’t forwarded to Homey. I’m guessing Homey isn’t ‘subscribed’ to the topic. Does anyone know how I fix that? @Camelen perhaps?

0 Likes

#19

First I’d like to say that I also use mosquitto as a bridge and haven’t even attempted to connect MQTT Hub directly to gbridge.

Anyway have you tried to use MQTT Explorer? I find it to be a good debugging tool.

If you connect MQTT Explorer to Mosquitto you can see if the publish from both homey and gBridge is correct.

You can see that the topics change in real time when you make changes in both Google Home and Homey.

Try that and you could take a screenshot how the values look and show here if you need further help :slight_smile:

Edit: it’s also important to note that gbridge switches the action and status topics by default. So the action topic should be:
slaapkamer-dimmer/onoff/set

And the status topic:
slaapkamer-dimmer/onoff

Default is the other way around!

0 Likes

#20

Edit: it’s also important to note that gbridge switches the action and status topics by default. So the action topic should be:
slaapkamer-dimmer/onoff/set
And the status topic:
slaapkamer-dimmer/onoff
Default is the other way around!

Thx, switched those around.

In MQTT Explorer I only see two elements in the treeview: gBridge and $SYS. Shouldn’t Homey be showing there as well?

This is what I’m seeing in the log after starting mosquitto

1550701196: mosquitto version 1.4.14 (build date 2017-07-10 23:55:18+0100) starting
1550701196: Config loaded from mosquitto.conf.
1550701196: Opening ipv6 listen socket on port 1883.
1550701196: Opening ipv4 listen socket on port 1883.
1550701196: Bridge local.broker1 doing local SUBSCRIBE on topic #
1550701196: Connecting bridge bridge-01 (192.168.1.184:1883)
1550701196: Bridge broker1 sending CONNECT
1550701196: Bridge local.gbridge-u796-sdjlnsdbkdshjsd doing local SUBSCRIBE on topic gBridge/u796/+/+
1550701196: Bridge local.gbridge-u796-sdjlnsdbkdshjsd doing local SUBSCRIBE on topic gBridge/u796/+/+/set
1550701196: Connecting bridge kappelt-gbridge (mqtt.gbridge.io:8883)
1550701196: Bridge gbridge-u796-sdjlnsdbkdshjsd sending CONNECT
1550701196: Received CONNACK on connection local.gbridge-u796-sdjlnsdbkdshjsd.
1550701196: Bridge local.gbridge-u796-sdjlnsdbkdshjsd sending SUBSCRIBE (Mid: 2, Topic: gBridge/u796/+/+, QoS: 0)
1550701196: Bridge local.gbridge-u796-sdjlnsdbkdshjsd sending SUBSCRIBE (Mid: 3, Topic: gBridge/u796/+/+/set, QoS: 0)
1550701196: Received PUBACK from local.gbridge-u796-sdjlnsdbkdshjsd (Mid: 1)
1550701196: Received SUBACK from local.gbridge-u796-sdjlnsdbkdshjsd
1550701196: Received SUBACK from local.gbridge-u796-sdjlnsdbkdshjsd

Shouldn’t there be a mention of Homey subscribing too?

When I for instance try to switch the light on through Google Home, I see the following

1550701612: Received PUBLISH from local.gbridge-u796-sdjlnsdbkdshjsd (d0, q0, r0, m0, ‘gBridge/u796/slaapkamer-dimmer/onoff/set’, … (1 bytes))
1550701612: Sending PUBLISH to mqttjs_332f7476 (d0, q0, r0, m0, ‘gBridge/u796/slaapkamer-dimmer/onoff/set’, … (1 bytes))

It gets published to MQTT Explorer, but not to Homey. When switching through Homey I see the following

1550701771: Received PUBLISH from homey_276051ba (d0, q0, r1, m0, ‘gBridge/u796/slaapkamer-dimmer/onoff’, … (4 bytes))
1550701771: Sending PUBLISH to local.gbridge-u796-sdjlnsdbkdshjsd (d0, q0, r1, m0, ‘gBridge/u796/slaapkamer-dimmer/onoff’, … (4 bytes))
1550701771: Sending PUBLISH to mqttjs_332f7476 (d0, q0, r0, m0, ‘gBridge/u796/slaapkamer-dimmer/onoff’, … (4 bytes))

Like I said, i’m very new at this, but it seems as if Homey is only sending MQTT commands out, but not receiving them and acting on them. I’ve already looked through the settings of the MQTT Client and MQTT Hub on Homey, but can’t find a setting/option that might affect this.

0 Likes