MQTT Hub/Gateway

Version 3.5.0 (test)

  • MQTT Device icons

All 5955 icons from the MDI iconset can be searched and selected as device icon. Additional custom .svg images can be uploaded.

For version history, see: CHANGE_LOG

2 Likes

Version 3.5.1 (test)

  • Upload custom icon fixes
  • Remove uploaded icons on cancel pairing OR uninstall of MQTT Device

For version history, see: CHANGE_LOG

Brilliant update! Now I need to recreate all devices :sob:

Sorry…

Version 3.5.2

  • HA Discovery: Cover position template fix for HA version 2021.6+ (issue 56)
  • Security: Homey, jsonPath & lodash NPM package upgrades

For version history, see: CHANGE_LOG

1 Like

I tried the new icons and I seem to have trouble with the custom SVG one. First I tried using Safari on a MacBook and it didn’t work. Then I tried moving the files to my iPhone and upload it and it didn’t work. last I tried using Chrome and I got it the Icon to upload and attach to the device.

I can see this custom icon in both chrome and safari but there isn’t any icon at all on my iPhone. I tried restarting the MQTT Hub app, the iPhone app and the iPhone itself but none of it mattered. It’s also been a couple of hours since I did it and it has not appeared.

The ones you choose in the list does not seem to have this problem.

This is the icon I used:

Any ideas?

I had some trouble with the web app. Seamed like the icon isn’t uploaded to CDN before it is loaded into the mobile app. So opening the mobile app after creating the device in the browser did the trick on my side.

@Camelen Where can I find the SVG version of that particular icon?

Found already: https://www.iconfinder.com/icons/998251/download/svg/512

Had no problem uploading the icon & adding it to the device:
image

This time added using the web app in Chrome. Did not even have to load the device in the mobile app.

And indedeed…icon is not displayed in the mobile app (Android) :frowning:
Lets try adding the icon from the app…

There’s a small bug in the mimetype, preventing me to select an SVG on mobile.
But after resolving this, the selected icon on mobile is correctly uploaded and added to the MQTT device.

The strange thing: the icon is not displayed on mobile, but is in the web app ?!?!?

Yes and it is also displayed in the web app in a different browser so it’s not some cache-thing. At least the behavior seems consistent over the phone-apps.

Version 3.5.3

  • SVG mimetype fix for uploading MQTT Device icons

For version history, see: CHANGE_LOG

Maybe it’s something with the SVG structure? Viewport? etc.
I’m not an SVG expert :slight_smile:

I have barely used svgs before so I’m probably not very helpful here. With the 3.5.3 update I can also upload from the phone app and it shows during the configuration process but not after it’s finished.

I just realized that an svg file is basically just code so I tried downloading an icon from https://materialdesignicons.com/ and upload it and that file worked so I guess there’s a problem with the svg-file I used.

I think that I have found some unwanted behavior.

It seems as if MQTT Hub puts into the set topic what it sees in the state topic.
This will causes some trouble for me and does also seem wrong to me.

Explanation / to repliacte:
I’m starting to transition to zwavejs2mqtt and am adding my devices to Homey through MQTT Hub.
While trying to add a dimmer (fibaro) the payload for current value looks like this:
State topic: zwave/kitchen/island/switch_multilevel/endpoint_1/currentValue
Payload: {“time”:1620932977766,“value”:32}

Set topic is:
Topic: zwave/kitchen/island/switch_multilevel/endpoint_1/targetValue/set
Payload: 0-99 integer (will round if decimals) or true / false (remember last level).

So I used a valueTemplate simply named “value” and to circumvent 0-100 to 0-99 I tried to set the output template to value*99/100.
This caused erratic behavior because there was a disconnect between what MQTT Hub sets and what is reported back, which then MQTT Hub sets into the /set topic and so on.

I also checked by just changing the current value topic with MQTT Explorer to a new dim value and MQTT Hub then puts this value in the /set topic. If I turned of MQTT Client to disconnect homey this behavior did not happen so I’m pretty certain that this isn’t caused by some of my other devices.

@Camelen Isn’t it the other way around? The state topic is updated with the value provided on the /set topic. The device state is synced with the input value.

I expect you got into a message loopt…
Did you try rounding the values to break this loop?

I also got comparable behaviour with a light brightness / dim level, while working on the HA Discovery and auto generation of MQTT devices based on the HA discovery protocol ($config).
So it already was the next thing on the list :slight_smile:

My guessing (probably incomplete…):
Due the calculation you’re communicating floating point values i.s.o integers. Because the input (set) and output (state) topics are lined up, you end up with a message loop. This is because the other end of the line (zwavejs2mqtt) also detects a new/changed value and reports a state change of the device back to Homey. Homey gets a new input and sends a device state change to zwavejs2mqtt, …, loop, …, etc…

This loop will break if the MQTT device input (set) equals the current state, but this won’t happen due the small floating point difference introduced by the calculation. Maybe rounding the values is a first workaround to hit this brake? But it’s probably not a / the full / correct solution. As mentioned, this needs some attention…

Maybe the equality check needs to be placed after the equation has been executed, but again, I need to check this…


Regarding the auto discovery of HA devices: I’m using the MQTT statestream, combined with this BluePrint to create HA Discovery topics for all HA devices. Allowing me to import all devices from HA to Homey, without a single manual definition. Work in progress…

Just checked, calculation is executed before value comparison, so thats not the answer…
device.js (r263)

Isn’t it the other way around? The state topic is updated with the value provided on the /set topic. The device state is synced with the input value.

Well yeah that’s the way it is supposed to be I guess. The way I thought that it should work is that the /set topic is never touched except for changing the state of the device. Do we really need to have a sync from the current state → /set? Because that’s what I’m seeing.

If I change the dim value in Homey to 32 the /set topic gets changed to 32, raw number.
This triggers a change in state of the device through zwavejs2mqtt and the currentValue topic is updated to reflect the 32 dim level.

However if I change the currentValue manually in MQTT Explorer to 32 (this does not trigger a state change of the device itself in zwavejs2mqtt) then homey / MQTT Hub changes the /set topic to reflect 32 and THEN zwavejs2mqtt gets triggered to carry out the state change.

This seems incorrect to me. Why is Homey/MQTTHub syncing the /set value with the currentValue? I just don’t see the reason for it.

Due the calculation you’re communicating floating point values i.s.o integers. Because the input (set) and output (state) topics are lined up, you end up with a message loop. This is because the other end of the line (zwavejs2mqtt) also detects a new/changed value and reports a state change of the device back to Homey. Homey gets a new input and sends a device state change to zwavejs2mqtt, …, loop , …, etc…

Yes, this sounds reasonable. But why though? Why does /set have to line up with currentValue in both directions? Is there any benefit to it except risks for loops etc.?

Regarding the auto discovery of HA devices : I’m using the MQTT statestream, combined with this BluePrint to create HA Discovery topics for all HA devices. Allowing me to import all devices from HA to Homey, without a single manual definition. Work in progress…

This sounds great. There’s auto discovery between zwavejs2mqtt to HA but obviously not to Homey and it’s kind of a PITA to add all the devices to homey through the app/webapp.

Just checking:
Where did you put the /set topic on the MQTT Device capability config?
And isn’t the /set topic called by zwavejs2mqtt?

The /set topic should never be updated by Homey on device state change, unless it’s configured as state topic for the MQTT Device capability.

{
“dim”: {
“capability”: “dim”,
“stateTopic”: “zwave/kitchen/island/switch_multilevel/endpoint_1/currentValue”,
“setTopic”: “zwave/kitchen/island/switch_multilevel/endpoint_1/targetValue/set”,
“valueTemplate”: “value”,
“outputTemplate”: “”,
“displayName”: “Dim level”
},

This is the code of the device.
If I disconnect Homey from MQTT the behavior stops.

The /set topic should never be updated by Homey on device state change, unless it’s configured as state topic for the MQTT Device capability.

That’s what I thought and that’s why I’m reporting this bug :slight_smile:
The fault could be in my settings but I don’t really think so.

I can check logs in my mosquitto to verify who posts the change.

Looks correct…
FYI: valueTemplate can be left black for the same behaviour.

The ‘setTopic’ is called when the MQTT Device state (capability value) is changed.
A change can be triggered manually, via a flow / script or a message on the state topic…

1 Like

From what I can tell Mosquitto supports my suspicion. I did not post anything that should have touched the /set topic of the dimmer here.

This is the log from Mosquitto:
1620939241: Received PUBLISH from mqtt-explorer-1e2de860 (d0, q0, r0, m0, ‘zwave/kitchen/island/switch_multilevel/endpoint_1/currentValue’, … (33 bytes))

1620939241: Sending PUBLISH to homey_client (d0, q0, r0, m0, ‘zwave/kitchen/island/switch_multilevel/endpoint_1/currentValue’, … (33 bytes))

1620939241: Sending PUBLISH to 5vArLtX1iTBXYhodlZW1RO (d0, q0, r0, m0, ‘zwave/kitchen/island/switch_multilevel/endpoint_1/currentValue’, … (33 bytes))

1620939241: Sending PUBLISH to mqtt-explorer-1e2de860 (d0, q0, r0, m0, ‘zwave/kitchen/island/switch_multilevel/endpoint_1/currentValue’, … (33 bytes))

1620939241: Received PUBLISH from homey_client (d0, q0, r1, m0, ‘zwave/kitchen/island/switch_multilevel/endpoint_1/targetValue/set’, … (2 bytes))

1620939241: Sending PUBLISH to ZWAVE_GATEWAY-zwavejs2mqtt (d0, q0, r0, m0, ‘zwave/kitchen/island/switch_multilevel/endpoint_1/targetValue/set’, … (2 bytes))

1620939241: Sending PUBLISH to mqtt-explorer-1e2de860 (d0, q0, r0, m0, ‘zwave/kitchen/island/switch_multilevel/endpoint_1/targetValue/set’, … (2 bytes))