Beiträge von Bekka420

In den Einstellungen vom Eingang ist ein drop-down menü, siehe Screenshot

Und ja , digital in und gnd

Danke für die vielen Infos , werde den Großteil meiner Lüfter bald auch mit dem rgbw pm regeln und dadurch auf step downs verzichten können

für den von dir genannten zweck reicht vmtl auch locker der pm mini gen3 -> günstiger und verfügbar bei den bekannten quellen
es sei denn matter oder zigbee spielen eine rolle, da bin ich dann raus

Ein paar Denkanstöße zum dimmen des rgbw pm per Blu Button

Du könntest auf die MehrfachKlicks actions mit einem Offset legen und damit in einem raster dimmen , siehe hier

https://shelly-api-docs.shelly.cloud/gen2/Component…Light/#lightset

In Ermangelung eines 4fach Buttons habe ich das noch nicht realisiert, aber so ist es im Kopf geplant Dann wären die fix Werte schonmal passé

ebenfalls ist dort das dimmen per rpc beschrieben dimup dimdown und dimstop , das hab ich aber noch net selbst probiert sollte aber funktionieren als wäre ein Taster direkt am rgbw

Single push : toggle

Double push: dimup / offset +15

Triple push: dimdown / offset -15

Long push: dimstop

So oder so ähnlich

moin

hab scheinbar nen bug gefunden, erneut in sachen counter reset. aufgefallen ist es mir leider erst nach dem update auf 1.62

wie dort beschrieben
https://shelly-api-docs.shelly.cloud/gen2/Component…ounters-example

wollte ich den counter eines Dimmer 0-10V PM G3 resetten
bekomme darauf aber leider eine 404

zunächst hielt ich mich für übermüdet, aber
/rpc/light.GetStatus?id=0 funktioniert und liefert auch den counter
hat man mglw den reset in der light instanz vergessen zu implementieren ?

eben noch getestet:
der reset via switch bei einem 1pm mini g3 funktioniert einwandfrei
ebenso via pm1 bei einem pm mini g3
beide laufen auf der aktuellen 1.62

nein, bisher habe ich dahingehend nichts gemeldet. hatte mich ehrlich gesagt mehr oder weniger damit abgefunden, fummelige aufgaben auf den laptop verlagert und auch bis zu diesem thread nichts von derartigen problemen bei anderen leuten gehört bzw gelesen. nach weiteren tests und nochn büschen beweismaterial sammeln werd ich das aber wohl mal nachholen

habe eben die app incl cache und nutzerdaten gelöscht und das ganze frisch installiert.

nach dem testweise schalten eines relais wurde ich wieder aufgefordert das passwort einzugeben. es schaltete doppelt. jetzt mal abwarten und sehen wie es sich verhält wenn das "timeout" erreicht ist. die hoffnung ist, dass sich die app das nun "merkt" und der fehler nur bei erstkontakt auftritt (klammert sich an letzten halm xD )

hier mal etwas detaillilerter beschrieben:

drücke in der android app auf schalten - das relais schaltet sofort
es folgt direkt danach die passwortabfrage wie in casi239 screenshot - gebe ich dort dann das passwort ein und bestätige , schaltet das relais nochmal
das passiert bei allen passwortgeschützten shellys, auch bei den dimmern oder den unis.
ohne passworteingabe verbleibt der shelly im "locked" status
den shelly kann ich danach per passwort freischalten, aber dann wird wieder geschaltet
der einzige weg ohne doppeltes schalten führt über den taskmanager, app beenden und neustarten.
locked ist dann weg, die angezeigten daten korrekt und es wird nicht nochmal geschaltet.

edit nächster tag:

das neu aufsetzen der app scheint die lösung gewesen zu sein. mal abwarten obs auch so bleibt.
habe inzwischen auch den rgbw pm wieder mit nem passwort versehen und wurde NICHT danach gefragt <- alles falsch

ne, irgendwie funktionierte die lokale netzwerksteuerung nicht. die schaltbefehle kamen über die cloud (source shc). neustart der app - altes problem

du kannst den switch direkt über die webgui des shellys über components -> bthome verbinden und dann dem entsprechend actions anlegen.

ohne wifi am endgerät geht es nicht über die app bzw die cloud

das passwort welches abgefragt wird ist das im gerät hinterlegte für die webgui, nicht der 4 stellige pin
es gibt eine option in der app, siehe screenshot, wenn ich die deaktiviere werden die passwörter nicht mehr abgefragt

Ist bei mir auch so und tw sehr anstrengend, letztens ging deswegen fast ein Gerät kaputt.

Es passiert immer wenn das die app ausführende Gerät im selben netz wie die zu steuerden Shelly's hängt.

dort die Email Adresse des Nachbarn bzw des 2. Account eintragen und voila

Mit der neuen beta fw gibt es die Option die physischen Inputs zu sperren

ist schon wem die power factor anzeige aufgefallen ? (hier ein plus2pm, die anderen beiden verhalten sich ebenso)

http://<shelly-ip>/light/0?turn=on

ohne sonstige parameter schaltet der dimmer entweder auf den zuletzt eingestellten brightness wert oder mindestens auf das voreingestellte minimum (siehe screenshot)

es ist entweder eine solche voreinstellung nötig oder ein brightness level in der url, in beiden fällen natürlich über null

aufgrund von frustration mit dem shelly support hab ich mich da eher fern gehalten, aber ich geb mir den abend nen ruck mehr als in ablage p kann es ja nicht landen

hab das gleiche "problem" mit einem dieser dimmer als lüftersteuerung, danke fürs einreichen des vorschlags

intern läuft da eine light instance, das wird vmtl automatisch als lichtquelle von der cloud bewertet

evtl pin lock funktion ausprobieren ?

nach dem teilreset oder beim kompletten ?

das ist jetzt gerade, es sieht aus als laufen beide mit aber in der webgui ist einer bei null (edit: das soll scheinbar so sein, der reset hat auch gefunzt ich war nur zu langsam beim abfragen )

der komplette reset funktioniert einwandfrei, lediglich ein teilreset (nur ["aenergy"] ) ergibt den oben gezeigten fehler.
da bei dir keine returned energy gemessen worden ist kannst du das an dieser stelle nicht nachstellen

was möglicherweise dazu geführt hat dass den fehler deswegen noch niemand entdeckt hat bzw hier davon berichtet worden ist

gehen wir mal stück für stück durch. hier haben wir den aktuellen ist zustand

und

huhu

hab eben scheinbar nen fehler in der PM1 instanz entdeckt. das gerät ist ein PM Mini Gen3 an der PV , bei dem ich den active energy zähler resetten wollte um standbyverbrauch der wechselrichter besser im auge behalten zu können. edit: ich wollte explizit nur den einen zähler resetten, ret- aenergy sollte erhalten bleiben

der call ist folgender gewesen:

RPC/PM1.ResetCounters?id=0&type=["aenergy"]

der aenergy zähler wurde daraufhin zwar umgeschrieben, aber nicht resettet. es wurde stattdessen der zu diesen zeitpunkt gültige (negative) returned energy wert eingetragen, siehe screenshot.

Plus uni