Closed tomrosenback closed 2 years ago
Yeah, I suppose this could be improved. The idea is to publish the state for all modes since they're mutually exclusive.
I'll come up with a fix.
Yes I have now seen the switches flip back and forth in HA when for example changing the away mode state, this after I added the alarms to the publishValues aswell, so as the amount data to be pulled from the Modbus interface adds up it takes more time and HA has time to think that the command didn´t go through.
Ideally only changed / affected values should be published.
console.log(`Updating setting ${settingName} to ${payloadString}`)
await setSetting(modbusClient, settingName, payloadString)
} else if (topicName.startsWith(TOPIC_PREFIX_MODE) && topicName.endsWith('/set')) {
const mode = topicName.substring(TOPIC_PREFIX_MODE.length + 1, topicName.lastIndexOf('/'))
console.log(`Updating mode ${mode} to ${payloadString}`)
await setFlag(modbusClient, mode, payloadString === 'ON')
}
Here I would put it, just after await setSetting
would be a publishSettings
or even publishSetting
depending how it would be read from Modbus, respectively after await setFlag
would a publishFlags
be.
Closed with the merge of #34
As the amount of values fetched and published when a value is changed, say Away mode, the response gets back with the state of the written value with a big delay as all the different registers needs to be read.
Suggestion Only publish related setting(s) / flag(s) on MQTT callback as the rest of the values are anyway periodically published.