Closed fightforlife closed 3 years ago
First, if you are using command delegation, you should be able to do this with your command config as it only uses the config there to attempt to map command params to individual MQTT topic notifications. If you aren't USING those notifications, you should just set the command to null so you ONLY get the automatic command topic publish, and it doesn't try and publish additional messages per-parameter. I know this isn't spelled out real clearly:
"commands": {
"action.devices.commands.OnOff": null
},
As for your issue, I think you are sending the wrong value to "google/home/execution/testSwitch/OnOff" on changes."Command delegation" only applies to piping through the incoming command "as is", the state topics are still single value mappings. That is, it LOOKS like you were sending {"on":true}
, when you SHOULD have send true
.
Thank you very much! It is working now. 68fbc4deaa8ff1933f097d1484a50911386af61b helped to understand the examples.
Maybe in the future there could be a "delegation mode" for states?
This app is a bridge between Google's API (request-response) and MQTT (pub-sub / asynchronous fire and forget); that difference limits my options. The alternative is to act as a bridge to arbitrary WebHooks instead and make someone do the JSON building themselves in something like node-red. That actually has a lot of advantages because Google implements different traits in a pure request-response manner that I CAN'T accommodate with a pub-sub model... but obviously would REQUIRE something like node-red in the picture... at which point I've basically recreated NORA, but with the OAuth / Google API handling moved locally.
That said, Google has added several traits that I can't handle with this model. I handle CameraStream for instance because... well because I wanted it... but there is a portion of it I can't support: auth tokens. That is a pure request-response action, where the request would require generating a new token and returning it, which I can't do without delegating the entire command AND getting a response from outside which MQTT is not suited for.
Having a "WebHook" option would actually solve that, while maintaining the rest of the MQTT bridging for basic pure-state traits... but on the other hand, you'll find a comment in the code around the "response faking" I do that I consider my approach there pretty ill conceived anyway. There's an inherent race condition in a pub-sub protocol where I have to wait for the state to come back to be able to generate a response, so I FAKE it by taking current state at the time, overlaying the command param values (transformed), and returning that, and hoping ReportState cleans up any discrepancies. That DOESN'T completely handle pure request-response traits...
But having a WebHook option for those situations could give an alternative without throwing out the whole model and going to something like a pure NORA node-red model. I have actually considered the possibility of dropping the MQTT binding in favor of competing with NORA like this, but frankly if he just distributed the server side piece for you to run locally, its BASICALLY the same thing.
Sorry this is mostly me brainstorming. I don't think your case (OnOff) makes a case for this, but some of the other traits COULD. I will keep this option in the back of my head as we go forward as a possibly addition in the future.
As your original issue is resolved, I'm going to close this.
Hi i8beef,
I created a "testSwitch" which should report its state to homegraph. To simplify things I set the state topic to the standard delegate topic. Now everytime I set the device to ON via the Google Home App, the switch shows ON for a second an then switches back to OFF in the App. (the real state is still ON, no MQTT message with "on": false.) As far as I can see the MQTT payload is correct
Most likely this is a configuration error on my side. But I currently have no clue what to look for.
Device configuration of "testSwitch"
LOG of switching "testSwitch" on via Google Home App.