NEWS

@rrov1
danke Dir, ich hab das schon relativ hinbekommen.

Ich habe irgendwie jedoch im io ne Fehlermeldung:

script.js.common.Spa.SpaUpdateValues: *** stderr: Error: Command failed: python3 /SpaController/spa_updateBulk.py 54657**********a2d3-7b6acda379a4 http://172.17.0.4:8087 SPA80:********:2c 192.168.188.68 javascript.0.Datenpunkte.SwimSpa 2025-07-09 21:48:42,362> ERROR Cannot get full struct, protocol retry count exceeded 2025-07-09 21:49:30,203> ERROR Exception during spa connection Traceback (most recent call last): File "/usr/lib/python3.11/asyncio/runners.py", line 190, in run return runner.run(main) ^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/asyncio/runners.py", line 118, in run return self._loop.run_until_complete(task) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/asyncio/base_events.py", line 640, in run_until_complete self.run_forever() File "/usr/lib/python3.11/asyncio/base_events.py", line 607, in run_forever self._run_once() File "/usr/lib/python3.11/asyncio/base_events.py", line 1884, in _run_once event_list = self._selector.select(timeout) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/selectors.py", line 468, in select fd_event_list = self._selector.poll(timeout, max_ev) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/SpaController/spa_updateBulk.py", line 52, in alarm raise SystemExit("Timed out: Maximum script runtime reached.") SystemExit: Timed out: Maximum script runtime reached. During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/local/lib/python3.11/dist-packages/geckolib/async_spa.py", line 367, in connect await self._connect() File "/usr/local/lib/python3.11/dist-packages/geckolib/async_spa.py", line 239, in _connect config_file_handler = await self._protocol.get( ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/geckolib/driver/async_udp_protocol.py", line 146, in get await config_sleep(GeckoConfig.PAUSE_BETWEEN_RETRIES_IN_SECONDS) File "/usr/local/lib/python3.11/dist-packages/geckolib/config.py", line 105, in config_sleep await asyncio.wait([ConfigChange], timeout=delay) File "/usr/lib/python3.11/asyncio/tasks.py", line 418, in wait return await _wait(fs, timeout, return_when, loop) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/asyncio/tasks.py", line 525, in _wait await waiter asyncio.exceptions.CancelledError Timed out: Maximum script runtime reached.

Kannst Du damit zufällig was anfangen?

@sascha-hartmann Wenn Du da eine PV Batterie erfolgreich mit genutzt hast, passt evtl. die Verdrahtung oder die Parameter nicht.

Verdrahtung könnte man mal A / B auf einer Seite tauschen. Endwiderstände nicht vergessen, wenn keine im Gerät verbaut sind. (120 Ohm). Parameter abgleichen (meist 9600 Baud)

RS 485 Treiber kann man hinter RS 232 Chips schalten. Evtl. ist sowas in Deinem Stick gemacht worden.

RS 485 gibt es einmal als Modbus, wo man mit Adressen arbeiten muss, aber auch als Punkt zu Punkt - Verbindung. Dann haben die Geräte keine Adresse (angegeben). Da wird RS 485 nur wegen der möglichen 1200 Meter Kabelstrecke genutzt, verhält sich aber in der Kommunikation wie RS 232.

@sent1
2 Beiträge parallel zu "bespielen" ist nicht unbedingt sinnvoll. Da das Gerät lt. Beschreibung MQTT spricht bleibt ja nicht viel Auswahl.

@io2345 Falls sich doch noch jemand findet, den das interessiert: Ich habe es hier nochmal offiziell gemeldet:
https://github.com/iobroker-community-adapters/ioBroker.email/issues/398

io2345 created this issue in iobroker-community-adapters/ioBroker.email open [outlook] Mail sending not working from scripts. Test from adapter is ok #398

@master67
Dann spendiere dem Nachbar doch noch ein Bier 🍺

@feuersturm Ja, na klar. Auch den Admin-Adapter reinstalliert.
Werde das wohl auch mit dem History-Adapter machen

UPDATE:

History-Adapter neu installiert - alles okay - es geht wieder :-))

Danke - auch für den Tipp mit "iob diag" ( kannte ich noch nicht ).

Lg

@reinhard-boehm sagte in Alexa2-Adapter Problem bei Amazon-Anmeldung:

bekomme auch den Code per SMS geschickt.

https://github.com/Apollon77/ioBroker.alexa2?tab=readme-ov-file#problem-with-cookie-determination-with-sms-based-2fa-flow

@matt77che

Schau in's Log rein.

@b-freak

Auf den Server schaltert man sich per SSH auf.
Wie willst du die Kiste genau administrieren? Ein Terminal wie z. B. die Powershell, puTTY usw. ist da meiner Meinung nach unerlässlich.

@arteck Eine USV sollte schon korrekt eingerichtet werden. Dann greifen auch die Regeln. Das automatische Wiedereinschalten sehe ich als Kür statt als Pflicht. Die Datenträger zu schützen als Pflicht.

Setzt man eine USV ohne irgendwelche Meldungen an den Server ein, dann verschiebt sich das Problem korrupter Datenträger womöglich nur nach hinten.

@thorsten-s-0 Danke.

Im LATEST Repository gibts relese 2.6.2. Warum der Maintainer diese noch nicht für STABLE freigegeben hat kann nur er sagen.

2.6.3 ist nur ein temporärer nicht genauer definierter Softwarestand auf Github.

Von direkten Installation von GitHub - insbesondere auf produktiven Systemen - wird explizit abgeraten.

GitHub Versionen können sich jederzeit (auch kurzfristig) ändern und durchaus auch in sich inkonsistent und fehlerhaft sein. Versionsangaben von GitHub Installationen sind Schall und Rauch da die Versionsnummer zumindest bei Verwendung der standardmäßigen Umgebung erst im Zuge der Releaseerstellung geändert wird.

Auf explizite Aufforderung durch den Entwickler kann eine GitHub Installation zur Fehlereingrenzung oder zum Test neuer Funktionalität - unter Inkaufnahme des erhöhten Risikos - natürlich erfolgen.

Adapter die nur via GitHub oder npm (also NICHT aus einem der beiden Repositories) installierbar sind sind mit erhöhter Vorsicht zu betrachten. Hier sollte der Entwickler drum ersucht werden eine Aufnahme in die Repositories zu veranlassen indem z.B. ein Issue im Adapterrepository erstellt wird.

Und falls es irgendwie unklar ist:

ioBroker unterstützt folgende Arten von Installation:

aus dem STABLE Repository

Das sind Adapter Releases die keine groben Fehler aufweisen (sollten). Natürlich kann es auch dort Fehler geben, die Behebung davon obliegt dem jeweiligen Dev und kann ggF auch dauern.

aus dem LATEST Repository

Das sind Adapter Releases die neu erstellt wurden und nur rudimentär getestet sind - oft auch als BETA Releases bezeichnet. Releases aus dem LATEST sind primär für unsere zahlreichen freiwilligen Tester gedacht. BETA / LATEST Releases können durchaus Fehler aufweisen - auch wenn ich davon ausgehe dass jeder aintainer dies zu vermeiden versucht. Vom Einsatz auf produktiven Systemen wird abgeraten außer man braucht irgenein neues Feature (z.B. neues Gerät) unbedingt. Hier muss dann jeder Entscheiden was ihm wichtig ist.

direkt von GITHUB

Von Installationen direkt aus Giuthub wird definitiv abgeraten außer auf Anweisung des Maintainers und für den Fall dass man gemeinsam mit diesem etwas testen will. Details siehe oben.

direkt von npm

Diese Installation kann erforderlich sein, wenn man eine bestimmte Version installieren möchte / muss. Im Normalfall sollte man direkte npm Installationen ebenso meiden wie direkte GitHub Installationen - ausgenommen um z.B. zu einer bekannten Version downzugraden - obwohl hier wenigstens ein definierter Stand garantiert ist.

Adapter die NUR via npm und/oder nur via GitHub installierbar sind sollte man meiden - diese wurden nicht mal einem rudimentären Review unterzogen und sollten mit dem Attribut "vollständig auf eigenes Risiko verwenden" installiert werden. Hier empfiehlt es sich den Developer zu ersuchen eine Aufnahme in die Repos zu veranlassen. Wenn dieser darauf nicht reagiert sollte man von einer eher kurzen und unklaren Lebensdauer des Adapters ausgehen. Support meiner-/unsererseits für solche Adapter ist mit Sicherheit minimalistisch.

@mcm1957

@pingo ich hatte es gelöst und es hat auch ne ganze weile gut funktioniert, aber anscheinend hat growatt was umgestellt, bei mir geht es nicht mehr, eventuell jemand ne lösung?

@ro75 Das hat funktioniert. Frage alle drei Minuten ab und schon ist die Meldung weg. Danke für die Info!
Aber seltsam, da man IIRC laut Beschreibung des Servers 10.000 Abfragen täglich durchführen kann. Das wäre ja alle 7 Sekunden wenn ich richtig rechne.

Hallo zusammen,
ich habe es auch nicht hinbekommen mit Fronius zu kommunizieren.
Die Verbindung bei Fronius bleibt einfach rot.
Ich habe eine GEN24 10kW und einen Huawei 10kW.
Der Huawei soll als virtueller Zähler über den Modbusadapter ausgelesen werden und die Daten dem Fronius übermitteln.

Könnt ihr mir weiterhelfen? Vielleicht reicht es für den Anfang wenn ihr eure Einstellungen inkl. Register teilt, dann könnte ich es damit versuchen.

Modbus-Test abgeschlossen. Der Adapter taugt für micht nichts. Als Client, wie beschrieben, so lala, als Server hat es nichts gebracht. Ich rate davon ab. Vllt. um einen WR auszulesen brauchbar, aber das war ja nicht das Ziel.
Der Quelltext sieht so aus, als ob alles vollständig implementiert ist, aber mehr Zeit verbringe ich damit nicht mehr.

MQTT ist mir zu kryptisch per Variablennamen, Funktionsaufrufen etc. Das straight-forward einzubinden ist müßig für komplexere Strukturen. Sicherlich gibt es Frameworks, die über MQTT abstrahieren, aber es ändert den Kern der Sache nicht.

Letztlich hat sich OPC UA bewährt, nahezu reibungslos, auch mit NodeRed.
(Von dem OPC-Adapter rate ich ab)
Die Zertifikate bringen auf allen Teilnehmerseiten zwar ein paar Eigenheiten mit, aber dafür hat man ggü. MQTT auch ein objektorientiertes und transportübergreifendes Protokoll mit allen Finessen.
Nur leider deutlich mehr Overhead als Modbus.
Influx lässt sich anbinden. Was will man mehr:)