WUD - What's up docker

[Varazir]

Hello,

WUD has has MQTT support and say it's playing nice with home assistance.
https://getwud.github.io/wud/#/configur ... gers/mqtt/
I thought I would give it a try.

I can see my containers in my MQTT explorer


This is my setup in Domoticz


Maybe I'm doing something wrong or need some something to translate the MQTT payload in Domoticz for it to discover.

This is payload for Domoticz
https://gist.github.com/varazir/ecac2f5 ... 2a09cfc057

Show status, if there an update maybe more but it's what I come up with.

maybe with script/API trigger an update from Domoticz.

[Varazir]

I see that I missed in the docker conf

- WUD_TRIGGER_MQTT_MOSQUITTO_HASS_ENABLED=true
- WUD_TRIGGER_MQTT_MOSQUITTO_HASS_DISCOVERY=true

few devices has been created. One step forward

[heggink]

Quite interesting! Is this compensating for the lack of update indicators in dockge?

[Varazir]

Quite interesting! Is this compensating for the lack of update indicators in dockge?

yes sort of and no notification in Domoticz.

[Varazir]

I'm have set it up using the Python Plugin: MqttMapper plugin to do this but it seams like WUD isn't that good at pushing data to the MQTT broker.
I think I see the issue, the cron was set to run 0300

Change the cron to every 5 min.

https://github.com/FlyingDomotic/domoti ... per-plugin

[Varazir]

Example

Code: Select all

{
	"Dockge Status": {
		"topic": "wud/container/docker/dockge-dockge-1",
		"key": "wud/container/docker/dockge-dockge-1-status",
		"type": "244",
		"subtype": "73",
		"switchtype": "0",
		"mapping": {
			"item": "status",
			"default": "0",
			"values": {
				"running": "100"
			}
		}
	},
	"Dockge Update": {
		"topic": "wud/container/docker/dockge-dockge-1",
		"key": "wud/container/docker/dockge-dockge-1-update",
		"type": "244",
		"subtype": "73",
		"switchtype": "0",
		"mapping": {
			"item": "update_available",
			"default": "0",
			"values": {
				"false": "0",
				"true": "100"
			}
		}
	}
}

[waltervl]

So what was wrong with the HA Discovery option? From the documentation it just should work.

[Varazir]

So what was wrong with the HA Discovery option? From the documentation it just should work.

With this settings


I only get this devices


This how it looks like in MQTTexplorer



Logs

[waltervl]

Yes, and that seems correct. i see 3 binary sensors in config and 4 sensors. So in Domoticz creates 3 switches and 4 custom sensors. So exactly what WUD configured. It also should be enough to manage the system I suppose.
But perhaps in topic WUD/update also config topics are present?

It is (or was) by the way not advised to have the discovery topic (default homeassistant) the same as the main state topic.... If you want to differ better make it for example WUD_discover, zwave_discover, zigbee2mqtt_discover etc

[Varazir]

Yes, and that seems correct. i see 3 binary sensors in config and 4 sensors. So in Domoticz creates 3 switches and 4 custom sensors. So exactly what WUD configured. It also should be enough to manage the system I suppose.
But perhaps in topic WUD/update also config topics are present?

Don't know, But it don't show status of each container. It's what I'm after.

It is (or was) by the way not advised to have the discovery topic (default homeassistant) the same as the main state topic.... If you want to differ better make it for example WUD_discover, zwave_discover, zigbee2mqtt_discover etc

Why dose it matter ?

If I use the homeassistant topic for all will that not mash everything and domoticz will hard understand what is what?
For me it's more logic to separate them. Then dose it matter to use *_discover? Dose the the plugins care about the topic? as long as it's matching in the settings shouldn't it work ?

[waltervl]

The discovery topic is by default split from the state topic to ease the system in discovering devices. Else every new message in the integration also has to be checked for config changes. And when you have a lot of devices you will get a lot of unnecessary possible config changes that needs to be handled.

In the past this could go wrong, this is why you see a split in config and state topics.