Beiträge von eiche

Ok, Schaltung erkannt und du hast offenbar bereits etwas gemessen bzw. Werte erfassen können.

Aber zu den Ausgaben: Bitte, bitte kein Foto davon - grässlich. Texte sollen, wann immer möglich, kopiert und eingefügt werden.

1. Verwende einen anderen Browser, welcher die Ausgabe strukturiert!
   Auf Windows ist das bspw. Edge. Ansonsten tut das meiner Erfahrung nach der Mozilla Firefox bestens. Mit Apple Computern habe ich keine Erfahrung.
2. Dann kopiere dessen Ausgabe in die Zwischenablage und füge den Inhalt der Zwischenablage in deiner Antwort ein!

Zumindest verwendetest du bereits einen Browser.

$Thomas63 Am oberen Foto in #7 vermute ich eine Brücke zwischen ANALOG IN und GND. Eine Schaltskizze wäre erheblich besser als solche Fotos.

Und ... vergiss erst einmal die App und die Cloud!

Nimm einen Web Browser und tue das, was ich oben bereits beschrieb!

Hast du auch das AddOn per Konfiguration eingebunden?

Vielleicht genügt es, den LDR zwischen "VREF + R1 OUT" und analog GND anzuschließen, wobei "VREF + R1 OUT" auch mit "ANALOG IN" zu verbinden ist. Im allgemeinen wird ein zusätzlicher Spannungsteilerwiderstand erforderlich sein.

Tipp zum fotografieren: Vermeide Parallaxe-Fehler, d.h. fotografiere aus einem Winkel, welcher die Leitungsanschlüsse eindeutig erkennen lassen!

Ok, besser verständlich.

Zitat von $Thomas63

das die Markise wieder scheißt

Ich täte eine Markise nicht scheißen lassen.

Ein LDR ist ein von der Lichtstärke abhängiger Widerstand, also ein analoges Bauelement. Somit kannst du diesen ausschließlich irgendwie am analogen Eingang verwenden (als Teil eines Spannungsteilers), solange du keinen Analog-Digital-Umsetzer ergänzen willst. Somit setze ich vortaus, dass wir von analogen Spannungsschwellen reden.

Ich nutze derzeit keinen analogen Sensor und muss deshalb folgende Frage(n) stellen.

Hast du den LDR bereits in die Schaltung integriert?

Verwende bitte einen Web Browser und gibt in der Adresszeile folgenden URL ein!

http://<IP Adresse deines Shelly Plus 2PM>/rpc/shelly.getstatus

Was erhältst du als Ausgabe? Am besten ist es, wenn du diese Ausgabe selbst soweit interpretieren kannst, dass du den Fokus auf Teile richten kannst, die für dein Anliegen wesentlich sind.

Gibt es darin einen Eintrag wie "voltmeter..." oder "input:...", der zum LDR bzw. analogen Eingang passen?

Notfalls kopiere die gesamte Ausgabe in deine Antwort!

Edit: Zu deinem Foto.
Ich erkenne nicht, dass du den LDR geeignet am analogen Eingang betreibst.

LAUT61 Deine Formulierungen sind gewöhnungsbedürftig, wenn auch noch interpretierbar.

Zitat von LAUT61

Wenn Temperatur Pufferspeicher = 2K höher als WW Speicher

Wenn die Temperatur des Pufferspeichers mindestens 2K über der Temperatur des Warmwasserspeichers liegt ...

Zitat von LAUT61

Wenn Temperatur Pufferspeicher = Warmwasserspeicher

Wenn die Temperatur des Warmwasserspeichers die Temperatur des Pufferspeichers erreicht hat ...

1. Geht das überhaupt ohne Toleranz von bspw. 0,1K?
2. Sind diese kleinen Temperaturdifferenzen realistisch nutzbar?
3. Soll dies für jede absoluten Temperaturwerte gelten oder erst ab einer unteren Temperaturschwelle im Pufferspeicher?

Der Rest ist klar beschrieben und kann per Skript implementiert werden.

Im Gegenteil, die Beschreibung ist, zumindest für mich, unverständlich, auch wenn die genutzte Ausstattung klar ist. Ich bin noch nicht einmal fähig, diese Beschreibung zu interpretieren.

Zitat von $Thomas63

Wie schreibe ich den Befehl das die markise ab 50% ausführt und ab 30% wieder einfährt bekomme das nicht gebacken?

1. Wie lautet die Bedingung bzw. lauten die Bedingungen?
2. Soll etwas ausgeführt werden, wenn die Markise mindestens 50% geöffnet ist?
3. Was soll dann ausgeführt werden?
4. Was hat das mit dem Öffnungsgrad von 30% zu tun?
5. Soll die Markise eingefahren werden, wenn diese mindestens oder höchstens (?) 30% geöffnet ist?

Gehe bitte in dich und versuche eine verständliche Beschreibung deiner Absichten bzw. Ziele zu formulieren - am besten auch mit Interpunktion (Komma, Punkts, ...)!

Zitat von MaMoe696

Aus nach 30 min UND Verbrauch weniger als 10 Watt, ansonsten bleib noch an.....

MaMoe696 Deine Formulierung ist schlicht ungeeignet. "Aus"schalten ist eine Folgerung auf eine Bedingung. Du formulierst es als Teil einer Bedingung. Das kann nicht gelingen. Ich sehe zwei mögliche Interpretationen.

1. Vermutlich so: Wenn 30 min nach Einschalten oder später die Leistung < 10 W dann ausschalten.
2. Weniger wahrscheinlich: Wenn 30 min lang die Leistung < 10 W dann ausschalten.

Welches von beiden meinst du? Oder ist es noch etwas anderes?

bynight

Du hast offensichtlich, wissend oder unwissend, gebrauchte Ware gekauft. Es gibt in den Shelly keinen Standard-Benutzernamen und kein Standard-Passwort. Deshalb kann dir solche niemand nennen. Im Auslieferungszustand ist der Zugriff ungeschützt. Aber thgoebel kann solche Dinge, sofern vorhanden, auslesen, was keine Selbstverständlichkeit und mit erheblichem Aufwand verbunden ist. Deshalb ist sein Angebot ein sehr, sehr freundliches.

steffda zu #1 und #4

Nein, eine Benutzerverwaltung mit Rechtevergabe sind in der Shelly Cloud bisher nicht implementiert - zumindest nicht in der Basis Ausstattung. Die kostenpflichtige Variante nutze ich nicht.

Firmware 0.14.x kann ich nicht empfehlen, das ist allerdings von dir offenbar nur als temporärer Rettungsanker gemeint.

Deine Schilderung lässt ein schwaches WLAN an der Montageposition vermuten.
Hast du mal versucht, den Shelly für eine höhere Feldstärke dichter an einen WLAN Accesspoint zu bewegen und dann die Prozedur wiederholt?

Ich habe auch mitunter erlebt, dass eine neuere Firmware Version nicht erkannt wurde und kenne dafür den Grund nicht. Zumeist gelang das update nach einem oder zwei Reboots, notfalls nach Factory Reset.

Wenn dies nicht hilft ...
Shelly der ersten Generation (Shelly 1) habe ich auf Tasmota umgeflasht -per Tasmotizer. Vermutlich gelingt dies auch mit einer Shelly Firmware. (Ich täte solches auf eigenes Risiko versuchen.)

Hast du mal die Suchfunktion mit dem Schlüsselwort "flashen" versucht? Es gibt mindestens eine Anleitung zum flashen einer originalen Shelly Firmware.

Und schließlich kann ein Produktionsfehler nicht ausgeschlossen werden.

Vertraue keiner Übersetzung, die du nicht selbst versaut hast.

Zitat von steffda

Eben ist die Heizung angegangen mit der Meldung shos_rpc_inst.c:230 Switch.Set via SHC 23.251.137.237:602.

Ok, dann brauchst du dort keine Szenen, weil dies das Cloud-Thermostat erfüllt. Dieses Thermostat ist dann nichts anderes als eine spezifische Anwendung zweier Szenen. Ich kenne das Cloud-Thermostat nicht aus eigener Erfahrung.
SHC steht für Shelly Cloud.

Zitat von steffda

Das Script läuft und bringt regelmäßig die Meldung "Locale Aktion nicht ausgeführt.".

Dass dies auf Grund deiner im H&T verankerten Actions und dem Skript zu erwarten und völlig in Ordnung ist, wirst du vermutlich wissen. Diese Ausgaben zeigen, dass

1. vom H&T regelmäßig die Skriptfunktion per Actions aufgerufen wird,
2. das Skript ein Schalten per lokal wirkender Actions nicht durchführt, weil die Cloud verfügbar ist,
3. die Priorität des Cloud-Thermostats gegenüber den lokalen Actions wirkt.

Kurz: Es sieht danach aus, dass alles wie gewünscht arbeitet.

Wenn du nun noch temporär die Cloud im Schalt-Shelly sperrst, solltest du erleben, dass die lokalen Actions die Heizung ein- und ausschalten lassen.

Das Skript ist zwar ungetestet, sollte aber wie gewünscht funktionieren. D.h. solange der Schalt-Shelly mit der Cloud verbunden ist, wirken die beiden Actions nicht. Diese wirken nur bei Cloud Nichtverfügbarkeit. Du brauchst also noch zwei Szenen in der Cloud für die von dir gewünschte Cloud-Priorisierung.

Man kann das Skript nach zwei Seiten umgestalten.

1. So speziell, dass kein Parameter erforderlich ist. Dann brauchst du zwei solcher Funktionen, die man "einschalten()" und "ausschalten()" nennen kann.
   Das macht das Skript doppelt so umfangreich. Dann ist kein Parameter erforderlich.
2. So allgemein, dass das Skript für jegliche verfügbare Methode nutzbar ist, was einen komplexe Parameterstruktur in den Actions erfordert.

Mit diesem Skript habe ich einen Mittelweg gewählt, der dicht bei 1. liegt und das Skript sehr kurz hält.

Die Funktion "schalten()" importiert einen Parameter, den ich "ein" nenne. Sowohl die Funktion als auch der Parameter können auch ganz anders genannt werden.

Beim Aufruf, hier per Action URL, wird an schalten() als Aufruf-Parameter true bzw. false übergeben. Per "ein" kommt somit einer der Wahrheitswerte true/false bei schalten() an. Somit wird im Aufruf von Shelly,call() an Stelle von "ein" der Wahrheitswert eingesetzt. Dies bewirkt, abhängig vom "ein"-Wert, das Ein- bzw. Ausschalten des Ausgangs. Es gibt hier keinen Parameter "aus". Du kannst diesen sog. formalen Parameter auch "what" nennen und "what" statt "ein" im Shelly.call() Aufruf eintragen.

Alles klar?

Zitat von steffda

Und ganz generell @all: Ich bin beeindruckt wie schnell und kompetent einem hier geholfen wird. Vielen Dank dafür!

Gerne ... wenn solche Hilfe positiv aufgenommen wird.

Ich beschäftige mich wesentlich lieber mit konstruktiven Dingen.

steffda

Obiges gilt für Actions auf dem Skript Shelly. Da diese Action bei dir auf dem H&T eingetragen wird, lautet der URL dort

http://<IP Adresse das Schalt-Shelly>/rpc/script.eval?id=1&code="schalten(true)"

bzw.

http://<IP Adresse das Schalt-Shelly>/rpc/script.eval?id=1&code="schalten(false)"

und das ganze Skript auf dem Schalt-Shelly wie oben.

function schalten(ein) {.
	if(!(Shelly.getComponentStatus("cloud").connected))
		Shelly.call("switch.set", {id:0,on:ein});
}

Das wäre bereits alles.

Edit:
Dazu braucht es selbstverständlich ein funktionstüchtiges WLAN. Zum testen ist also temporär die Internetverbindung auf dem Router zu deaktivieren. Und zwecks Protokollierung das Skript etwas zu erweitern. Statt die Internetverbindung auf dem Router zu deaktivieren, kannst du selbstverständlich die Cloud auf dem Schalt-Shelly disablen.

function schalten(ein) {
	let fill = "nicht ";
	if(!(Shelly.getComponentStatus("cloud").connected)) {
		Shelly.call("switch.set", {id:0,on:ein});
		fill = "";
	}
	print("Lokale Action " + fill + "ausgeführt.");
}

An Hand der am rechten Rand im Protokollfenster (Console) zu sehenden Uhrzeit kannst du recht gut prüfen, wann was geschah.

Ich habe den Code nachträglich noch ein wenig servicefreundlicher umgestaltet.

Wichtig!
Wenn eine Action mit der Methode "Script.Eval" einen Fehler beinhaltet, insbesondere der Funktionsname falsch geschrieben wurde, dann kann das Skript abgebrochen werden. Deshalb sollte nach dem Anlegen einer solchen Action deren Funktionsweise getestet werden.

Mit der Verwendung eines HTTPServer Endpoints im Skript ereignet sich kein Skriptabbruch wegen eines solchen Action-Schreibfehlers. Ein solches Skript ist aber nicht mehr so schön kurz und einfach.

Die Generation 2+ Dokumentation ist ziemlich gut, wenn man sich erst einmal an die RPC Notation gewöhnt hat. Ich hatte vorher halt noch nie das Bedürfnis, nach einer Component "Cloud" zu suchen.

steffda

Somit sollte beim eintreffen einer Action Nachricht vor deren Ausführung einfach die folgende Abfrage genügen.

if(!(Shelly.getComponentStatus("cloud").connected)) {
	// Führe den Action-Auftrag aus.
}

Das ist am besten in seiner Verlässlichkeit bei ausbleibender oder schwacher WLAN-Verbindung zu testen. Ich bin zuversichtlich, dass es so gelingt. Dazu braucht man noch nicht einmal einen cronjob, hier schedule job genannt.

Für solche Actions genügt im einfachsten Fall die Methode "Script.Eval":

http://127.0.0.1/rpc/script.eval?id=1&code="schalten(true)"

Zum ausschalten ist der Parameter false geeignet: ...&code="schalten(false)"

Im Skript mit der Id 1 muss diese Funktion stecken. Hat das Skript eine andere Id, muss halt diese hinter ...?id= eingesetzt werden

function schalten(ein) {.
	if(!(Shelly.getComponentStatus("cloud").connected))
		Shelly.call("switch.set", {id:0,on:ein});
}

Der Funktionsname darf selbstverständlich auch anders lauten.

Oder kürzer:

let is_enabled   = ((Shelly.getComponentConfig("cloud").enable) ? '' : 'nicht ') + 'enabled';
let is_connected = ((Shelly.getComponentStatus("cloud").connected) ? '' : 'nicht ') + 'connected';
print('Die Cloud ist ' + is_enabled + ' und ' + is_connected + '.');

Mir gefällt der trinäre Operator.

Ich testete es soeben und bestätige Michaels Aussage.

Ob die Cloud enabled ist, erfährt man mit .../rpc/cloud.getconfig.

Irgendwie auch naheliegend.

Dann kann ich ja den Cloud Status abfragen, wenn ich sehen will, ob es gegenwärtig eine Verbindung zur Cloud gibt.

Ja klar, das geht.

Für eine hohe Funktionssicherheit sollte jede zuletzt getriggerte Action im Skript gespeichert und dann ausgeführt werden, wenn bei Cloud-Ausfall die letzte (gespeicherte) Action nicht älter als ... ist. Dann ginge eine solche Action bei unmittelbar danach ausgefallener Cloud nicht verloren.

Könnte der H&T Skripte, dann gelänge es noch erheblich besser/sicherer unter Verwendung zweier Skripte, eines auf dem H&T, das andere auf dem schaltenden Shelly. Beide Skripte täten sich austauschen. Dazu müsste hypothetisch der H&T per USB versorgt werden.

Vermutlich wird hier jemand einwenden, dass für so etwas doch ioBroker, HomeAssistant, HomeMatic, openHAB, FHEM ... da wäre(n).