Beiträge von eiche

Ich gelangte irgendwie hierher und möchte zu Michaels ( ostfriese) Skript etwas ergänzen, was auch bspw. das Anliegen von mhritter betrifft.

1. Die Abarbeitung von Einträgen in Datenfeldern kann durchaus über deren Stellen (Indexe) in den unterschiedlichen Datenfeldern erfolgen. Dies ist allerdings strukturell fehlerträchtig. Eine mittelflexible Lösung kann imho besser über eine (zunächst funktionslose) Datenstruktur erfolgen, siehe 2.
2. Eine geeignete Datenstruktur kann hierarchisch wie folgt aufgebaut werden.
   let device = [
   {"ipaddr":<IP Adresse>, "name":<user name>, "online":false, "online_action":[<list of URLs>], "offline_action":[<list of URLs>]},
   {"ipaddr":<IP Adresse>, "name":<user name>, "online":false, "online_action":[<list of URLs>], "offline_action":[<list of URLs>]},
   // ...
   ];
   Eine solche Struktur ermöglicht, jeder IP Adresse eine Liste an URLs im Online- bzw. im Offline-Fall zuzuordnen, bspw. auch die von mhritter gewünschten Aktivierungen/Deaktivierungen von Schedule Jobs. Auch kann jede dieser Listen leer sein. Eine geeignete Wiederholungsstruktur (Schleife) kann leicht die jeweilige Liste abarbeiten. Der Zusammenhalt aller Dinge in einem solchen Eintrag des Datenfeldes "device" ist bereits verankert, wozu es keinen korrespondierenden Index braucht. Der Zugriff gelingt über einen laufenden Index und den selektierenden primären Schlüssel <IP Adresse>.
3. Statt der Listen für Online- und Offline-Aktionen können zwei Funktionen eingebaut werden, was noch etwas mehr Flexibilität ermöglicht.
   let device = [
   {"ipaddr":<IP Adresse>, "name":<user name>, "online":false, "online_action":function (index){}, "offline_action":function (index){}},
   {"ipaddr":<IP Adresse>, "name":<user name>, "online":false, "online_action":function (index){}, "offline_action":function (index){}},
   // ...
   ];
   In dieser Lösung ist per Initialisierung den Funktionen für "online_action" und für "offline_action" die jeweils gewünschte (benannte) Funktion zuzuordnen. Dies unterstützt die Nutzung einzelner Funktionen für mehrere Geräte.

Mit einer Lösung gemäß 2 oder 3 gelänge es relativ leicht, das Anliegen von mhritter zu implementieren.

Solches ist einer der Gründe, weshalb ich einer Datenstruktur zu Beginn zumeist die höhere Priorität zuordne als der Ablaufstruktur, welche sich dann an der Datenstruktur orientieren muss.

Vielleicht helfen diese Anmerkungen für weitere Anliegen ähnlicher Art.

Ich sah mir soeben dein letztes Skript etwas genauer an. Ich schätze das Skript trotz seiner Kürze als relativ unübersichtlich ein, was eine Pflege erschweren wird.

Die derzeit gewollte Funktionalität des Skripts ist trotzdem vermutlich vorhanden.

Zitat von hjbucher

192.168.33.11

192.168.33.1

Dieser Zugriff funktioniert ausschließlich dann, wenn dein Endgerät (Smartphone, Tablet, Notebook, ...) mit dem aktiven Accesspoint des Shelly verbunden ist. Afaik ist erst ab Geräten der zweiten Generation zeitgleich eine WLAN-Einbindung und aktivem Accesspoint möglich. Das Web UI muss genauso über lokales WLAN wie über den Shelly Accesspoint erreichbar sein.

Dies kann aus naheliegenden Gründen nicht zugleich, also über das lokale WLAN und über den Shelly AP, gelingen.

Edit: Mit zwei Endgeräten sollte der zeitgleiche Zugriff über das WLAN und den Shelly AP bei Geräten ab zweiter Generation gelingen. Dann muss ein Endgerät mit dem WLAN und das andere mit dem Shelly AP gekoppelt sein.

Das könnte etwas für eine "smart home Tafel" sein - in Anlehnung an die übliche Tafel für Lebensmittel.

Für die Teilhabe an unterstützender Elektronik in verschiedenen Lebenslagen.

AlexSchmitz

Es wird gerne zwischen "feste" und "statische" IP Adresse unterschieden.

Eine feste IP Adresse ist eine, welche der DHCP Server (bspw. eine FRITZ!Box) an Hand der MAC Adresse des Client diesem Client immer wieder zuweist. Diese liegt somit im DHCP IP Adressbereich des Servers.

Eine statische IP Adresse hat nichts mit DHCP zu tun und darf, wie Captain_Byte andeutete, nicht im IP Adressbereich des DHCP Servers liegen. Bei Verwendung einer statischen IP Adresse, was ich bevorzuge, musst du somit den Adressbereich des DHCP Servers kennen, um sicher keine IP Adresse aus diesem Bereich zu vergeben.

Zitat von seseis

Leider gibt's derzeit nur den frame für 3 Einsätze.

Vielleicht für alte Shelly i3 (Name?) ...

https://www.shelly.com/de/products/sh…-switch-4-white

Solche habe ich mit Shelly i4 im Einsatz. Leider ist der Abdeckrahmen etwas zu groß, was bei Einzeldosen kein Problem darstellt.

Dieser URL ist rückwärtskompatibel zu Shelly Geräten der ersten Generation.

Versuche es auch mal mit dem originären URL für einen Plus Plug S (zweite Generation) - am besten per Web Browser Adresszeile, um die Reaktion des Plus Plug S zu testen!

http://<IP Adresse des Plus Plug S>/rpc/switch.set?id=0&on=true

Zum Ausschalten am Ende ...&on=false.

Wenn der Plus Plug S sich wie gewünscht verhält, kannst du diesen URL im Button 1 eintragen und entsprechend testen. Danach sollte feststehen, welches der beiden Geräte ggf. nicht funktioniert.

Zum Dimmer siehe die Dokumentation.

Edit: API Dokumentation zum schalten von Shelly Geräten ab Generation 2. Hier spielt die Component Switch die entscheidende Rolle.

Zunächst ein paar Hinweise und eine Frage zu deinem Skript/Anliegen.

1. Ich sehe keinen triftigen Grund, die Berechnungsfunktion (calculateDewPoint) lokal in loop zu definieren. Man kann so etwas tun, es macht den Code aber unübersichtlicher.
2. Solange ich kein Skriptproblem wegen Abbruchs vorfinde, lasse ich Ausnahmebehandlungen (try, catch) weg. Das ist zwar Ermessenssache, nach meiner Kenntnis aus C++ brauchen Ausnahmebehandlungen aber Ressourcen, weshalb ich solches nicht ohne Not einsetze, zumal dein Skript recht kurz ist.
3. Für eine explizite, zyklische Abfrage der Messwerte sehe ich keinen Grund. Hier täte ich einen EventHandler einsetzen, welcher sofort auf das von der Firmware gelieferte Event reagiert.
4. Konstanten sollten nur dort definiert werden, wo sie gebraucht werden. Dies kann durchaus global sein, in deinem Skript werden a und b nur in der Berechnungsfunktion gebraucht und sollten dort lokal definiert werden. Du kannst diese auch global definieren, dann aber mit aussagekräftigen Namen statt a und b.
5. Auf Grund welchen Ereignisses soll der Shelly einschalten und wie soll dieses Einschalten erfolgen - manuell oder automatisiert? Im zweiten Fall wären zwei Referenzwerte für eine Hysterese zielführend.

Wie eine Nachricht (an die Shelly App) gesendet werden kann, weiß ich nicht. Aber die Stelle, an welcher dies erfolgen kann, steht fest. Ich täte dazu MQTT einsetzen, andere vermutlich ein übergeordnetes System. Wie der Ausgang eines Shelly ab zweiter Generation geschaltet werden kann, ist in der API Dokumentation zu finden.

Auf der Grundlage deines Skripts gelänge dies wie folgt.

let RefDewPoint = ...; // Hier setzt du den von dir gewünschten Wert ein!

// Das MQTT Topic ist ausschließlich für das Senden einer MQTT Nachricht erforderlich.
// Ich setzte hier in der Shelly Konfiguration den Eintrag eines öffentlichen MQTT Brokers voraus, wie test.mosquitto.org.
// Dafür ist das Topic insbesondere bei Verwendung des öffentlichen Brokers geeignet anzupassen.
let MqttTopic = "crypticPreTopic/deviceDewPoint/belowReference"; 

function calculateDewPoint(t, rh) {
	let a = 17.27;  // Konstante für die Magnus-Formel
	let b = 237.7;  // Temperaturkonstante in der Magnus-Formel
    // Berechnung des Sättigungsdampfdrucks
    let gamma = (a * t) / (b + t) + Math.log(rh / 100.0);
    // Berechnung des Taupunkts basierend auf dem Sättigungsdampfdruck
    let dp = (b * gamma) / (a - gamma);
    return dp;
}

function Loop(){
  try{

	let temp= Shelly.getComponentStatus('Temperature', 100).tC;
	let humidity= Shelly.getComponentStatus('Humidity', 100).rh;

	let dewPoint = calculateDewPoint(temp, humidity);

	print("Temperatur: ", temp, "°C");
	print("Luftfeuchtigkeit: ", humidity, "%");
	print("Taupunkt: ", dewPoint.toFixed(2), "°C");
	
	//Verarbeiten des berechneten Taupunktes	
	if(dewPoint < RefDewPoint) {
		// Nachricht senden, was ich hier ausschließlich per MQTT andeute.
		MQTT.publish(MqttTopic, true);	
		//Ausschalten des Shelly-Ausgangs.
		Shelly.call("switch.set", {id:0, on:false});
	}
	// Bei Berücksichtigung einer Hysterese ist ein weiterer Vergleich mit einem zweiten Referenzwert
	// ähnlich wie oben ggf. mit automatisiertem Einschalten zielführend.
	// else if(dewPoint > ... ) {
	// 		// Anweisungen
	// }
  }catch(e){print(e);}
}

Timer.set(2000,true,Loop);

Ich habe dein Skript weitgehend so belassen. Den Einsatz eines EventHandlers magst du selbst prüfen. Bei Bedarf kann ich eine solche Alternative gerne ergänzen. Informationen dazu in der API-Dokumentation.

Frage: Wie hast du denn ein solches Skript per trial and error zustande gebracht - ohne Programmierkenntnisse? Solches erscheint mir recht abenteuerlich.

Zitat von nurmaso

Ich suche aber nach einer Möglichkeit, dass man nicht zyklisch überwachen muss, sondern der i4 das sofort mitkriegt, wenn eine Lampe eingeschaltet wird.

Ich habe nur eine Shelly Duo zum testen und tat dies für ein Forumsmitglied auch bereits.

Dazu kannst du in der Shelly Leuchte eine Action anlegen, welche bspw. auf das Einschalten reagiert. Im Skript des i4 verwendest du im einfachsten Fall eine Funktion oder etwas besser einen HTTPServer Endpoint. Die Action auf der Leuchte lautet bspw. so.

http://172.16.8.1/rpc/script.eval?id=1&code="sync()"
allg.
http://<IP Adresse des Zielgerätes (i4)>/rpc/script.eval?id=<Skript Id>&code="sync()"

Im Skript muss die Funktion, welche auf die Action reagieren soll, in diesem Beispiel sync() lauten und das abarbeiten, was du erreichen willst.

Auf diese Weise meldet die Leuchte das Einschalten oder das, was sie melden soll, bspw. auch das Ausschalten. Ohne die Leuchte per polling abzufragen, da die Leuchte selbst das Ereignis der Änderung mitteilt. Das Abfragen der Leuchtenzustandsparameter musst du selbstverständlich in sync() noch selbst coden, bspw. so wie der Link von ThomasHRO zeigt. Allerdings täte ich darin ein Array aus IP-Adressen verwenden und zum synchronisieren eine Schleife abarbeiten lassen.

Edit:
Nicht alle Änderungen einer Shelly Leuchte können in einer Action verwendet werden.
Wäre eine solche Leuchte mit einem ESP32 ausgestattet, wäre sie vermutlich skriptfähig. Dann könnte jegliche Änderung per Skript mitgeteilt werden.

Das ist hier relativ ausführlich beschrieben:

https://github.com/mongoose-os-libs/cron

Zitat

• @sunset-1h30m 1 * * : Run 1.5 hours before the sunset every 1th day of month;

Für deinen Zweck lautet der timespec Wert also:

@sunset-2h * * *

Dies lässt sich auch per Web UI einstellen, solange man keine spezifischen Methoden wie "Script.Eval" einsetzen will.

nurmaso

Zitat von nurmaso

Meine Funktion arbeitet aber von 120 Minuten vor Sunset bis zum Sundet zyklisch.

Solches kann leicht per Schedule Job alias Zeitplan realisiert werden.

Aus meinem Beitrag #16:

Zitat

Die Firmware 1.3.1 lässt im Web UI keine Änderung von KVS Variablen mehr zu. Damit ist für manche Anwender die KVS Nutzung kaum noch möglich. Hoffentlich wird dies noch geändert. Ob dies per RPC Methode gelingt, habe ich bisher nicht getestet.

Zwischenzeitlich testete ich, ob eine KVS Variable per RPC änderbar ist - via Web Browser Adresszeile.

Ergebnis: Ja, das ist möglich. Diese Einschränkung betrifft also nur das Web UI.

Ob diese Einschränkung in 1.3.2 beseitigt ist, weiß ich allerdings nicht.

Edit: Soeben getestet und für schlecht befunden. Auch in Firmware 1.3.2 sind KVS Variable nicht per Web UI änderbar.

Mein Verdacht: Auf Entwicklerseite wird dies entweder nicht ernst genommen oder dies ist beabsichtigt.

Die Freilaufdiode (1N4004) am Türöffner (4) erscheint wegen induktiver Last angemessen.

Ich verstehe nicht, was mit "Tür" in rot gemeint ist. Vermutlich ist das der Türöffner, welcher bereits in schwarz im Plan enthalten ist.

(4) wird nie geschaltet? Irgendwie ist der Plan an dieser Stelle sinnfrei.

nurmaso

Hinweis zur Zeitsteuerung, auch gekoppelt mit sunset ...

Die Shelly Firmware beinhaltet einen Scheduler und bietet den Einsatz von Schedule Jobs.

Damit lassen sich gewünschte Aktionen sehr verlässlich und effizient triggern. Es lassen sich bis zu 20 Schedule Jobs anlegen und editieren. Dies gelingt am flexibelsten per RPC und der Web Browser Adresszeile (URL). Bei Bedarf kann ich weitere Informationen dazu liefern.

Hierzu habe ich einen kurzen Beitrag erstellt ...

Danke für die Info.

Bei Szenen bin ich weitgehend ebenso raus wie Michael. Auch verstehe ich deine Beweggründe kaum. Ein vor Ort Lichteinfall kann afaik ausschließlich per Lichtsensor vor Ort erfasst werden und nicht etwa aus einer großflächigen Wetterlage. Schon deshalb erscheint mir eine Szenen-Lösung eher abwegig.

Falls in einer Szene, was ich zunächst vermute, aber nicht weiß, auch URL eintragbar sind, ließe sich, trotz meiner Bedenken, ein parametrierter Aufruf einer Skriptfunktion implementieren.

Etwa so:

http://<IP Adresse des Shelly>/script/<Skript Id>/<HTTPServer Endpoint Name> ...

Der HTTPServer Endpoint Name ist nach eigenem Belieben wählbar, die abschließenden drei Punkte stehen für ergänzbare Parameter.

Solche URL können selbstverständlich auch von anderen Devices im lokalen Netz ohne Cloud Erfordernisse genutzt werden, bspw. von einem "intelligenten" Lichteinfall-Sensor.

RB0815

Willst du ausschließlich die beiden fest im Skript verankerten Positionen anfahren lassen, um die Lamellen ein wenig zu drehen?

Ich halte das Skript für suboptimal, weil es so nicht gestattet, die Lamellen nach dem Fahren auf eine beliebige Position noch zu drehen.

Deshalb schlage ich folgende Variante vor, welche imho zielführender arbeitet und zudem wegen Parametrierbarkeit besser pflegbar ist - u.U. auch flexibler nutzbar.

1. Eine äußere Anweisung zum Anfahren einer parametrierten Position - Shelly.call(...).
2. Innere Anweisungen zum kurzzeitigen fahren (öffnen/schließen) der Jalousie. Diese Anweisungen müssen in der callback Funktion von 1. stehen.
   Grund; Wie bereits von ostfriese angemerkt, arbeiten die RPC-Aufrufe (Shelly.call(...)) asynchron.
   Diese Platzierung der Anweisungen innerhalb der callback Funktion von 1. lässt die Anweisungen in kürzestmöglichem Zeitabstand zum Positionsanfahren ausführen.

Zu 2.

Zur Parametrierung der inneren Anweisungen ist der user defined Parameter (=zusätzlicher, letzter Parameter in Shelly.call() Aufrufen) zielführend einsetzbar. Dafür täte ich vorzeichenbehaftete Zahlen vorsehen, welche die Drehung der Lamellen bestimmt.

Für die relative Zeitsteuerung sind zwei Anweisungen erforderlich.

1. Ein Shelly.call() Aufruf zum öffnen/schließen der Jalousie, abhängig vom Vorzeichen des user defined Parameters.
2. Ein Timer.set() Aufruf mit dem Betrag des user defined Parameters und in der callback Funktion nach Timer Ende das Anhalten der Jalousie.

Dies sind bisher planerische Gedanken/Vorstellungen, welche in einem Skript sehr wohl implementierbar sind und imho als best practicable zielführend eingestuft werden können. Über die erreichbare Präzision beim abschließenden Lamellendrehen liegen meinerseits keinerlei Erfahrungen vor. Letzteres wäre per geeigneten Tests herauszufinden.

Falls du zum Skript konkretere Code-Teile brauchen solltest, kann ich solche gerne beisteuern - allerdings kann ich mangels Verfügbarkeit solcher Jalousien nicht selbst testen.

oldchiefphil

Diese Steuerbox hat nach den Aussagen von @Benjidoggi ein internes Enable, welches verhindert, das der Antriebsmotor gleichzeitig Spannung zum Hoch- und zum Herunterfahren erhält - jedenfalls interpretiere ich es so.

Dann ist zunächst ein gegenseitiges Verriegeln auf dem Plus Uni nicht zwingend erforderlich. Eine Kalibrierung des Lifts gelänge ausschließlich mit Hilfe von Zeitmessungen und dem Eintragen deren Ergebnisse in ein Skript oder in das KVS, welches von einem Skript gelesen werden sollte. Dann stünden fast beliebig viele Zwischenpositionen zur Verfügung, was aber nicht ohne Skript gelänge. Theoretisch wären insgesamt sechs Zeitmessungen zielführend, in jeder Fahrtrichtung drei. Ganz nach unten/oben und in jeder Fahrtrichtung zwei zusätzliche zu Zwischenpositionen. Letztere wären für die Anlaufdauern erforderlich, was ein wenig zusätzliche mathematische Berechnung (linearer Funktionen) erforderlich macht. Alles kein Hexenwerk. Ich habe es nur durchdacht, aber selbst noch nicht angewendet. Vermutlich geht die Kalibrierung auf einem Shelly Plus 2PM etwas redundant so vor + Erkennung des automatischen Abschaltens seitens eines Rollladenantriebs.

Ein solches Skript müsste sich die letzte Position merken, um die Einschaltdauer für eine neue Zwischenposition ermitteln zu können. Nach Skriptstart muss eine Referenzposition angefahren werden. Es ist anzunehmen, dass die vorhandene Steuerbox-Elektronik den Antrieb bei erreichen einer Endposition automatisch ausschaltet. Dann sollte der Plus Uni zur Steuerung der Box geeignet sein - ein passendes Skript vorausgesetzt. Da aber der Plus Uni per se kein Gerät zur Ansteuerung eines Rollladens, einer Markise oder eines Lifts ist, kann hierfür zunächst kein Sprachassistent genutzt werden. Dann wäre für jede Zwischenposition eine separate Routine ein Workaround - nicht schön, aber vielleicht möglich.

Edit:
Ich empfehle, zunächst die Nutzbarkeit eines Shelly Plus 2PM zu prüfen. Dieser kann zwar bei Einsatz einer unüblichen Spannungsversorgung nicht automatisiert kalibrieren, aber vielleicht ist eine solche Kalibrierung per Konfiguration über Fahrdauern möglich (?). Ansonsten kann auch auf einem Plus 2PM ein Skript genutzt werden.

Nach meiner Erinnerung gibt es unterschiedliche Pin Maps. Ich bin dbzgl. nicht auf dem Laufenden. Deshalb kann ich dir hierbei nicht direkt weiterhelfen.

Ich täte ein reduziertes Programm schreiben (setup() und loop()), welches nach einem Reset alle möglichen Pin Nummern einmal durchläuft. Zu jeder Pin Nummer täte ich den Signalzustand per serieller Schnittstelle auf den Monitor übertragen lassen.

Sobald der zur Verfügung stehende Eingang (SW) zwischen zwei Reset geändert wird, könnte ich daran die passende Pin Nummer erkennen. Etwas komfortabler wäre bspw. der Empfang einer MQTT Nachricht, auf Grund welcher der Eingangszustand der gewünschten Pin Nummer ebenfalls per MQTT Nachricht übertragen würde.

Beispiel:

Zu veröffentlichte MQTT Nachricht für den Shelly: (Diese kann bspw. über einen öffentlichen MQTT Broker vertöffentlicht werden.)

Topic: ShellyPlus1-<MAC Adresse>/input/number
Payload: <Pin Nummer>

Vom Shelly veröffentlichte Nachricht nach dem Empfang der obigen Nachricht:

Topic: ShellyPlus1-<MAC Adresse>/input/status
Payload: <Eingangszustand>

Solches kann mit MQTT fx, MQTT Explorer, Abdroid App MQTT Dash oder Node-RED praktiziert werden.

Der Rest obliegt deiner Kreativität.

Btw, auch ein per Taster ausgelöster Interrupt könnte hierfür eingesetzt werden. Die ISR setzt eine boolean Variable auf true, woraufhin loop() die Eingänge "abklappert", sachlich als polling bezeichnet.

...

Soweit habe ich deinen Code nicht analysiert. Vermutlich liegt es an der Pin Nummer.