"in" nodes cause warning about not using retain even for devices that support getting their state

[Cyberbeni]

When we connect to mqtt and get the devices from the bridge, we send a get message for every device that supports it:

node-red-contrib-zigbee2mqtt/nodes/server.js

Lines 725 to 753 in 59d3120

	if (node.getTopic('/bridge/devices') === topic) {
	if (Zigbee2mqttHelper.isJson(messageString)) {
	node.devices = JSON.parse(messageString);
	for (let ind in node.devices) {
	let topic = node.getTopic('/' + (node.devices[ind]['friendly_name'] ? node.devices[ind]['friendly_name'] : node.devices[ind]['ieee_address']));
	if (topic in node.devices_values) {
	// getDeviceOrGroupByKey will add up-to-date information from node.device_values
	} else {
	// force get data
	// definition.exposes[].access has to be 0b1xx to support get
	// special devices, like "Coordinator", don't have a definition
	// Zigbee2MQTT seems to answer with the full state, not just the ones marked with gettable (but if we just send an empty/dummy payload, there won't be an answer)
	if (node.devices[ind].definition) {
	let getPayload = {}
	let isEmpty = true
	for (let exp of node.devices[ind].definition.exposes) {
	if (exp.access && (exp.access & 0b100)) {
	getPayload[exp.name] = ""
	isEmpty = false
	}
	}
	if (!isEmpty) {
	node.mqtt.publish(topic + '/get', JSON.stringify(getPayload))
	}
	}
	}
	}
	}
	} else if (node.getTopic('/bridge/groups') === topic) {

"in" nodes trigger a warning about not using retain right after deploy because they start up before this initial querying finishes. This warning was originally intended for devices that don't support get (most likely battery powered ones) because their state otherwise can't be queried after a Node-RED deploy.

node-red-contrib-zigbee2mqtt/nodes/server.js

Lines 454 to 456 in 59d3120

	if (payload_all == null) {
	node.warn('You need to turn on the "retain" option for the device in Zigbee2MQTT to be able to read it before a state change.')
	}

[andreypopov]

Do you want to remove this warning?

[Cyberbeni]

No, I think the warning is useful but the "in" node behaviour could use improvement.

I have 2 different types of "in" nodes:

• in node with send value on start and send only if value changes -> this shows warning but still sends correct value around start
• in node without send value on start and without send only if value changes (for decoupled switch single/double click handling) -> this shows warning too and sends value 3 times

I would expect the second one to not send any value. (It currently doesn't break anything for me because it sends null all 3 times and I filter out anything that is not "single" or "double")

This issue is mostly just for reference in case the current behaviour breaks other people's flows or if someone is looking for issues at open source projects that they can get experience with while also helping others.

[Wolk9]

I think, I have my setup crashing due to this "in" issue. :-|