Test Adapter Zendure Solarflow

[Murphy 0]

@karacho
Du überschreitest das max. Input Limit deines Gerätes.

Setze das Limit auf das maximal erlaubte zurück bevor du es sendest.

So habe ich es gemacht.

Deine Hardware erlaubt 900!

Allerdings wäre es besser du benutzt Geräte Automation Limit falls es das Objekt bei deiner Hardware gibt.

Nachtrag: Beim Geräte Automation Limit muss Laden ein Minuswert und Entladen ein positiver Wert sein.

[Karacho]

@murphy-0
Wo kommt denn der Wert 900 her? Wo wird der gesetzt? InputLimit von Zendure ist doch 2400W?

[Bernd1967]

@karacho sagte in Test Adapter Zendure Solarflow:

@murphy-0
Wo kommt denn der Wert 900 her? Wo wird der gesetzt? InputLimit von Zendure ist doch 2400W?

Gesetzt wird der "Max" Wert beim Datenpunkt selbst (Objektdaten).
Ich glaube die Grenze 900W gibt es beim Solarflow 2400ac nicht.
Hast Du mehrere Geräte von Zendure ?
Wie lautet der Productkey von dem Gerät ?
Was hast Du in den Adaptereinstellungen eingestellt ?
Welche Version hat der Adapter ?

Wenn dein Produktkey nicht stimmt oder nicht bekannt ist, gilt das Limit 900W im Adapter.

Sonst lösch mal den Datenpunkt und starte den Adapter neu.

[The_Stig]

Tjo - bei mir ist weiter der Wurm drin. Jetzt auch keine Reaktion vom Hyper mehr in der Cloud. Weder über MQTT noch in der Zendure App...hilft vermutlich nur wieder komplett Trennung und Reset...mann ey...mit dem Hyper werde ich irgendwie nicht froh.

[Bernd1967]

@the_stig sagte in Test Adapter Zendure Solarflow:

Tjo - bei mir ist weiter der Wurm drin. Jetzt auch keine Reaktion vom Hyper mehr in der Cloud. Weder über MQTT noch in der Zendure App...hilft vermutlich nur wieder komplett Trennung und Reset...mann ey...mit dem Hyper werde ich irgendwie nicht froh.

Bei mir auch Heute Morgen, Hyper (mit lokalem Broker) hängt.
Ich denke das liegt an den Geräten selbst.
Alle versuche den Hyper milde zu stimmen mit langsamen Umschalten, vorher auf 0 setzen schlagen fehl. Einmal den Broker neu starten und alles ist wieder Okay.

[The_Stig]

@bernd1967 bei mir nicht. Alle softwareseitigen Versuche helfen nicht. Nur einmal komplett abstöpseln...nervig

[Bernd1967]

@the_stig sagte in Test Adapter Zendure Solarflow:

@bernd1967 bei mir nicht. Alle softwareseitigen Versuche helfen nicht. Nur einmal komplett abstöpseln...nervig

Auch nicht wenn dein Hyper im lokalen Broker ist ?
Den Zendure Broker können wir natürlich nicht neu starten, obwohl.... das wäre ja mal eine Maßnahme

[maxclaudi]

@bernd1967

Der reine Wechsel auf 0 als Zwischenschritt (wie ich ihn Dir vorgeschlagen habe), funktioniert leider nicht.

[Bernd1967]

@maxclaudi sagte in Test Adapter Zendure Solarflow:

@bernd1967

Der reine Wechsel auf 0 als Zwischenschritt (wie ich ihn Dir vorgeschlagen habe), funktioniert leider nicht.

Ursprüngliche Nachricht gelöscht ?
Ich werde den Vorschlag mit "autoModel=0" im Wartemodus jetzt testen.
Auf "packState=0" werde ich erstmal nicht reagieren, da sowieso beim umschalten zwischen laden und entladen bei mir eine Wartezeit vorhanden ist.

[Murphy 0]

@bernd1967

autoModel 0 vor dem Umschalten hat bei mir nix gebracht.
Seit ich prophylaktisch alle 3 Stunden den Mosquitto neu starte jetzt seit 3 Tagen keine Abbrüche mehr.

Nachtrag:
Im Homeassistant Adapter von Fireson existiert das Problem scheinbar auch.
Zitat:

Hyper2000

Second try to solve the Hyper2000 communication issue. No extra risk for your device, just another way of controlling the Hyper2000. In order to detect if it is working, the automatic reset has been switched off This also means that if you want to use/change local MQTT you have to do it manually by using the MqttRest switch. If the Hyper2000 'freezes' you can use the same MqttReset to unfreeze. NOTICE that the communication issue used to popup after 2-3 days

Sollte ein Zitat aus fremder Quelle hier nicht erlaubt sein lösche ich es gerne wieder.

[The_Stig]

@bernd1967 said in Test Adapter Zendure Solarflow:

@the_stig sagte in Test Adapter Zendure Solarflow:

@bernd1967 bei mir nicht. Alle softwareseitigen Versuche helfen nicht. Nur einmal komplett abstöpseln...nervig

Auch nicht wenn dein Hyper im lokalen Broker ist ?
Den Zendure Broker können wir natürlich nicht neu starten, obwohl.... das wäre ja mal eine Maßnahme

Ich habe ja erst wieder auf die Cloud zurück geschaltet, da es im lokalen Betrieb noch häufiger eingefroren ist. Jetzt wieder zurück auf lokal und stündlichen MQTT-Restart. Mal schauen, ob das hilft...

[The_Stig]

@murphy-0 said in Test Adapter Zendure Solarflow:

@bernd1967

autoModel 0 vor dem Umschalten hat bei mir nix gebracht.
Seit ich prophylaktisch alle 3 Stunden den Mosquitto neu starte jetzt seit 3 Tagen keine Abbrüche mehr.

Nachtrag:
Im Homeassistant Adapter von Fireson existiert das Problem scheinbar auch.
Zitat:

Hyper2000

Second try to solve the Hyper2000 communication issue. No extra risk for your device, just another way of controlling the Hyper2000. In order to detect if it is working, the automatic reset has been switched off This also means that if you want to use/change local MQTT you have to do it manually by using the MqttRest switch. If the Hyper2000 'freezes' you can use the same MqttReset to unfreeze. NOTICE that the communication issue used to popup after 2-3 days

Sollte ein Zitat aus fremder Quelle hier nicht erlaubt sein lösche ich es gerne wieder.

Weißt du, wie dieses Unfreeze funktioniert? Reiner Neustart?

[maxclaudi]

@bernd1967
adpater schaltet nur hart um, anhand vom value.

HA macht es bei allen Geräten so:
Wenn nur value geändert wird, dann gleich wie beim adapter.
wird zwischen Lade und Entladebefehl (oder anders rum) geswitched, dann nur mit Zwischenschritt.

im manager.py Methode switch_mode()

# Stop current AC operation
await device.power_set(ManagerState.IDLE, 0)

Dieser Aufruf sorgt dafür, dass immer zuerst ein Power-Set auf 0 Watt passiert – und zwar mit:

{"properties": {"smartMode": 1, "acmode": X, "inputLimit" oder "outputLimit": 0}}

Daraus folgt:

• Wenn vorher geladen wurde (ManagerState.CHARGING): acmode: 1, inputLimit: 0
• Wenn vorher entladen wurde (ManagerState.DISCHARGING): acmode: 2, outputLimit: 0

Dadurch stoppt jede AC-Leistung sofort, Gerät fällt in autoModel:0 und acMode:0.

---

Jetzt folgt ein warten auf Idle-Bedingung

while not device.is_idle():
    await asyncio.sleep(1)

...direkt danach:

while not device.is_idle():
    await asyncio.sleep(1)

is_idle() steckt im device.py und sieht ungefähr so aus:

def is_idle(self) -> bool:
    return (self.autoModel == 0 
            and self.acMode == 0
            and self.inputLimit == 0
            and self.outputLimit == 0
            and abs(self.inputWatt) < 5
            and abs(self.outputWatt) < 5)

Bedeutet also:
packState ist nicht die einzige Idle-Bedingung.
Wenn PV DC lädt, stört das nicht.
weil im HA Code "idle" nicht allein von packSate abhängig gemacht wird.
Vielmehr kann packSate auch "1" sein, aber AC-seitig wird geprüft, dass nichts per AC ge- oder entladen wird ~0W.

Wenn is_idle() true, geht’s direkt weiter:

await device.power_set(target_state, target_power)

Das ruft dann power_set() in device.py auf

if state == ManagerState.CHARGING:
    self.hass.async_create_task(
        self.httpPost("properties/write", 
            {"properties": {"smartMode": 1, "acmode": 1, "inputLimit": -power}}
        )
    )
else:
    self.hass.async_create_task(
        self.httpPost("properties/write", 
            {"properties": {"smartMode": 1, "acmode": 2, "outputLimit": power}}
        )
    )

Was sagt uns das?
Bevor ich wieder alles lösche, eine Zusammenfassung:

Bei Schaltwechsel zwischen Laden und Enladen oder anders rum:

1. Moduswechsel mit neuem value wird gesetzt.

2. Dann folgt automatisch erzwingen von Idle:

• Limit auf 0 setzen
• autoModel:0, acMode:0
• warten bis keine AC-Leistung mehr fließt (inputWatt/outputWatt ~ 0)

3. Idle-Check:

• mehrere Parameter (nicht nur packState)
• PV-Ladung DC stört nicht

4. wenn Idle, dann neues Limit + neuer Modus setzen

Immer mit smartMode:1 im JSON

Wie erzwingt HA Idle bzw. wann wird ein sate auch als Idle interpretiert?

Ablauf im Code:
Altes Limit auf 0 setzen

bei Laden: inputLimit = 0
bei Entladen: outputLimit = 0

immer mit autoModel:0 und meistens mit smartMode:1 im JSON

Warten, bis Gerät aufhört, Leistung zu ziehen/abzugeben.

HA fragt zyklisch die Leistung (inputWatt, outputWatt) ab

Sobald beide annähernd 0 Watt (und acMode = 0), gilt das als „idle“

Neuen Modus setzen (autoModel wieder auf 8 oder anderes Ziel)

danach acMode und neues Limit mitschicken

Fazit:
Idle wird nicht nur aus packState übernommen, sondern auch so interpretiert, indem HA die Limits auf 0 setzt und wartet, bis AC-Leistung stoppt. PV-DC-Ladung beeinflusst das nicht.

PS: acMode:0 wird im code auch als 0 intepretiert, wenn keine AC Leistung mehr vorhanden ist. Der eigentliche acMode kann dabei auch mal acMode:1 oder acMode:2 sein, denn eigentlich gibt es den acMode:0 nicht.

PPS:
Fällt schon auf, dass die Umschaltung zu autoModel:0 und weiteres im json smartMode:1 meist beinhaltet.

---

auch dieser Post wird wieder gelöscht oder gekürzt werden.
Nicht weil es nicht richtig ist, sondern weil ich viel Arbeit investiere und hilfreiche Infos sende.
Dann missfällt irgend jemand mein Post und bewertet es mit -1.
Statt zu fragen oder zu kommentieren.