Beiträge von Seven of Nine

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.


    mit den neuen Shelly Plus (über ShellyScript) könnte man folgendes Szenario problemlos abbilden, ich nenne es mal "Automatische Heizungssteuerung"


    - wenn der Temperatur-Sensor über einen Zeitraum X eine Temperatur kleiner Y misst, dann das Relais anschalten.

    - wenn die Temperatur dann den Wert Z erreicht hat, dann das Relais wieder ausschalten..


    Leider gibt es für die ShellyPlus-Serie aktuell noch kein TempAddon..Denke aber, das Addon kommt in ein paar Wochen auf den Markt..

    Wenn du also noch ein paar Wochen warten kannst gibt es dafür bestimmt eine Lösung (ohne Cloud oder Smarthome-Zentrale)

    From what I know:
    the relais (at least for a Shelly 1) are from different manufactors..

    UL version has a panasonic relais inside, the non-UL-Version a relais from HongFa.

    besides 1pm & 2.5 are there any other UL certified products (ie dimmer, RGBW, gas...)?

    no, AFAIK not. But Shelly Gas (and other Plug&Play Shellies) sholdn't be a problem as they are not mounted inside a wall box.

    RGBW2 is low voltage (12-24v dc), not sure if there's a UL certificate needed at all.

    Mahlzeit,

    da hier aktuell noch kein deutscher Bereich für ShellyScripts existiert poste ich das einfach mal hier:

    Zur Ausgangsituation:
    Hab eine Waschmaschine, die über einen alten ShellyPlug betrieben wird. Wenn die fertig ist soll eine Push-Benachrichtigung auf das Smartphone gesendet werden.


    Das geht mit den neuen Shellies der Plus / Pro-Serie problemlos, und zwar ohne Cloud und ohne Smarthome-Zentralen wie ioBroker, HomeAssistant etc..

    Was wird gebraucht:

    1) Shelly Plug / Plug-S / Shelly 1PM.. (irgendein Shelly, der den Stromverbrauch misst)

    2) Shelly der neuen Plus oder Pro-Baureihe mit mind. Firmware 0.8.1 (Script Funktion muss vorhanden sein)

    3) Smartphone mit der App "Telegram"
    4) Telegram-Bot, Anleitung dazu z.B. hier https://www.heise.de/tipps-tricks/T…-s-5055172.html

    Meine Waschmaschine hat die Eigenart zwischendurch kurze Pausen einzulegen, da wird dann auch kein Stromverbrauch gemesssen.. Das Script macht folgendes:

    der ShellyPlug wird minütlich geprüft.. wenn der Stromverbrauch > 10 Watt ist gehe ich davon aus, dass die Waschmaschine in Betrieb genommen wurde. Wenn der Stromverbrauch Anzahl 5 Prüfungen unter 10 Watt ist, dann ist die Maschine fertig und soll mich per Telegram benachrichtigen.

    Angepasst werden muss:

    - die IP-Adresse vom Shelly, der überwacht werden soll

    - der Telegram API Key

    - die Telegram Chat ID

    Optionale Änderungen:

    - die ausgegebene Meldung
    - Die Zahl in Watt, unter der das Gerät fertig sein könnte..

    - die Anzahl der Prüfungen, die erfolgreich sein muss bevor die Push-Benachrichtugung verschickt wird.

    https://github.com/shelly-tools/s…_consumption.js

    Leider finde ich keine Einstellmöglichkeit für einen An/Aus Wechselbetrieb, d.h. 10 Min an, 30 Min Pause, wieder 10 Min an usw.

    mit den alten Shellies (1. Generation) geht das entweder über eine Szene in der Cloud oder einer externen Smarthome-Lösung (HomeAsisstant, OpenHAB, ioBroker..)

    Mit den neuen Geräten (gibt leider noch keinen Shelly 2/2.5 der neuen Generattion) wird das direkt funktionieren, weil Auto-On und Auto-Off Timer gleichzeitig genutzt werden können..

    Komplett andere API

    Die Definition einer API ist, dass diese immer abwärtskompatibel ist. Wenn man neue Features will, kann man eine API erweitern, muss aber IMMER dafür sorgen, dass die Abfragen auf die bisherigen Schnittstellen auch identische Antworten liefern (Uptime, Status etc.). Meiner Meinung nach war da bei Shelly jemand "faul" und dachte sich "Ach ich fang neu an - ist einfacher als zu erweitern und mein Stackoverflow sample sieht eh anders aus" ;)

    Geht gar nicht - so kriegt man externe Entwickler definitiv nicht dazu die Produkte zu implementieren und so wird Shelly nie über einen bestimmten Punkt raus wachsen können - mehr als Schade... Hoffentlich geht's da definitiv nochmal zurück ans Reißbrett...

    Sehe ich (selbst als Entwickler tätig) komplett anders.. Früher gab es drei komplett unterschiedliche Wege einen Shelly anzusprechen.. REST, MQTT und Coap hatten gemeinhin absolut nichts miteinander zu tun und man musste (sofern man alle 3 Wege unterstützen wollte) 3x komplett eigenständig etwas bauen..

    das hat Allterco jetzt glücklicherweise vereinheitlicht.. ich kriege jetzt, egal ob über Websockets, UDP oder eben MQTT(s) immer das gleiche (standardisierte) JSON zurück.. Ich kann also unabhängig vom Übertragungsweg der Daten direkt den Zustand ermitteln oder auch verändern und sende / erhalte ein und den selben Datensatz..

    Manchmal ist es sinnvoll (auch wenn es einmalig mehr Arbeit bedeutet) Altlasten über Board zu werfen und neu anzufangen... Das "Mitschleifen" dieser Altlasten hätte vermutlich eine erhebliche Verzögerung bei der Entwicklung bedeutet, zudem massenweise Ressourcen verschwendet die jetzt für neue Funktionalitätten genutzt werden können..

    wollte mein Fritte als ntp-server eintragen, ... konnte ich aber noch nicht finden

    ist als Feature-Request bereits eingereicht und von den Entwicklern "in Arbeit".. sehe ich selbst als "madatory", also zwingend notwendige Funktion.

    Wer, der bei klarem verstand ist, würde sowas als Standard wollen? Besonders unerfahrene User (und das sollen lt. Werbespots ja 99% sein) möchten da ihren Server eintragen und dann "muss das alles laufen"TM...

    Sehe ich komplett anders.. MQTT ist (speziell wenn es verschlüsselt genutzt wird was ja mit den NG-Geräten jetzt funktioniert) ist ungeeignet für Einsteiger und diejenigen, die es nutzen sollten wissen was sie tun..
    Dazu gehört für mich auch, dass nur Meldungen verschickt werden die man tatsächlich haben will.. und zwei Häckchen zusätzlich zu aktivieren ist m.E. kein Drama ;)

    Habt ihr die Geräte im Einsatz? Oder durftet sogar testen?

    ja, sogar testen.. 1x 4 Pro, 2x Shelly Plus 1, 2x Shelly Plus 1PM

    Zustimmen kann ich hier:

    Wenn jemand Settings im Client-Mode einträgt, dann MUSS MUSS MUSS der AP-Mode sofort deaktiviert werden!

    Dimitar hat bereits zugesagt, dass man sich der Sache annimmt..

    Zur Temperatur-Entwicklung kann ich noch nichts sagen, da die o.g. Geräte bis auf den Pro 4PM noch nicht verbaut sind..

    From what I know there's currently no announce topic via MQTT but you can customize the topic so you don't have to know the device names at all..

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.


    With this configuration you'd have to subscribe to either #livingroom or #livingroom/ceilinglight as topic.

    Großer Vorteil der neuen RPC-Schnittstelle:

    man schickt einfach ein passendes JSON, dabei ist es egal ob das JSON über HTTP POST via cURL, oder per MQTT(s) oder auch per UDP an den Shelly geschickt wird :love:

    per MQTT(s) vom Mosquitto:

    Code
    mosquitto_pub -h localhost -p 1883 -u admin -P admin -t house/livingroom/rpc -m '{"id":124, "src":"user_1", "method":"Switch.Set", "params":{"id":0,"on":true}}'

    das gleiche via cURL:

    Code
    curl -X POST -d '{"id":124, "src":"user_1", "method":"Switch.Set", "params":{"id":0,"on":true}}' http://<ip-vom-shelly>/rpc

    identisch ist es aus einer eigenen Software auf die UDP-Schnittstelle, hier mal als Beispiel via PHP auf Port 3333 (ungetestet!)

    PHP: udp_sender.php
    <?php
    $ip = '192.168.178.93';
    $port = 3333;
    $message = '{"id":124, "src":"user_1", "method":"Switch.Set", "params":{"id":0,"on":true}}';
    
    if ($socket = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP)) 
        socket_sendto($socket, $message, strlen($message), 0, $server_ip, $server_port);

    ich finde das schon ziemlich genial, dass man jetzt unabhängig vom Übertragungsprotokoll ein und die selbe Anweisung verschicken kann und auch immer ein und die selbe Rückantwort erhält..

    Wenn die Shellys, wie in meinem Beispiel, über mehrere Monate nicht gebraucht werden, einmal am Tag "hochfahren" und sofern nichts anliiegt wieder in den Tiefschlaf schicken.

    findest du das sinnvoll, wenn man damit ein Gerät (Licht, Heizung, Garagentor ...) schaltet, dass diese Schaltung unter Umständen 24 Stunden verzögert wird?

    das mag in wenigen "Sonderfällen" OK sein aber für die übliche Verwendung (Licht, Steckdosen, Garagentor...) ist das meines Erachtens totaler Blödsinn..

    Nun, ich habe z.B. fünf Shellys, die die Heizung steuern. Die könnten im Sommer problemlos schlafen und ich würde die jeden Tag für 23 Stunden in den Tiefschlaf schicken.

    Bei Shellys mit (ausschließlich) Sensoren ist es einfach: Gerät schläft bis ein Sensor eine Veränderung meldet.. DW2 geht offen, H&T stellt höhere Temperatur fest..

    ein Shelly1 hat ja eigentlich den Sinn (bei Bedarf) ein Relais zu schalten. das tut aber der Shelly nicht von selbst sondern "wartet" auf einen (externen) Befehl.. Sei es über den Schalter oder eben Alexa, die Cloud oder sonst irgendeine Quelle..


    Nach welchen Kriterien sollte man den denn dann schlafen schicken bzw. aufwecken?

    ich finde die Idee sehr gut! Unsere Rolloschalter (10 Shelly2.5), ideln doch den ganzen Tag nur rum und heizen sich auf 60°C auf. Effektiv genutzt werden sie nur in engen Zeitfenstern.

    Von daher klares Voting für Deep Standby

    Während sie im DeepSleep sind kann man sie weder über die Cloud schalten noch über Alexa noch über sonstige externe Systeme wie ioBroker, OpenHAB oder HomeAsisstant..

    welchen Sinn haben die Shellies an der Stelle den überhaupt noch?