Announce: 1.3.0 changes
i8beef opened this issue · comments
I have just released 1.3.0. There are breaking changes here for upgrades:
ASPNETCORE_PATHBASE removal
Removes environment variable ASPNETCORE_PATHBASE requirement. This setting is now a config variable called appPathBase to eliminate confusion over this ONE ENV var being necessary.
If you have issues accessing the user interface after upgrading, check that you've added this to your config file (set to same '/google/home' or other proxy path that would have been applied to the ENV variable before).
IdentityServer 4 auth updates
Updated some of the IdentityServer 4 changes that are needed to use their newer recommendations for setup of the OAuth system. As they are going commercial, I wanted to be on the latest in case their support / documentation goes to hell.
If you experience any issues with account linking / tokens, please report here, as the first try for this required rollback...
Delegate command changes
"Delegate commands" have been reworked. Instead of requiring a topic map of "_" to be used in config files, the app will now automatically publish ANY incoming command to a standardized location defined by google/home/execution/DEVICEID/COMMAND. This is a more generic solution that would open the possibility of a "pure delegation" approach out of the box for those wanting to handle all processing externally instead of by the relatively simple state mutations this app allows. Note: Current validation rules would prevent this, but this will be opened up in the future.
As an example, a device with id "my/special/device" will have any "action.devices.commands.ColorAbsolute" command's params sent as a serialized JSON object to the topic google/home/execution/my/special/device/ColorAbsolute.
Any of these existing "_" topics should be removed from config files in the future, and move to these new topic subscriptions.
Request response logging
Adds request/response logging via "Verbose" log level for debugging purposes, which will log the entire JSON request / response.
You probably don't want to leave this on long term as it cranks the log level for everything across the board and will generate a lot of logs. It will also leak semi-sensitive data such as Bearer token usages in HTTP clients, so be aware of this.
Additional fixes
- Any trait can be assigned to any device again. Google has cleared up that this is their intention.
- Validation fixes for fanSpeed commands as Google added options for setting by percentage.
Maybe you can put the description of Delegate command changes also on the wiki.
Maybe make the "google/home/" part from google/home/execution/DEVICEID/COMMAND configurable ?
If you'd like to request that the topic root be configurable, can you make a separate ticket so I can track the work?
Thanks. I will do.
Regarding "delegate mode": Will there be a way to also report the state in the same format?
Maybe to something like this? Which accepts the same kind of payload like the execution generates.
google/home/state/DEVICEID/COMMAND
QUERY / ReportState are currently both driven by the "state" of each trait. As you publish the updated "state" MQTT messages, those update the internal state for the trait, which gets reported to Google appropriately.
This isn't 100%, as there are several different "approaches" to command handling... It generates a fake response by transforming the incoming command params into a response... which requires a bunch of maintenance to support everything (and falls short in several areas). I kinda have to do this to get the "current" value and generate a response before any of the effected state may have actually changed (Google has been unclear on if this is actually necessary for non-request-response commands, relying on response state instead would be much cleaner for my implementation....).
I am actually reworking a lot of this right now to base a lot of processing off Google's published schemas instead of trying to track their changes manually... it will still have to "fake" some state here with some hard coded value copying between request and response, but validation, "command response only" state, and some other things should open up here then.
Closed as of 2.0 release.