Return tan to API requests whenever possible

[m-seker]

Summary

Fixes #1001

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Docs
• Build-related changes
• Other, please describe:

If changing the UI of web configuration, please provide the before/after screenshot:

Does this PR introduce a breaking change? (check one)

• Yes
• No

If yes, please describe the impact and migration path for existing setups:

The PR fulfills these requirements:

• When resolving a specific issue, it's referenced in the PR's body (e.g. Fixes: #xxx[,#xxx], where "xxx" is the issue number)

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature
• Related documents have been updated (docs/docs/en)
• Related tests have been updated

PLEASE DON'T FORGET TO ADD YOUR CHANGES TO CHANGELOG.MD

• Yes, CHANGELOG.md is also updated

To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.

Other information:

[hyperion-project]

Hello @m-seker 👋

I'm your friendly neighborhood bot and would like to say thank you for
submitting a pull request to Hyperion!

So that you and other users can test your changes more quickly,
you can find your workflow artifacts here.

If you make changes to your PR, i create a new link to your workflow artifacts.

Best regards,
Hyperion-Project

[Paulchen-Panther]

I'll check it out tomorrow. thank you

[dermotduffy]

Tested in a custom build! Thank you for the quick fix, this works as expected and now includes the tan:

{"command": "clear", "tan": 29}
{"command":"clear","error":"Errors during specific message validation, please consult the Hyperion Log","success":false,"tan":29}
{"tan": 30}
{"command":"","error":"Errors during message validation, please consult the Hyperion Log.","success":false,"tan":30}

This example continues to NOT include the tan, but its entirely malformed JSON, so I think that's much more reasonable/expected:

{"malformed", "tan": 32}
{"command":"","error":"Errors during message parsing, please consult the Hyperion Log.","success":false,"tan":0}

Thanks again.

[dermotduffy]

@m-seker Hmm. Unintended consequence:

{"command": "serverinfo"}
{"command":"serverinfo","error":"Errors during specific message validation, please consult the Hyperion Log","success":false,"tan":0}
{"command": "serverinfo", "tan": 1}
{"command":"serverinfo", ... lots of content ... }

... from the logs ...

 2020-09-10T05:32:52.899Z [hyperiond JSONCLIENTCONNECTION] (ERROR) While validating schema against json data of 'JsonRpc@::ffff:<IP_ADDRESS>':[root].tan: integer expected

=> Accidentally made tan a mandatory field?

[m-seker]

@dermotduffy You are right, I fixed it, it should be OK now.

[dermotduffy]

@m-seker Rebuilt, now works without tan, thanks.

A question: Is there an intended distinction between tan==-1 and tan==0?

garbage
{"command":"","error":"Errors during message parsing, please consult the Hyperion Log.","success":false,"tan":0}

vs

{"command": "clear"}
{"command":"clear","error":"Errors during specific message validation, please consult the Hyperion Log","success":false,"tan":-1}

[Paulchen-Panther]

@m-seker
Would you like to look again because of @dermotduffy problem with the output of TAN 0 and TAN -1? Or can I merge this PR and you check back later?

[hyperion-project]

Here is your new link to your workflow artifacts.

[m-seker]

@dermotduffy I couldn't decide whether it should be initialized to 0 or -1, 0 seems better fitted. Thanks @Paulchen-Panther