MQTT Hub/Gateway

Just updated the app to x.0.1. Waiting for approval from Athom.
And you’re correct: master branch is for Homey 1.5.13, Beta branch for Homey 2.0

Hi,
Sorry for not understanding.
I am trying to set the dim level on a fibaro dimmer 2 in my livingroom
My Homey is called ’HomeyHome’
Mosquitto_pub -m ”0.5” -t ”HomeyHome/light/Livingroom/Livingroom Vitrin/dim/update”

Nothing is happening. Also tried with just ”homey/…” but same result.
What did I not get right?

Also, how do I send a ’describe’ command to list all devices?

The ’state’ repport comes out to the broker so mqtt is up and running.

Thanks

Helge

Try with ‘normalized’ names and remove the quotes around the value:
Mosquitto_pub -m 0.5 -t ”HomeyHome/light/livingroom/livingroom_vitrin/dim/update”

Get devices request has yet to be implemented (high on the prio list, see also posts about the homie convention above).

Do you get messages on ”HomeyHome/#"?

Note: The device name is also going to be normalized in the next version (small bug)

Hi,

Still the same problem.

Topics are case sensitive, try:
Mosquitto_pub -m 0.5 -t ”homey/light/livingroom/livingroom_vitrin/dim/update”

I see Homey 1.5.13 has a small bug in grabbing the device name and will fallback to ‘homey’.

I have also a problem to get it work…

I am using MQTT Client v2.2.0 beta and MQTT Gateway v2.0.0 beta but the only message that comes every 30 second is “Homey/unknown/home/system/general/state”
I have also restated my homey.

Any ideas what could be wrong?

Im am runnig the latest beta. Tried both lower case and right case.

did you try with ‘homey/’ i.s.o. HomeyHome? (because the system info is dispatched on the homey/# topic)

Yes tried all sort of combinations. Is there any whay to get dubug info from the app?

Yes, install the app via the athom-cli
source (Homey 2.0): https://github.com/harriedegroot/nl.hdg.mqtt/tree/beta

I started working on the implementation of the Homie convention (v3.0.1).
For now it’s based on the stable branch (Homie v1.5.13)

Currently the registration of devices and their properties (capabilities) is working.
Also the initial value is already dispatched.

What has to be done (a lot):

  • All translations between Homey values and their Homie conterpart (classes/types, capabilities/properties, types/datatypes, etc.)
  • All message handling (set values, broadcast, etc.)

For the initial setup, see the ‘homie’ branch:

This is a new utility that is very useful for exploring all topics in use on your broker…


1 Like

anyone who can help me because I only receive the system status “Homey/unknown/home/system/general/state” ?

I have tried some restarts of the apps and also of Homey itself, but still the same :man_shrugging:

Do you have some more info?
E.g. What’s your Homey firmware version?
Maybe your’re able to run the app via the athom-cli & grab the debug log?

You already receive the system info from the Gateway app. This means the connection with the broker (via the MQTT Client app) is working.

as already wrote at GitHub:
I don´t know why it was not working before, but after installing the v2.0.1 via athom-cli it works!!!

Thanks Harrie!

Sneak peek!

Device discovery within openHAB via the Homie Convention:

3 Likes

First impression of HABpanel using MQTT. It’s a working demo, including live updates & setting the values.
All devices and their properties (+datatypes) are automatically detected and imported via the Homie Convention:

5 Likes

Gr8!

I’m on the same path, but with Node Red. In my situation I need to create a flow for every device/state that need to be changed from the Node Red dashboard, might a future update on the MQTT Gateway bring an easy solution for that? Saw a 'FlowTriggerDispatcher: not implemented’message, indicating a flow solution might be implimented at some point.

Thanks so for, happy with the possibilities even without an easy flow solution!

Cheers,
/Cacti

States can be triggered using an ‘update’ message (it’s roughly explained in the app description/readme).
There’s no need to create a flow for device state updates.

Starting flows via a message is not (yet) implemented.

Thanks, I’ll have a look at it!