Add blauberg-ventilation to latest

[intellicasa]

No description provided.

[mcm1957]

@intellicasa
You adapter might solve the this adapter request
ioBroker/AdapterRequests#286
As theres a statement that the vents noted are compatible / identical to blauberg.

Please take a look at that reqeust and comment / confirm or rejec this assumtion based on your knowlegse.

[mcm1957]

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.

• Readme.md is very short

  The README.md of this adapter is very minimalistic. Please add a short description about the functionality of the adapter, add links the the manufacturer site (if applicable) and add a description of the configuration of the adapter (if it's not completly self explainig). If you provide an external documentation - which should be located at doc/xx directory - please add links to at least the english documentation.

• 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, '_');
  }
  

  You are creating states based on entry done by user (vent.name). This entry is already filtered/converted. Please ensure that it contains only valid characters (see FORBIDDEN_CHARS). In addtion you should ensure that all names are unique and even unique after conversion.

• use async and await with asynchronous calls

  Most of your routines should be asynchronous as they call asynchronous routines themself.

  You should use await at asynchronous calls unless you really do not care when the call is processed.
  i.E. setObjectNOtExistsAsync without an await might cause random effects as the creation of the object might be completed until is is accessed next - or not
  see https://github.com/intellicasa/ioBroker.blauberg-ventilation/blob/5ef6714b58892ef160bcb5792a2858cde9a9f45d/main.js#L196 as an example.

  But this topic should be reviewed forthe whole code.

• 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.

  Please note that role value required write=false. Input states (write:true) could be of role level as an example.
  But maybe you bind better matching roles. If possible try to configure all states i.e. using a table. Correct roles ease usage for vis applications and typedetector to decide what kind of a device the adapter handles.

• consider using adapter.setTimeout / this.setTimeout instead of (standard) setTimeout

  The adapter package provides wrapper routines for native setTimeout, setInterval, clearTimeout and clearInterval. Using those routines ensures that timers are cancelled on on load. Additional checks on thomse limits might be performed, too. So consider replacing native setTimeout/clearTimeout by adapter.setTimeout/adapter.clearTimeout or this.setTimeout/this.clearTimeout. The same refers to setInterval/clearInterval.

• check and limit configurable timeouts / intervals

  Node setTimeout/setInterval routines have a maximum allowed value of 2,147,483,647 ms. Using delays larger than 2,147,483,647 ms (about 24.8 days) result in the timeout being executed immediately. So all (user configurable) values passed to setTimeout / setInterval should be checked in code and limited. Checking/limiting in code is required as config data could be changed directly or by some other adapter too, so limiting at ui level might not be sufficient.

• ensure that all operations are completed within intervalls

  As users could configure a encreasing number of vents it could be hard to ensure that querying all vents is compete within one interval period. If querying would last longer than one interval period multiple scnas would start to run in parallel and fianlly overloading the system.

  So please evaluate to either add a sort of firewall (busy flag) to avoid multiple paralel executions of the scan loop or (in most cases better) replace intervall by a timeout started at every scan completion.

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!

[mcm1957]

reminder 01.01.2024

[mcm1957]

reminder 31.01.2024

[mcm1957]

How should we continue?
Do you need any further help?

Please let me/us know (by adding a comment) when all issues noted earlier are processed by you and a new review seesm to be appropiate.

If there is no response until 28.2.2024 this PR might be closed.

reminder 15.2.2024

[mcm1957]

How should we continue?
Do you need any further help?

Please let me/us know (by adding a comment) when all issues noted earlier are processed by you and a new review seesm to be appropiate.

If there is no response until 28.2.2024 this PR might be closed.

reminder 22.2.2024

[mcm1957]

How should we continue?
Do you need any further help?

Please let me/us know (by adding a comment) when all issues noted earlier are processed by you and a new review seesm to be appropiate.

If there is no response until 28.2.2024 this PR will be closed.

reminder 28.2.2024

[mcm1957]

As there was no reaction to the lastest status polls this PR will be closed now.

Feel free to create a new PR at any time if you plan to further maintain / fix this adapter.