Warning "get state error: Connection is closed."

[ioBroker-Bot]

This issue has been copied from #308

original creator @nobbiman

originally created at 2026-01-21T08:47:53.000Z

---

Describe the bug
The numerous warning messages in the logs read:
powerfox2.0 2026-01-12 13:35:07.261 warn get state error: Connection is closed.
the error messages are
powerfox2.0 2026-01-12 14:30:05.965 error error: AxiosError: timeout of 10000ms exceeded
or
powerfox2.0 2026-01-12 20:04:36.107 error error.message: getaddrinfo EAI_AGAIN backend.powerfox.energy

Expected behavior
no messages

Versions:

• adapter 0.0.14
• ioBroker 7.0.7
• node v22.21.0
• Debian Bookworm

Additional context
I'm reporting here about the numerous error messages my ioBroker adapter is generating. Unfortunately, I'm not getting any help from the community at https://forum.iobroker.net/topic/83551/powerfox2, but I don't want to tolerate these error and warning messages.
What could be the cause and how can the problem be resolved?

[ioBroker-Bot]

originally commented by @Ax-LED at 2026-01-22T16:37:50.000Z

@nobbiman

the timeout error comes from powerfox webservices which sometimes don't respond.
So this is not a fault in the adapter but comes from the Powerfox web service.

AxLED

[ioBroker-Bot]

Copying finished.

[mcm1957]

powerfox2.0 2026-01-12 13:35:07.261 warn get state error: Connection is closed.
This error is caused by a bug inside the adapter, see below

powerfox2.0 2026-01-12 14:30:05.965 error error: AxiosError: timeout of 10000ms exceeded
powerfox2.0 2026-01-12 20:04:36.107 error error.message: getaddrinfo EAI_AGAIN backend.powerfox.energy
These errors are caused be powerfox websiete and / or users dns setup. You are correct for those messages.

Lets get back to powerfox2.0 2026-01-12 13:35:07.261 warn get state error: Connection is closed.:

You are polling the powerfox website inside a loop sending axios requests for each device. As soon as axios gets an answer this answer is processed. The problem is that you process these answers using .then coding style. The block / function specified with .then is executed asynchronous in respect to the code calling axios. So the stop statement is executed IN PARALLEL to all axios calls and the resulting .then code setting the states.

As the stop function has some timeout / delay this will work in many cases but it is likely that several axios responses are returned AFTER stop has already closed the state db connection. This causes the errors listed above (and leads to some missing updates.

So you either must delay the stop be waiting for all axios requests to return or use async/wait instead of .then style as code after an await will not execute until the promise specified with await is completed.

In addtion I would suggest to migrate the adapter from scheduled to daemon as starting every minute is ruther often for a scheduled adapter. But this is not related to the problem listed by @nobbiman
see #54

[Ax-LED]

@mcm1957
Hello Martin, thank you for your suggestions. Unfortunately, I don't know how:

• I can quickly switch the adapter from scheduled to daemon
• the code should look like in order to use async/wait instead of .then

All I can say is that I have been using “my” powerfox2 adapter successfully for several years and it does what it's supposed to do.

However, I am open to pull requests for the two points mentioned above.

As a hobby coder who has never learned this, I find it very cumbersome to change an adapter and then get it back into the stable repository. The code can be changed quickly, but I don't enjoy the “deliberately high requirements” for getting the adapter into stable.

AxLED

[mcm1957]

I do not see any “deliberately high requirements” high requiremnts. Once everything is updated and the code works for users at lates repository updating the revision at stable is a click at iobroker.dev.

Your adapter did not get any updates since some time. So several pending PRs should be evaluated and merged to get an up to date release.

If you do not have time / possibilities to do these steps we can move the adapter into the iobroker-community-organisation (still with full write access for you if desired) so that others can work on the adapter too. If you have questions related to open PRs I would suggest to ask at our development channels ats telegram or dicord (invite links see www.iobroker.dev). A single PR to fix the race condition within your code would be possible of course but would include most of the other PRs too. But feel free to ask at developer channels or forum if someone has time to cleanup the code.

[Ax-LED]

@mcm1957 ,

can you guide me through the process as last time?
I am talking about the 23 PR and a change in the code to use async/wait instead of .then.

I can test it at home, as i still use powerfox.
We can also write in german, as this is your native language also.

Best regards.

AxLED

[mcm1957]

Hallo,
Ja gerne auch in deutsch.
Zuerst mal ein ganz herzliches DANKE dass du dir Zeit nimmst den Adapter zu warten.
Ich werde dich durch die notwendigen Anpassungen begleiten. Da ich aber extrem in Zeitdruck bin (nächste Woche bin ich urlaubsbedingt überhaupt offline) kanns ein wenige dauern.

Als ersten Schritt würde ich raten die exsitierenden PRs großteils abzuarbeiten.

Generell gilt: PRs NICHT mergen wenn die Tests nicht OK sind (rotes Kreuzerl, kein grünes Hakerl).

Ich werde mal jeden existierenden PR kommentieren mit "MERGEN", "WARTEN", "NICHT MERGEN".

DANKE für deine Arbeit!

[Ax-LED]

@mcm1957
Hallo Martin,

danke für deine Unterstützung, habe deine kommentierten Anweisungen soweit ausgeführt. Sind nun von 23 PRs auf 7 PRs runtergekommen. Ich habe keinen Stress die PRs schnell abzuarbeiten, richte mich da nach deiner Zeit. ioBroker soll ja ein Hobby sein das Spaß macht :-)

• [iobroker-bot] Setup Auto-Merge for Dependabot PRs #307 -> hier kann ich nicht "mergen", Meldung: This branch has conflicts that must be resolved
• Bump @iobroker/testing from 4.1.3 to 5.2.2 #293 -> hier ist nichts kommentiert, habe daher nichts gemacht

Bitte teile mir mit wie es weiter geht.

AxLED

[mcm1957]

Hab grad gesehen, dass du durch einen Fehler in der test.yml keine PRs getestest hast. Ist aber kein Problem.

Hab PR #313 erstellt der da korrigiert. Der testet grad. Mal abwarten ob OK.

[mcm1957]

OK, PR #313 hat die Tests bestanden. Bitte den PR mergen.
Sobald das erledigt ist, lass ich vom Bot den PR #307 neu erstellen.

[mcm1957]

Leider hat Github derzeit Probleme sodass Tests failen.
Siehe https://www.githubstatus.com/

Wir müssen mal bis morgen warten. Macht keine Sinn die Fehler zu ignorieren und ich kann die Tests remote nicht neu anstoßen.