Beiträge von LustigePerson

Ok, danke. Ich denke dann muss ich Einiges umbauen, da ich ja aktuell die Sensoren der Shelly integration nutze. aber dann ist es wohl so. Möglicherweise kann ich es auch über Custom Templates zusammenhäkeln.

Vielleicht kommt von Tasmota ja bald ein passendes Template für den Shelly, das wäre wohl die technisch weitaus profesionellere Lösung, bei der nicht ständig nicht-konfigurierbare Parameter verändert werden. Shelly baut echt coole Geräte, aber die Softwares sind absolute Clownsprodukte.

Hallo,

bei mir hängt ein Pro 3 EM in der Unterverteilung und ich stuere diverse Dinge Verbrauchsabhängig, wobei wichtig ist, dass ich auch eine Solaranalage im System habe.
als ich den Pro 3 EM gekauft habe hat er alle 1-3 Sekunden einen Wer reported. Ich erinnere michd aran, dass es beim Update von 0.14.1 schon Schwierigkeiten gab, weil sowohl das WebUI, als auch das senden per MQTT super träge war. Das wurde dnan IMHO in einem späteren update wieder zurückgenommen. Im Zuge des Desaters mit Update 1.5 habe ich mien Ganzes System jetzt noch mal angeschaut und festgestellt, dass mit 1.4.1 (und vermutlich schon früher) das ganze Reporting super träge ist. Per MQTT und ind er Ha integration bekomme ich nur alle 15 Sekunden einen Wert, selbst bei großen Lastwechseln. Daher ist einerseits meine Saldierung daneben, aber auch der errechnete Momentanvebrauch haut halt völlig daneben, da die PV-Analge Ihre Werte jede Sekunde sendet.

WIE kann ich das einstellen? Bzw. welche Workaround muss ich wählen? Tasmota z.B. hat ja die Möglichkeit zu konfigurieren in welchem intervall Daten gesendet werden und bei welcher absoluten bzw. prozentualen Änderung. Es kann ja wohl nicht sein dass Shelly, die mal als "professionell" gelten wollten, das nciht unterstützen, oder?
Ich gehe also stark davon aus, dass ich etwas übersehe, denn das kann ja wohl nciht das gewünschte Verhalten sein.

Für eure Hilfe wäre ich sehr dankbar.

Zitat von Angel

Bitte damit überprüfen ob die Probleme mit den HA-Scripts und auch dem Eco-Mode weiterhin bestehen.

Soll das ein Witz sein? Sind die User das Shelly Testlabor? Vielleicht solltet ihr euren Entwicklern mal eine Schulung zum Thema "Test driven Development" spendieren...

Die wenigsten Nutzer werden daheim komplexe Testaufbauten haben und sind durch Shelly's Politik keine downgrades anzubieten und selbst nicht vernünftig zu testen gezwungen "in Production" zu testen und zu hoffen dass nichts schief geht.

SEHR enttäuschend.

Angel In der Ankündigung zu den Problemen steht, dass 1.4.4 zur Verfügung gestellt wird. -> wo?

hampenpampen Danke für die Zusammenfassung. Was ich eben noch intzeressant finde: Das Reporting intervall für die Sensoren ist viel länger geworden, was für mich auch ein Problem ist. Ich frage mich ob das daran liegt dass Bluetooth hier Rechenzyklen frisst, oder ob das "Absicht" war.

Zitat von apreick

Arbeitet dort auch fleißig (empfängt dort viele andere und meine Geräte)

Ist bei dir das Update Intervall jetzt auch länger? Ich erinnere mich dass es diesen bug schon mal Beinwechsel auf 1.0.0 oder so gab. Ich bekomme jetzt z.t. nur alle 20 Sekunden ein Update. Da in Home assistant saldiert wird, ist das sehr ungünstig.

Zitat von Sheldor81

Ticket ist eröffnet.

Habe Antwort. Angeblich machen sie keine downgrades mehr und mein einziges Skript soll schuld sein. Deaktivieren des selben bringt aber nichts.

Auffällig ist aber, dass das Update Intervall auch sehr viel geringer ist. Nicht nur per mqtt, sondern auch direkt in der Cloud bzw. web app

Zitat von apreick

Neu Laden

Ah! 🤣

Ok. Das ergibt Sinn. Ich werde mal auf Rückmeldung vom Support warten, vielen lieben Dank für deine Hilfe!

Zitat von apreick

mindestens 3x reflash (am Tablet sowie Edge am Laptop

Darauf habe ich mich bezogen.

Und tagesaktuelle FW installieren, ok. Aber was soll man machen? Bevor man installiert alle Foren in aller Tiefe durchsuchen?

Oder gibt es eine einfaxhe Möglichkeit sich ein Bild der Lage zu machen? Selbst wenn es Probleme gibt und ne 1.5.1 kommt kann diese ja wieder mit neuen Bugs kommen.

apreick Was meintest du denn mit reflash?

Ich finde das ehrlicherweise bei shelly super problematisch, dass die immer so Bananaware (reift beim Kunden) vertreiben.
Entweder das Zeug ist komplett durchgetestet bevor es released wird ODER es muss einen Weg zum downgrade geben ohne auf ein ticket zu warten.

Das ist mein erstes Shelly Gerät und auch mein Letztes glaube ich. Ich dachte das wäre (mindestens) semiprofessionel, aber selbst mein Open Source Tasmota läuft überall stabiler.

Wenn ich über die Cloud AP nen AP aufmache habe ich über diesen genau das Gleiche problem, mit gleicher Meldung.
Aber selbst wenn ich drauf komme: wo bekomme ich ne alte FW her?

in HA habe ich auch den Eindruck, dass das MQTT intervall größer ist oder zumindest kommen seltener Daten an als vorher.

EDIT: Nachdem ich den AP deaktiviert habe, komme ich per Edge Browser (Weder Firefox, noch chrome, was gar keinen sinn ergibt) auf die UI.

ALSO: wo bekomme ich jetzt FW 1.4.5 her?

Beim Pro 3EM komme ich nicht mehr ins Webinterface:

Die Verbindung zu ws://192.168.178.61/rpc wurde unterbrochen, während die Seite geladen wurde. 192.168.178.61:12:2495
Error: Error in transport
    oncePromise http://192.168.178.61/:12
    oncePromise http://192.168.178.61/:12
    oncePromise http://192.168.178.61/:12
    messageQueue http://192.168.178.61/:12
    getNextMessage http://192.168.178.61/:12
    refresh http://192.168.178.61/:21
 Error in transport 192.168.178.61:21:15278
    refresh http://192.168.178.61/:21
Connected to Device... 192.168.178.61:21:14852
Failed init with error: TypeError: e.data.values[0] is undefined
    EMData http://192.168.178.61/:12
    subscribe http://192.168.178.61/:12
    EMData http://192.168.178.61/:12
    registerComponent http://192.168.178.61/:12
    initComponents http://192.168.178.61/:12
    initComponents http://192.168.178.61/:12
    _DeviceComponentsFactory http://192.168.178.61/:12
    r http://192.168.178.61/:12
    r http://192.168.178.61/:12
    _doInitialRequests http://192.168.178.61/:21
    refresh http://192.168.178.61/:21
    DeviceFactory http://192.168.178.61/:21
    <anonymous> http://192.168.178.61/:21
192.168.178.61:21:15953
Uncaught (in promise) TypeError: e.data.values[0] is undefined
    EMData http://192.168.178.61/:12
    subscribe http://192.168.178.61/:12
    EMData http://192.168.178.61/:12
    registerComponent http://192.168.178.61/:12
    initComponents http://192.168.178.61/:12
    initComponents http://192.168.178.61/:12
    _DeviceComponentsFactory http://192.168.178.61/:12
    r http://192.168.178.61/:12
    r http://192.168.178.61/:12
    _doInitialRequests http://192.168.178.61/:21
    refresh http://192.168.178.61/:21
    DeviceFactory http://192.168.178.61/:21
    <anonymous> http://192.168.178.61/:21
192.168.178.61:12:98385
    _doInitialRequests http://192.168.178.61/:21
    InterpretGeneratorResume self-hosted:1413
    AsyncFunctionNext self-hosted:800
    (Async: async)
    refresh http://192.168.178.61/:21
    InterpretGeneratorResume self-hosted:1413
    AsyncFunctionNext self-hosted:800
    (Async: async)
    DeviceFactory http://192.168.178.61/:21
    <anonym> http://192.168.178.61/:21
TypeError: e is undefined bundle.js:2:616682

MQTT und Cloud laufen noch, aber auch etwas instabil.

Hallo,

nach dem update auf 1.5.0 komme ich nicht mehr auf das Webinterface. Der Pro 3EM kommuniziert noch per MQTT und ist auch in der Cloud verfügbar, allerdings scheint auch dort die Verbindung etwas instabiler als sonst.
Per (verschiedenen) Browsern komme ich aber nicht mehr über die lokale IP auf das Webinterface.
Fehler:

Die Verbindung zu ws://192.168.178.61/rpc wurde unterbrochen, während die Seite geladen wurde. 192.168.178.61:12:2495
Error: Error in transport
    oncePromise http://192.168.178.61/:12
    oncePromise http://192.168.178.61/:12
    oncePromise http://192.168.178.61/:12
    messageQueue http://192.168.178.61/:12
    getNextMessage http://192.168.178.61/:12
    refresh http://192.168.178.61/:21
 Error in transport 192.168.178.61:21:15278
    refresh http://192.168.178.61/:21
Connected to Device... 192.168.178.61:21:14852
Failed init with error: TypeError: e.data.values[0] is undefined
    EMData http://192.168.178.61/:12
    subscribe http://192.168.178.61/:12
    EMData http://192.168.178.61/:12
    registerComponent http://192.168.178.61/:12
    initComponents http://192.168.178.61/:12
    initComponents http://192.168.178.61/:12
    _DeviceComponentsFactory http://192.168.178.61/:12
    r http://192.168.178.61/:12
    r http://192.168.178.61/:12
    _doInitialRequests http://192.168.178.61/:21
    refresh http://192.168.178.61/:21
    DeviceFactory http://192.168.178.61/:21
    <anonymous> http://192.168.178.61/:21
192.168.178.61:21:15953
Uncaught (in promise) TypeError: e.data.values[0] is undefined
    EMData http://192.168.178.61/:12
    subscribe http://192.168.178.61/:12
    EMData http://192.168.178.61/:12
    registerComponent http://192.168.178.61/:12
    initComponents http://192.168.178.61/:12
    initComponents http://192.168.178.61/:12
    _DeviceComponentsFactory http://192.168.178.61/:12
    r http://192.168.178.61/:12
    r http://192.168.178.61/:12
    _doInitialRequests http://192.168.178.61/:21
    refresh http://192.168.178.61/:21
    DeviceFactory http://192.168.178.61/:21
    <anonymous> http://192.168.178.61/:21
192.168.178.61:12:98385
    _doInitialRequests http://192.168.178.61/:21
    InterpretGeneratorResume self-hosted:1413
    AsyncFunctionNext self-hosted:800
    (Async: async)
    refresh http://192.168.178.61/:21
    InterpretGeneratorResume self-hosted:1413
    AsyncFunctionNext self-hosted:800
    (Async: async)
    DeviceFactory http://192.168.178.61/:21
    <anonym> http://192.168.178.61/:21
TypeError: e is undefined bundle.js:2:616682

D.h. slebst wnen ich wüsste wie, könnte ich nicht downgraden.

Zitat von Huckes

Ok, aber wenn ich "total active power" benutze, dann kann ich doch aus dieser Angabe den saldierten Wert bereits errechnen und muss nicht erst über die Werte der drei Einzelphasen "phase_a|b|c_active_power" gehen und das dann summieren.

Evtl. stehe ich auf dem Schlauch oder mein E-Technik-Studium ist zu lange her und ich hab' mich dann später nur noch mit Bits und Bytes beschäftigt.

Vermutlich zu spät aber für's Protokoll: Die FW vor 1.0.0 hat die Summe nciht per MQTT bzw. Shelly integration in HA übermittelt, daher musste man dort händisch summieren.

Hallo Huckes
hier mein Code für Import, Export, Consumption und aktuelle net-power. Da muss dann eben noch ein Integral drauf. (Riemann Summe als Helper) und zum Aufsummieren ein (oder mehrere z.B. Tag, Monat, Jahr) Verbrauchszähler (ebenfalls Helper)

template:
  - sensor:
      - name: "Power Import"
        unit_of_measurement: 'W'
        state: >-
          {% if (states('sensor.shellypro3em_01_phase_a_active_power')|float + states('sensor.shellypro3em_01_phase_b_active_power')|float + states('sensor.shellypro3em_01_phase_c_active_power')|float) > 0 %}
            {{ states('sensor.shellypro3em_01_phase_a_active_power')|float + states('sensor.shellypro3em_01_phase_b_active_power')|float + states('sensor.shellypro3em_01_phase_c_active_power')|float | round(4)}}
          {% else %}
            {{ 0 }}
          {% endif %}
        availability: "{{
            [ states('sensor.shellypro3em_01_phase_a_active_power'),
              states('sensor.shellypro3em_01_phase_b_active_power'),
              states('sensor.shellypro3em_01_phase_c_active_power')
            ] | map('is_number') | min
          }}"
      - name: "Power Export"
        unit_of_measurement: 'W'
        state: >-
          {% if (states('sensor.shellypro3em_01_phase_a_active_power')|float + states('sensor.shellypro3em_01_phase_b_active_power')|float + states('sensor.shellypro3em_01_phase_c_active_power')|float) < 0 %}
            {{ (states('sensor.shellypro3em_01_phase_a_active_power')|float + states('sensor.shellypro3em_01_phase_b_active_power')|float + states('sensor.shellypro3em_01_phase_c_active_power')|float | round(4)) * -1 }}
          {% else %}
            {{ 0 }}
          {% endif %}
        availability: "{{
            [ states('sensor.shellypro3em_01_phase_a_active_power'),
              states('sensor.shellypro3em_01_phase_b_active_power'),
              states('sensor.shellypro3em_01_phase_c_active_power')
            ] | map('is_number') | min
          }}"
      - name: "Power Consumption"
        unit_of_measurement: 'W'
        state: >-
          {% if (states('sensor.power_export')|float(0)) > 0 and (states('sensor.hm600_power')|float(0) - states('sensor.power_export')|float(0)) < 0 %}
            {{ 0 }}
          {% elif (states('sensor.power_export')|float(0)) > 0 and (states('sensor.hm600_power')|float(0) - states('sensor.power_export')|float(0)) > 0 %}
            {{ ((states('sensor.hm600_power')|float(0)) - (states('sensor.power_export')|float(0))) | round(4) }}    
          {% else %}
            {{ ((states('sensor.power_import')|float(0)) + (states('sensor.hm600_power')|float(0))) | round(4) }}
          {% endif %}
      - name: "Power Net"
        unit_of_measurement: 'W'
        state: >-
          {{ (states('sensor.shellypro3em_01_phase_a_active_power')|float + states('sensor.shellypro3em_01_phase_b_active_power')|float + states('sensor.shellypro3em_01_phase_c_active_power')|float)|round(2) }}

siehe auch mein thread: Wirkleistung - Scheinleistung - Powerfaktor -- Irgendwas stimmt hier nicht

Irgendwas stimmt da halt nicht. Der Support will das Problem wie üblich nicht verstehen und verwies bei mir auf die 5% Fehler unterhalb 1A. Das solle die 500% Abweichung erklären und eigentlich seiner Shelly auf für industrielle Anwendung und nicht für so kleine Leistungen gedacht. Da die Integration über die active power in home assistant aber einigermaßen zum EVU Zähler passt gehe ich auch einfach von einem unsinnigen Powerfactor aus.

Also, hier das Update: Der shelly support kann an den Zahlen nichts falsches finden und verweist auf den 5% fehler unter 1A. Die 20 bis über 500 % Abweichung zwischen manuell berechneter und angezeigter Wirkleistung sollen demnach auch korrekt bzw. vom Fehler abgedeckt sein. Ich habe mir jetzt noch mehrere Screenshots und Videos zum 3EM und dem "Pro 3EM" angeschaut und durch die Bank weg hat der Pro größere Abweichungen.
Wie hier im Thread auch von Jonvelle gezeigt, passen die Werte beim "alten" 3EM i.d.R. zusammen.

Ich werde den Shelly also wohl wieder ausbauen und mal nen 3EM testen oder mich, was wahrscheinlicher ist, nach Lösungen abseits von Shelly umschauen. Mein generelles Gefühl ist dass die ihre Produkte nicht wirklich im Griff haben.

thgoebel Nene, auf keinen Fall nehme ich davon Abstand. Aber trotzdem ist mir halt wichtig zu verstehen ob die angezigten Werte stimmen. Ich habe mir das Datenblatt auch angesehen und IMHO kommen die Werte, wie du schon sagtest, zwar vom Chip, aber d.H. ja nicht das schelly da nicht noch irgendwie rumbiegt oder etwas falsch zuordnet (Siehe z.B. die doppelte Gesamtsumme bis zur aktuell FW).
Wenn ich das aber richtig verstanden habe ist es tatsächlich möglich dass die Wirkleistung stimmt obwohl Scheinleistung und PF nicht zusammen passen, weil die intern nicht auseinander errechnet werden. Trotzdem SOLLTEN diese Werte ja zumindest in der Größenordnung passen, was ja absolut nicht der Fall ist und sich nur erklären lässt wenn die verschiedenen Werte SEHR unterschiedliche Fehler (bei geringen Lasten) produzieren.

Was ich schon etwarte ist dass ich mich auf die Werte und den Shelly verlassen kann, ob Sie vom Chip oder aus der Implementation kommen sei mal dahingestellt. Ich hoffe der support meldet sich dazu, ansonsten bleibt halt am ende, egal warum, das mindestens einer der Werte pro Phase B/C nicht stimmen kann.

Zitat von thgoebel

Es empfiehlt sich, das Datenblatt zu dem IC in einer ruhigen Minute zu studieren:

Uff,,, ich dachte eigentlich ich kaufe ein funktionierendes Produkt und gut. Wenn ich jetzt erst 100 Seiten Dokumentation lesen muss um zu verstehen warum es was anzeigt kann ich den Kram auch gleich selber bauen, z.B. per PZEM-004T. Dann habe ich auch alle Variablen selbst im Griff.
Und da du oben ja auch selbst geschrieben hast dass Phase B/C nicht richtig aussehen gehe ich von einem Problem mit dem Geät aus. Die Zuordnung und Verkabelung habe ich nun oft genug geprüft. Also warte ich mla noch 2-3 Tage auf Antwort vom Support um zu schauen ob die das schlüssig erklären können. Ansonsten geht das Teil vermutlich zurück, dann ist mir auch egal ob der Chip, die Implemanttion oder die Anzeige das Problem ist.

EDIT: Trotzdem erst mal danke dir für den Link.

Danke thgoebel, Wie gesagt wenn ein Wasserkocher o.Ä. läuft dann schenit der "Fehler" ja auch nicht so groß. ICh werde das noch mal mit ohmschen Verbrauchern testen.

Aber dein Beitrag bestätigt meine Verwirrung. Es wird doch zunächst mal die Scheinleistung ermittelt und dann mit dem PF die Wirkleistung errechnet. Schau dir mal (Extrembeispiel) Phase C in meinem ersten Bild an: 94.8VA bei PF -0.53. Dabei werden 8.8W angezeigt. Die 8.8 Watt können passen (nur ein paar standby Verbraucher). Aber wie kommt dieser Wert zustande? Ja wohl ganz offensichtlich nicht durch Multiplikation des PF mit der Scheinleistung, das müsste irgendwas um 47W sein (Das wäre gegeben die Verbraucher auch völlig unrealistisch).

WENN die Wirkleistung stimmt und diese aus den anderen Werten errechnt wird MÜSSEN diese Werte doch ebenfalls korrekt sein, oder?