Beiträge von eiche

Also wissense nee ...

Vielleicht ist meine kleine Skripteinführung notwendiger als gedacht.

Du entscheidest über deinen (längeren ) Code.

Bereits in C ist das Resultat eines booleschen Ausdrucks ein Wahrheitswert. Aber Hauptsache ist, dass du mit deinem Skript zurechtkommst und dich sicher fühlst.
Vermutlich ist die eigene Lesart entscheidend. Ich lese x = y > 0 so: x ist definiert als "Der y Wert ist größer als 0".

Konntest du etwas über die Ursachen der Skript Stopps herausfinden?

Diese URL hast du aber bereits in den beiden Actions auf dem H&T eingesetzt, sollten somit wie gewünscht funktionieren.
Stimmt vielleicht die IP Adresse des Shelly nicht, der schalten soll?

Btw, die Ausgabe von Webhook.ListSupported kannte ich noch nicht. Diese kann ich zwar verstehend lesen, aber keinem Webhook (=Action) zuordnen.

Der geeignete URL zum einschalten lautet

http://<IP Adresse des Schalt-Shelly>/rpc/switch.set?id=0&on=true

Das kannst du leicht per Browser und Adresszeile testen.

Zum ausschalten entsprechend mit on=false.

Zu switch.on gibt es keine behandelnde Firmware-Funktion, funktioniert also nicht.

Die Dokumentation zum schalten der Component "Switch"

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?