Beiträge von eiche

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).

steffda

Meine bisherigen Tests ergaben, dass es vermutlich mit Szenen nicht gelingen wird. Ich nutze keine Szenen und bin deshalb nicht sehr vertraut damit. Ich löse Fernzugriffe per VPN.

Es dürfte am einfachsten sein, per Skript nur die Verfügbarkeit der Cloud zu prüfen, was bspw. ca. 5s dauern kann. Diese Verzögerung spielt aber bei Fernzugriff wohl keine Rolle.
Bei Auslösen einer lokalen Action (an das Skript gerichtet), kann das Skript die Cloud-Verfügbarkeit prüfen und die Action nur dann ausführen, wenn die Cloud nicht verfügbar ist.

Ich kenne das Cloud-Thermostat nicht aus eigener Erfahrung und weiß deshalb nicht, ob sich dieses mit Actions auf dem H&T beißen täte, vermute aber eher nicht.
Das solltest du selbst herausfinden!

steffda

Wenn dir dieses Feature wichtig ist, habe ich folgende Idee dafür. Dafür ist ein Skript unabdingbar.

1. Per Cloud wirst du eh Szenen einrichten.
2. Du erstellst zum selben Zielgerät eine Szene, die alle paar Minuten eine Nachricht an das Skript sendet bspw. alle 3 Minuten - bisher ungetestet.
3. Das Skript führt an es selbst gerichtete Action-Nachrichten nur dann aus, wenn die letzte spezifische, zeitgesteuerte Nachricht (s. 2) aus der Cloud 4 Minuten alt oder älter ist.

Das ist alles ungetestet, sollte aber möglich sein. Der Vorteil wäre, dass du selbst per spezifischer Nachricht aus der Cloud eine solche Priorisierung aktivieren könntest. Das Zeitintervall ließe sich auch kürzer parametrieren, ich bin halt kein Freund von hohem Traffic.

Die reine Verfügbarkeit meines Cloud-Servers kann ich inzwischen abfragen. Das genügt aber vermutlich nicht zur Priorisierung.

Zitat von steffda

Eine Art Vorrangschaltung wäre da schön, so dass die Cloud Priorität hat, und wenn die nicht verfügbar ist, dann die Actions greifen.

So etwas als fertiges Feature ist mir unbekannt. Per Skript lässt sich eine solche Priorität implementieren, da ein sog. Event auch die Quelle des Event in seiner Information mitliefert. Ein von der Cloud ausgelöstes Event hat als "src" Wert "SHC" (vermutlich von SHelly Cloud) und ließe sich priorisieren. Dann müssten allerdings die Actions das Skript ansprechen, damit dieses solche Actions ggf. unterdrücken könnte.

Eine Cloud-Verfügbarkeit habe ich bisher in keinem Skript abgefragt und weiß deshalb nicht, wie dies gelingen kann. Ich las an anderen Stellen etwas, was darauf hindeuten könnte, dass so etwas möglich sei.

Fazit: Es sollte möglich sein. Dazu müsste sich jemand der Mühe unterziehen, solches zu testen - vielleicht ich. Mal sehen ...

Jan_Stfbg

Das Prinzip (zum Verstehen) der MQTT Kommunikation per Shelly Generation 2+ Firmware: Request and Response

1. HomeMatic muss eine MQTT Nachricht senden mit
   a) einem Identifier zwecks eindeutiger Zuordnung der Shelly Antwort zur gesendeten Nachricht,
   b) eine Quellenangabe, hier das HomeMatic, welche in der Shelly Antwort als Pre-Topic verwendet wird,
   c) die RPC Methode, ggf. ergänzt durch Parameter
2. Die Shelly Firmware wird wie folgt antworten, wenn Request verarbeitet werden konnte.
   Topic: <Quellenangabe aus 1.b)>/rpc, Payload: eine Information zur Verarbeitung des Request

Beispiel (unabhängig von HomeMatic):

zu 1. MQTT Request Nachricht:
Topic: <im Shelly eingetragenes MQTT prefix>/rpc
Payload: '{"id":"mein_Versuch","src":"aha/so_gehts/also","method":"switch.set","params":{"id":0,"on":true}}'
Die Payload lässt den Ausgang 0 einschalten.

zu 2. MQTT Response Nachricht vom Shelly:
Topic: "aha/so_gehts/also/rpc"
Payload: '"result":{"was_on":false}' ... und weiteres wie der "id" Wert "mein_Versuch" ...
wenn vor dem Einschalten ausgeschaltet war.

Vielleicht habe ich eine kleine Abweichung in der MQTT Response eingebaut, was aber wenig relevant ist. Alles andere dürfte stimmen und die Antwort ist per Topic leicht überprüfbar.

Vermutlich baut HomeMatic seinen eigenen "src" Wert ein.

Edit:
Vermutlich ließe sich notfalls ein Adapter per Node-RED Flow implementieren. Blockly ist nicht meins - zuviel drumherum für wenig Code. Ich glaube in HomeMatic heißt es statt Node-RED "Red-Matic".

Zur Component MQTT in der Dokumenttion

Reveive notifications over MQTT

Send command over MQTT example

Darüber ist einiges in der Dokumentation zu finden. Zusätzlich ließen sich noch Anwender definierte Topics und Payloads, so heißen die Bestandteile von MQTT Nachrichten (was du als Pfade bezeichnetest), per Skript verwenden.

Die per Firmware verwendeten Nachrichten basieren auf dem Request/Response Prinzip, wozu MQTT nicht zwingend gedacht ist.

Da ich kein fertiges übergeordnetes System nutze, kann ich dir zur CCU3 bzw. HomeMatic(?) nichts mitteilen. Ich weiß aber, dass darin auch eine Node-RED Variante zur Verfügung steht ...

Zitat von leerraum

dann über Shelly

Genauer: ..., dann über die Zeitpläne des Shelly - so viel Zeit und Präzision muss sein.

Vielleicht wird alle 5 Minuten eine relationale Datenbank durchforstet, um alle in's Nirgendwo verweisende Fremdschlüssel zu beseitigen.

Zitat von $Thomas63

Super Dankeschön werde ich so machen ....wer hat dann vorrang Shelly oderWetterstation ?

Ich habe keine Wetterstation, aber die Anleitung zu deiner Station gelesen.

Die Station meldet etwas an den Shelly, welcher darauf reagiert, wenn der von der Station kommende URL verarbeitbar ist. Wenn die Station den URL zum einfahren der Markise sendet, wird der Shelly dies tun, unabhängig vom Zeitplan. Ebenso umgekehrt. Es gibt auf diesem Weg keine Priorität. Prinzipiell könnte eine Prioritätenliste per Skript implementiert werden, aber ...

Wozu brauchst du eine Priorität und welche Aktionen sollten darunter fallen?

Nachfrage:
Ich sah mir die Fotos von dieser Wetterstation an. Sieht alles nach Kunststoff aus und die Windmesserflügel haben filigrane Ärmchen, die schnell altern und abbrechen dürften, wenn diese aus Kunststoff sind.
Gibt es dbzgl. mit dieser Station bereits Langzeiterfahrungen oder sonstige Erfahrungen?