MQTT Hub/Gateway

And all thanks to your Heimdall app :smiley:!
The implementation can be found here. You can probably copy/paste most of changes if you want. I changed some of the CSS, added a few classes & fixed a height issue with the devices list.

I love where this is going. I did notice something that worries me a little though. My Homey loadavg rises considerably when I start the MQTT gateway from around 0.4 to 1.4 and it seems to stay there when I keep the MQTT gateway running. This seems to result in my Homey being sluggish at times noticable in stutting speech an added lag on execution of flows.

I looked into the app performance in developer tools but I do not see anything strange there. Both memory and CPU usage are within range. So I’m not sure where it’s coming from and how to prevent it. Being able to select which devices publish their status may help though.

Is this something others are seeying as well?

Are u using a ‘switch’ control in openHAB? I once added a ‘button’ control which didn’t work.

Can you set the values using the MQTT Explorer?
This works for me (turns light on):

Yes, I’m noticing performance drops as well…and its worse with Homey 2.0 compared to 1.5.13.

Excluding devices is indeed one way of solving this.
I’m also working on the workflow of connecting/disconnecting.
Probably event listeners are not being disposed correctly, resulting in duplicate handling of messages.
And there is the socket connection drops…

This is prio 1 on my todo.

2 Likes

I’m using the Switch control and what you are describing in MQTT-Explorer is exactly the parameter change that openHAB does. So I have basically verified that openHAB publishes the correct change in the MQTT-broker but Homey does not carry out the action (turning the swtich/lamp on).

I have also tried to do it manually in MQTT-Explorer the same way as you describe, but Homey does nothing. However if I change things in Homey they do indeed change in MQTT-Explorer / broker as well.

So it seems as if Homey doesn’t understand that it should change it’s setting when something happens in the broker.

Sorry… I’m trying to help you where I can, but I can’t reproduce your problem…
What versions are you on (Homey, broker, client, gateway, etc.)?

I think you’re doing a great job. I realize it’s not very easy to get things to work for everyone. One thought I had is that maybe it works for you because you had it working on 1.5 and some setting transferred over that won’t work if you install it on 2.0? Maybe not, but anyway:

Homey: 2.0.0
(App 2.0.246 iOS)
MQTT Client: v2.2.0 (beta installed via CLI / Github)
MQTT Gateway: v2.0.1 (homie2 branch, just updated to the new version with the configurations but no change).
MQTT Broker: 1.4.10 Mosquitto installed via openHABian config util.

And the openhab version? I’m running 2.5 snapshot.

openHAB: 2.4.0-1
I guess I could try to update, but since sending a command manually to the MQTT-Broker doesn’t work. Shouldn’t this basically mean that openHAB doesn’t have anything to do with it? Maybe I misunderstand how the connection work.

You’re correct. The issue is somewhere between the broker and the gateway. I’m using the MQTT broker app from @scanno.

If you run in debug mode, do you see incoming debug messages?

What does the mqtt client app say in the logging? Is it connected to your mosquitto broker? Did you add the correct ACL’s (i.e. can the MQTT client subscribe / publish on the topic?)

Ok I’ve got some interesting news. I have two lights, kitchen window and living room window. One of these I can control through MQTT but not the other. Both are shown as channels in OpenHAB both are updated in the broker when I change the state of them manually through Homey but only one of them responds to the “set”-attribute in the MQTT-broker.

And well one I can also control in OpenHAB as well as manually in MQTT-explorer. The other doesn’t respond.

EDIT:
And it is shown in the Client log that it receives “false on homie/homey/kitchen-window/onoff” when it’s triggered through OpenHAB.
But if i try to trigger the livingroom-window nothing comes through on the log.
But it does send out the state of it (livingroom-window) from homey to the broker, just not the other way around.

That’s good news!

Any clue what’s the difference between the two devices?

restart the MQTT gateway app. You lost the realtime socket connection to the MQTT client.

I can’t really think of any difference between them except the names. They are both Fibaro Single Switch 2 devices connected to outlets that have lights connected to them.

Edit:
I tried to reboot the gateway. The behavior is the same one of the lights work but not the other (same as ones as before).

Edit2:
It seems as the name might be incorrect in the MQTT-broker.
In Homey it’s called “Living Room Window” but in the broker “Living-Room_Window”
Those with only one space in their name “Kitchen Window” in the broker called “Kitchen
-Window” seem to work.

I changed the name to “Livingroom Window” and it started to work.

Found it! It’s the _ in the device name (reserved by Homie convention). Already tried to fix that one (thought it was). It is a bug in the topic name normalization code. Need to have another look at it I guess! Problem only exists for device names with more then two words (> 1 space).

1 Like

Thanks a lot for the help, you are correct. This solved the problem. Everything I’ve found so far seems to work now!

1 Like

Thanks, I’ll certainly have a look! I’m not aware of a height issue with the devices list, can you tell me what’s wrong with it? I’ve mainly focused on getting Heimdall working on V2, it seems the technical issues are solved so now I can look into the UI/UX.

Your fix worked for me Harrie

@Camelen - the fix for this was only posted to github a day ago, I think you are using a slightly outdated version of the code maybe ??

Just as a mention I’m struggling with openHAB similar issues to others, the set property is not being populated for me … but things are working well with HomeAssistant :wink:

thanks for the debugging @Camelen, i followed your steps and now it also works for me!
Great work @HarriedeGroot !

1 Like