@mcm1957 , @crunchip ,
Moin Männer und nochmals Danke für Eure Hilfestellungen.
Heute Morgen läuft es!
Wieso? Nun, ich habe noch einmal alles zurück gesetzt, die Instanz gelöscht
und alles kpl. neu aufgebaut, wobei darauf geachtet wurde, dass überall,
wo Username und Passwort zu setzen waren, auch tatsächlich identische Daten
neu und "zu Fuß" (nicht aus irgendwelchen PW-Verwaltungen) eingetragen wurden.
Und siehe, es ward Licht, nun ist alles grün und die Verbindung steht.
Nochmals DANKE!

@mcm1957 , @crunchip ,
Moin Männer und nochmals Danke für Eure Hilfestellungen.
Heute Morgen läuft es!
Wieso? Nun, ich habe noch einmal alles zurück gesetzt, die Instanz gelöscht
und alles kpl. neu aufgebaut, wobei darauf geachtet wurde, dass überall,
wo Username und Passwort zu setzen waren, auch tatsächlich identische Daten
neu und "zu Fuß" (nicht aus irgendwelchen PW-Verwaltungen) eingetragen wurden.
Und siehe, es ward Licht, nun ist alles grün und die Verbindung steht.
Nochmals DANKE!

@mcm1957 ,
vielen Dank für Deine Antwort.
Hast Recht, das war der falsche Screenshot. Richtig ist der Nachfolgende,
aber auch das funktioniert nicht.

Ich war dann mal so frei, Dir einen Kaffee auszugeben...

Hallo liebe Spezialisten,
nach nunmehr 2 Tagen heftigen erfolglosen Probierens, einen Shellystecker (Plug S der 3. Generation)
in einer weiteren Instanz des Shelly-Adapters mit MQTT-Unterstützung einzurichten, gebe ich es auf,
um nun Euch Insider um Rat und Hilfe zu bitten.
Ich füge einmal einige Screenshots ein, auf dass Ihr Euch ein Bild machen könnt:
Ich habe wegen der Error-Msgs im Protokoll

die diversten Kombinationen mit mqtt-Usernamen und mit oder ohne Passwort versucht, auch anhand
von Threads über Shelly-Einbindung hier im Forum (allerdings nur bis Gen. 2 gefunden).
Nach jeweiligen Neustarts der Instanz und auch des PlugS-3 bekomme ich dennoch immer nur

Auffällig ist mir als blutigem Laien auch, dass die Konfig-Seite des PlugS3

das Passort des Benutzernamens nach einem geforderten Neustart verliert (x-mal versucht).
btw: Die dort eingetragene Server-IP ist doch die des Raspi mit der IoB-Instanz...? Richtig?

Ich hänge noch einige Shots von Adapterkonfigs an:

Abschließend bitte ich Euch Szenekenner, mir, einem alten Sack (71), mit Euren Kenntnissen
weiter zu helfen. Wo mache ich welchen Fehler...? Vielen Dank für Eure Hinweise!

@andre-6
Hi, dieser Frage möchte ich mich anschließen.

Während einer PV-Überschussladung meines Skoda Enyaq:
Seit heute (8.3.) 11:25 Uhr keine Aktualisierung im Adapter-Objekt mehr,
im Objekt bleibt die letzte Aktualisierung wie angenietet stehen. (Modifizierter Adapter Github Vers. 0.5.1)
Gleiche Einträge in den Protokollen, wie bei Dir.

Für Eure Tipps wäre ich (Laie) sehr dankbar.

@grave-digger said in Einsteiger verzweifelt bei Adapterkonfiguration:

Solar Edge Set App runterladen, einen Account anlegen dich mit dem WR verbinden und die Einstellungen selbst machen.

Hi @grave-digger ,
Das geht nur für Installateure, und das was ich ausschließlich ansehen kann, beinhaltet nicht die relevanten Informationen...

Modbus Adressen das musst du Ausprobieren laut Doku Solar Edge ist es z. B. die 40020 jetzt Testen ob diese geht wenn nicht 40019 oder 40021 Testen.

Ja, das habe ich alles schon durch...
Ich werde mal meinen Installateur "anbaggern", der soll das mal alles überprüfen.

Einstweilen Danke für Deine Unterstützung.

@glasfaser said in Einsteiger verzweifelt bei Adapterkonfiguration:

bist du auch mal hiernach gegangen ... um den Port zu prüfen ..

Jou, habe das hier zurück bekommen:
pi@raspberrypi:~ $ nmap -sU -p 502 192.168.178.45
You requested a scan type which requires root privileges.
QUITTING!
pi@raspberrypi:~ $ nmap -Pn 192.168.178.45
Starting Nmap 7.80 ( https://nmap.org ) at 2022-12-08 07:49 CET
Nmap scan report for PVA-Wechselrichter.fritz.box (192.168.178.45)
Host is up (0.014s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
80/tcp filtered http
8080/tcp filtered http-proxy
Nmap done: 1 IP address (1 host up) scanned in 1.30 seconds

Das Gleiche auf Port 1502 und auch auf der IP des zweiten Wechselrichters (Batt.-speicher)

Demnach ist der Port (1)502 geschlossen, also nicht ansprechbar? Ist Modbus-TCP möglicherweise doch nicht aktiviert?
(Mann Mann, ich glaube, ich vergesse das ganze Thema und lese wieder das Web-Portal von SE aus... )

@thomas-braun said in Einsteiger verzweifelt bei Adapterkonfiguration:

Und besser etwas in die Grundkommandos zum Handling von Debian Linux einlesen.

Moin und vielen Dank, soetwas habe ich gesucht.

@grave-digger said in Einsteiger verzweifelt bei Adapterkonfiguration:

Schau Mal in diesem Beitrag,
https://forum.iobroker.net/topic/38322/tutorial-solaredge-modbus-iobroker-grafana?_=1670427866975
alles gut erklärt.
Versuche bitte am Anfang nur eine Modbus Adresse auszulesen

@grave-digger , Danke für Deine Mitteilung.
Ja, genau -dieses- Manual habe ich herangezogen, um zu einem Ergebnis zu kommen.
Nur eine Adresse: Ja, habe mit 40021, bzw. 40020 nochmals alles durchprobiert (Port, ID, Master...) = es bleibt dabei -> (fiktive Einheitsbezeichnung) immer nur gelb.

@glasfaser said in Einsteiger verzweifelt bei Adapterkonfiguration:

hast du es gesehen , bzw. ein Screenshot von den Einstellen in der SolarEdge " Installateur App "!?
bist du auch mal hiernach gegangen ... um den Port zu prüfen ..
https://forum.iobroker.net/topic/57719/tagessumme-der-solaredge-ermitteln-und-grafisch-darstellen

Moin und zunächst Danke für Dein Reply.
Nein, dem Installateur habe ich dabei nicht zugesehen.
Da ich ihn aber gezielt darauf hingewiesen habe, Modbus-TCP zu aktivieren, hat er auf nochmaliges Befragen 1/2 Std. später bestätigt, es freigeschaltet/eingerichtet zu haben.

Portprüfung: Am Prompt erhielt ich nur das:
pi@raspberrypi:~ $ nmap -sU -p 502 192.168.178.45
-bash: nmap: command not found
pi@raspberrypi:~ $ nmap -Pn 192.168.178.45
-bash: nmap: command not found
pi@raspberrypi:~ $

Und ich muss eingestehen, dass ich als blutiger Laie nicht die geringste Ahnung habe, wie 'nmap' nachzuinstallieren ist...

Hallo liebe Forengemeinde,
bitte erlaubt mir zunächst den kurzen Vorspann zu meinem Problem:
68-jähriger Anfänger mit neuer PVA (08/22), E-Auto und Wallbox sucht zuverlässigeres Monitoring,
als EVU- und PVA-Hersteller-Web.Portale bieten können.

Meine Hardware:
SolarEdge Wechselrichter SE9K-RW0TEBEN4, Modbus-Zähler SE-MTR-3Y-400V-A,
Batteriespeicher StorEdge 10 kWh, Batt.-Wechselrichter SE5000H-RW000BNN4,
Wallbox SolarEdge Home EV Charger 22 kW (eine umgebrandete auf 11 kW gedrosselte Keba Contact P30c).

Die Wechselrichter und die Wallbox sind jeweils mit LAN-Kabel über eine Fritz!Powerline-Verbindung
zum Router Fritz!Box 7490 verbunden. --> PVA-Installateur versicherte, 'Modbus-TCP' aktiviert zu haben.
Die Wallbox ist über Web-Portal ansprech- und auslesbar, die W.Richter melden ordnungsgemäß an SE,
das Web-Monitoring funktioniert (weitestgehend).
Weiterhin Raspberry Pi 4/8MB mit IoBroker v6.2.23 (alles vor einer Woche frisch aufgesetzt... - läuft)

Aktuelle Absicht: Einbindung der WR und WB mit allen relev. Daten zur späteren Datenspeicherung/-visualisierung, Einbindung der Wallbox ggf. mit Steuerung des Überschussladens.
Später dann Auslesung und Einbindung der Gas- und Wasserzähler mit statistischer Zielsetzung/Visualisierung.

Mein Problem:
Trotz vieler YT- und ausführlichen Anleitungen auch hier aus dem Forum und deren punktueller Beachtung
(speziell von @hennerich --> Danke für Deine Arbeit!) und Folgeautoren gelingt es mir nicht,
zunächst nur zwei oder drei Testdaten unter Holding-Register über den Adapter "ModBus"(Vers. 5.0.5)
nach dem 'Go' in den Objekten sichtbar zu machen.
Ich habe Base 0 und Base 1 (Register +/- 1) rauf und runter versucht,
ich habe Port 502 und auch Port 1502 versucht, ich habe Einstellung Master und auch Slave probiert,
ich habe Geräte ID 0, 1 und 2 versucht, mit und ohne 'Aliases benutzen', alles einzeln und nacheinander
bei jeweiliger "Erfolgs"-kontrolle... ---> Nichts, aber auch gar nichts ist zielführend.
Im Objekt sind die Ergebnisrubriken kurz grün, dann schwarz und letztlich gelb.
Ich habe noch nichts außer 0 (Null) gesehen.
In den Protokollen heißt es immer nur "Socket Error", gefolgt von "Client in error state" und der Zeile
On error: {"errno":-111,"code":"ECONNREFUSED","syscall":"connect","address":"192.168.178.45","port":1502}

Ich erbitte Eure Unterstützung per zielgerichteter Hinweisgebung. Es funktioniert bei so vielen Leuten,
was läuft bei mir falsch, was übersehe ich?

Für Eure Mühe schon jetzt meinen herzlichsten Dank.