MQTT Hub/Gateway

Hi @HarriedeGroot on/off is perfect for me atm, thank you very much.

:+1: Color & dim/brightness should work also.

2 Likes

Hi HarriedeGroot,

sorry for asking, but again, I am new to MQTT.
I now know that the MQTT Hub/Gateway will send all states to the broker (by means of the MQTT Client app) as soon as it connects to the broker (in this case, my app)

However, the Broker doesn’t have to be my app, but can also be another app (like Mosquitto).
What if your app is already connected (and sent the status) to the Broker and I am connecting at a later time?
How do we synchronize? Is there a special command I can send so you will broadcast all states again?
Or does the broker needs to send all the cached data (belonging to the subscription)?.

I hope you understand my problem/question.

edit:
For now, I will retain the messages in my own broker. But I just wondering about brokers that do not retain the messages.

@RobertP All messages are send with the retained flag. This means the broker will keep a copy of the last message for each topic & send this message on subscription. It’s part of the MQTT protocol.

Furthermore I still need to implement birth & last will messages for the hub.

1 Like

@HarriedeGroot, I am trying to set a value (switch light on), but I cannot get it to work.
Topic: ‘homie/lamp-eethoek/onoff/set’
Payload: ‘true’
Retain: false
QoS: AtMostOnce

I have all default in the two apps
The MQTT Client has no setting activated
The MQTT Hub has only DEVICEID=homie

What am I doing wrong?

You look to be missing a topic hierarchy in your MQTT set comand - your Homey name.

homie/HomeyName/lamp-eethoek/onoff/set

K

@xAPPO, but I do receive the Topic that way (without the HomeyName)
It says in the settings that the HomeyName is optional (and I didn’t fill this in)
I do receive: ‘homie/lamp-eethoek/onoff’

the “/set” is not necessary I think. But to be honest I am not really sure.
I just tried this, but for me it also do not work. I can receive alle states but I am not able to set states.

I have tried the Homie Convention and also the Custom format.

@dewenni If you are using the homie3 protocol to control devices in Homey then the set topic is mandatory. Also you do have a space between homie/ and HomeyName but that might be a typo.

https://homieiot.github.io/specification/
section 5.4.1

@RobertP I also suspect it maybe mandatory to use both ‘homie’ as the root topic and to have a Homey name set to adhere to the homie3 spec. You have the Homey name set as ‘homie’ and the homie root topic blank, which is bound to be challenging. Try it with both set and see if it works, if so then regress and see when it stops working.

N.B. In the homie3 spec device ID refers to your Homey - and a device within Homey has a node ID

K

You are absolutely right!
I added a root id to setting (‘Homey’) and now it works.
You get: ‘Homey/homie/lamp-eethoek/onoff

Seems to me that the description of the setting should be changed. It is not optional at all if you want to set a value.
(unless it is a bug)

I’ll check.

Currently working on a new version of the settings. Including options for HA discovery, topic normalization, birth & last will, etc.

Another issue/question.
Check out the log below;
At line 790 I set the dim value to 0.3
The light dims (yeah! It works! :smiley:

But, however the light stays dimmed, I get the new state back with Payload=1

What is causing this?

EDIT:
Got it. You should use Retain=true when you set a value.

795 18:36:06.396 123 MTTQ Client Local => From=f331881e5a004c6fa522f3a11a8967a9 → Message: Topic=Homey/homie/werkkamer-lamp/dim, Payload=1, QoS=AtMostOnce, Retain=False
794 18:36:06.383 12 MTTQ Broker=> From=homey_6d1f3ea5 → Message: Topic=Homey/homie/werkkamer-lamp/dim, Payload=1, QoS=AtMostOnce, Retain=True
793 18:36:06.325 123 Controller action: Device.GetDeviceProperties
792 18:36:06.259 123 ExecuteWithinTransaction: Added 0, Deleted 0, Updated 1 objects in tables DevicePropertyValue
791 18:36:06.251 123 MTTQ Client Local => From=f331881e5a004c6fa522f3a11a8967a9 → Message: Topic=Homey/homie/werkkamer-lamp/dim, Payload=0.3, QoS=AtMostOnce, Retain=False
790 18:36:06.246 12 MTTQ Broker=> From=homey_6d1f3ea5 → Message: Topic=Homey/homie/werkkamer-lamp/dim, Payload=0.3, QoS=AtMostOnce, Retain=True

Hey. Just wanted you to notice the requirement that gbridge has regarding Lastwill. I don’t really understand it honestly but see the thread about gbridge and Google home :slight_smile:

It’s already implemented (settings not yet available).
Screenshot_20190223-225406

1 Like

As long as the topic is choosable it looks great! :+1::grin:

I made some changes in settings to get more control over all topics (homie, custom, ha discovery, etc.)

1 Like

@HarriedeGroot
If you can make this work with gBridge… I’ll donate to you too

@KonradWalsh I followed the other thread, but what has to be implemented for the HUB to get things working?
If it’s only the birth & last will messages, these will be available soon (configurable).

I think… Think…

It needs to send all the devices info to gBridge…

@pkappelt will know better

@KonradWalsh I didn’t look at gBridge (yet), but in my understanding it’s already possible to connect gBridge with Homey by using the MQTT Hub with an external broker (mosquitto, cloudmqtt, HiveMQ, …). @Camelen and @xAPPO both got this working?

The problem was/is a direct connection with the internal mqtt broker of gBridge. This can be solved by sending the correct birth & last will messages (already implemented, available soon)?
When setting the correct device topics in gBridge (follow the homie convention), you should be able to connect all your devices?

Please correct me if I’m wrong!

Is there anything I can do (within the hub) to simplify the process?