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 
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 But dont know if its from me 
I wonder if Athom has also implemented rate limiting for API calls… 
Really dont care anymore
1 Like
Sorry, this is all too technical for me…
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
The Message queue of the hub is already capable of delaying the message publishing. It’s turned of (delay 0) in the current implementation, but if the bizarre API calls rate limiting is a true fact it can probably be omitted. It won’t solve anything though, the same number of calls wil be executed eventually. It also means external platforms potentially receive state updates delayed and a broadcast will take even longer…choosing the optimal value will be random trial and error. I hope it’s not necessary to enable this.
MessageQueue: https://www.github.com/harriedegroot/nl.hdg.mqtt/tree/master/mqtt%2FMessageQueue.js
1 Like
Just updated to v2.4.2, it re-setteled it self smoothly, and all errors in the hub are gone.
Thanks a lot the 3 of you, will contribute to your beer cellar too.
Updated the MQTT Hub app to SDK v3.
Also addressed some long lasting issues and added a flowcard to trigger the broadcast.
Who is willing to test?
Available on test channel in the app store: MQTT Hub | Homey
Source: GitHub - harriedegroot/nl.hdg.mqtt: MQTT Hub/Gateway for Athom Homey
Version 3.0.0
- Upgrade to Homey SDK v3
- Added flow card to trigger a broadcast
- Removed guid from default homie topic at app install
- Delayed the initial broadcast by 30 sec.
- Removed ‘icon’ from Home Assistant payloads
- Cast enum values to string
3 Likes
Yes, will install it today.
Thx for this update!
No programming skills here, so don’t expect a very indepth review pls… 
Updated the test version of the MQTT Hub to v3.0.0: MQTT Hub | Homey
So it can be installed using the app store.
4 Likes
Solved my icon issue and seems to work just fine.
1 Like
Downloaded and installed, running together with client v2.4.1.
After a short restart battle, I got the triangle running again.
This time restart order: broker, client , hub was the solution.
Have no use cases for the flowcards, however a quick check, and maybe it’s me but I only have the option:
“Als MQTT apparaat is veranderd”
I can’t find the AND cards as shown in the examples on the app store.
In the THEN section I only have the “Broadcast uitvoeren” option.
Again thanks a lot for all the effort!
