MQTT Hub/Gateway

Apps
1153

On the Virtual Devices app target_temperature is configurable for min, max and step during device setup.

Screenshot 2022-10-04 at 17.34.23
Screenshot 2022-10-04 at 17.34.23770×1280 55.8 KB

So might be doable.

@HarriedeGroot, any chance we could have configurable limits for target_temperature similar to what is available in Virtual Devices? Either from the advanced JSON configuration and/or during setup of the MQTT Device when Target Temperature is selected.

Created an issue at github: MQTT device target_temperature configurable value min/max/decimals/step capabilityOptions · Issue #82 · harriedegroot/nl.hdg.mqtt · GitHub

Updated the issue in Github with further ideas.

1 Like
1154

Ah yes, true that! I should’ve known that hehe.

1 Like
1155

Does anyone here know if it is possible to invert the status of a mqtt hub contact sensor?

1156

Try with Device capabilities app Device Capabilities App for Homey | Homey

1158

Am I alone with the issue that after each reboot I need to do a “Broadcast”? Or has anybody an idea why this happens? Without the “Broadcast” I just get updates on HA on some of the devices…
Of course I can trigger a broadcast after a reboot, but it would be interesting to know where the issue is.

1159

No you’re not alone. Same here. :blush:
Don’t know why.

1160

Yes, same here. I made a workaround reacting on the Mqtt topic of HA state.

First flow eeacts on the topic change and changes a variable.

Second flow reacts on the changed variable to restart the Hub app.

That prevebts the restart when Homey is restarted and the Mqtt client get the online state from HA.
It will only restart the app if the state changes from offline to online after HA was restarted.

Since I made this flow, the Hub is restarted automatically and HA is up to date.

1 Like
1161

All right, thanks a lot for the homey flow @RonnyW! However I’m not sure whether I do have the same issue as you or not. I’ve restarted Homey yesterday and not HA. May be it happens as well if I do a HA restart, but at least a Homey restart triggers my issue.

1162

After Homey restart you can set a timer to restart the HubApp again. After 10minutes or so - when all apps are running again.

1163

Yepp that was exactly my initial plan. But do you face both issues as well or just the HA restart issue? Btw in my case it seems to take a lot of time until homey has started all the apps.

1164

Depends on the # of apps you run, starting 43 apps here takes around 45 minutes, about a minute for every app. When you look it this way it seems less long?
Maybe you can force the MQTT app to start quicker after a Homey reboot, by first enabling it after x minutes, and then restart it 30s after that.

I let the hub restart after HA comes back online, and also when Homey is restarted.

1165

Just a simple flow on Homey restart.
Firt is the heating plan to wait for the Eurotronics app an ZWave zo start. Then the MqttHub.

I don’t think you can force an app to start earlier. And it’s better to start the Hub late. Then all devices are already present.

1166

Will this flow not just start these apps two times? First time with restart and second time with this flow. Or maybe that’s the point and I’m missing it. :blush:

1167

That’s right. That’s why at first start most of the devices are not ready and are not synced to HA after Homey restart.
The flow restarts the app after some time to re-sync all devices.

1 Like
1168

Observe fal the following:
When restarting without restart flows, the MQTT Hub is very slow when transmitting. This continues until the MQTT client hangs and deactivates.
Nearly 15 minutes pass before the hub closes again quickly after a restart of the client. After that, the client is also no longer terminated.
I also have a flow that restarts Homey with disable Client and Hub. After 15 minutes the client starts first and after 20 minutes the hub.

1169

How do you restart without starting the hub?

1170

Simply write a flow that Homey should deactivate the hub and the client on restart. In the same flow, start the client and hub with a time delay of xx minutes.

1 Like
1171

So this is all new to me so excuse the question but cannot find an answer.

How do you configure MQTT to use the MQTT Broker on Homey rather than another one I have running?

I cannot find where the IP address is set or the username/pwd

I can see it is publishing albeit erratically to a test MQTT Broker I setup earlier.

But now need it to work with the MQTT Broker setup on Homey.

I am reducing the workload on Homey to the things it connects to that I would struggle to connect to directly in Node Red, so Homey will have little to do and can carry the load of the Broker.

Can someone point me to how I point the MQTT Hub to itself on port 1883 and feed it credentials?

Many thanks

1172

Ok made some progress no idea how or why now sort of working.

Now trying work out why some selected devices are replicating to the MQTT and others not.

1173

I use MQTT hub now to read settings of my heating pump (dutch: warmtepomp) from ITHO Daalderop the WPU5G. I have a device which reads all numbers and publishes it to my mosquitto MQTT server.

Whenever I create a new MQTT Hub device with labels attached to the different readings, it initially displays the right labels. When I change for instance one letter in the label and save it, it only displays “generic label” for every setting, but in the config the real display names are set.

What do I do wrong in the below configuration, and can someone point me to how to set it to the right names and don’t have to create a new MQTT hub device everytime (and lose all my metric-history :-():

{
  "alarm_generic": {
    "capability": "alarm_generic",
    "stateTopic": "itho/ithostatus",
    "setTopic": "",
    "valueTemplate": "$['cv-mode-active']",
    "outputTemplate": "",
    "displayName": "CV mode"
  },
  "alarm_generic.1": {
    "capability": "alarm_generic",
    "stateTopic": "itho/ithostatus",
    "setTopic": "",
    "valueTemplate": "$['free-cooling-mode-active']",
    "outputTemplate": "",
    "displayName": "Cooling"
  },
  "alarm_generic.2": {
    "capability": "alarm_generic",
    "stateTopic": "itho/ithostatus",
    "setTopic": "",
    "valueTemplate": "$['boiler-mode-active']",
    "outputTemplate": "",
    "displayName": "Boiler"
  }
}

This is how it’s displayed after one time extra pressing save (as you can see, no “Display names” as was set in the config:
Scherm­afbeelding 2023-03-11 om 10.52.52