Beiträge von SeRef

Zitat von SeRef

Solange unter "Output on URL" er per http einen Befehl an sich selber sendet, wird dort http als letzte Quelle stehen, egal auf welchem Weg er ein- oder ausgeschaltet wurde.

Zitat von radierer

Das ist logisch. Verstehe ich denn "Output on URL" falsch? Ich habs so interpretiert, dass der Befehl dann abgesetzt wird, wenn switch=an. Und nicht bei jeder x-beliebigen Aktion. Falsch interpretiert?

Sorry, falsche Info. Bei "Output on URL" natürlich nur beim Einschalten und nicht beim Ausschalten.

Das er allerdings, obwohl schon Ein, auch beim Dimmen den Action auslöst, ist schon fragwürdig. Meiner Meinung nach sollte das nicht so sein und würde es als Bug bezeichnen. Hier wäre es besser, einen separaten Action zu haben, der dann auslöst, wenn der Dimmwert geändert wurde.

Hallo cf-mossi,

http://<ip>/roller/0/calibrate

Ist hier unter "Position control" zu finden.

Gruß

SeRef

Es hat den Anschein, dass alleine das Ändern des Dimmwertes den Action schon auslöst (ob das nun ein Feature oder Bug ist )

Wann genau der Action auslöst, ließe sich recht leicht herausfinden. Du könntest z.B. per Befehl eine Variable über die API von ioBroker ansprechen und diese ins Log schreiben lassen.

Zitat von radierer

Bei mir steht immer http?

Solange unter "Output on URL" er per http einen Befehl an sich selber sendet, wird dort http als letzte Quelle stehen, egal auf welchem Weg er ein- oder ausgeschaltet wurde.

Hallo radierer,

ich habe keinen Dimmer um es nachstellen zu können und bin mir über sein Verhalten nicht sicher, habe aber eine Vermutung.

Du schaltest den Dimmer ein. Er sendet daraufhin an sich selbst über Output on (URLs) den Befehl, einzuschalten und auf 50% zu Dimmen. Meine Vermutung ist nun, dass er, da er den Befehl zum Einschalten bekommen hat, wieder den Befehl über Output on (URLs) absendet und so eine Schleife entsteht.

Versuch mal das turn=on wegzulassen:

http://localhost/light/0?brightness=50

Okay, sehe gerade erst, dass es zwar im Forum zum normalen 1PM steht, die Frage aber dem Plus galt. Hatte ich überlesen.

Wie es sich beim Pro4 PM verhält, kann ich nichts zu sagen. Mein 1PM hinter einer PV zeigt positive Werte und auch die Verbrauchswerte sind positiv. Firmware ist die 1.11.7

Ob Bezug oder Lieferung, die Leistung wird immer als positiver Wert angegeben.

Hallo Schmalz,

Zitat von Schmalz

Ich habe ein CUX D Typ (40) als Dimmer angelegt.

laut Anleitung sollte es ein Typ(28) sein. Ist an der Seriennummer in der URL für die Actions zu erkennen.

Die Ordnerstruktur ist meines Wissens identisch.

Gruß

SeRef

Wenn es dir nur darum geht, die Variable zu ändern, kannst du dir den Umweg über das CUxD-Gerät sparen. Der Shelly kann die Variable auch direkt ändern:

http://192.xxx.x.xxx:8181/x.exe?ret=dom.GetObject(%22Anwesend%20Moni%22).State(0)

bzw.

http://192.xxx.x.xxx:8181/x.exe?ret=dom.GetObject(%22Anwesend%20Moni%22).State(1)

Hallo Wilfrieduc,

Zitat von 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

Zitat von AleXSR700

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.

Zitat

1PM


shellies/shelly1pm-<deviceid>/relay/0/energy reports an incrementing energy counter in Watt-minute

2.5


shellies/shellyswitch25-<deviceid>/roller/0/energy reports amount of energy consumed in Watt-minute

bzw.

shellies/shellyswitch25-<deviceid>/relay/<i>/energy for each relay <i>; reports amount of energy consumed in Watt-minute

Alles anzeigen

In der Tat, das sieht okay aus.

Als Option hättest du den schon erwähnten Tausch des Shelly gegen einen anderen. Damit könntest du den Fehler noch etwas weiter eingrenzen. Kommt es vom Shelly oder eventuell Motor.

Im Firmware Archiv hier im Forum ist v1.9.6 (sollte neu genug ein) und im Filebase die 1.10.4 20210429-102101/v1.10.4-g3f94cd7.

Zitat von Hirschcom

Firmware (20200629-130515/release-1.7@28744b8b)

Könnte an der alten Firmware liegen. Aktuell müsste die 20210429-102101/v1.10.4-g3f94cd7 sein.

Hallo Hirschcom,

Zitat von Hirschcom

Also der Link bzw. die URL muss falsch sein.

Ich vermute das %27 für ein " steht ... und %20 für ? und %22 für ?

wer kann hier witerhelfen ? kenne mich da nicht so gut aus

%27 -> ' (Apostroph)

%20 -> ␣ (Leerzeichen)

%22 - > " (Anführungszeichen)

Ich habe den Link Versuchsweise in einem 2.5 eingegeben. Dort wird er ohne Fehlermeldung akzeptiert.

Gruß

SeRef

gelöscht

Zitat von Seven of Nine

Obstacle Detection im Shelly aktiviert?

.. oder/und Max power protection. Waren zumindest auch meine ersten Gedanken.

Beides würde unter "stop_reason" angegeben.

Interessant wäre auch, was der Shelly als Grund für den Stopp angibt. Dazu gib einfach im Browser folgendes ein (IP anpassen!):

http://<Ip vom Shelly>/roller/0

Hinter "stop_reason" wird es ausgegeben.

Vielleicht gibt das einen Hinweis.

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

Hallo elkon,

hast du die Funktion "Obstacle Detection" oder "Max power protection" aktiviert? Wenn ja, versuche es mal mit höheren Werten.

Gruß

SeRef