Beiträge von eiche

Vermutlich passt, beides zugleich zu verwenden, nicht zusammen.

Ich halte von einem per Cloud genutzten Thermostat nichts. Wegen der URL schaue ich vorsichtshalber erst noch einmal nach, bevor ich in kürze einen passenden URL notiere.

akreienbring

Du hast die Aufrufstruktur passend aufgezeigt.

Und dann gibt es noch HTTPServer Endpoints, im Empfängerskript einzubauen. Diese können sowohl per GET als auch per POST Nachrichten empfangen.
Vorteil: Ein Skript wird bei einem Fehler nicht angehalten, es wird dann halt nicht das Gewünschte ausgeführt.

Wenn bspw. bei Methode "Script.Eval" ein Tippfehler im Funktionsnamen innerhalb des URL vorliegt, stoppt die Firmware das angesprochene Skript.

Zitat von Eagle69

Mittlerweile wenn man einige Jahre schon in der Rente ist, habe ich das Gefühl das man geistig sehr unflexibel wird.

Keine Verallgemeinerung bitte! Ich bin schon lange in Rente.

Vor 30 Jahren war BASIC bereits erheblich antiquiert, im Verhältnis zu leistungsfähigen Sprachen - in aller Freundschaft.

Im Vergleich dazu ist diese Skriptsprache richtig gut, obwohl es wesentlich bessere gibt.

ostfriese Ein unglaublich guter Vergleich.

Kein Design kann so "chique" oder chic oder schick(?) sein, wie die Inhalte, um die es geht.

Für ein solches Skript bräuchte bspw. ich klare Beschreibungen der Voraussetzungen, des Anliegens und der vorhandenen Ausstattung ... und vielleicht auch ein wenig der eigenen Fähigkeiten des Auftraggebers.

Btw, es gibt hier noch andere, die ein solches Skript erstellen können.

Btw, ich nutze für die Shelly ausschließlich statische IP-Adressen, von Anfang an.

Ich erledige solche Anliegen per Skript, weil

1. ich das kann,
2. ein Skript viel mehr kann als alles andere,
3. ein Skript ausbaufähig ist,
4. damit ein Shelly autark arbeiten kann, was die höchstmögliche Ausfallsicherheit bietet.

Zitat von steffda

Das Teil weis selber, dass es nur ein Relais schalten kann, das muss man ihm nicht noch mitteilen.

Doch, dass muss man, weil die Kommunikationsschnittstelle der ersten Generation das so vorgibt. Ich empfehle trotzdem den RPC URL ab zweiter Generation.

Sorry apreick, diese beiden URL sind nicht das Gleiche, sie wirken nur gleich, solange die Rückwärtskompatibilität erhalten bleibt. Ich empfinde die alte Variante nicht als einfacher, weil die neue API erheblich mehr Kommunikationskanäle zulässt als die Firmware zur Generation 1. Dies will ich nur mal ergänzend deiner "einfacher" Aussage gegenüberstellen.

Wie ich bereits per PN antwortete, ja, du kannst einen Sensor einbinden. Aber ...

Zitat von gexle

Also sozusagen wenn der Eingang am Shelly auf 1 ist wäre

Ein digitaler Temperatursensor sendet kein binäres Signal (0 vs. 1), sondern die gemessene Temperatur als digital dargestellten Wert, also nicht als analoge Spannung sondern als Zahlenwert.

Zitat von gexle

und wenn dann keine Ahnung die Temperatur im Puffer 60 Grad erreicht hat soll der Ausgang für 10min geschaltet werden

Wenn eine Tempertut von bspw. 60°C unterschritten, dann Durchmischung ein. Dann aber auch besser konsequent bei Überschreitung einer bestimmten höheren Temperatur wieder aus.

Diese Temperaturschwellen sollten am besten nicht statisch sein. Besser wären zwei Sensoren in deutlich unterschiedlichen angebracht. Die Differenz beider gemessenen Temperaturen sei dann ausschlaggebend für das Einschalten.

Edit:
Ach so, du meintest den Schalter am üblichen Shelly Eingang. Ja klar, das ginge selbstverständlich. Aber Actions können bisher keine logischen Verknüpfungen. Dazu braucht man dann Szenen (leider Cloud), ein übergeordnetes System oder am besten ein Skript, weil dies am verlässlichsten ist.

ostfriese

leicht off topic:

Hast du an deinem Motorrad gebastelt?

Ist irgendwo MQTT im Spiel?

Zitat von Dakotaman

Irgendwie ist das nicht mehr mein Shelly Forum...

sagte der Routinier und verschwand in seiner Höhle.

der.fpg

Dein Ärger ist verständlich bei deinen negativen Erfahrungen. Aber deine Vorschlaghammerkritik ist es nicht.

Gründe:

1. Bisher gelang es mir noch immer, die Firmware zu aktualisieren, manchmal erst nach mehreren Schritten.
2. Die Pflege der Firmware ist sehr gut, wenn auch immer mal wieder Bugs damit hereinkommen. Nur ohne Firmwarepflege gibt es auch keine neuen Bugs. "Nur wer nichts macht, macht auch nichts verkehrt."
3. Das Konzept der RPC-Methoden ist Tasmota(32) weit überlegen und sehr verständlich im Vergleich.
4. Das Skripten gelingt hervorragend, wenn auch Berry als Programmiersprache in Tasmota32 überzeugender ist.
5. Kommunikationsschnittstellen wie "Script.Eval", HTTP-URL, HTTP-Endpoints sind bestens geeignet, Shelly übergreifend zu implementieren.
6. Die Schedule Jobs leisten verlässliche Arbeit und sind, wenn auch nicht komplett per Web UI, sehr vielseitig einricht- und nutzbar.
7. Wenn man sich auf das Skripten einlässt, braucht man absolut kein übergeordnetes System, es ist selbstverständlich optional möglich - ich nutze Node-RED Flows.
8. Die Shelly brauchen keinerlei Gateway, Bridge oder sonstiges proprietäres Zeugs, um eingesetzt werden zu können - bis auf die BLU Dinger.
9. Nicht zuletzt ist die Dokumentation sehr gut und relativ ausführlich zusammengestellt, insbesondere ab Generation 2. Manche Dinge muss man trotzdem mit Versuchen eindeutiger herausfinden.
10. Viele Anwendungen gelingen bereits mit relativ einfachen Konfigurationsschritten (manche nennen so etwas fälschlicherweise programmieren), welche allerdings nicht DAU sicher sind.

Wenn ich auch nicht viele Smart Home Produkte anderer Hersteller kenne, so bin ich davon überzeugt, dass ein System, welches so offen ist wie das Shelly System, nicht leicht zu finden sein dürfte, wenn überhaupt.

Habe ich noch einen Grund vergessen?

Zitat von wilhelm1

Dabei möchte ich die Schalter durch Kontrollschalter ersetzen

Vorsicht bei Schaltern mit Kontrolllämpchen! Wenn du die Kontrolllämpchen mit den Ausgängen der Shelly schalten lassen kannst, gelingt das ohne weiteres, nicht aber, wenn die Lämpchen von den Schaltern geschaltet werden, die ja an den Shelly Eingängen liegen. Dann wirst du zusätzlich den hier sog. "Bukowski-Draht" basteln müssen.

Btw, diese Lösung von Schaltern/Tastern an Eingängen der schaltenden Shelly ist am ausfallsichersten, weil deren Funktion auch ohne WLAN sichergestellt ist.

Ein Shelly i4 zusammen mit 4 Tastern in einer Leerdose lässt erheblich mehr Möglichkeiten zu, ist aber WLAN abhängig.

Zitat von steffda

Übrigens, auch mit USB-Versorgung geht der H&T in den Sleepmodus.

Aus genau diesem Grund verwende ich meine H&T nicht zur Regelung. Eine solche Implementation wäre mir zu träge. Mit einer trägen Fußbodenheizung reicht so etwas vermutlich völlig aus.

Ich habe übrigens eine autarke Heizkreisregelung per Shelly Skript zusammengestellt, die bestens und ausfallsicher arbeitet, incl. Zeitplänen. Bei Letzterem gefällt mir meine Weboberfläche noch nicht, was ich irgendwann einmal bei Bedarf angehen will. Das Skript ist herunterladbar und müsste bei Einsatz für deinen Zweck angepasst werden, weil die gemessenen Temperaturwerte von einem anderen Gerät (H&T) kommen.

Jo, das sollte so gelingen. Damit hast du zwei Temperaturschwellen genutzt, eine Solltemperatur liegt nicht vor, man kann sie sich aber bei ca. 19.75C vorstellen.

Auf diese Weise auf eine andere "Solltemperatur" zu wechseln, macht selbstverständlich kein Anwender, weil das zu aufwändig und insbesondere fehlerträchtig wäre.

Solange genau diese beiden Temperaturschwellen genutzt werden sollen, ist es aber praktikabel.