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.
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
The hub broadcasts all device state changes (no flow cards needed). You just need to point gBridge to the correct topics I think.
Ok… I’ll play with that and see what I can do
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’
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?
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
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
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)
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
?
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
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
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.
MQTT client is published
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
Thanks!
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?
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.
