MQTT Hub/Gateway

and another resolution : Node Red: A widget based dashboard working with Homey trough MQTT - #743 by Khoi_Ho_Si

Have tried all sorts of orders for restarting, disabling, etc, but no luck anywhere…
Just spend a few saturdays designing a nice map of my home to use in HA or NR… :frowning:

Haha, bit frustrated here, sorry… :slight_smile:

1 Like

What is not working exactly? I see messages published in the MQTT client and posted on the broker from the MQTT hub.

For me everything just works after a reboot.

Both you and Harry justly state the apps work as they intented to do. The question is how do you get them to work together.
See the posts above, from here, MQTT Hub/Gateway - #784 by mits? (and in other forums too).
The hub reports publishing problems, after a Homey restart/upgrade or after the latest update of the client and is practicaly impossible to resolve these errors.
It is unclear if this due to the hub or the client, it’s unclear how to fix theses as there does not seem to be a “works for all sequence” in how to start the MQTT triangel trio.
Hopefully you are able to bring a light in the dark.

@Robert_Zwetsloot You forgot Homey. Homey is responsible for maintaining the socket connection between the apps. If the connection isn’t stable, there’s isn’t much we can do about it.
The number of complaints about this issue is increased enormously with Homey v5.
The issue was there from the beginning though.

Have you tried running the app from the command line to see if it logs any additional error data?

@HarriedeGroot I found the issue: apparently, an API endpoint needs to return proper JSON, otherwise ApiApp throws an exception. The MQTT Client API endpoints don’t return JSON, so an error is generated.

This is, of course, not documented anywhere :confounded:

Issue here: ApiApp throws exception when endpoints return un-JSON-serializable data · Issue #184 · athombv/homey-apps-sdk-issues · GitHub

1 Like

Thanks @robertklep! Does it mean the exceptions should be catched by the Hub? And/or does the Client of @scanno needs some changes?

From what I understand from Athom’s response, the client app should be modified so it always returns something that can be serialized to JSON.

Something like this:
let response = {
result: -1,
error: “”
}

Lol even the broker now gets rate limited when MQTT Hub is broadcasting all the states

Or just return {}.

uploaded a test build
Well a return code with an error description could bring more possibilities in the future

1 Like

Anyway back to writing my thesis :confused:

The broker doesn’t have any flow cards though, does it?

But adding a JSON result does not solve the startup problems

Dos not have flow cards

but:

Unfortunately, your app nl.scanno.mqttbroker (v1.0.5) has crashed.

Error: rate_limited
at Remote Process
{
code: 429
}
Error: rate_limited
at Remote Process
{
code: 429
}
Error: rate_limited
at Remote Process
{
code: 429
}
Error: rate_limited
at Remote Process
{
code: 429
}

Getting this error :confused: But dont know if its from me :slight_smile:

I wonder if Athom has also implemented rate limiting for API calls… :thinking:

Really dont care anymore

1 Like

Sorry, this is all too technical for me… :slight_smile:
Meanwhile the MQTT Client was automatically updated to 2.4.2 on my Homey.

Do I understand correctly that you think the problems might be solved then? Then I’d be happy to test…

Anyway, thanks @robertklep @scanno and @HarriedeGroot for your effort and time!
I’ll buy you a beer!
(EDIT: @robertklep Pls send me a Paypal link; as I can’t find yours… The other two have there beers already. :-))

@scanno null is also a valid json value and can be the replacement for undefined responses if there is no error.

1 Like