Beiträge von SeRef

    Hallo Wilfrieduc,

    Mit x Varianten, eine davon:

    http://user:pw@192.xxx.x.xxx:8181/x.exe?ret=dom.GetObject(“%40NeuCux.CUX4000001:1.SET_STATE%40”).State(1)

    In der Url sind die Anführungszeichen (") durch %22 bzw. %27 (') zu ersetzen. Die %40 (@) dürfen dort nicht stehen.

    Entweder wird das Gerät über seinen Namen oder über seine Adresse angesprochen. Beides gemischt geht nicht.


    http://user:pw@192.xxx.x.xxx:8181/x.exe?ret=dom.GetObject(%22NeuCux:1%22).DPByHssDP(%22SET_STATE%22).State(1)


    http://user:pw@192.xxx.x.xxx:8181/x.exe?ret=dom.GetObject(%22CUxD.CUX4000001:1.SET_STATE%22).State(1)


    Der port 8181 muss enthalten sein. Freigegeben wird er in den Einstellungen zur Firewall. Zum Testen würde ich über den Sicherheitsassistenten die Einstellungen auf Relaxed stellen und wenn es funktioniert wieder zurück auf die alten Einstellungen. Minimiert die Fehlerquellen. In der Url ist dann auch keine Angabe des Nutzers und Passwort nötig.


    http://192.xxx.x.xxx:8181/x.exe?ret=dom.GetObject(%22NeuCux:1%22).DPByHssDP(%22SET_STATE%22).State(1)

    http://192.xxx.x.xxx:8181/x.exe?ret=dom.GetObject(%22CUxD.CUX4000001:1.SET_STATE%22).State(1)


    Die Url kann zum Testen auch in einem Browser als Adresse eingegeben werden.

    Die Befehlszeilen habe ich nicht explizit getestet, sollte so aber passen. Wenn nicht, bitte noch mal melden.

    Gruß

    SeRef

    Aber wird der Wert auch per MQTT mitgeteilt

    Ja wird er. Allerdings nicht in kWh, sondern in Wattminuten ohne Kommastelle. Der Wert ist aber bei kleinen Verbräuchen sehr ungenau.

    Mal eine etwas andere Theorie:

    Das Lager war schon länger defekt. Bei jedem Starten des Motors war der Anlaufstrom dadurch höher als normal. Dieser höhere Einschaltstrom hat dazu geführt, dass die Relaiskontakte höher belastet wurden bis einer mal kleben blieb. Beim nächsten ansteuern des Motors in die andere Richtung kam es dann durch den klebenden Kontakt zum Kurzschluss.


    Gruß

    SeRef

    Wenn man die Funktion aktiviert, erscheinen weitere Einstellmöglichkeiten.

    Obstacle.png


    • Disabled -> Aus
    • While Opening -> aktiv nur beim Öffnen
    • While Closing -> aktiv nur beim Schließen
    • While Moving -> aktiv beim Öffnen und Schließen


    Wenn er einfach stoppt, dann wäre das eine Möglichkeit, also einfach eine herausnehmbare Sperre einbauen. Entweder ein Loch bohren und einen Stift einstecken oder ein entsprechend langes Holzleistchen in die Rolladenführungsschiene stecken (am Besten dann beidseitig).

    Davon würde ich abraten. Bevor der Motor in der Abwärtsbewegung stoppt, wickelt er den Panzer erstmal weiter von der Welle bis es zur Blockierung im Rollokasten kommt. Wenn das mal vorkommt, wird die Überlasterkennung den Motor und den Panzer vor gravierenden Schäden bewahren. Aber auf Dauer wird das nicht lange gutgehen.

    Angeschaut habe ich mit das, was über das Web-Interface angezeigt wird.

    Dort sind die Werte bei mir quasi identisch 181W mit 1.9.2 und 180W mit 1.10.1

    Die Werte der Leistungsanzeige, die über die Webui angezeigt werden sind bei mir auch in etwa gleich. Nur eben der Verbrauch der einzelnen Fahrt, den ich ermittele, indem ich über API mit <ip>/meter/{index} unter total abrufe und die Differenz zum vorhergehenden berechne, liegen weit auseinander. Auch differieren die Verbräuche der Fahrten untereinander sehr stark. Bei 1.9.4 sind es ca. 1-3 Wmin, bei 1.10.0 sind es schon mal 80 Wmin.

    Wenn ich über die angezeigte Leistungsaufnahme und der Laufzeit den Verbrauch berechne, komme ich in etwa auf den Wert wie ich ihn auch bei 1.9.4 übermittelt bekomme.

    Der Jahreswert ist die Summe der Verbräuche der letzten 12 Monate. Da ich aber erst die Werte von drei Monaten habe, ist der Wert über den Dreisatz (Summe / Anzahl * 12) berechnet.

    Ob es Sinn ergibt, in Anbetracht der Messungenauigkeit, den Eigenverbrauch mitzuberücksichtigen, will ich mal dahingestellt lassen. Zumal der Verbrauch vom Shelly zum Betreiben des Rollos meiner Meinung nach dazu gehört. Ich will aus der Verbrauchsmessung keine Wissenschaft machen, ein angenäherter Wert reicht mir da völlig aus. Aber dazu sollten die Werte schon halbwegs plausibel sein.

    Ohh Mann, es war scheinbar gestern Abend doch zu spät. :sleeping:

    Meine Aussagen beziehen sich nicht auf die Leistungsmessung, sondern auf die Verbrauchsmessung.

    Ich habe mir für meine Homematic eine Verbrauchsanzeige hinzugefügt. Um die Berechnung dafür kontrollieren zu können, logge ich die über die API gelesenen Werte. Da ist es mir dann aufgefallen.


    Verbrauch.png


    Der Shelly war ca. 3 Tage auf v1.10.0 bzw. v1.10.1. In diesen drei Tagen hat sich der Verbrauch für den laufenden Monat dermaßen erhöht, dass er schon über dem Verbrauch des Vormonats ist. Erst vermutete ich einen Fehler in der Berechnung, sah dann aber im Log, das die übermittelten Verbrauchswerte deutlich von den bisherigen abweichen.

    Seit ich wieder zurück auf v1.9.4 ist es wieder okay.

    Gruß

    SeRef

    PS: Der Jahreswert ist eine Hochrechnung aus den bisherigen Werten. Solange habe ich den Shelly noch nicht.

    Hallo,

    mir ist aufgefallen, das seit dem Update von 1.9.4 auf 1.10.0 die Leistungsmessung gravierend andere Werte ermittelt. Fahrten, die vorher ca. 33 - 35 Wmin bei 80% Fahrtzeit waren, sind jetzt ca. 90 - 180 Wmin. Noch größer ist die Abweichung bei der Fahrt der restlichen 20%. Vorher ca. 9 Wmin, jetzt 80 - 90Wmin. Update auf 1.10.1 brachte keine Besserung.

    Hat noch jemand solche Abweichungen feststellen können?

    Gruß

    SeRef