Add deyeidc to latest

[raschy]

Please add my adapter ioBroker.deyeidc to latest.

This pull request was created by https://www.iobroker.dev c0726ff.

[raschy]

Bluefox ist also invinited to npm

[mcm1957]

Link to repo: https://github.com/raschy/ioBroker.deyeidc

adapter checker seems to be OK:
[W171] "common.title" is deprecated in io-package.jon
[W400] Cannot find "deyeidc" in latest repository

@GermanBluefox
Why does automatic checker report "No changed adapters found?"

[mcm1957]

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

I would like to give some (preliminary) feedback based on my personal oppinion. This is NOT an offical review and @Apollon77 might have several additional suggestions or even a different oppinion to one or the other statement. Please feel free to contact him (or wait for a response from him) if you cannot follow my suggestsions or before you spend major effort.

• some error text is in german

  I would suggest to use english error messages or to support multilanguage error text, but not to use german only text as ioBroker is an international software.

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

Thanks for reading and evalutaing this suggestions.
McM1957

[mcm1957]

RE-CHECK!

[raschy]

Please RE-CHECK the Release 0.0.7 from 27.05.2023

[raschy]

Please RE-CHECK the Release 0.0.9 from 10.07.2023

[mcm1957]

[W505] setTimeout found in "main.js", but no clearTimeout detected - false positive

[raschy]

Do I have to do anything else to get into the latest repository with the adapter?

[mcm1957]

Do I have to do anything else to get into the latest repository with the adapter?

No not st the moment.
Its just time to wait for official review by @Apollon77

thanks

[github-actions]

Automated adapter checker

ioBroker.deyeidc

👍 No errors found

• 👀 [W400] Cannot find "deyeidc" in latest repository
• 👀 [W505] setTimeout found in "main.js", but no clearTimeout detected

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

[mcm1957]

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

I would like to give some additional (preliminary) feedback based on my personal oppinion. This is NOT an offical review and @Apollon77 might have several additional suggestions or even a different oppinion to one or the other statement. Please feel free to contact him (or wait for a response from him) if you cannot follow my suggestsions or before you spend major effort.

• Readme.md - text Developer Manual

  The header "Developer Manual" seems to be a left over.
  https://github.com/raschy/ioBroker.deyeidc#developer-manual

  But this is no blocking point for sure - it's onbly a cosmetic feedback.

• onStateChange handler ignores ack flag

  The adapter must honor the ack flag when processing onStateChange events. Whenever the onStateChange handler is called for an own state (a state owned by the processing instance of the adapter) it must ignore this event if the ack flags is set. Only stateChanges with ack==false are allowed to be processed.

  When processing foreign states which are output of another adapter processing must only occure if the ack flag is true.

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!

Note: W505 setTimeout is a false positive.

[raschy]

I would also like to thank someone for taking care of the adapter.
I can certainly change the title in the readme. But what should 'onStateChange handler ignores ack flag' tell me? At the moment I don't have a starting point where I need to make a change. Can I please get an explanation or a concrete action?

[mcm1957]

Current code is

	async onStateChange(id, state) {
		if (state) {
			// The state was changed
			//this.log.debug(`state ${id} has changed to ${state.val}`);
			if (id.indexOf('Power_Set') > 1) {
				await this.setPower(id, state);
			} else {
				await this.updateData(await this.computeData(id, state));
			}

You can simply change

    if (state) {

to

    if (state && !state.ack) {

Background:

Every state has an ack flag.
Whenever the adapter sets a value of an OWN state it also sets ack=true indicating the value is confirmed.
If some external source (user, script, other adapter) sets the value of an state it must set this value using ack=false indicating that that value is not yet confirmed by the target adapter. An adapter must only react if the ack-flag of an own state is false and ignore writes to own states with ack=true. (This is i.e. important if a state is written from external source but also by the adapter during updating values. Otherwise setting the value by adpatercode would trigger the adapter action and hence possibly result in some processing loop).

When listening to external states (States of other adapters) most likely the code should react on ack=true only.

[raschy]

Thank you for the quick answer and the detailed explanation.
In principle, that may be correct. In my adapter, all states are stored with ack:true. Since I check for my own state here, the check for if (state && !state.ack) will then never occur. To make this 'adapter compliant' I would have to check for if (state && state.ack). This would be feasible, but in my opinion it does not really help.

[mcm1957]

Thank you for the quick answer and the detailed explanation. In principle, that may be correct. In my adapter, all states are stored with ack:true. Since I check for my own state here, the check for if (state && !state.ack) will then never occur. To make this 'adapter compliant' I would have to check for if (state && state.ack). This would be feasible, but in my opinion it does not really help.

I do not really understand...
Who is writing to the subscribed states? Your own adapter or some external software (user, script, other adapter)?

Its ok if your OWN adapter writes with ack-flag true. But in this case I do not see why you would take the overhead of onStateChange processing?

External code should write with ack=false.

[raschy]

The data points that are subscribed to there are set by the adapter itself. I cannot judge how much overhead the onStateChange produces. I have not seen any other way to solve this.

[mcm1957]

As asking for another solution. I guess you could call "doProcessing" directly after a setState the same way as using an onSetState callback. So I do not see the problem to do it directly.

But I will leave this to @Apollon77 to decide whether its OK that a adapter communicates with itself using subscribed states.
For me its - except this point - OK.

[mcm1957]

@Apollon77
Please check / comment / merge

[raschy]

I understand the concern about the correct, resource-saving way of working of an adapter. However, since the data points can be freely selected by the user and I do not know which data points are to be "used", I find it very difficult to find the other way at the moment. Nevertheless, I will pay special attention to this point in any further development.

[mcm1957]

According to feedback at telegramm this logic is OK.
so lgtm ...

[mcm1957]

ok to release according to tg

[mcm1957]

@raschy

This adapter has been released to latest repository and should be visible within 24h maximum.

Please create a thread at https://forum.iobroker.net/category/91/tester titled like "Test Adapter " to collect some user feedback and provide a link to this topic when requesting addition to stable repository later.

Note: If an other testing topic already exists, ist OK to continue using this topic too.

[raschy]

Thank you for including the adapter in the latest repository.
There is already a thread (https://forum.iobroker.net/topic/63899/neuer-adapter-cloudfreie-auslesung-von-deye-invertern) that I would like to continue.

[mcm1957]

Thats totally OK