UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[bolliy]

@rvn1909 versuch mal ältere Firmware Versionen. Huawei hat immer wieder Probleme mit der modbus-tcp Implmentierung.

[rvn1909]

@bolliy Wenn das so ohne Weiteres möglich wäre. Anscheinend unterstützt die EMMA kein Rollback. Wie ich da nun hinkomme ohne sämtliche Daten zu verlieren ist die Frage. Muss schauen ob ich da ne Art Backup erzeugen kann..

[bolliy]

@rvn1909 wenn für dich die Nutzung von facebook kein Problem ist, kannst du deine Fragen super gut hier stellen:
https://www.facebook.com/groups/653371832541018/?ref=share
Dort kannst du auch fragen, ob modbus-tcp Probleme bei der letzten emma Firmware bekannt sind.

[bolliy]

@rvn1909 übrigens ist nur eine modbus-tcp-Verbindung zur emma möglich. Also weder mehrere Adapter, evcc oder sonstiger Client können gleichzeitig auf die emma per modbus zugreifen. Dafür ist der modbus-proxy da, dieser ist multi-clientfähig.
Alle anderen Clients müssen den modbus-proxy nutzen.

[rvn1909]

@bolliy da muss ich leider moralisch gesehen passen ;-) Ich muss hier wohl geduldig sein, bis sich was bei der FW ergibt oder generell der Adapter in meinem Konstrukt stabil läuft. Auf jeden Fall danke für deinen Support und die Arbeit dahinter!

[bug77]

Kann mir jemand erklären wie ich die Wallbox von Huawei reinbekomme?

Ich habe eine Emma, sun2000 10kw WR, luna2000 7kw, Wallbox sc 22kt
Einzige ID im Adapter ist 5 für den sun2000.
Keine weitere ID ansprechbar 1-10

In der App ist die Wallbox da. Über Modbus kommt alles rein, außer die Wallbox.
Modbus Proxy ist aktiviert mit: 0.0.0.0 Port 502
Wallbox ist über LAN verbunden

In der Wallbox ist Freigabe für Managementsysteme aktiviert auf IP von IoBroker 192.168.0.14 und Port 502

Es kommen keine Daten rein :-(

Was mache ich falsch?

[bolliy]

@bug77 das Auslesen des Huawei Chargers über die Emma ist im Adapter noch nicht implementiert. Lt. der MODBUS Interface Definitions (https://photomate.zendesk.com/hc/en-gb/article_attachments/20421983900701) sollte diese aber möglich sein. Leg doch mal ein issue auf github an.
Wenn du mich beim Testen unterstüzt und ich Zeit finde, werde ich das gerne einbauen ;)

LG Stephan

[bug77]

@bolliy kann ich gerne machen. Ich erstelle ein Issue

[bolliy]

Neue Testversion sun2000 Adapter Version v1.5.0 released.

Die Installation erfolgt über npm oder morgen über das Beta Repository.

Wie vielleicht schon bei euch bekannt ist, kann der Wert usableSurplusPower
über die Parameter im Pfad sun2000.x.control.usableSurplus gesteuert werden. Nun kann für den bufferSoc eine Hysterese eingestellt werden.

bufferHysteresis
Die Hysterese ist die Differenz zwischen dem Soc (bufferSoc), bei dem die Nutzung der Hausbatterie (bufferPower) zuschaltet (Einschaltpunkt) und dem Soc (bufferSoc), bei dem sie wieder ausschaltet (Ausschaltpunkt). Eine größere Hysterese sorgt für weniger häufige Schaltungen, während eine kleinere Hysterese eine genauere Regelung ermöglicht.

Das Thema Überschuss wird im Wiki behandelt.

Stephan

[Vito666]

@bolliy said in Test Adapter sun2000 v0.1.x - Huawei Wechselrichter:

@vito666 die Berechnung lautet:
houseConsum = actPower - meterPower + extPower;

Die Aktualisierung von sun2000.0.control.externalPower jede Sekunde ist etwas übertrieben. Die Verarbeitung des extPower erfolgt nur im eingestellte Intervall des Adapters.
Aus den o.a. Daten kann ich leider nicht erkennen, dass die Berechnung falsch sein soll. Hier sind die Daten sun2000.0.collected.activePower, sun2000.0.collected.externalPower und natürlich sun2000.0.meter.activePower zur selben Zeit welche unerlässlich wären.

LG Stephan

@bolliy Moin Stephan,
das Problem bei meiner falschen houseConsumption Berechnung ist, dass sich sun2000.0.collected.externalPower nur einmalig beim Adapterstart den aktuellen Wert von sun2000.0.control.externalPower holt. Der Wert bleibt ab dann statisch. Ich habe den Adapter schon neu installiert und auch 1.5.0 getestet, das Verhalten ändert sich leider nicht.
Gruß
Vito

[bolliy]

@vito666 verwendest du blockly mit dem Funktionblock aktualisiere? Falls das zutrifft, dann nehme bitte den Funktionsblock steuere.
Siehe https://github.com/bolliy/ioBroker.sun2000/wiki/Verarbeitung-der-Sollwerte
Stephan

[Vito666]

@bolliy Moin Stephan,
danke, an der Stelle hatte ich genau den Fehler gemacht.
Gruß
Vito

[bahnuhr]

@bolliy
Guten Morgen,
könntest du noch einen "deviceStatus_Text" einbauen.
z.B. nach diesem Schema:

setState(SHI + id + ".DeviceStatus",           getU16(Buffer[id-1], 32089));
        var deviceStatusName = "";
        switch (getState(SHI + id + ".DeviceStatus").val) {
            case 0: deviceStatusName = "Initializing";break;
            case 1: deviceStatusName = "Detecting ISO";break;
            case 2: deviceStatusName = "Detecting irradiation";break;
            case 3: deviceStatusName = "Grid detecting";break;
            case 256: deviceStatusName = "Starting";break;
            case 512: deviceStatusName = "On grid";break;
            case 513: deviceStatusName = "On grid Power limit";break;
            case 514: deviceStatusName = "On grid self derating";break;
            case 768: deviceStatusName = "Shutdown fault";break;
            case 769: deviceStatusName = "Shutdown command";break;
            case 770: deviceStatusName = "Shutdown OVGR";break;
            case 771: deviceStatusName = "Shutdown communication disconnected";break;
            case 772: deviceStatusName = "Shutdown power limit";break;
            case 773: deviceStatusName = "Shutdown start manually";break;
            case 774: deviceStatusName = "Shutdown DC switch OFF";break;
            case 1025: deviceStatusName = "Grid dispatch cos(Phi)-P curve";break;
            case 1026: deviceStatusName = "Grid dispatch Q-U curve";break;
            case 1280: deviceStatusName = "Spot-check";break;
            case 1281: deviceStatusName = "Spot-checking";break;
            case 1536: deviceStatusName = "Inspecting";break;
            case 1792: deviceStatusName = "AFCI self-check";break;
            case 2048: deviceStatusName = "I V scanning";break;
            case 2304: deviceStatusName =" DC input detection";break;
            case 40960: deviceStatusName = "No irradiation";break;
            default: deviceStatusName = "undefined";break;
            }
        setState(SHI + id + ".DeviceStatus_Text",  deviceStatusName);

Wäre doch gut, wenn man anstatt der Nr. auch einen Text hätte.

mfg
Dieter

[bolliy]

@bahnuhr schau mal hier
sun2000.0.inverter.0.derived.deviceStatus

LG Stephan

[bahnuhr]

@bolliy
Ist ja nen Ding.

Ich habe hier geschaut:
sun2000.0.inverter.0.deviceStatus

Aber dass bei derived auch was ist, hab ich nicht gefunden.
ok, dann hat man Nr. als auch Text, an unterschiedlichen Stellen, aber gut.

[bolliy]

@bahnuhr der State sun2000.0.inverter.0.deviceStatus ist der eigentliche Wert aus dem WR. Die Werte im path derived sind die interpretierten bzw. abgeleiteten Informationen dazu.

Stephan

[bahnuhr]

@bolliy
Ja, ist bei dem "noch" von mir genommenen Script grundsätzlich auch so.
Hatte nur das Script geändert und den Text genau unter die Nr. gesetzt.

[bahnuhr]

@bolliy
Ich bin gerade am umändern (von Script auf Adapter). Ist gar nicht so wenig was man ändern muss.

Nochwas ist mir aufgefallen:

Die Werte L1 + L2 + L3 müssten doch "activePower" ergeben. Beim Script was das rechnerisch richtig. Beim Adapter passt dies nicht.

Liegt dies an unterschiedlichen Abfrageintervallen ?

[bolliy]

@bahnuhr ja,

activePower wird im high Interval ausgelesen. Die Phasen im low Interval.

[bahnuhr]

@bolliy
Wäre es sachlogisch, wenn man dies ändern würde.
Denn rechnerisch müsste dies passen.