NEWS

@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:)

@australien Klingt nett, was da im README bei Github steht: Der Proxy braucht die Hersteller Cloud nicht....

The connection to the TSUN Cloud is optional and can be switched off in the configuration (default is on). Then no more data is sent to the Internet, but no more remote updates of firmware and operating parameters (e.g. rated power, grid parameters) are possible.

@waxkarle sagte in Parsen Wert ermittel:

gibt es eine Möglichkeit an die Werte zu kommen?

Schau mal hier: https://forum.iobroker.net/topic/81260/aktienkurse-aus-seite-auslesen/7
Vielleicht hilft Dir das weiter.

@wurstdlx Ja, kannst Du.

@recaremo said in ioBroker Migration SD - USB:

Sorry, das Log soll ja nicht ausgewertet, kommentiert oder sonst was werden. Soll nur zeigen Restore erfolgreich abgeschlossen.

Wenn das Log nicht mal gelesen werden soll, dann erspar uns bitte das Postings.
Da ich aber davon ausgehe, dass du durchaus anbietest das Log zu lesen, dann poste es bitte auch lesbar. Nicht jjder sitzt vor einen 48 Zoll Bildschirm.

Ergo
Log (vom PC) NIEMALS als Screenshot posten sondern unter Code Tags. Screenshots ausschließlich dann wenn entweder Grafische Element wichtig sind oder ein Test Copy (z.B. von Geräteeinstellungen) nicht sinnvoll möglich ist.

Danke für deine Mithilfe.

@Codierknecht
@paul53

Danke Euch zwei, klappt 🙂

@infomathi83

meine erste Vermutung währe, das sich Datenpunkte verändert haben, oder sich nicht mehr aktualisieren weil die was umgebaut haben. Mal geprüft ob alles noch beim alten ist und sich regelmäßig aktualisiert, bzw. soweit wie es sollte.

@wendy2702

Ja - beenden ist schont deine Zeit.

Das einzige Ziel des TE lt Beitrag im Paralleltopic (https://forum.iobroker.net/topic/81215/modbus-verbindung-zu-codesys-runtime-herstellen/11) ist:

Zieldefinition:
Interfunktionalität der Adapter
interdisziplinäre Modbus-TCP Kommunikation.

Und ohne detaiullierte Information über Zeil und Einstellungen / Logs wird hier niemand weiterkommen.