Beiträge von ostfriese

Lässt sich nicht änden, ist read only.

Ansätze für Tricks hast du ja selbst genannt.

Ein nicht publiziertes Limit ist ein Bug

Vielleicht sollte man sich angewöhnen, die Alterco Geräte erst ein Jahr nach Erscheinen anzufassen. Wir sind da zu schnell.

Aber, selbst dann sind die ja noch nicht fertig.

Als ich meiner besseren Hälfte erzählte, dass Alterco an die Börse geht, hat sie gefragt, ob sie Aktien kaufen soll.

Meine Antwort dürft ihr raten...

Ist mir auch aufgefallen. Ich habe mich tot gesucht. Ich wollte etwas für Debug-Zwecke ausgeben. Hatte das vor einem Block regulärer Ausgaben platziert.

Kam nichts.

Habe dann versucht, den Fehler in meiner Programm-Logik zu finden. Durch Zufall bin ich dann auf den Bug gekommen.

Der Gen 2 Shelly, falls vorhanden, kann ein beliebiger in deinem Netz sein. Aber ohne einen Gen 2 kommt ja noch Setup 1 aus meinem Eröffnungspost in Frage.

Ist mir zu unverlässlich. Temperatur Delta für Meldungen im Batteriebetrieb mit 0,5 K zu groß.

Intervall der Meldungen (selbst) bei Netzteilbetrieb zu lang. Träges Messverhalten, da Masse zu groß.

Die Schwachstelle ist der H&T.

Besser nicht, ist AC.

Input mode per Skript setzen

Die möglichen Werte für in_mode:

follow    <-- Toggle
detached  <-- Detached
flip      <-- Edge
activate  <-- Activation
momentary <-- Momentary

Shelly.call("Switch.SetConfig", {"id":0,config:{"in_mode":"detached"}},
  function(result, error_code, error_message) {
    aw = Shelly.getComponentConfig("switch:0");
    print(aw.in_mode);
  }
);

Ich warte jetzt erst einmal auf eine Fehlermeldung von Cyb.2K

eiche Danke, für die ausführliche Darstellung.

Es gibt da, wie man sieht, verschiedene Ansätze. Wie komplex die Materie ist, sieht man ja schon an der Länge deines Post.

Deine Lösung stellt eine, sehr bequeme, Generierung von Schedules mit erweiterten Möglichkeiten dar. Ein Segen, für den 'Fachmann', ein Fluch für den 'mir ist egal wie, Hauptsache es funktioniertmann' , da die äußere Logik vom Anwender deines Tools selbst erstellt werden muss.

Außerdem beinhaltet dein Tool die wertvolle Erkenntnis und Umsetzung, dass man Shedules erheblich vielfältiger Nutzen kann, als im WebUi vorgegeben. Hat auch mein Wissen erweitert.

Bei meinem Ansatz ist das völlig anders. Die Konfigurationsmöglichkeiten sind absolut eingeschränkt. Man kann ja nur die Endzeit eingeben.

Dafür muss ich aber die komplette Logik liefern. Außerdem steht mir, bei meiner Lösung etwas sehr wichtiges nicht so einfach zur Verfügung, sprich Astrozeiten, hier Sonnenuntergang.

Das Problem ist gelöst, ist aber so komplex, dass es mehr als die Hälfte des Codes beansprucht. (z.B. Api liefert alle Zeiten im AM/PM System und müssen auf das 24h System umgerechnet werden.)

Dazu kommt der eingeschränkte Sprachraum (und besonders dieser asynchrone Mist mit den RPC-Calls ) von mJs. Es ist schon in einer vollwertigen Programmiersprache nicht ganz trivial, mit Zeiten, Zeiträumen und Vergleichen derer umzugehen.

Hätte nicht gedacht, dass die es so komplex es, die einfachere Anforderung,

verhindere, dass jemand das Licht in einem gewissen Zeitraum ausschaltet,

umzusetzen.

Ich habe gestern den ganzen Tag getüftelt, bin aber noch nicht zu einer Lösung gekommen, die mich zufrieden stellt. Zumal die Schaltungsgestaltung des TE nicht ideal ist.

Aber, man wächst ja an den Herausforderungen

Ich sehe schon, dass läuft auf zwei Lösungen heraus

Ich versuche (aus Spieltieb ) den EventHandler in dem gewünschten Zeitraum abzuschalten.

nach dem Schema:

Wenn Zeit gleich Sonnenuntergang, dann EventHandler aus. <--Schaltbefehle werden nicht verarbeitet

Wenn Zeit gleich Endzeit, dann EventHandler an <-- Schaltbefehle werden verarbeitet

Der Sinn ist ja, dass der TE einen Schedule konfiguriert hat, der das Licht zum Sonnenuntergang für eine bestimmte Zeit einschaltet, und der Taster dann nicht dazwischen funkt.

Ich denke, das geht so:

function handle_events(e) {
  //do_something
}

//API: Shelly.addEventHandler(callback[, userdata]) -> subscription_handle
let subscription_handle = Shelly.addEventHandler(handle_events);
print('subscription_handle is', subscription_handle);

//API: Shelly.removeEventHandler(subscription_handle) -> boolean
let answer = Shelly.removeEventHandler(subscription_handle);
print('subscription_handle ', subscription_handle, 'removed is', answer);

eiche Danke für den Test und die Hinweise. Auf Ideen kommen die Leute

Bin gerade dabei, das Skript zu härten.

"script:1":{"id":1,"running":false,"mem_free":25200,"errors":["error"]}

ist eine Nullaussage, in Bezug auf den Fehler.

Interessanter ist dieses:

"wifi":{"sta_ip":"192.168.0.22","status":"got ip","ssid":"nicht verbunden!","rssi":-75}

Der ist nicht mit dem Wlan verbunden. Da wird die Frage, nach dem WARUM interessant.

function handle_events(e) {
  //do_something
}

//API: Shelly.addEventHandler(callback[, userdata]) -> subscription_handle
let subscription_handle = Shelly.addEventHandler(handle_events);
print('subscription_handle is', subscription_handle);

//API: Shelly.removeEventHandler(subscription_handle) -> boolean
let answer = Shelly.removeEventHandler(subscription_handle);
print('subscription_handle ', subscription_handle, 'removed is', answer);

Ausgabe:

subscription_handle is 1

subscription_handle 1 removed is true

Pack Code bitte in Codetags.

Sonst wäre mein Skript ja sinnlos, weil die von @66er genannte Möglichkeit ja für GEN 2 direkt funktioniert.

Zitat von Schubbie

Der TE hat keinen Plus, dann ist doch dennoch ein neuer Shelly notwendig oder bin ich nun total daneben?

Nein, du hast natürlich Recht.

Der Shelly 1(Client), als dummer nicht HTTPS-Kenner, sagt dem schlauen Gen 2 (Server) über einen Webhook:

Ich möchte diese Nachricht senden.

Der Gen 2 sagt:

Mach ich gerne für dich.

Ich dachte, dass wäre klar.

Aber manchmal bin ich ein Fachidiot

eiche perfekt erklärt

Zitat von Schubbie

Und das funktioniert auch per Shelly 1

Mein Skript schon. Das ist ja ein Server für alle Shelly. Konnte man aber heute eleganter lösen.(Den Teil mit dem Zeitzonen Trick).

Vlt. fasse ich das noch einmal an.