Homey Community Forum

MQTT Hub/Gateway

#386

I’m waiting for athom to approve the update to MQTT client. When that’s done I’ll try to bypass my mosquitto server and make a direct connection to gBridge.

My expectation is that it will work with no adjustment to MQTT Hub. But before I’ve tried I can’t be sure.

0 Likes

#387

I installed @scanno new version in github. Yes gBridge connects now and I can capture things using flows. I cant figure out how to send changes to keep gBridge status updated but nonetheless gBridge does connect to the new MQTT Client

0 Likes

#388

The hub broadcasts all device state changes (no flow cards needed). You just need to point gBridge to the correct topics I think.

0 Likes

#389

Ok… I’ll play with that and see what I can do

0 Likes

#390

You can’t alter how gBridge organises it’s topics so you have to alter how MQTT-Hub sends them by setting the ROOT topic to gBridge and your DEVICEID to your gBridge userID.
e.g.
gBridge
u123

This is within the homie3 spec but possibly means devices won’t be discovered by apps like openHAB as they expect a root topic named ‘homie’

0 Likes

#391

I didn’t know that openHAB expects “homie” to discover.

But you should be able to add it manually to openHAB by specifying the correct root topic and deviceid right?

0 Likes

#392

Indeed if you can configure the root topic in openHAB that should work otherwise the default would be ‘homie’. The userID should be OK as is.

I’m assuming gBridge allows creation of all the other sub topics. Using the gBridge MQTT broker creates a cloud dependency of course which slows things down. Bridging a local broker would be my recommendation.

Ahh no… (gBridge does not support the homie3 spec). Instead you will have to manually create the devices through gBridge. It just means that the status and control topics are linked.

Also the default topics gBridge suggests are misleading - the /set subtopic should be on the Action topic not the Status - there is more info 4 posts below and also in the gBridge thread in this community

0 Likes

#393

Meaning… gBridge will then auto create the relevant devices? I am doubtful because it didnt work for me… but I might have done it wrong… maybe @pkappelt can chime in here

0 Likes

#394

No gBridge will not auto create devices. You need to create each device yourself.

Edit:
But for this to work you need to set the correct ROOT TOPIC and DEVICEID in MQTT-Hub.
And those values are chosen by gBridge and should be as xAPPO writes
gBridge
u123 (exchange 123 to your username)

0 Likes

#395

so if I have a device in Homey called
Window Lights

I would create a device in gBridge called Window Lights and set the topic to be /window_lights/onoff

?

0 Likes

#396

In that scenario you would:

Create a device in gBridge, the name of the device is not important in the connection to Homey but should be chosen to something you’d like to say.

After it’s created you go into the device and edit the ACTION topic and STATUS topic

ACTION topic (for onoff capabilities) should be:
/window-lights/onoff/set

STATUS topic should be:
/window-lights/onoff

0 Likes

#397

so I did this in GBridge

Light: Window Lights
Features and MQTT-Topics:
On and Off
gBridge/u***/window-light/onoff
gBridge/u***/window-light/onoff/set

Brightness
gBridge/u***/window-light/brightness
gBridge/u***/window-light/brightness/set


in MQTT Hub I have

COMMUNICATION PROTOCOL - Custom
ROOT TOPIC = gbridge
Device ID = my u*** id from gBridge
Include Class and Include Zone unticked or off

I hit the switch in Homey and it doesnt replicate to gBridge

0 Likes

#398

This might be better followed up in the gBridge thread … or a new one - MQTT-Hub isn’t a factor here.
If you’d like to open a new thread I’ll see if I can help.

1 Like

#399
0 Likes

#400

MQTT client is published

1 Like

#401

I might have found a little bug, when using the boolean true (in configuration.yaml), the conversion to string makes the T a capital letter. if this is already a known issue, then i’m sorry. when using the string “true” everything is working as expected.

using:
Gateway: v.2.2.1
Client: v2.2.1

0 Likes

#402

@HarriedeGroot
Sent you a small donation for the use of your app

0 Likes

#403

Thanks!

0 Likes

#404

@HarriedeGroot

Been following this topic for a while, looks very promising and rapidly developing! I was wondering if the birth and last will messages can be used to trigger a flow? Eg, when a light bulb is switched on through a physical switch?

0 Likes

#405

Birth & last will messages are there to indicate if the hub is running or not. It’s a message like any other, so yes you can trigger a flow by using the flow cards from the MQTT Client app. I don’t understand your sample, but to be clear, you cannot turn the hub on or off by publishing to these topics.

0 Likes