Offensichtlich, bin ich nicht allein mit diesem „Problem“:
Beiträge von TheWoo
-
-
Ich habe gesehen, dass beim Shelly 1 via http://ip-adresse_shelly1/settings ein Parameter namens longpush_time angezeigt wird (hier erläutert) . Beim Shelly Dimmer 2 gibt es einen Parameter dieses Namens offensichtlich nicht.
Lässt sich die Zeitschwelle mit der zwischen Short Press und Long Press beim Dimmer 2 unterschieden wird irgendwo einstellen?
-
So ... gerade Antwort vom Shelly Support erhalten.
Frage:
Does a stronger MOTION SENSITIVITY (so lower value, let's say 1 instead of 50) reduce the battery run time?
I'm not talking about the sensor recognizing motions more often/faster, thus reporting more often.
I'm talking about the 99% of the time when the sensor sits on the wall, watches and waits for a motion. Does it make a difference in this idle-watching period for the battery run time whether MOTION SENSITIVITY is set to 1 or 256?
Antwort:
If you lower the motion sensitivity, the unit will become more sensible and will log motions more often, so the battery will be used more.
Nachfrage:
Thank your for the swift reply, but it seems you ignored what I wrote. I'm interested in the battery runtime effect when there is NO MOTION? So again: Does a higher sensitivity (1 instead of 256) reduce battery runtime if no one (no person, no animal) is present?
Guess you need to forward this question to your engineers...
Antwort:
We have checked with our relevant team, and it will not affect the battery of the device.
We remain at your disposal in case of further questions.
ZUSAMMENFASSUNG
Stärkere Empfindlichkeit = kürzere Akkulaufzeit bei Bewegungserkennung, aber kein Einfluß auf die Akkulaufzeit durch bloßes „an der Wand hängen“ (ohne Bewegung).
P.S.: Ein wenig bescheuert ist, dass höhere Empfindlichkeit einen niedrigen Wert und umgekehrt erfordert. Wenn man also von „higher Motion Sensitivity“ spricht, ist nicht eindeutig klar, ob von einem höheren Zahlwert oder tatsächlich höheren Empfindlichkeit die Rede ist (die zwei stehen sich ja konträr gegenüber ... da hat der Software-Ingenieur nicht wirklich nachgedacht). Ich versuche dieses potentielle Missverständnis zu vermeiden, indem ich von „stronger Sensitivity/stärkerer Empfindlichkeit“ spreche.
-
Also alle meine Motion stehen auf 1. da sie schnell reagieren sollen.
Wozu brauchst du diese Erkenntnis, wenn ich fragen darf?
Maximale Empfindlichkeit hätte ich eben auch gerne, aber ich habe keine Lust den Sensor alle 6 Monate von der Wand zu holen (notfalls kann ich auch 5V via USB einspeisen, „Saft“ liesse sich weitestgehend verdeckt zuführen).
Der Shelly Motion ersetzt hier gerade einen Homematic BWM, da ist man mit 2-3 Jahren Laufzeit unter Realbedingungen verwöhnt (klar, mit anderen Pferdefüßen, wie 868 MHz Duty Cycle und dementsprechend größeren Zeitfenstern ... jaaaaaa, ich weiß Wifi vs. 868 MHz, das ist ganz was anderes verbrauchstechnisch).
-
Ich habe mal beim Hersteller gefragt, und warte/hoffe auf brauchbare Antwort. Ich berichte...
-
Die Frage wurde offensichtlich noch nicht gestellt (zumindest kann ich sie über die Forensuche nicht finden):
Hat eine höhere Empfindlichkeit bei der Bewegungserkennung (also kleinerer Wert in der Einstellung MOTION SENSITIVITY, z.B.1 statt 25) einen verkürzenden Effekt auf die Akkulaufzeit?
Dass er schneller, im Sinne von häufiger/öfter, Bewegungen erkennt und meldet, und das logischerweise auf den Stromverbrauch geht ... klar. Das meine ich hier aber nicht.
Mir geht es um die 99% der Zeit in denen der Sensor beobachtend an der Wand sitzt und auf eine Bewegung wartet. Macht es da für die Akkulaufzeit einen Unterschied, ob MOTION SENSITIVITY auf 1 oder 256 sitzt?
-
Gibt es eine Möglichkeit den aktuellen Dimmwert über einen Parameter als Teil einer Action-URL zu versenden? Also sowas wie http://mein.smarthome.server/shellymonitor?brightness=%brightness%, wobei %brightness% beim Versenden durch den aktuellen Dimmwert ersetzt wird. (ESPEasy bspw. kann sowas).
Momentan muss ich den Weg durch die Brust ins Auge gehen, dass bei Action mein.smarthome.server angestoßen wird, und der dann erst den Shelly Dimmer fragt, was sein aktueller Wert ist.
-
Tja, was eigentlich zum Glück nur fehlt, ist ein, nennen wir es optionaler BUTTON 1 SHORT PRESSED URL - Toggle State A & B. Also die Möglichkeit per Checkbox zwei Toggle-Zustände mit URLs anzugeben. (Oder gar drei oder vier, die linear per Loop oder Bounce abgearbeitet werden).
-
-
Schade, habe es mal als Feature Request an Allterco geschickt.
Sehe ich das richtig, dass der Dimmer sich nicht selbst einen Einschaltbefehl mit Dimmwert per bspw. BUTTON 1 SHORT PRESSED URL senden kann:
http://10.0.1.xx/light/0?turn=on&brightness=40 funktioniert problemlos per Browser, aber wenn ich das in besagte Shelly-Action eintrage und „enable“ passiert mal gar nichts. (Ja, Button Type steht wie vorgeschrieben auf Detached).
-
Ich würde gerne einen Dimmer 2 mit folgendem Tastenverhalten versehen:
- Taste 1 (kurz): Umschalten zwischen 0 und 40%.
- Taste 2 (kurz): Umschalten zwischen 0 und 100%.
Ist das mit der Standard-Firmware (ohne Verwendung der Cloud) realisierbar? Falls ja, wie?
Und weiter: Ein graduelles Dimmen durch langen Tastendruck würde ich am liebsten gleich mit deaktivieren.
-
Ich experimentiere hier gerade/noch mit einem Shelly Dimmer 2 (neueste FW-Version 20210723-153500/v1.11.0-Dimmer-g1d5998d) , weshalb das Gerät öfters mal vom Strom getrennt wird.
Dabei ist mir aufgefallen, dass wenn ich den Dimmer wieder mit Strom verbinde, der Dimmer zwischenzeitlich (wir sprechen von Minuten) das Wifi-Netzwerk, mit dem es zuvor verbunden war, vergessen hat – die LED blinkt rot.
Ich komme dann über den AP Mode und den Shelly Finder an den Dimmer ran, kann die Wifi-Netzwerk-Verbindung wieder eingeben/herstellen, aber das hält wieder nur, so lange das Ding Strom hat.
Merkwürdigerweise konnte ich dieses Verhalten letzte Woche noch nicht beobachten, da hatte er sich die Einstellungen problemlos auch bis zum nächsten Tag gemerkt.
Normal, ein Knall im EEPROM oder eine Einstellungssache/ein Software-Bug? Ich bin verwirrt.
-
Nur Doofe/Faule kaufen zum Listenpreis, der tatsächliche Preis ist niedriger. Der Listenpreis des erwähnten HM-IP-UP-Dimmers ist EUR 60,– fertig aufgebaut, bzw. 50,– als 15-Minuten-Bausatz. Tatsächlich bekommt man das Ding über die richtigen Kanäle auch schon für EUR 40,– fertig aufgebaut.
Die von Dir genannten EUR 71,95 beziehen sich auf den alten Nicht-IP-Dimm-Aktor HM-LC-Dim1TPBU-FM, der ursprünglich mal bei EUR 60,– bzw. 50,– lag, und vermutlich aufgrund der aktuellen Chip-Krise so teuer geworden ist. (Droht uns vielleicht bei Shelly auch noch).
-
Nun, ja. Ich hänge ein Zwischensteckermessgerät Typ SBC-500 von Voltcraft davor. Mit diesem messe ich beim ESPEasy im Non-EcoMode Standby 0.7W und irgendwas zwischen 0.25W und 0.4W im EcoMode Standby. Das selbe Messgerät liefert mir beim Shelly halt 1.0W.
Latenz ist für mich nur von relativer Wichtigkeit, das hängt vom Einzelfall ab, wie/wo der Aktor schalten muss. Ja, die extreme „Snappyness“ von Wifi ist hübsch, aber die geringe Latenz bei HM undramatisch. Geringe Betriebskosten sind da m.E. langfristig höher zu bewerten.
-
Ich bin neu in Sachen Shelly und habe mir zum Testen mal einen Dimmer 2 zugelegt. Was mir auffällt, ist der – man möge lachen – recht „hohe“ Standby-Verbrauch den ich mit ziemlich genau 1 Watt gemessen habe.
Zum Vergleich: Homematic IP Dimmer ziehen 0,4 Watt, ein ESPEasy Aktor (der wie der Shelly einen ESP8266 im Herzen hat) zieht 0,75 Watt Stand-by bzw. um die 0,3 Watt im Eco-Mode.
Der Unterschied klingt nach nichts, aber wenn man 15 oder 20 dieser Dimmer 24/7/365 im Einsatz hat summiert es sich. Geht man von 0,5 Watt Differenz aus mal 15 Geräte mal 24 h mal 365 Tage = 65 kWh * € 0,28 = € 18 Strom-Mehrkosten jährlich. Tendenz steigend, so man nicht eine Photovoltaikanlage sein eigen nennt.
Jetzt kann man den günstigeren Gerätepreis den Stromkosten entgegensetzen, dennoch lautet meine Frage:
Lässt sich der Stand-by-Verbrauch der Shelly-Geräte per Software-Einstellung reduzieren (vgl. ESPEasy Eco-Mode)?
Oder gibt es Pläne seitens Allterco den Stromverbrauch in der nächsten Gerätegeneration in der Hardware zu reduzieren?
