Test Adapter Zendure Solarflow
-
@nograx sagte in Test Adapter Zendure Solarflow:
@rene55 sagte in Test Adapter Zendure Solarflow:
@maxclaudi oha! Bei mir steht autoModel auf "Smart Matching Mode". Eigentlich schon immer, weiß nicht seit wann?!
Das macht die Funktion setDeviceAutomationInOutLimit, das ist normal.
solar-flow-adapter:
Am Ende wird immer ein deviceAutomation-Payload gebaut.
In allen Pfaden, wo setDeviceAutomationInOutLimit wirklich ein _arguments befüllt, wird hart autoModel: 8 gesetzt.
Im gesamten Code gibt es keine Stelle, wo der aktuelle autoModel-Status vom Gerät abgefragt oder berücksichtigt wird, bevor der Payload gesendet wird.Beispiel (Hyper, Output):
_arguments = [ { autoModelProgram: 2, autoModelValue: { ... }, msgType: 1, autoModel: 8, // <--- fest! }, ];Bei jedem Aufruf von setDeviceAutomationInOutLimit wird autoModel:8 stumpf in die Nachricht gepackt und gesendet.
Ob das tatsächlich in zwei Flash-Schreibvorgängen endet (Limit + Mode), hängt von der Firmware-Implementierung ab. Wahrscheinlich verhindert Zendure unnötige Commits, sodass nur dann geschrieben wird, wenn sich was ändert.
Quelle solarflow-adapter: Auszug mqttService.ts
export const setDeviceAutomationInOutLimit = async ( adapter: ZendureSolarflow, productKey: string, deviceKey: string, limit: number // can be negative, negative will trigger charging mode ): Promise<void> => { if (adapter.mqttClient && productKey && deviceKey) { adapter.log.debug( `[setDeviceAutomationInOutLimit] Set device Automation limit to ${limit}!` ); if (limit) { limit = Math.round(limit); } else { limit = 0; } if (adapter.config.useLowVoltageBlock) { const lowVoltageBlockState = await adapter.getStateAsync( productKey + "." + deviceKey + ".control.lowVoltageBlock" ); if ( lowVoltageBlockState && lowVoltageBlockState.val && lowVoltageBlockState.val == true && limit > 0 ) { limit = 0; } const fullChargeNeeded = await adapter.getStateAsync( productKey + "." + deviceKey + ".control.fullChargeNeeded" ); if ( fullChargeNeeded && fullChargeNeeded.val && fullChargeNeeded.val == true && limit > 0 ) { limit = 0; } } if (limit < 0) { // Get input limit, make number positive and the new value negative limit = -getMinAndMaxInputLimitForProductKey(productKey, -limit); } else { limit = getMinAndMaxOutputLimitForProductKey(productKey, limit); } const topic = `iot/${productKey}/${deviceKey}/function/invoke`; adapter.msgCounter += 1; const timestamp = new Date(); timestamp.setMilliseconds(0); // HUB1200 & HUB 2000 let _arguments: IDeviceAutomationPayload[] = []; const productName = getProductNameFromProductKey(productKey); if ( productName.toLowerCase().includes("2400 ac") || productName.toLowerCase().includes("solarflow 800") ) { adapter.log.debug( `[setDeviceAutomationInOutLimit] Using HEMS Variant of device automation, as device '${productName}' detected!` ); // HEMS Variante const hemsEP = { arguments: { outputPower: limit > 0 ? limit : 0, chargeState: limit > 0 ? 0 : 1, chargePower: limit > 0 ? 0 : -limit, mode: 9, }, function: "hemsEP", messageId: adapter.msgCounter, deviceKey: deviceKey, timestamp: timestamp.getTime() / 1000, }; adapter.mqttClient?.publish(topic, JSON.stringify(hemsEP)); return; } else if (productName.toLowerCase().includes("hyper")) { if (limit < 0) { adapter.log.debug( `[setDeviceAutomationInOutLimit] Using CHARGE variant of HYPER device automation, as device '${productName}' detected and limit is negative!` ); // Input / Charge _arguments = [ { autoModelProgram: 1, autoModelValue: { upTime: 0, chargingType: 1, pullTime: 1800, price: 2, chargingPower: -limit, prices: [ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, ], outPower: 0, freq: 0, }, msgType: 1, autoModel: 8, }, ]; } else { adapter.log.debug( `[setDeviceAutomationInOutLimit] Using FEED IN variant of HYPER device automation, as device '${productName}' detected and limit is positive!` ); // Output _arguments = [ { autoModelProgram: 2, autoModelValue: { chargingType: 0, chargingPower: 0, freq: 0, outPower: limit, }, msgType: 1, autoModel: 8, }, ]; } } else { if (limit < 0) { adapter.log.warn( `[setDeviceAutomationInOutLimit] Using CHARGE variant of Hub device automation is currently not working! You have to manualy switch acMode and inputLimit!` ); /* // Input / Charge _arguments = [ { autoModelProgram: 2, autoModelValue: { upTime: 0, chargingType: 1, pullTime: 1800, price: 2, chargingPower: -limit, prices: [ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, ], outPower: 0, freq: 0, }, msgType: 1, autoModel: 8, }, ]; */ } else { // Output adapter.log.debug( `[setDeviceAutomationInOutLimit] Using FEED IN variant of Hub device automation, as device '${productName}' detected and limit is positive!` ); _arguments = [ { autoModelProgram: 2, autoModelValue: limit, msgType: 1, autoModel: 8, }, ]; } } const deviceAutomation = { arguments: _arguments, function: "deviceAutomation", messageId: adapter.msgCounter, deviceKey: deviceKey, timestamp: timestamp.getTime() / 1000, }; adapter.mqttClient?.publish(topic, JSON.stringify(deviceAutomation)); } };man könnte auch den code erweitern, dass zuerst der aktuelle autoModel-State aus properties.autoModel gelesen und nur gesetzt wird, wenn er ≠ 8 ist?
Dann würde man sicherstellen, dass das Gerät nicht unnötig mit Mode:8 überschrieben wird.
z. B. zentrale Logik, die egal ob Hub, Hyper oder HEMS immer zuerst prüft, ob das Gerät schon im richtigen Mode ist. Nur wenn der autoModel ≠ 8 ist, wird autoModel: 8 in den Payload gepackt. Damit würden unnötige Doppel-Writes gespart.
Beispiel/Vorlage: vereinheitlichte Version von setDeviceAutomationInOutLimit:
export const setDeviceAutomationInOutLimit = async ( adapter: ZendureSolarflow, productKey: string, deviceKey: string, limit: number ): Promise<void> => { if (!adapter.mqttClient || !productKey || !deviceKey) return; adapter.log.debug( `[setDeviceAutomationInOutLimit] Set device Automation limit to ${limit}!` ); // normalize limit limit = limit ? Math.round(limit) : 0; // LowVoltageBlock / FullChargeNeeded prüfen if (adapter.config.useLowVoltageBlock) { const lowVoltageBlockState = await adapter.getStateAsync( `${productKey}.${deviceKey}.control.lowVoltageBlock` ); if (lowVoltageBlockState?.val === true && limit > 0) limit = 0; const fullChargeNeeded = await adapter.getStateAsync( `${productKey}.${deviceKey}.control.fullChargeNeeded` ); if (fullChargeNeeded?.val === true && limit > 0) limit = 0; } // Grenzen für Input/Output anwenden if (limit < 0) { limit = -getMinAndMaxInputLimitForProductKey(productKey, -limit); } else { limit = getMinAndMaxOutputLimitForProductKey(productKey, limit); } const topic = `iot/${productKey}/${deviceKey}/function/invoke`; adapter.msgCounter += 1; const timestamp = Math.floor(Date.now() / 1000); // --- geändert/neu: aktuellen Mode abfragen --- const currentModeState = await adapter.getStateAsync( `${productKey}.${deviceKey}.properties.autoModel` ); const currentMode = currentModeState?.val; const targetMode = 8; const includeMode = currentMode !== targetMode; const productName = getProductNameFromProductKey(productKey).toLowerCase(); let payload: any; if (productName.includes("2400 ac") || productName.includes("solarflow 800")) { // HEMS Variante, von HEMS habe ich keine Erfahrung/Ahnung! payload = { arguments: { outputPower: limit > 0 ? limit : 0, chargeState: limit > 0 ? 0 : 1, chargePower: limit > 0 ? 0 : -limit, mode: 9, }, function: "hemsEP", messageId: adapter.msgCounter, deviceKey, timestamp, }; } else if (productName.includes("hyper")) { // Hyper Variante if (limit < 0) { payload = { arguments: [ { autoModelProgram: 1, autoModelValue: { upTime: 0, chargingType: 1, pullTime: 1800, price: 2, chargingPower: -limit, prices: new Array(24).fill(1), outPower: 0, freq: 0, }, msgType: 1, ...(includeMode ? { autoModel: targetMode } : {}), }, ], function: "deviceAutomation", messageId: adapter.msgCounter, deviceKey, timestamp, }; } else { payload = { arguments: [ { autoModelProgram: 2, autoModelValue: { chargingType: 0, chargingPower: 0, freq: 0, outPower: limit, }, msgType: 1, ...(includeMode ? { autoModel: targetMode } : {}), }, ], function: "deviceAutomation", messageId: adapter.msgCounter, deviceKey, timestamp, }; } } else { // Hub Variante if (limit < 0) { adapter.log.warn( `[setDeviceAutomationInOutLimit] CHARGE variant for Hub not supported – use acMode + inputLimit manually!` ); return; } else { payload = { arguments: [ { autoModelProgram: 2, autoModelValue: limit, msgType: 1, ...(includeMode ? { autoModel: targetMode } : {}), }, ], function: "deviceAutomation", messageId: adapter.msgCounter, deviceKey, timestamp, }; } } adapter.mqttClient?.publish(topic, JSON.stringify(payload)); };HINWEIS: das war nur eine Idee / Vorlage. Nicht auf Fehler überprüft und ob es funktioniert, weiß ich auch nicht.
@nograx sagte in Test Adapter Zendure Solarflow:
Die setDeviceAutomationLimit Methode wurde ja auf deinen Hinweis hin implementiert, so wie die Integration von HA es macht (wo sollen hier die Unterschiede sein?).
Mein Hinweis war als Link auf eine der Quellen gedacht.
Was man daraus macht, ist eine andere Sache.
Auf einen Unterschied habe ich bereits gleich bei Punkt 1 meines Posts hingewiesen.
Du schaltest hart. HA macht das vom packState abhängig. Bei HA ist packState:0 nicht nur stumpf packState:0. Es werden auch andere parameter berücksichtigt, was dazu führt dass selbst wenn packState nicht 0 sein könnte, es als packSate:0 gewertet wird, wenn.... usw.edit:
So viel ich mich erinnere, wird dann in Abhängigkeit davon vor dem sofortigen Wechsel zwischen Entladen und Laden (oder Laden auf Entladen) erst in Mode:0 gewechselt und nicht einfach direkt umgeschaltet.
Quasi wie ein 3 Stufenschalter Laden->0 -> Entladen.
Entladen -> 0 -> Laden.
Beim solar-flow-adapter findet das nicht statt.
Laden-> Entladen / Entladen-> Laden.
Korrigiert mich, wenn ich das nicht richtig verstanden habe.
Beschäftige mich nicht mehr weiter damit.
edit EndeIch weiß gar nicht warum ich so bin und das nicht lassen kann.
Das Thema ist doch für mich abgeschlossen?
Richtig, das muss jetzt ein Ende haben, nachdem ich zu viel Zeit damit verbracht habe.
Vielleicht waren ja ein paar Ideen/Erkenntnise/Hinweise/Beobachtungen usw. für den einen oder anderen hilfreich. -
-
autoModel: 8 wird auch bei der HA Integration immer mit geschickt. Da das Zendure abgenickt hat (die Integration offiziell ist) muss ich davon ausgehen das das so OK ist.
-
packState: Kannst du das bitte erläutern und mir ein Beispiel zeigen? Kann zu "packState" in der HA Integration nicht viel finden.
-
"hart" schalten. Hier bräuchte ich auch mal ein Beispiel bzw. ne Referenz in dem Code der HA Integration, das verstehe ich nämlich auch nicht.
-
-
@nograx sagte in Test Adapter Zendure Solarflow:
- autoModel: 8 wird auch bei der HA Integration immer mit geschickt. Da das Zendure abgenickt hat (die Integration offiziell ist) muss ich davon ausgehen das das so OK ist.
wie Du möchtest.
Ob das speziell abgenickt wurde und bei vielen anderen Stellen: weiß ich nicht.
Meine Vermutung ist, dass sie nur auf Nachfrage reagieren und mal machen lassen.
Kostet sie nichts. Aber genug mit Spekulationen.
Für meinen Teil, mach ich so viel wie möglich safe.-
packState: Kannst du das bitte erläutern und mir ein Beispiel zeigen? Kann zu "packState" in der HA Integration nicht viel finden.
-
"hart" schalten. Hier bräuchte ich auch mal ein Beispiel bzw. ne Referenz in dem Code der HA Integration, das verstehe ich nämlich auch nicht.
packSate habe ich dazu in meinem code zur Auswertung mit verwendet, weil es quasi "idle" ist und in HA das IDLE (State=0) ist.
Versteht man schon
Im solarflow-adapter-code benutzt Du auch Idle für packState:0Möchte mich jetzt nicht wieder Tage mit der HA-Intergration beschäftigen
Egal, war zu lang raus aus dem py-Code und musste das gerade nochmal runterladen und anschauen.
Basis nun: Zendure-HA-1.1.4-pre2
Wenn man in den Code schaut, wird es schnell nachvollziehbar
A)
Was passiert bei Wechsel von negativ -> positiv (CHARGING -> DISCHARGING)?
Beispiel: -100 W (Laden aus Netz) zu 200 W (Entladen ins Haus).- manager.py erkennt, dass der gewünschte Wert Vorzeichen wechselt.
- Aktuelle ManagerState (CHARGING) passt nicht mehr.
- deshalb wird der State auf IDLE gesetzt: Übergangsschritt.
- deviceAutomation wird mit autoModel=0, autoModelProgram=0 aufgerufen.
- „Stop-Befehl“: das Gerät ist kurz im IDLE-Modus.
- Danach wechselt manager.py den State auf DISCHARGING.
- deviceAutomation wird erneut aufgerufen mit:
{ "autoModel": 8, "autoModelProgram": 2, "autoModelValue": { "chargingPower": 0, "outPower": 200, "freq": 0 } }
B)
sodele oder vice versa, was passiert bei Wechsel von positiv -> negativ (DISCHARGING -> CHARGING)?
Beispiel: 200 W (Entladen) -> -100 W (Laden aus Netz).- manager.py setzt State auf IDLE -> autoModel=0.
- danach manager.py setzt State auf CHARGING -> autoModel=8, autoModelProgram=1.
Payload u. a.:
{ "autoModel": 8, "autoModelProgram": 1, "autoModelValue": { "chargingPower": 100, "outPower": 0, "chargingType": 1, "price": 2 } }
C)
Bedingung für IDLE (State=0)IDLE wird immer dann gesetzt, wenn:
-
Der gewünschte neue Wert 0 ist
-> Payload mit autoModel=0. -
Oder beim Umschalten der Richtung (negativ <-> positiv).
Damit wird garantiert, dass das Gerät nie „hart“ von Charge zu Discharge springt.
Im Code (z.B. hyper2000.py) :
"autoModel": 8 if state == ManagerState.DISCHARGING else 0, "autoModelProgram": 2 if state == ManagerState.DISCHARGING else 0,Wenn state == IDLE, landet man also automatisch bei 0/0.
Fazit:
- es wird immer über autoModel=0 (Idle) geschaltet, wenn von negativ <-> positiv gewechselt wird.
- Idle wird akzeptiert, wenn man manuell 0 setzt, oder
- die Steuerung in manager.py beim Richtungswechsel einen „Zwischenstopp“ macht.
- Dadurch sieht der Payload-Fluss z. B. bei -100 -> 200 so aus:
- deviceAutomation { autoModel=8, program=1, chargingPower=100 } (alter Zustand)
- deviceAutomation { autoModel=0, program=0 } (IDLE)
- deviceAutomation { autoModel=8, program=2, outPower=200 } (neuer Zustand)
Hinweis:
urprünglich ging ich davon aus, dass packState:0 == Idle ist und habe es in meinem Code entsprechend verwendet.Wie bereits erwähnt, akzeptiert HA den Status auch als "IDLE", selbst wenn packState ≠ 0, solange andere Parameter passen.
Die Details lassen sich im Code auch gut nachvollziehen – ich denke, damit sollte genug Material da sein, um es weiterzuverfolgen.Meine Analyse beschränkt sich auf die HA-Integration und zum Vergleich mit der solar-flow-Adapter-Funktion.
Fehler meinerseits sind dabei nicht ausgeschlossen.Persönlich mag ich den Weg nicht, zu hacky und zu viele unbekannte Faktoren.
Bleibe beim bisherigen: Mode: 0, smartMode: 1 und outputLimit.im HA code
Zendure-HA-1.1.4-pre2\custom_components\zendure_ha\manager.py
Zendure-HA-1.1.4-pre2\custom_components\zendure_ha\devices
Alle Geräte wie hub2000.py oder hyper2000.py etc.Hoffe, das hilft Dir – mehr habe ich dazu nicht, gern geschehen.
-
@nograx Hallo erst mal und Danke für dein Adapter,
Habe vom Hub2000 auf Hyper 2000 gewechselt, aber der Hyper zeigt mir nur die Packdata (akkus) an
Fehler im iobroker: " [createSolarFlowLocalStates] Unknown product (Hyper2000_3.0). We cannot create control states! Please contact the developer!"
Fallback werden mir die Daten angezeigt im Verzeichnis: zendure-solarflow.0.hC1g9Utt.xxxxxxx.
Habe schon so ziemlich alles durch probiert, neuen Acount, neue Instanz aber bekomme keine Daten.
Die Handy App und Steuerung vom shelly funktionieren.
das Problem schon mal gehabt oder bekannt?gruss Bernd
-
@bmgs sagte in Test Adapter Zendure Solarflow:
Fehler im iobroker: " [createSolarFlowLocalStates] Unknown product (Hyper2000_3.0). We cannot create control states! Please contact the developer!"
Fallback werden mir die Daten angezeigt im Verzeichnis: zendure-solarflow.0.hC1g9Utt.xxxxxxxxWürde die letzten Ziffern entfernen und durch xxxxxxxx ersetzen. Das ist Deine deviceID.
Hoppla eine neue Hyper2000_3.0 Version mit neuer productID: hC1g9Utt, wenn das stimmt muss sie erst eingepflegt werden
-
@maxclaudi said in Test Adapter Zendure Solarflow:
@bmgs sagte in Test Adapter Zendure Solarflow:
Hoppla eine neue Hyper2000_3.0 Version mit neuer productID: hC1g9Utt, wenn das stimmt muss sie erst eingepflegt werden
Danke für die Info, ist der hyper wenigstens nicht defekt, Daten in der App sind ja auch io.
Gruss
Bernd -
@bmgs
nichts defekt, einfach abwarten auf ein neues Release -
@maxclaudi said in Test Adapter Zendure Solarflow:
@bmgs
nichts defekt, einfach abwartenDie Packdata liegen in zendure-solarflow.0.B3Dxda.xxxxxxx übrigens,
eigentlich sollte doch da der rest auch auftauchen.Gruss
Bernd -
-
Gerade 2.02 installiert.
-
@bmgs sagte in Test Adapter Zendure Solarflow:
B3Dxda
Wenn B3Dxda der product key ist sollte es mit der Version 2.0.2 laufen. Installation wäre per npm (Expertenmodus aktivieren) jetzt schon möglich. Im Beta Kanal taucht die im Laufe des Abends auf. Der andere sieht mir eher nach dem deviceKey aus und den solltest du hier ggf. entfernen
-
@nograx
ich bin nicht so der Experte...
aber hast du hier nicht ein return vergessen?return "hyper 2000"; case "gda3tb": return "hyper 2000"; case "b3dxda": "hyper 2000"; case "8bm93h": return "ace 1500"; case "bc8b7f": -
@intruder7 Jo danke für den Hinweis. 2.0.3 ist unterwegs.
-
Die Nutzung von setDeviceAutomationInOutLimit bzw. der HA-Integration deviceAutomation invoke führt in Verbindung mit der Cloud definitiv zu Konflikten.
Wer mit der Cloud arbeitet und einen Proxy zum Mitschneiden nutzt, kann das auch selbst nachvollziehen.
Das könnte ein Hinweis darauf sein, dass nicht jede Code-Funktion auf GitHub offiziell abgenommen ist – möglicherweise reicht es, wenn jemand mit „Maintainer“-Rechten den Code einstellt oder pflegt.
@lesiflo
Die Schwierigkeiten bei dir hängen nicht mit einem Cloud-Fehler zusammen, sondern damit, dass setDeviceAutomationInOutLimit in deiner Konfiguration verwendet wird.
Mit Cloud-Anbindung kann diese Funktion technisch bedingt nicht konfliktfrei laufen. -
@maxclaudi Habe ich schon vermutet. Nachdem ich gestern wieder setDeviceAutomationInOutLimit aktiviert habe, ist wieder ein Hyper ausgestiegen. Mit input/output und Cloud läuft es fehlerfrei. Ich lass das erstmal so. Lokale Anbindung bringt bei mir keinen Benefit, Cloud läuft stabil.
-
@maxclaudi sagte in Test Adapter Zendure Solarflow:
Die Nutzung von setDeviceAutomationInOutLimit bzw. der HA-Integration deviceAutomation invoke führt in Verbindung mit der Cloud definitiv zu Konflikten.
Wer mit der Cloud arbeitet und einen Proxy zum Mitschneiden nutzt, kann das auch selbst nachvollziehen.
Das könnte ein Hinweis darauf sein, dass nicht jede Code-Funktion auf GitHub offiziell abgenommen ist – möglicherweise reicht es, wenn jemand mit „Maintainer“-Rechten den Code einstellt oder pflegt.
@lesiflo
Die Schwierigkeiten bei dir hängen nicht mit einem Cloud-Fehler zusammen, sondern damit, dass setDeviceAutomationInOutLimit in deiner Konfiguration verwendet wird.
Mit Cloud-Anbindung kann diese Funktion technisch bedingt nicht konfliktfrei laufen.Um das Thema für mich abzuschließen, hier noch einmal der aktuelle Stand – rein als technische Information für alle:
Der Konflikt entsteht nicht dadurch, dass man setDeviceAutomationInOutLimit verwenden möchte, sondern weil diese Funktion zwingend den SmartMatchingMode benötigt, um korrekt zu funktionieren.
Sobald ein Wert über setDeviceAutomationInOutLimit gesetzt wird, wird automatisch der SmartMatchingMode aktiviert.In diesem Modus übernimmt die Cloud die Steuerung anhand der aktuell über die App gesetzten Parameter und synchronisiert die Werte kontinuierlich.
Dadurch entstehen Konflikte:-
Die Cloud überschreibt die von setDeviceAutomationInOutLimit gesetzten Werte mit ihren eigenen, was zu unerwarteten Änderungen führt.
-
Wird anschließend erneut ein Wert über setDeviceAutomationInOutLimit gesetzt, überschreibt die Cloud diesen wieder – dieser Kreislauf kann Fehlverhalten wie „Freeze“ oder MQTT-Probleme erzeugen.
Das ist vorprogrammiert und logisch nachvollziehbar.
Deshalb ist eine konfliktfreie Nutzung von setDeviceAutomationInOutLimit bei gleichzeitiger Verwendung der App mit Cloud-Anbindung nicht möglich.Ganz isoliert, nur lokal, könnte setDeviceAutomationInOutLimit vielleicht fehlerfrei verwendet werden, da hier weder App noch Cloud beteiligt sind.
Das kann ich nicht beurteilen, weil ich nicht setDeviceAutomationInOutLimit/DeviceAutomation invoke in einem AutomatikMode verwenden möchte. -
-
@maxclaudi Ich habe mir jetzt mal versucht in die Issues bei der HA Integration einzulesen. Dort ist beschrieben das das Problem mit dem "Freeze" behoben ist (es sei denn ich übersehe da jetzt was).
Da ich mit der 2.0.3 jetzt beim Hyper 1:1 das von der HA Integration übernommen habe würde ich @lesiflo mal bitten das mit der Version noch mal auszuprobieren.
Ist wird auch angemerkt das Zendure hier wohl ein Firmware Update veröffentlicht hatte welches das Problem beheben sollte? Seid ihr da auf dem aktuellen Stand?
-
Tut mir leid, Issues lese ich gar nicht. Ich analysiere Code, teste, logge und werte aus – mehr ist das nicht.
Ich bin auch nicht fehlerfrei und möchte niemandem etwas unterstellen. Ich teile nur, was ich selbst analysiert und/oder getestet habe.Im aktuellen Code – Zendure-HA-1.1.4-pre2 von HA, wenn er so verwendet wird – kann der Konflikt nicht behoben sein.
Ich wüsste nicht, wie die Firmware zwischen einem externen invoke und der App in einem Modus unterscheiden sollte. Im aktuellen Code ist das für mich nicht erkennbar. -
@maxclaudi sagte in Test Adapter Zendure Solarflow:
Tut mir leid, Issues lese ich gar nicht. Ich analysiere Code, teste, logge und werte aus – mehr ist das nicht.
Ich bin auch nicht fehlerfrei und möchte niemandem etwas unterstellen. Ich teile nur, was ich selbst analysiert und/oder getestet habe.Im aktuellen Code – Zendure-HA-1.1.4-pre2 von HA, wenn er so verwendet wird – kann der Konflikt nicht behoben sein.
Ich wüsste nicht, wie die Firmware zwischen einem externen invoke und der App in einem Modus unterscheiden sollte. Im aktuellen Code ist das für mich nicht erkennbar.Ich gehe aktuell davon aus das es von der HA Integration noch deutlich mehr Installationen vorhanden sind als vom ioBroker Adapter. Hier müsste es doch also ne Menge Leute geben die Probleme haben. Auch hier gibt es Stand jetzt nur @lesiflo und ggf. dich?
Wenn hier so viele Hyper regelmäßig aussteigen würden, wäre das in den Github Issues deutlich sichtbar...
-
@nograx sagte in Test Adapter Zendure Solarflow:
Ich gehe aktuell davon aus das es von der HA Integration noch deutlich mehr Installationen vorhanden sind als vom ioBroker Adapter. Hier müsste es doch also ne Menge Leute geben die Probleme haben. Auch hier gibt es Stand jetzt nur @lesiflo und ggf. dich?
Wenn hier so viele Hyper regelmäßig aussteigen würden, wäre das in den Github Issues deutlich sichtbar...Einige Nutzer haben über MQTT-Probleme berichtet, die möglicherweise von dieser Funktion stammen.
Auf die Schnelle fallen mir hier @Bernd1967 und @Murphy-0 ein (letzterer setzt nur sehr wenige Schreibvorgänge, 90–150).Es wird sicherlich viele User geben, die gar nicht wissen, woher die Probleme kommen, und etwas anderes vermuten – z. B. Router, Broker etc. – liest man doch häufiger.
Auffällig ist nur, dass die Probleme in Verbindung mit der neuen Funktion auftreten.
Einige Nutzer sind vermutlich auch nicht so technisch versiert.
Zum aktuellen HA Code Zendure-HA-1.1.4-pre2:
-
in allen Geräteklassen (hyper2000.py, hub2000.py, aio2400.py, …) wird "function": "deviceAutomation" gesendet – das ist der lokale Befehl.
-
In device.py taucht topic_function auf:
self.topic_function = f"iot/{self.prodkey}/{self.deviceId}/function/invoke" self.mqttPublish(self.topic_function, command)Das ist der MQTT-Topic für Befehle.
Dort gibt es auch mqttProperties, die eingehende Cloud-/Gerätenachrichten verarbeiten.Das bedeutet:
- Lokal gesetzte deviceAutomation -> MQTT-Publish geht raus.
- Cloud aktiv -> über dasselbe Topic kommt ebenfalls ein Befehl (function/invoke).
- Das Gerät empfängt also lokal und Cloud-Befehle über denselben Kanal.
Konfliktmechanismus (Cloud vs. Lokal):
- setDeviceAutomationInOutLimit schickt fixe Werte.
- Die Cloud schickt ebenfalls deviceAutomation (ihre Automatik-Parameter).
- Beide nutzen dasselbe Topic -> das Gerät führt den letzten Befehl aus.
Fazit:
- Ob mit oder ohne Freeze, der Ablauf ist logisch, weil man im SmartMatchingMode ist.
- Sobald Cloud verbunden und Mode 8 aktiv -> Cloud sendet kontinuierlich neue Automatik-Parameter.
- der lokale Code „hackt“ sich zwar rein, verliert aber gegen die Cloud-Syncs.
Wer die Situation selbst nachvollziehen möchte, kann bei aktiver Cloud-Verbindung lokal einen Proxy dazwischenschalten und den MQTT-Verkehr mitloggen. So lässt sich das Zusammenspiel von lokalen Befehlen und Cloud-Sync beobachten.
-
