Keep an internal state for each device and send it to HomeGraph only if it is changed

[moromindful]

Hello,

First of all great job with HomeAutio. I run it in docker on my qnap nas and it is great as I have a couple of sonoff mini's that run Tasmota which are also controlled by a fibaro home center 2 by http not mqtt and the fibaro link with google home doesn't expose this devices so HomeAutio does what I need and does it good 👍 . Now I can control the devices from the fibaro app and also from the google home app.

The fibaro home center 2 doesn't integrate my thermostats and temperature sensors with google home and I am planning to expose them via HomeAutio by publishing their state every 10 seconds or so to a status topic so it would be great if you handled state changes by reporting the state to HomeGraph only if the state change. (reporting to google only when the temperature changes). Right now it sends the state over and over every time fibaro home center 2 publishes the state. I know I can handle this myself but it would be usefull to others and me also as other gateways may not be so easy to script this.

Here is a temple for a light maybe someone will find it usefull when they start using HomeAutio:
"dining_lights": {
"id": "dining_lights",
"type": "action.devices.types.LIGHT",
"willReportState": true,
"roomHint": "Living Room",
"name": {
"defaultNames": [],
"name": "Dining Lights",
"nicknames": []
},
"deviceInfo": {
"manufacturer": "Sonoff",
"model": "Tasmota",
"hwVersion": "1.0",
"swVersion": "1.0"
},
"traits": [
{
"trait": "action.devices.traits.OnOff",
"commands": { "action.devices.commands.OnOff": { "on": "dining_lights/cmnd/POWER" } },
"state": {
"on": {
"topic": "dining_lights/stat/POWER",
"googleType": "bool",
"valueMap": [
{
"mqtt": "ON",
"type": "value",
"google": "true"
},
{
"mqtt": "OFF",
"type": "value",
"google": "false"
}
]
}
}
}
]
},

[Michael Hallock]

Probably not in the card right now. I suggest debouncing and republishing under another topic you control and binding to that if this is an issue for you.

Long answer: This app is a "bridge" between Google's implementation and MQTT... but because (a) MQTT is wide open to how you implement your states, and (b) Google keeps adding to their side and implementing things in COMPLETELY different ways, it is difficult to be a middle man here, requiring translation (see valueMap), some interesting approaches to response generations for commands, etc. I have attempted to support the entire Google Home list of traits, which I'm dedicated to continuing, but that's getting difficult.

Unfortunately, my suggestion to you is kind of what I SHOULD have done about valueMaps too, requiring people to republish to a set of topics when they needed additional translation instead of attempting to provide a translation layer in app... and Im hesitant to add additional pieces to that like debouncing, etc., as that actually possibly will require some creative solutions...