Information about the app and how to use it, published in the App Store
This app creates a MQTT Server (also called Broker), and publishes Homey Proâs devicesâ state to it.
USAGE
First, create a new user with a username & password in the appâs Advanced Settings.
Then, download any MQTT Client and connect to Homey Proâs IP address on your LAN. All topics should be visible automatically.
To set the status of a device, publish a JSON-strigified value to homey/devices/<device-id>/capabilities/<capability-id>. For example, publish true to homey/devices/abc...efg/capabilities/onoff to turn on a device.
NOTES
The server also supports the âhomieâ convention (see https://homieiot.github.io) for compatibility with 3rd party MQTT clients.
I need MQTT protocol also for getting data from my micro solar inverter resp. from a DTU (Data Transfer Unit).
An info which I posted just on Slack:
Before the MQTT Server App was released, I used the Broker and the Client App and it worked without any problems.
After the MQTT Server App was released (first without any flow cards), I installed this App, deactivated the MQTT Broker and activated/configured the MQTT Server App. Because there were no flow cards in the Server App available, I still used the MQTT Client App. And this worked also with no problems, the flow wasnât never deactivated due to much executed.
After Emile added some flow cards for the MQTT Server App, I deactivated the MQTT Client App and rebuild the flow with the new flow cards from the Server App. After this was done it took just some minutes and the flow was deactivated due to much executions.
But as you can see at the screen shots, the flow is a duplicate from the âoldâ flow with the flow cards from the MQTT Client App. So nothing was changed, just the flow cards were replaced.
In Short:
MQTT Broker + MQTT Client (Flow) =
MQTT Server + MQTT Client (Flow) =
MQTT Server + Flow =
Additional infos:
Publishing interval micro solar inverter/DTU: 5 seconds
I had to make a new attempt and I can actually see messages coming through to the MQTT Client but for some reason it doesnât update my virtual device. Not sure whatâs happening. Either way I have to retract my previous statements, the official app does work as a broker.
When I can do it without upsetting normal operation I will modify my setup to use the cards from the new app.
If you âfeedâ the virtual device with the flow cards of the MQTT Client App, then you have to modify this flow with the cards of the MQTT Server App, of course.
I proceeded as follows:
â duplicated the flow with the flow cards from the MQTT Client App and deactivated the duplicated flow immediately
â replaced the flow cards with the flow cards from the MQTT Server App
â deactivated the MQTT Server App
â activated the new flow with the MQTT Server flow cards
The âoldâ flow with the flow cards from the MQTT Server App doesnât need to be deactivated, because this flow doesnât work anymore because the MQTT Client App is deactivated.
At this point I had already deactivated the MQTT Broker App and the topics were already published via the MQTT Server App.
The MQTT Client app takes considerable care to only start flows for messages to topics that it knows it will have a positive trigger for.
The MQTT Server app starts the flow on every single message that gets published, and will then check if the message is published to a topic that it should trigger on. Which is too late to prevent the flow from being rate limited. Even if a flow only has one trigger topic, if the broker receives enough messages the flow will be rate limited (even if none of those messages are actually published to the trigger topic).
Interesting information on the different trigger behavior.
Anyway, I have had it running for a while now with the MQTT Server trigger cards and as far as I can tell it works as expected.
In my particular setup the message rate is rather low and the majority are handled so the difference in triggers between this and the MQTT Client app shouldnât be an issue.
I seem to remember Athom having previously dismissed the idea to have MQTT support built in, which is a pity in my mind, but an official app is welcome.
I have just done a test with the MQTT Explorer program.
First I activated the MQTT Server app and observed the data traffic in the MQTT Explorer program for approx. 10-15 seconds:
(MQTT Server App)
Then I deactivated the MQTT Server App and activated the MQTT Broker App and also observed the data traffic for approx. 10-15 seconds:
(MQTT Broker App)
In other words, the MQTT Server App processes a lot more data than just the MQTT Broker app, caused by homey and homie.
I know that the MQTT Server App is a broker, client and hub in one.
Are the topics homey and homie published more or less by the hub of the MQTT Server App? Are these data from all devices in Homey, e.g. to publish the for Home Assistant, @robertklep?
For a seamless HA integration, the HA Auto discovery is needed. Else you have to add all topics manually to HA
PS: I asked Emile on Slack about this. If the MqttServer should replace the MqttHub in future, the community has to add this functionality to MqttServer (fork+PR). Same for device list/filterâŚ
HA was just an example, I donât want to send any topics to HA, so no HA auto discovery neededâŚ
I would be interested to know whether Emile would really integrate the PRs and publish the app in the App Store if, for example, HA auto discovery was added.
To be honest, I doubt that. Especially when a HA integration is involved.
Nah, thatâs just the other way around, from HA to Homey. I guess with the idea to make it easier for people to migrate from HA to Homey. And he doesnât want to provide a way to make it easier to do that in reverse
No, itâs for both ways, I quote ¨Iâm not going to actively build anything for Home Assistant"
But, the Athom HA app already has been built, fair enough haha
