Beiträge von eiche

Niomzone

Ich verwende zum manuellen Steuern meiner Rollladenantriebe je zwei Taster an einem i4.

Auf den Plus 2PM läuft jeweils ein Skript mit selbstgeschriebenen Subscriber, Publisher und Eventhandler. So kann ich die von mir gewünschten Topics selbst frei festlegen.

Auf dem i4 läuft ein Skript, welches die von mir festgelegten Topics verwendet. Darüber steuere ich auch alte Shelly 2.5 an. Die Nachrichten lege ich per Konfiguration in den Skripten fest, damit sie leicht anpassbar sind.

Wenn du schon selbst programmierst, dann sollten solche mJS Skripte für dich kein Problem darstellen.

Allerdings habe ich für die von mir gewünschte Flexibilität nicht wenig Zeit investiert.

Ob eine solche Vorgehensweise für dich in Frage kommt, weiß ich selbstverständlich nicht.

Es geht tatsächlich noch viel einfacher - in einem Skript. Hier habe ich jegliche Retriggerbarkeit weggelassen.

// Author: eiche
// I call this script "switchLatency".
// When switch:0 toggles on, enable is set to false and a message (e.g. a switch on message) is send to a second device.
// This action is only triggered if enable is true.
// After the LatencyTime enable is set to true.

let Method = 'http.get';
let SwitchOn = {'url':'http://172.16.3.62/relay/0?turn=on'}; // switch on message
let LatencyTime = 1*60*1000; // 1 minute
let enable = true;

Shelly.addStatusHandler(
  function(e) {
    if (enable && e.component==="switch:0" && e.delta.output) {
      enable = false;
      Shelly.call(Method, SwitchOn);
      Timer.set(LatencyTime, false, function() {enable = true;});
    }
  }
);

Warum bin ich darauf nicht sofort gekommen?

Zitat von markus-hi

Problem ist nun, dass ich keinen der beiden via mqtt ans Laufen bringe.

Also erhältst du auch vom Licht schaltenden Shelly 1 (mit Allterco Firmware?) keine MQTT Nachricht? Ich nehme an, dass dieser Shelly per Taster gesteuert wird.

Wenn ich das richtig verstanden habe, würde ich zunächst einmal die MQTT Kommunikation des Shelly 1 versuchen zum laufen zu kriegen.

Der sollte nämlich mit jedem Schalten eine Nachricht absetzen.

Wie kommunizieren denn bisher der Shelly 1 und Node RED miteinander, per HTTP?

Sorry, ich sah eben erst, dass ihr bereits viel weiter seid.

Hiermit ersetze ich meine beiden Skripte (in #52) durch die aktuellen.

Alles bereits vorher von mir Beschriebene gilt nach wie vor.

Wichtig!

Da ich hier einen kleinen Automatismus per Shelly.getCurrentScriptId() eingebaut habe, müssen beide Skripte in der Liste unmittelbar hintereinander stehen, das Skript "enable" zuerst. Die Skripte erkennen so selbst die passenden Id.

Man kann so beide Skripte hinter ggf. bereits vorhandenen Skripten ablegen wie auch davor liegende Skripte löschen - ganz nach Belieben.

Im ersten Skript ist in Zeile 10 die IP-Adresse des Slave einzusetzen!

Das erste Skript "enable":

// Author: eiche
// I call this script "enable".
// When switch:0 toggles on, a message is send to a second device e.g. a switch on message.
// Within the on time (e.g.) this action is retriggerable.
// After the retriggerable time a second script (called "disable") is started, which stops this "enable" script.
// The script "disable" starts the "enable" script after a while and stops itself.
// Both scripts must have consecutive id, "enable" first.
// version 2023-01-07

let Method = 'http.get';
let SwitchOn = {'url':'http://172.16.3.62/relay/0?turn=on'}; // switch on message
let Retriggerable = 5*1000; // 5 s

let SuccId = Shelly.getCurrentScriptId() + 1; // id of the successor script "disable"

let h = Shelly.addStatusHandler(
  function(e) {
    if (e.component === "switch:0") {
      if (e.delta.output) {
        Shelly.call(Method, SwitchOn);
        // If you don't whish retrigger, delete Timer.set() and only use both inside instructions! 
        Timer.set(Retriggerable, false, function(){
          Shelly.removeStatusHandler(h);
          Shelly.call('Script.Start', {id:SuccId});
        });
    }
  }
});

Das zweite Skript "disable":

// Author: eiche
// I call this script "disable".
// When it is started, it stops the "enable" script.
// After the end of an invoked timer the script "enable" is started and this script "disable" stops itself.
// Both scripts must have consecutive id, "enable" first.

let DisableTime = 1*60*1000; // 1 minute

let ThisId = Shelly.getCurrentScriptId(); // this script id
let PreId = ThisId - 1; // id of the predecessor script "enable"

Shelly.call('Script.Stop',{id:PreId});

Timer.set(DisableTime,false,
  function(){
    Shelly.call('Script.Start', {id:PreId}); // start "enable"
    Shelly.call('Script.Stop', {id:ThisId}); // stop "disable"
  }
);

Diese beiden Skripte gefallen mir besser.

Ergänzung:

Der Slave (hier ein Plug S) ist per Shelly App tatsächlich noch schaltbar, auch ohne den Gateway-Eintrag. Offenbar greift die App schlicht per WLAN zu. Das ist zwar nicht gewünscht, muss aber kein Problem sein.

Ich kann hierfür empfehlen, ein anderes Frontend als die Shelly App einzusetzen oder alle beteiligten Personen darauf hinzuweisen, nur Räume und Gruppen zu verwenden.

Schade, dass man die Option "Entdeckte Geräte" in der App nicht deaktivieren kann. Vielleicht wäre es praktikabel, ein Gerät in der Cloud zu verstecken.

Nachtrag 2023-01-07:

Sorry, ich musste noch ein wenig nacharbeiten. Im ersten Skript habe ich noch zusätzlich den status handler entfernt (Shelly.removeStatusHandler(h)).

Ich weiß nicht, ob mit dem Stopp eines Skript auch dessen Referenzen entfernt werden. Deshalb habe ich vorsichtshalber diesen Aufruf noch eingefügt.

Das zweite Skript ist wie vorher geblieben.

Ich versuche noch, die Funktionalität in einem einzigen Skript zu implementieren.

Praxis ist, wenn es funktioniert ...

Ich habe testweise in Shelly.call() nicht die Methode 'http.get' und den URL verwendet sondern:

Shelly.call('Script.Start',{'id':3});

Ich erwartete, dass dieser Aufruf bereits genügt. Aber nein, so gelingt der Start des Script 3 nicht. Ohne die single quotes um id ist es nicht anders.

Script.Start wie auch Script.Stop sind in der Methodenliste aufgeführt (<ip-address>/rpc/Shelly.ListMethods).

Deshalb ist zu erwarten, dass obiger Aufruf das Script ebenso startet wie mit

Shelly.call('http.get', {'url':'http://127.0.0.1/rpc/Script.Start?id=3'});

Das tut er merkwürdigerweise nicht.

Nachgereicht:

Ich hatte im zweiten Skript ("disable") einen Syntaxfehler. Der kurze Aufruf gelingt doch. Ich werde die jetzigen Skripte nachreichen.

Johnny Glatteis

So, geschrieben und getestet mit einem Shelly Plus 1 (Master) und einem Shelly PlugS (Slave).

Die gewünschte Funktion wird mit zwei Skripten implementiert, ein Skript "enable" und ein Skript "disable". Diese Namen sind selbstverständlich frei wählbar. Beide Skripte laufen auf dem Master.

Sowohl die IP-Adressen als auch Dauern sind für eigene Zwecke anzupassen.

Zuerst "enable", welches auch enabled werden sollte, damit es nach einem Stromausfall automatisch gestartet wird.

// Author: eiche
// I call this script "enable".
// When switch:0 toggles on, a message is send to a second device e.g. a switch on message.
// Within the on time (e.g.) this action is retriggerable.
// After the retriggerable time a second script (called "disable") is started, which stops this "enable" script.
// The script "disable" starts the "enable" script after a while and stops itself.

let Method = 'http.get';
let SwitchOn = {'url':'http://172.16.3.62/relay/0?turn=on'}; // switch on message
let StartDisable = {'url':'http://127.0.0.1/rpc/Script.Start?id=3'}; // instead of id 3 use the "disable" script id
let Retriggerable = 5*1000; // 5 seconds

Shelly.addStatusHandler(function(e) {
  if (e.component === "switch:0") {
    if (e.delta.output === true) {
      Shelly.call(Method, SwitchOn);
      // If you don't whish retrigger, delete the Timer.set() and only use the Shelly.call()! 
      Timer.set(Retriggerable,false,function(){Shelly.call(Method, StartDisable);});
      // Shelly.call(Method, StartDisable); // without retrigger
    }
  }
});

Dieses Skript reagiert auf das Einschalten des eigenen Relais mit dem Senden einer Nachricht an den Slave. Diese Aktion ist für eine gewisse Zeit (hier 5s) retriggerbar. Die Retriggerbarkeit kann leicht entfernt werden.

Das zweite Skript "disable" ist nicht zu enablen, weil es nur durch das erste Skript gestartet werden soll.

// Author: eiche
// I call this script "disable".
// When it is started, it stops the "enable" script.
// After the end of an invoked timer the script "enable" is started and this script "disable" stops itself.

let Method = 'http.get';
let StopEnable = {'url':'http://127.0.0.1/rpc/Script.Stop?id=2'}; // instead of id 2 use the "enable" script id
let StartEnable = {'url':'http://127.0.0.1/rpc/Script.Start?id=2'}; // dito
let StopDisable = {'url':'http://127.0.0.1/rpc/Script.Stop?id=3'}; // instead of id 3 use the "disable" script id
let DisableTime = 1*60*1000; // 1 minute

Shelly.call(Method, StopEnable);

Timer.set(DisableTime,false,
  function(){
    Shelly.call(Method, StartEnable);
    Shelly.call(Method, StopDisable);
  }
);

Dieses Skript stoppt das erste Skript "enable" und startet einen Timer. Sobald der Timer abgelaufen ist, startet dieses Skript das erste Skript "enable" und stoppt sich selbst.

Das "enable" Skript ist somit während der "disable" Dauer inaktiv und der Slave kann nicht per Master geschaltet werden.

In der Praxis werden die gewünschten Dauern länger sein. Für Funktionstests sind die obigen Dauern gut geeignet.

Wer es noch ein wenig komfortabler möchte, mag Shelly.getCurrentScriptId() verwenden. Wenn bspw. beide Skripte hintereinander liegen, können alle konstanten Skript-Id per Shelly.getCurrentScriptId() und Konvertierung in einen String ersetzt werden.

Wichtig!

Für lokale HTTP-Nachrichten, also zum selben Gerät, muss die IP-Adresse 127.0.0.1 (=localhost) verwendet werden. Mit der eigenen IP-Adresse funktionieren die HTTP-Nachrichten derzeit nicht (Firmware 0.12.0).

Der Slave sollte ausschließlich vom Master gesteuert werden können. Die Shelly App könnte dies evtl. trotzdem, das habe ich nicht getestet.

Empfehlungen:

1. Die Einschaltdauer des Master auf 1s stellen.
2. Den Slave nicht mit der Cloud verbinden. Er kann sogar ganz ohne Internetzugriff auskommen.

Womit der Master eingeschaltet wird, ist total beliebig. Entscheidend ist nur das Einschalten. Auf diese Weise gibt es reichlich Steuerungsoptionen.

Wenn statt des Plus 1 bspw. ein Plus 2 verwendet wird, kann per zweitem Relais eine Signalleuchte geschaltet werden.

Und nun viel Erfolg! Und einen Dank an SebMai für seine initiierende Skriptidee.

Noch ne Idee

Erstmal würde ich die Skriptlösung bevorzugen.

Gründe:

1. Der Script-Shelly arbeitet autark und somit am funktionssichersten, weil außer ihm alles ausfallen darf und er kann immer noch arbeiten.
2. Es kann eine Cloud verwendet werden, muss aber nicht.

Nun meine Zusatzidee - ohne Signalleuchte, die kann eh irgendwie geschaltet werden:

Erforderlich sind

• ein Shelly der zweiten Generation, weil darauf ein Script arbeiten soll, bspw. das von SebMai oder eines auf seiner Grundlage
  Hier bietet sich ein Plus 1, ein Pro 1, ein Plus 2 oder ein Pro 2 an.
  Ich nenne diesen Shelly den Master. Der Master schaltet den eigentlichen Verbraucher NICHT.
• ein beliebiger Shelly mit Relais, der den eigentlichen Verbraucher schaltet
  Ich nenne diesen Shelly den Slave.

Der Master erhält bei Bedarf die Verbindung mit der Cloud und kann per Sprachassistent gesteuert werden.

Der Slave erhält keine Verbindung zur Cloud und kann (vermutlich) nicht per Sprachassistent gesteuert werden. Notfalls könnte in dessen Konfiguration bei statischer IP-Adresse das Gateway weggelassen werden, wodurch der Slave sogar keine Verbindung mit dem Internet hätte.

Der Master steuert per Skript den Slave. Wenn der Master eingeschaltet wird, wodurch auch immer, kann er dem Slave die Schaltnachricht senden oder auch nicht, wenn dies temporär gerade gesperrt ist.

Auf diese Weise erscheint mir ein Einschalten innerhalb der gesperrten Zeitphase unmöglich, allenfalls wäre es evtl. per App im WLAN möglich, was ich nicht weiß, da ich die App für solche Zwecke nicht verwende.

Der Master mag vielleicht kurz schalten, wenn er den Befehl oder das Signal erhält, er kann aber bspw. nach eine Sekunde wieder ausschalten.

Vielleicht werde ich dieses gelegentlich ausgiebig testen ..

Btw - das Ganze ginge auch mit einem Shelly der ersten Generation und Tasmota-Rules.

Ich nutze bisher solche "hübschen" Dinge nicht. Vermutlich kann dir dabei Tasmota(32) weiterhelfen. Diese Firmware ist ziemlich flexibel konfigurierbar und sehr vielseitig einsetzbar, besonders dann, wenn man sie selbst kompiliert. Man kann aber auch fertig kompilierte Versionen einsetzen. Gewöhnungsbedürftig sind für eigene Erweiterungszwecke die Rules. Aus dem ESP32 wird mit der Programmierung in Berry eine "Kanone" - im nichtmilitärischen Sinne.

Das Tasmota32 System ist imho dem derzeitigen Shelly Firmwaresystem noch überlegen. Mit gefällt das Shelly Firmwaresystem trotzdem sehr gut und Allterco entwickelt ja auch weiter.

Der JSN-SR04T ist ein digitaler Sensor. Das Senden des Schalls wird binär getriggert. Sobald der Empfänger des Sensors den reflektierten Schall empfängt, wird dies binär mitgeteilt. Der Mikrocontroller muss die Zeitspanne zwischen dem Triggern und der Empfangsmeldung messen. Daraus ergibt sich die Laufzeit für Hin- und Rückweg des Schalls und daraus der Abstand zur reflektierenden Oberfläche. Hier ist also kein analoges Signal beteiligt.

Digital ist der Sensor durch die ihn begleitende Elektronik, welche mit dem Mikrocontroller kommuniziert.

WEMOS D1 ist eines der vermutlich geeigneten Boards, ich nutze ein für Experimentierzwecke geeignetes ESP32 Board mit zwei Stiftleisten zum stecken. Das ist zwar nicht erforderlich, ermöglicht mir aber einen einfachen Boardwechsel, wenn dies erforderlich ist.

Mit einem Arduino habe ich begonnen, ein ESP32 mit Tasmota32 ist aber wegen der bereits vorhandene Firmware (Tasmota) und deren Erweiterbarkeit per Berry-Funktionen eindeutig zu bevorzugen.

Mein System ist parametrierbar und liefert den resultierenden Nutzwert, hier also den verfügbaren Füllstand.

Bestätigung.

Ich nutze diesen gekapselten koaxialen US Sensor JSN-SR04T. Dieser hat sich bisher gut bewährt.

herrmannjoerg Ich messe meinen Zisternenfüllstand per Ultraschallsensor, aber mit einem Nicht-Shelly ESP32 Board und Tasmota32. Das gelingt sehr gut. Tasmota liefert einen Abstand, den ich mit einem Programm in der Sprache Berry von Ausreißern befreien und in den Füllstand umrechnen lasse. Mein einziges Problem ist die sehr hohe Luftfeuchtigkeit in der Zisterne, was in deinem Fall ja kein Problem darstellen wird.

Wie dies mit einem Shelly Plus Add On gelingen könnte, ist mir derzeit total unbekannt. Ich sehe dafür derzeit keine praktikable Möglichkeit. Allerdings habe ich dieses Add On bisher nicht und konnte mich darin noch nicht einarbeiten.

Vielleicht macht die sehr starke Oberflächenrauheit der Pelletfüllung einer Ultraschallmessung Probleme.

Ich habe mal die naturwissenschaftlich mathematischen Zusammenhänge notiert und hoffe, dass sich kein Fehler eingeschlichen hat.

Diese Notizen sind aus Notepad++ hierher kopiert, weshalb weder Tief- noch Hochstellungen und auch keine Schriftgrößenvariationen enthalten sind. Sie sollten trotzdem lesbar sein.

Ich lege hierfür irgendeine stabilisierte Referenzspannung und irgendeinen Reihenwiderstand zum NTC zugrunde. So lassen sich die Gleichungen auch bei einer externen Beschaltung mit anderer Referenzspannung und eigenem R1 verwenden.

Noch einmal die Anschlussbelegung von Allterco:

Heißleiter am Shelly Plus Add On

Kurzdarstellung ohne Herleitung: Alle Platzhalter außer t und p sind konstante Parameter.

mit t = Temperatur in °C:

t = 1 / (1/Tn + ln((R1/(100*Uref/(p*Uanmax) - 1))/Rn)/B) - 273 | Gl. 4.1

mit Uref = 3,3V und Uanmax = 10V:

t = 1 / (1/Tn + ln((R1/(33/p - 1))/Rn)/B) - 273 | Gl. 4.2

t = Temperatur in °C

Uref = Referenzspannung, hier am Spannungsteiler aus R1 + R(T)

Uan = analoge Eingangsspanng

Uanmax = maximal auswertbare analoge Eingangsspannung

R1 ist der im Shelly Plus Add On vorliegende Widerstand an Uref oder bei externer Beschaltung ein Widerstand zwischen Uref und ANALOG IN.

p = Uan/Uanmax in %

Kenngrößen des eingesetzten Heißleiters, mitunter auch NTC genannt:

Tn = Nenntemperatur, Einheit K

Rn = Nennwiderstand bei Nenntemperatur Tn

B = Temperaturkoeffizient für die Näherungsgleichung (s.u.)

Herleitung obiger Gleichungen

1. T = f(R(T)):

T = absolute Temperatur am bzw. im Heißleiter, Einheit K

Tn = Nenntemperatur, Einheit K

Rn = Nennwiderstand bei Nenntemperatur Tn

R(T) = Widerstand bei der Temperazur T

B = Temperaturkoeffizient für die Näherungsgleichung (s.u.)

R1 ist der im Shelly Plus Add On vorliegende Widerstand an Uref oder bei externer Beschaltung ein Widerstand zwischen Uref und ANALOG IN.

R(T) = Rn * e ^ B*(1/T - 1/Tn) | Näherungsgleichung

<=> R(T)/Rn = e ^ B*(1/T - 1/Tn)

<=> ln(R(T)/Rn) = B*(1/T - 1/Tn)

<=> ln(R(T)/Rn)/B = 1/T - 1/Tn

<=> 1/T = 1/Tn + ln(R(T)/Rn)/B

<=> T = 1 / (1/Tn + ln(R(T)/Rn)/B) | Gl. 1.1

2. Uan = f(R(T)):

Uan = analoge Eingangsspannung

Uref = Referenzspannung, hier am Spannungsteiler aus R1 + R(T)

R1 ist unbekannt, kann aber ermittelt werden

Uref/Uan = (R(T) + R1)/R(T) = R(T)/R(T) + R1/R(T) = 1 + R1/R(T)

<=> R1/R(T) = Uref/Uan - 1

<=> 1/R(T) = (Uref/Uan - 1)/R1

<=> R(T) = R1/(Uref/Uan - 1) | Gl. 2.1

3. Gl. 2.1 eingesetzt in Gl. 1.1 liefert T = f(Uan):

T = 1 / (1/Tn + ln((R1/(Uref/Uan - 1))/Tn)/B)

<=> T = 1 / (1/Tn + ln((R1/(Uref/Uan - 1))/Rn)/B) | Gl. 3.1

4. T = f(Uref/Uan), hier sind die Prozentwerte sofort nutzbar

Uanmax = maximal auswertbare analoge Eingangsspannung

p sei das Verhältnis aus Uan/Uanmax, welches theoretisch zwischen 0% und 100% variieren kann.

k = Uref/Uanmax <=> Uanmax = Uref/k <=> p = Uan/Uref/k = k*Uan/Uref

Mit Uanmax = 10V und Uref = 3,3V ist p = Uan/10V = 0,33*Uan/Uref <=> Uref/Uan = k/p = 0,33/p = Uref/(p*Uanmax)

Gl. 3.1 ist äquivalent zu

T = 1 / (1/Tn + ln((R1/(Uref/(p*Uanmax) - 1))/Rn)/B)

mit p in %:

T = 1 / (1/Tn + ln((R1/(100*Uref/(p*Uanmax) - 1))/Rn)/B)

Darin sind alle Werte außer T und p Konstante.

mit t = Temperatur in °C:

t = T - 273 = 1 / (1/Tn + ln((R1/(100*Uref/(p*Uanmax) - 1))/Rn)/B) - 273 | Gl. 4.1, Hier ist R1 irgendein Widerstand zwischen Uref und ANALOG IN.

mit Uref = 3,3V und Uanmax = 10V:

t = 1 / (1/Tn + ln((R1/(33/p - 1))/Rn)/B) - 273 | Gl. 4.2

Gleichung 4.1 ist die allgemeingültige Gleichung, die auch für eine externe Beschaltung gilt.

Es ist erkennbar, dass jeglicher Wunsch nach einem linearen (proportionalen) Zusammenhang keine reale Grundlage hat.

Ich sehe da nichts Unlogisches. Die Beschaltung realisiert einen Spannungsteiler an der Referenzspannung.

In der Doku steht nur etwas von Thermistor. Vermutlich soll es ein Heißleiter sein, wegen -t. Eine fallende Spannung signalisiert dann eine steigende Temperatur, was leicht umgerechnet werden kann. Ob dafür eine Konfiguration vorgesehen ist, weiß ich nicht.

Ob der Eingangsstrom an ANALOG IN hinein- oder herausfließt, kann ich den Unterlagen nicht entnehmen. Ich unterstelle, dass diese Stromstärke in dieser Beschaltung bereits durch R1 begrenzt wird, dessen Widerstandswert ich nicht kenne.

Das ist ja das Besondere an Allterco. Die Informationen sind weitgehend offen gelegt. Ich musste mich zuerst an den Stellen, die mich besonders interessierten lesend "durchärgern", bis ich an diesen Stellen die Dokumentation brauchbar verstand, mit einigen Experimenten gelang es aber verlässlich. Weiter so!

Ich bin kein Installateur und mit den verschiedenen Möglichkeiten der Heizungsregelung nicht vertraut.

Im allgemeinen basiert aber eine Regelung auf einer Nachführung der Istgröße in Richtung einer Sollgröße. Wenn deine Sensoren (hier NTC) im Estrich verbaut sind, dann ist offenbar die Sollgröße die Estrichtemperatur, was mir erst einmal etwas merkwürdig erscheint. Hier könnte ich mir eher eine Sicherheitskomponente vorstellen, welche dazu dienen soll, die Estrichtemperatur zu begrenzen. Als Sollgröße stelle ich mir eher die Raumtemperatur vor, wofür ein Sensor irgendwo im Raum zwischen Boden und Decke geeignet wäre.

Unabhängig von alledem: Bei der Ermittlung einer geeigneten Formel wirst du weitgehend selbst kreativ sein und zurecht kommen müssen. Zumindest sind Referenzmessungen dazu hilfreich bis erforderlich.

Das Umrechnen ist doch kein Problem. Es kann bspw. in einem zu erstellenden Skript erfolgen.

Allerdings ist dazu ein wenig zu programmieren.

Guten Morgen und ein glückliches neues Jahr.

Auch meine Shellies der ersten Generation hatten und haben eine kurze Id. Ich bin dabei, sie per longify auf die lange Id umzustellen. Bisher ging alles gut.

Ich danke den Beteiligten für die Info und meine Sensibilisierung zu dieser Eigenschaft.

Leider ist immer noch offen, was bei o.a. Problemen die Ursache ist.

Bemerkungen dazu:

Das Sichern von bisheriger Firmware per Flash-Adapter und -Programm sollte vor solchen missliebigen Problemen schützen können.

Ok, es ist relativ aufwändig, auch weil dazu der jeweilige Shelly auszubauen und wieder einzubauen ist.

Ich denke bspw. an Tasmotizer, mit welchem ich bereits vorhandene Original Shelly Firmware vor dem Flashen mit Tasmota gesichert habe.

Ich hatte bisher allerdings keinen Grund, dies rückgängig zu machen.

Wenn aber vor dem Update solche Probleme bekannt werden, bzw. dabei jemand ein solches Problem bei einem seiner Shellies feststellt, wäre dies eine mögliche Rettungsmaßnahme für weitere Shelly Updates.

Bei Plug (S) ist es besonders aufwändig, weil dieser afaik keine dafür vorgesehene Buchsenleiste besitzt. Es wäre somit zu löten.

Ich frage mich auch, wie man einen Shelly der zweiten Generation (Plus) ohne Eingriff flashen könnte. Bisher las ich dazu nichts.

Immerhin würde es genügen, vor einem Firmware Update von einem (Reserve-)Gerät desselben Typs bspw. den Auslieferungszustand zu sichern, um im Notfall diese Sicherung auf einen betroffenen Shelly zu übertragen.

Oh, ich glaube, mal gelesen zu haben, dass solche Firmwaredateien irgendwo hier verfügbar sein sollen. Das könnte wenigstens eine vorläufige Hilfe für den TE und andere Betroffene sein ...

Zitat von fritz45231987

"login":{"enabled":false,"unprotected":false,"username":"admin"}

Ich kann dies nur frei interpretieren, evtl. sollten diese Struktur/Objekt genauer untersucht werden.

Ein disabled login und nicht ungeschützt erscheint mir ein Widerspruch. Und dann noch ein Benutzername/Anmeldename(?) "admin" ... hmm

Da wäre eine Stellungname seitens Allterco interessant.

Möglicherweise dominiert login.enabled = false und der Rest ist irrelevant. Ich weiß es nicht.

Nach einem Test: Mein Test PlugS zeigt an dieser Stelle das Gleiche. Mein Verdacht erscheint somit unbestätigt.

Ich interpretiere in der original Doku das "-t" am veränderlichen Widerstandssymbol als negativen Temperaturkoeffizient. Ich kenne dafür zwei gegenläufige Pfeile.

Wenn meine Interpretation stimmt, sieht Allterco tatsächlich einen NTC vor.

Bestätigung aus der Doku:

• NTC resistors with 10 kΩ nominal resistance and β=4000 K

Ist bekannt, wie belastbar Vref out ist oder deren innerer (differentieller) Widerstand?

Ich bin heute wohl etwas zu nervös. Ich fand soeben dass dieser Ausgang max. mit 1mA belastbar sei.

Sorry