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.
Beiträge von SeRef
VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
-
-
Hallo 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
-
-
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
-
Wenn man die Funktion aktiviert, erscheinen weitere Einstellmöglichkeiten.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. - 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.
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.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. 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
-
Danke für die Rückmeldung
-
Hallo Saschago,
die spitzen Klammern (< >) dürfen nicht im Befehl stehen.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. Gruß
-
Hallo Olli,
Danke für die Rückmeldung. Es freut mich, dass es geklappt hat.
Bei HomeMatic war es von EQ3 anfänglich nicht beabsichtigt fremde Geräte einzubinden. Daher ist es auch nur über den Umweg CUxd möglich und dabei klemmt es halt hier und da etwas.
Im Gegensatz dazu ist ioBroker von Anfang an dazu gedacht gewesen Geräte verschiedener Hersteller miteinander zu Verbinden. Auch sind die Möglichkeiten einer Visualisierung deutlich besser.
Wenn jemand neu anfängt, nicht unbedingt HomeMatic Geräte einsetzen möchte und
/oder auf Visualisierung viel Wert legt, ist mit ioBroker meiner Meinung nach besser bedient.Viele Grüße
-
Hallo Olli,
da ich keinen DW2 habe, kann ich nur Vermutungen anstellen.
Wenn ich mir den Screenshot anschaue, denke ich, dass der DW2 je nach Helligkeit ein anderes Action auslöst. Da du aber den Status ohne Abhängigkeit haben möchtest, wirst du den Befehl für offen bei allen drei OPEN WHEN eintragen müssen.
Gruß
-
Hups, da war doch noch was ...
Bis jetzt sind alle meine Anforderungen an Shelly und HomeMatic erfüllt. Jetzt versuche ich die Shelly DW2 mit den Funktionen "open-close", eventuell "tilt", "temp" und wenns noch passt "light".
Die Darstellung von "open-close" sollte sich über die Actions direkt übertragen lassen. Es gibt von CUxD ein entsprechendes Gerät mit passender Symbolik (40 als SHUTTER). Für den Rest wirst du aber nicht um ein Skript herumkommen.
Gruß
-
Hallo Olli,
vielen Dank für deine Unterstützung.
Sehr gerne. Ich war eh gerade dabei einen Shelly vorzubereiten und da ich die Funktion Detached noch nicht kannte war es für mich auch sehr interessant.
Also das Thema Auto "on" ist erledigt. Habe ich rausgenommen. Weiß nicht was mich da geritten hat.
Sowas kommt schon mal vor, wenn man sich erst mal in etwas verrannt hat ...
TOP. Funktioniert einwandfrei.
Du bist der Größte.
Freut mich zu lesen. Aber der Größte ist doch weit übertrieben. 
Aber sag mal, was genau bewirkt "DPByHssDP"
Der Zugriff auf das Ojektmodell ist sehr umfangreich, daher nur mal in Kürze.
Es gibt verschiedene Möglichkeiten einen Datenpunkt anzusprechen und jede hat ihre eigene Syntax.
Das geht zum einen über die ISE_ID, die für jeden Datenpunkt eindeutig beim Anlegen vom System vergeben wird. Z.B. dom.GetObject(1234).State(1) (1234 ist hier nur ein Platzhalter). Dann geht es noch über die Adresse, dom.GetObject(CUxD.CUX2801001:1.SET_STATE").State(1).
Eine dritte Möglichkeit ist über den Namen. Wenn man über den Namen auf einen Datenpunkt von einem Gerät (nicht Systemvariablen!) und nicht auf STATE zugreifen möchte, geht es nur über DPByHssDP (dom.GetObject(„Test:1“).DPByHssDP(„SET_STATE“).State(1)).
Ein Kombinieren der verschiedenen Möglichkeiten wie du es versucht hast über Namen und Adresse (dom.GetObject(„Test:1.SET_STATE“).State(1)) ist nicht möglich.
Für weitere Informationen gibt es von EQ3 hierzu eine HomeMatic-Script Dokumentation in vier Teilen als pdf zum Herunterladen.
Ist zum Teil nicht gleich alles verständlich aber nach und nach erschließt sich einem so einiges.
Gruß
-
zu 1
muss ich so machen, damit wenn der Button in der APP betätigt wird das Relay nur 1 sek. anzieht. Der Garagentoröffner wird halt mit einem kurzen potentialfreien Kontakt (Taster) aktiviert. Wenn der Taster ein Schalter wäre, würde das Tor bei erneutem betätigen nicht stehen bleiben.
Dazu reicht es aber AUTO OFF zu aktivieren.
Wenn du auch AUTO ON aktivierst, kann es passieren (wenn du innerhalb der einen Sekunde ein zweites mal schaltest), dass das Relais vom zweiten Schaltbefehl vor Ablauf der Zeit ausgeschaltet wird und vom ON Timer nach einer Sekunde dauerhaft eingeschaltet wird. Jeder weitere normale (nicht doppelte) Schaltbefehl lässt dann das Relais nur für eine Sekunde abfallen und wird vom Timer wieder eingeschaltet.
Je nach Torantrieb kann das dazu führen, das der Antrieb von keiner anderen Quelle (originale Fernbedienung, Wand bzw. Schlüsseltaster, ...) mehr bedienbar ist.
Gruß
-
Hallo Olli,
wenn du den Eingang, der nicht den Ausgang schaltet, an die Homemati c weitergeben möchtest, musst du den Befehl unter "Button switched ON (OFF) url" eingeben.
Getestet habe ich, da ich (noch) keinen Shelly1 habe, mit einem 2.5. Denke aber, dass es gleich sein wird. Da muss der Befehl in "Button switched ON url"
http://192.168.2.97:8181/x.exe?ret=dom.GetObject(%22Test:1%22).DPByHssDP(%22SET_STATE%22).State(1)
und in "Button switched OFF url"
http://192.168.2.97:8181/x.exe?ret=dom.GetObject(%22Test:1%22).DPByHssDP(%22SET_STATE%22).State(0)
lauten.
Gruß
