Guide to Connecting gBridge to Homey for Google Assistant

Devices
41

curious… the site says its specifically requires TLS 1.3 minimum

42

Then they are crazy. TLS 1.3 has just been approved.

43

I am wrong… i mixed up protocol and tls and read 3.1 backwards

this is what I read

Server: mqtt.gbridge.io
Port: 8883
MQTT Protocol: Version 3.1.1 and 3.1 supported
TLS: TLS V1.2 is required
Authentication: required, as described above
44

And that is exactly what the MQTT client supports

45

Ill reach out to them and check … maybe the error message is ambiguous

46

Isn’t there anything in the gBridge logs?

47

They arent visible

I opened a thread over there

48

Seems there are some comparable issues. But no solution.

49

Also tried to connect to gBridge from the client and got this:

20190221-13:36:17 MQTT Reconnect
20190221-13:36:17 Broker State: RECONNECTING
20190221-13:36:18 MQTT Closed
20190221-13:36:18 Broker State: DISCONNECTED

Not sure what it means but I didn’t get the same message as @KonradWalsh. Anyway I’ll probably not try this type of connection.

Edit: Could this below be the culprit? (I did use “Disable Certificate Checking”)

“The server uses certificates signed by Let’s Encrypt. This CA is trusted by most systems, your shouldn’t need to do anything more than specifying your system’s CA directory.”

I know far too little about certificates and how they work to have any insights.

50

There seems to be some incompatibility in the MQTT protocol. At least that is what the error states. The MQTT library I use, states it supports MQTT 3.1, 3.1.1 and 5.0. So 3.1 and 3.1.1 matches the versions gBridge supports.

At the moment there is nothing I can do to change this.

51

Really appreciate you chiming in and clarifying…

52

From the MQTT specs:
The Server does not support the level of the MQTT protocol requested by the Client.

While at work I tried to force the mqtt protocol version the client uses, but I still get that error with gBridge.

53

Currently gBridge does allow basic non encrypted connection on port 1883 - and I have tried it from the Homey MQTT client but still get the unacceptable protocol message. I can connect on port 1883 from other clients but that’s not going to help.

K

54

The message has nothing to do with TLS. This message is a result of an error message generated by the MQTT library that the MQTT protocol cannot be matched.

That this happens is strange because the MQTT client and gBridge support the same client versions.

If the problem is the TLS connection, there would be another error.

2 Likes
55

Hi everyone,

that’s me - the head of gBridge.io

sorry I haven’t seen this thread earlier. Please feel free to notify my (or my employee) using the support email about such threads if there is an issue that affects many people.

It’s hard for me to debug these problems (since I don’t have a Homey at home and don’t known anyone who got one). Is someone reading along who is located in Dresden (Germany) or Nuremberg? I’d be willing to do a “personal debug session” for a evening or so then.

By the way, where have you seen that TLS 1.3 is required? This was a typo that has appeared accidentally in some documents (and has scared a whole lot of people). I’ve thought that I’ve corrected all documents to the correct TLS 1.2 :thinking:

Sadly, I need to keep the log files at a bear minimum (to be on the safe side regarding data privacy). Only critical errors are logged. So, of course, there’s nothing obvious in the log files for the past week. Starting a detailed trace for a single user is quite hard either on the production server.

Well, long story short, I’ve seen this problem before. Is it possible for you to define a last will topic for the connection to the gBridge mqtt server? Please try disabling this last will message (or set its topic to gBridge/u{userid}/lastwill.

Regards,
Peter

2 Likes
56

Hi Peter,

I am setting a last will message (default and hard codes for now). Will try to see if disabling the last will solves the problem.

57

Hi Peter,

Thanks for the hint regarding the LWT. Disabling the LWT results in a successful connection.

58

This is how it should look like :slight_smile:

20190223-13:08:49 Broker not connected, attempting connection
20190223-13:08:49 Broker URL: mqtts://mqtt.gbridge.io:8883
20190223-13:08:49 keepalive: 120
20190223-13:08:49 clientID = Test
20190223-13:08:49 rejectUnauthorized: true
20190223-13:08:50 MQTT client connected
20190223-13:08:50 Connected Topics:
20190223-13:08:50 Broker State: CONNECTED
20190223-13:08:50 sending queued messages

59

Awesome!

There are two main problems:

  • First, users are only allowed to publish/ subscribe/ do anything with topics beginning with the prefix gBridge/u{userid}. This includes the last will topic.
  • The MQTT broker we are using (emqx cluster) has a bug: If a user tries to connect with a LWT he has no access to, the server will report back the observed “Unacceptable protocol version” (instead of something useful). This bug costed me hours of work to debug and discover - it has been reported to emqx developers. They’ve fixed it and its going to be in the next upstream version.
60

So if you can push this update to the client we might get this working without additional hardware (RPI)?

Awesome that you guys could take the time to debug :slight_smile: