NEWS
Test Adapter Zendure Solarflow
-
@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.Ich schreibe meistens sehr direkt – bitte nicht falsch verstehen, es ist nie böse gemeint. Das ist einfach mein Stil und niemals abwertend gemeint.
-
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.
-
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 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.Ich schreibe meistens sehr direkt – bitte nicht falsch verstehen, es ist nie böse gemeint. Das ist einfach mein Stil und niemals abwertend gemeint.
-
-
@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?
-
-
@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.Ich schreibe meistens sehr direkt – bitte nicht falsch verstehen, es ist nie böse gemeint. Das ist einfach mein Stil und niemals abwertend gemeint.
-
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...
-
@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.
Ich schreibe meistens sehr direkt – bitte nicht falsch verstehen, es ist nie böse gemeint. Das ist einfach mein Stil und niemals abwertend gemeint.
-
-
@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.
Ich habe in meiner Kombi mit HUB1200 und ACE1500 zweimal probiert die neue Funktion mit setDeviceAutomationInOutLimit probiert aber leider ohne Erfolg. Entweder geht es in der Kombi nicht, der ACE kann ja regulär auch keinen Überschuss laden oder ich bin zu doof dafür 😵💫
Vielleicht kann mir ja einer weiterhelfen oder die Info hilft jemand anderem der selbes Problem hat. Nutze weiterhin die bekannten um In und Output Limit zu setzen.
-
-
Ich habe in meiner Kombi mit HUB1200 und ACE1500 zweimal probiert die neue Funktion mit setDeviceAutomationInOutLimit probiert aber leider ohne Erfolg. Entweder geht es in der Kombi nicht, der ACE kann ja regulär auch keinen Überschuss laden oder ich bin zu doof dafür 😵💫
Vielleicht kann mir ja einer weiterhelfen oder die Info hilft jemand anderem der selbes Problem hat. Nutze weiterhin die bekannten um In und Output Limit zu setzen.
@Felli
Bei mir läuft es mit einer HUB2000 + ACE1500 Kombi.
Überschussladen mache ich ebenfalls klassisch per Script über autoModel:0, acMode, inputLimit und outputLimit, alles in Verbindung mit smartMode:1 – und mit möglichst wenigen Schreibvorgängen. -
@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 said in Test Adapter Zendure Solarflow:
@bmgs sagte in Test Adapter Zendure Solarflow:
B3Dxda
Wenn B3Dxda der product key ist sollte es mit der Version 2.0.3 laufen.
Hallo, funktioniert leider bei mir noch nicht, im Fallback legt mit Zendur auch eine ander Nr. an.
zendure-solarflow.0.hC1g9Utt
Lg
Bernd -
@Felli
Bei mir läuft es mit einer HUB2000 + ACE1500 Kombi.
Überschussladen mache ich ebenfalls klassisch per Script über autoModel:0, acMode, inputLimit und outputLimit, alles in Verbindung mit smartMode:1 – und mit möglichst wenigen Schreibvorgängen.@maxclaudi sagte in Test Adapter Zendure Solarflow:
@Felli
Bei mir läuft es mit einer HUB2000 + ACE1500 Kombi.
Überschussladen mache ich ebenfalls klassisch per Script über autoModel:0, acMode, inputLimit und outputLimit, alles in Verbindung mit smartMode:1 – und mit möglichst wenigen Schreibvorgängen.Genau so mache ich es auch, Schreibvorgänge sind soweit kastriert und werden nur vom Wetter beeinflusst 😜 Danke für die Rückmeldung 🤙🏼
-
@maxclaudi sagte in Test Adapter Zendure Solarflow:
@Felli
Bei mir läuft es mit einer HUB2000 + ACE1500 Kombi.
Überschussladen mache ich ebenfalls klassisch per Script über autoModel:0, acMode, inputLimit und outputLimit, alles in Verbindung mit smartMode:1 – und mit möglichst wenigen Schreibvorgängen.Genau so mache ich es auch, Schreibvorgänge sind soweit kastriert und werden nur vom Wetter beeinflusst 😜 Danke für die Rückmeldung 🤙🏼
Ich möchte mich an dieser Stelle zurückziehen, da ich den Adapter selbst nicht mehr nutze und stattdessen auf eine eigene Lösung umgestiegen bin.
Meine bisherigen Hinweise basierten ausschließlich auf eigener Analyse und Tests – jeder kann das bei Interesse selbst nachvollziehen.
Vielen Dank an alle hier für den Austausch und die vielen Ideen, die indirekt auch zu meiner eigenen Lösung beigetragen haben :+1:
Da ich den Adapter selbst nicht mehr einsetze, schaue ich nur noch ab und zu vorbei und beschränke mich künftig eher aufs Mitlesen.
Nochmals ein herzliches Dankeschön an alle :-)
-
@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
Wie bereits schon geschrieben habe ich seit der Version 2.01 offline mit weniger Schreibzugriffe seit Wochen überhaupt keine Probleme mehr. Ich benutze setDeviceAutomationInOutLimit.
Für mich kommt nur der offline modus in Frage, da ich so auch den Shelly em3 offline benutzen kann.
Ich habe jetzt auf die Version 1.03 upgedated.
Falls ich da Probleme feststelle werde ich das hier mitteilen. -
@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?
@nograx Hab mal 2.0.3 installiert und setDeviceAutomationInOutLimit wieder aktiviert. Das vom @maxclaudi beschriebene Verhalten mit dem Smartmode in der App konnte ich auch sehen. Ich melde mich wenn's was neues gibt.
-
@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?
@nograx sagte in Test Adapter Zendure Solarflow:
@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).
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?
Hab da auch fleißig mitgelesen und zusätzlich noch in der Zendure Community
Ich hab das so verstanden das es mehrere Ursachen für die Freeze gibt.
Eine Ursache lag wohl im HA Adapter und dieser wurde wohl behoben.
Eine weitere Ursache liegt eventuell in der Firmware , da soll es noch ein Update geben, bisher ist aber noch keins veröffentlicht worden. Und was eben auch zum Freeze führen kann ist laut Zendure eine schlechte Wifi Verbindung.
Wobei ich denke, das es nur an der Firmware liegt. Es kann ja immer mal zum Ausfall der Wifi Verbindung kommen, aber dann sorge ich als Developer dafür das anschließend das Gerät auch wieder läuft. Scheinbar ist bei Zendure auch kein Logging vorgesehen, denn dann würde man sehr schnell dem Fehler auf die Schliche kommen. -
@nograx said in Test Adapter Zendure Solarflow:
@bmgs sagte in Test Adapter Zendure Solarflow:
B3Dxda
Wenn B3Dxda der product key ist sollte es mit der Version 2.0.3 laufen.
Hallo, funktioniert leider bei mir noch nicht, im Fallback legt mit Zendur auch eine ander Nr. an.
zendure-solarflow.0.hC1g9Utt
Lg
Bernd@bmgs sagte in Test Adapter Zendure Solarflow:
@nograx said in Test Adapter Zendure Solarflow:
@bmgs sagte in Test Adapter Zendure Solarflow:
B3Dxda
Wenn B3Dxda der product key ist sollte es mit der Version 2.0.3 laufen.
Hallo, funktioniert leider bei mir noch nicht, im Fallback legt mit Zendur auch eine ander Nr. an.
zendure-solarflow.0.hC1g9Utt
Lg
BerndKannst du mir davon wohl mal einen Screenshot per PN schicken?
-
@nograx Bisher keine Ausfälle seit der Umstellung auf 2.0.3 und setDeviceAutomationInOutLimit mit Cloud
-
@nograx Bisher keine Ausfälle seit der Umstellung auf 2.0.3 und setDeviceAutomationInOutLimit mit Cloud
@lesiflo sagte in Test Adapter Zendure Solarflow:
@nograx Bisher keine Ausfälle seit der Umstellung auf 2.0.3 und setDeviceAutomationInOutLimit mit Cloud
Da ist vll. der Testzeitraum einfach noch zu kurz. :) Aber danke das du es ausprobierst!
-
@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.
@maxclaudi schade das du hier jetzt einen anderen Weg gehst. Wie genau gehst du denn hier vor?
Das mit dem lokal habe ich immer noch nicht verstanden. Wenn ich über die Cloud verbunden bin, sendet ioBroker den invoke Befehl an den Cloud MQTT und das verbundene Gerät empfängt die Aktualisierung und verarbeitet diese. "Lokal" kann ich da gar nichts an das Gerät schicken weil dieses nur Befehle vom verbundenen MQTT Server entgegen nimmt.
Das einzige Problem das ich mir hier vorstellen kann, ist das Szenario das man hier unter Devices in der Zendure App noch einen Shelly oder ähnlich eingebunden hat und durch die Änderung des Mode dieser wieder aktiv geschaltet wird und somit der nachgelagerte Server bei Zendure wieder Befehle schickt. Dann versuchen natürlich 2 Steuerungen das Gerät zu steuern. Da kann es dann natürlich zu Konflikten kommen.
-
Support us
494
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge