Add google-home-nest to latest

[danieldriessen]

No description provided.

[mcm1957]

Thanks for spending your time and providing a new adapter for ioBroker.

Your adapter will get a manual review as soon as possible. Please stand by - this might last one or two weeks. Feel free to continue your work and create new releases. You do NOT need to close or update this PR in case of new releases.

In the meantime please check any feedback issues logged by automatic adapter checker and try to fix them.

You will find the results of the review and eventually issues / suggestings as a comment to this PR. So please keep this PR watched.

If you have any urgent questions feel free to ask.

reminder 22.05.2024

[github-actions]

Automated adapter checker

ioBroker.google-home-nest

-

👍 No errors found

• 👀 [W184] "common.main" is deprecated and ignored. Please remove from io-package.json. Use "main" at package.json instead.
• 👀 [W400] Cannot find "google-home-nest" in latest repository

Add comment "RE-CHECK!" to start check anew

[mcm1957]

@danieldriessen

First of all - THANK YOU for the time and effort you spend to maintain this adapter.

I would like to give some feedback based on my personal oppinion. @Apollon77 might have additional suggestions or even a different oppinion to one or the other statement. Please feel free to contact him if you cannot follow my suggestions or want to discuss some special aspects.

• io-package.json should require up to date js-controller and admin version

  New adapters should request js-controller 5 and admin 6 as minimum if there are no strong reason to support (and test) older releases. So please add / adapt at io-package.json:

        "dependencies": [
            {
                "js-controller": ">=5.0.19"
            }
        ],
        "globalDependencies": [
            {
                "admin": ">=6.13.16"
            }
        ]
  

• sensitive information, especially passwords should be stored encrypted

  You configuration seems to contain passwords (or other sensitive information) which is not stored encrypted. As long as those information is not stored inside a table you can encrypt and secure this infomation simply by adding the following configuration to io-package.json. The iob runtime will encrypt / decrypt the data as required; no addition programming effort is required. Note that users will need to reenter this info one time after adding encryption, so drop a note at release notes.

  "encryptedNative": [
    "password",
    "data2"
  ],
  "protectedNative": [
    "password",
    "data2"
  ],
  

  At least 'client-secret' seems to be worth protecting, if other senstive information (cloud access data) exists this should be protected too.

• sensitive information should not be logged into logfile

  To avoid publishing sensitive information when forwarding logs, those information should never be written into the logs but either omitted or at least partly masked so that the information cannot be misused. This relates at least to usernames, passwords, uniqui (user assigned) keys and tokens. In addition personal information like name, address, gegraphical coordinagtes should not be logged too.

  relates to client secret and maybe other security information

• sensitive information should not be stored at states

  You seem to store the client secret at a stae? Why do you do this? The secret will be accessible suing this.config whenever needed. And I do not expect that the client secret should be readable by anyone using the system neither that it should be changed by other adapters. State names and data are more or less public - to any securiyt relevant data should neither be part of an id or be stored within a state as other Adapters, any user of admin and depending on vis any vis user could access them.

  Do you really need the access tokens to be preserved when restarting the adapter? Otehrwise they should not be store at states too.

• invalid characters should be filtered from object ids

  Some characters are not allowed to be used as part of an object id. If an object id is not hardcoded or even depending on user input you should ensure that such an object id does not contain an invalid character. Iobroker provides the constant adapter.FORBIDDEN_CHARS, i.e. by using the following snippet:

function name2id(pName) {
    return (pName || '').replace(adapter.FORBIDDEN_CHARS, '_');
}

Looks like some parts of the object / state id are retrieved from external sources, i.e. the 'deviceId' Those parts (or the complete id) must be filtered to not contain any forbidden character.

• onStateChange handler only for deletion?

  Using an onStateHandler only to detect the delition of an state and to recreate it looks like an overhead as every stateChange must be processed by js-controller. and every subscription required the js-controller to process one more regex if any adapetr changes any state.

  So why not simply create the state whenever it shoudl be wirtten?
  Or simply create the state during startup only?
  I do not know any adapter which tries to fix deleted states during runtime - besides you approach will not work 100% anyway as there is no guarantee that the onStateChange is called after deleting a state befor any other access of your adapter occures.

  I would suggest to remove the onSateChange handler and to create states during startup only.

• reevaluate state roles

  Only the values specified here (https://github.com/ioBroker/ioBroker.docs/blob/master/docs/en/dev/stateroles.md) may be used as state roles. Do not invent new names as this might disturb the functionalyity of other adapters or vis.

  In addition the roles MUST match the read/write functionality. As an example a role value.* requires that the state is a readable state. Input states (write only) should have roles like level.*. Please read the description carefully. States with role 'button' should (must) have attribute 'common.read=false' set. A button ( "Taster" in german only triggers when you press but else has no state), so it should also be not readable. This is also like HomeMatic does it. A switch has clear states true or false and so can be read.

  Please avoid using general roles (state, value) whnever a dedicated role exists.

• Is there any reason to not use i18n translation environment?

  I suggest to evaluate to use i18n translation environment and the iobroker/adapter-dev environment (https://github.com/ioBroker/adapter-dev#iobroker-adapter-dev). You could easyly add new strings to the english json and run npm run translate afterward. When using i18n environment activating iobrokers weblate translation system (see https://github.com/ioBrokerTranslator/doc) is trivial.

  You have store translation directly at jsonConfig.json. Consider moving them into i18n/translation.json files.This would allow the use of weblate connection and hence adapting translations be native speakers withou direct access to repo files.

  This is only a suggestion and NOT blocking.

• Add timeout to axios calls

  All axios calls should have a timeout set. The default value for axios timeout is 0 which results in no timeout. So an unresponsive remote system could lead to an hanging adapter. Either set an appropiate timeout per axios call or set a default timeout globally for the axios instance.

• do not mix await and .then

  While javascript allows mixing 'action .then .catch' and await I would strongly suggest to clean this up. Either use await (togerther with try/catch if required) OR use .then .catch constructs. Mixing could leada to some surprising and hard to diagnose behaviour.

Thanks for reading and evaluating this suggestions.
McM1957

Please add a comment when you have reviewed and fixed the suggestionsor at least commented the suggestions and you think the adapter is ready for a re-review!

reminder 5.6.2024

[danieldriessen]

@mcm1957

Thank you for the review and for the reply.

As I mentioned in the adapter request repo., I am not a professional programmer. Therefore I knew that my code would probably be far away from perfect. On top of that, I sadly have zero javascript experience (besides the code I wrote for this adapter). So thanks again for putting me in the right direction. You probably scratched your head a lot while reviewing my code and I want to apologize for the inconvenience.

I will try to fix & improve all mentioned aspects of my code in the following days.

Thanks again.

[mcm1957]

As I mentioned in the adapter request repo., I am not a professional programmer.

No problem. Most of devs here do this at their free time and for fun.

On top of that, I sadly have zero javascript experience (besides the code I wrote for this adapter).

You code look very well. There are only seveal iobroker specific adaptions to be done. You will make this for sure. Please feel free to ask whenever you have a question. Please feel free to subscribe out telegram developer channels. Invites available at http://www.iobroker.dev.

[mcm1957]

Any news?
Do you need help?

Please feel free to ask whenever you have a question. Please feel free to subscribe out telegram developer channels. Invites available at http://www.iobroker.dev/.

Please add a comment when you have reviewed and fixed the suggestionsor at least commented the suggestions and you think the adapter is ready for a re-review!

reminder 21.6.2024

[danieldriessen]

Hey.
Thanks for offering help if needed.
I have started to work on your suggestions. Unfortunately I am not very far. But right now this has more to do with me having a lot of work currently. I hope that I will be able to work on the changes in the next week.
Afterwards I will post a comment and comment the suggestions.
Thanks again!

[mcm1957]

reminder 13.7.2024