Beiträge von gantim

Bisher war ich der Meinung, bei Shelly wäre das Updaten der Firmware problemlos möglich, mir nur zuviel Aufwand. Ich hatte entsprechendes gelesen, aber das war vermutlich vor Gen2. Und Firmware-Links gesehen.

Ist die Aussage, dass es die Firmware nicht mehr zum Download (und Einspielen per RPC oder Webinterface) bereitgestellt wird, offiziell und schriftlich vorhanden, oder kann ein Ticket beim Support möglicherweise eine andere Aussage erzeugen? Ich kämpfe gegen Miele und Grünbeck, weil viele Dinge nur über deren Server gehen. Ich möchte ungern alle Shellys im Haus austauschen, aber wenn der Hersteller nicht mehr vertrauenswürdig wäre (und das wäre dann der Fall), müsste das sein.

Die Firmware für 2PM ist durchaus zu finden unter dem Link https://updates.shelly.cloud/update/Plus2PM - aber wo man den findet, wenn er nicht zufällig in der Community erwähnt wird, weiß ich nicht.

Kann man die wirklich nicht herunterladen und aufspielen, ohne dass der Shelly eine Verbindung ins Internet benötigt?

Super, Anzeigegenauigkeit im Home Assistant von Default weg auf 2 Stellen hat für die Anzeige sofort geholfen, Klasse! Da habe ich den Sensor ja eh.

Das Ticket, ob man das auch im Script bekommen oder abfragen kann, mache ich vielleicht trotzdem noch, mal sehen, das ist eine gute Idee.

Edit: Das kann auch eine Erklärung für die Diskrepanz zwischen den Werten geben. Im Home Assistant wurde gelegentlich ein 0,5 Grad anderer Wert angezeigt. Meine Vermutung wäre nun, dass ein Wert gerundet ist und der andere abgeschnitten.

Ist völlig OK und mir bewusst. Es ist ein DS18B20, und ich hätte gerne den Messwert mit allen seinen Fehlern.

Übrigens glaube ich, dass dieser Fehler im Vergleich zur real existierenden Temperatur besteht. Er wird nicht, wenn permanent 21 Grad herrschen, abwechselnd 20.5 und 21.5 liefern, sondern üblicherweise 0,5 insgesamt falsch liegen. Permanent zu hoch oder zu niedrig. Vielleicht etwas verzögert reagieren, weil er sich erst erwärmen oder abkühlen muss.

Aber genau solche Dinge würde ich gerne sehen und messen wollen. Genau die Art der Ungenauigkeit würde mich interessieren. Das finde ich aber nur heraus, wenn ich genau den Wert erhalte, den der Shelly erhalten hat. Nicht gerundet, nicht interpoliert, falsch wie er sein mag. Das hätte ich gerne. Daher meine Frage, mit dem Hinweis, dass es nicht für den Betrieb relevant ist. Ich will ja niemanden verklagen, sondern die Genauigkeit des jeweiligen Sensors vielleicht sogar beurteilen können, schließlich habe ich mehr als einen und es könnten welche besser oder schlechter sein als andere.

Der Beitrag war jetzt aber nicht so direkt eine Antwort auf meine Frage?

Bei meiner Terrariensteuerung verwende ich auf dem Shelly Plus 2pm die Events des Addons mit event.name temperature, diese liefern die aktuelle Temperatur mit einer Nachkommastelle.

Allerdings sehe ich in der Konsole, dass der Shelly intern 2 Nachkommastellen verwendet. Das werde ich eher nicht im Normalfall/beim Betrieb brauchen, aber beim Debugging wäre es gelegentlich hilfreich. Besteht die Möglichkeit, die zweite Nachkommastelle auch zu erhalten?

Und nachdem wir das jetzt schon recht weit gesponnen haben, meine ketzerische Ansicht: So eine Aufgabe würde ich üblicherweise nicht einem Shelly überlassen.

Ich bin ein Freund davon, dass ein Gerät möglichst unabhängig arbeitet, dass ein Ausfall eines Systems nicht andere nach sich zieht. Bei manchen Steuerungen (Temperatur Terrarien) ist es mir wichtig, dass es unabhängig von irgendwelchen eigenen Servern (ganz zu schweigen dem Internet - das ist ein No-Go) läuft.

Aber die Feiertage durch den Shelly holen zu lassen finde ich unpassend. Ein Shelly ist eine IoT-Komponente. Sowas sollte nicht ins Internet gelassen werden. Oder gar von externen Diensten wie einem Feiertagsdienst im Internet abhängig sein. Was ist, wenn man 5 Shellys hat, soll jeder einzelne diese Liste holen? Klar, kann man machen, aber wenn sich die Adresse ändert, muss man sie an 5 Stellen ändern. Ich finde, da gehört es sowieso nicht hin.

Meine persönliche Lösung ist eine Integration namens Feiertag im Home Assistant, der auf einem Proxmox-Server läuft und sowieso viel bei mir im Haus macht. Die Rolladen-Öffnungszeit morgens ist 5 Minuten vor Sonnenaufgang, aber mindestens 6:15 an Werktagen und 8:00 an Sams-, Sonn- und Feiertagen. Die Schließzeit abends ist 5 Minuten nach Sonnenuntergang, aber spätestens 20:45 vor Werktagen und 21:30 vor sonstigen. Diese Uhrzeiten sind natürlich auf der GUI verstellbare Variablen. Der Home Assistant kümmert sich darum, alle iirc 14 Rolläden zu schließen. Er startet für den Terrassen-Rolladen einen Extra-Timer (der geht 3 Minuten nach den anderen runter, damit man die Chance hat, aus dem Garten reinzukommen oder das Schließen durch einfaches Bewegen des Rolladens abzubrechen). Und die Feiertage sind automatisch immer aktuell, weil die Integration gepflegt wird.

Wenn das alles jeweils in dem Rolladen-Shelly implementiert wäre (der bei mir üblicherweise kein Internet hat, aber egal), das ginge des öfteren schief. Da gehört es meiner Meinung nach einfach nicht hin. Mehrere Print-Ausgaben hintereinander werden verschluckt. Wenn man den 5. Timer gleichzeitig aktiv hat oder den 5. verschachtelten RPC-Call macht, steigt das Script aus. Shelly-Scripte sind daher prinzipiell als unzuverlässig zu betrachten. Meine Terrarien-Steuerung wird daher überwacht, wenn das Script 2 Minuten oder so nicht läuft, startet der Home Assistant es neu.

Solange es nur ein Shelly mit einer Aufgabe ist, passt das. Als Programmierübung ist es wunderbar und kann einen weiterbringen. Aber mittelfristig würde ich doch einen anderen Ansatz empfehlen. Wenn es keinen Home Assistant gibt, würde ich einen Dienst im Haus empfehlen, der die Daten holt, wann Feiertag ist, und die Information weitergibt. Wobei ich den Shelly vielleicht jede Nacht nach Tageswechsel um 0:01 fragen lassen würde, ob heute ein Feiertag ist, und dann die passende Aktion einleiten. Oder den Dienst, der die Feiertage holt, auf dem Shelly das Script starten lassen. Oder auch nur einen Schedule aktivieren. Oder wenn man sagt, dass der Dienst echt zuverlässig ist, direkt das Licht anschalten, wenn es sein soll (wie es auch der Home Assistant machen würde), und den Shelly "dumm" lassen als Schalter.

Die Möglichkeiten sind vielfältig, die Vor- und Nachteile auch. Ich wollte es nur erwähnt haben, dass man sich solche Gedanken machen sollte, was wo sinnvoll ist, bevor es mehrere Shellys sind, die solche Aktionen machen, und die Umstellung aufwändiger würde. Insbesondere da nur eine Detailfrage gestellt wurde, ohne die Gesamtsituation zu schildern.

Beispiel ist hier bei scheduleNextLightEvent. Das könnte schon weitgehend passen. Die Abfrage, was das nächste Event ist, passt in diesem Fall nicht direkt. Ich gehe davon aus, dass jeden Tag ein- und ausgeschaltet wird. Und ich bin auch bei täglich, das obige Script setzt ggf. ein paar Tage aus. Aber ein Tag hat 60*60*24 also 86400 Sekunden, und die kann man bei einem Timer auch mal Anzahl Tage dazurechnen, wenn das Event erst in mehreren Tagen ist. Hängt davon ab, was man will. Ich würde ansonsten ausschalten eh nicht in einem eigenen Script machen, damit nicht getrennt wird, was zusammen gehört. Für den Überblick.

Verbesserungsvorschlag: Ich finde es nicht gut, einen Timer jede Minute laufen zu lassen um zu checken ob eine bestimmte Minute erreicht ist, von der man eigentlich weiß, wann sie ist. Das kostet nur Strom und ist völlig unsinnige Verschwendung von Ressourcen. Wenn man weiß, wie lange es bis zum nächsten Event dauert, dann kann man einen Timer bis genau zu der Zeit setzen. Ändert sich die Planung, löscht man ihn (die ID des Timers ggf in einer globalen Variable merken, wenn sie null ist, läuft kein Timer) und setzt ihn neu.

Damit nicht genug, ist die bisherige Logik fehlerträchtig. Wenn jetzt der Timer um 05:54.998 zuletzt aktiv ist, aber ein anderes Event den Timer etwas verzögert, so wird 05:55 übersprungen und es ist gleich 05:56.

Nach Meldung beim Suport wurde ich gebeten, ein Ticket für "Proposal Archive" einzureichen, damit es in Zukunft berücksichtigt werden kann. Das habe ich getan. Inhalt:

Zitat

Show print() error

There is a circular buffer being used for print() which sometimes loses the output, see

https://shelly-api-docs.shelly.cloud/gen2/General/DebugLogs

It should be easy possible to check if there is something overwritten/lost and either throw an error/an exception or at least do a system message telling that there was output lost. It is really annoying if you search for an error and there is no output and you have no idea why.

Soso, KVS.GetMany liefert keine Liste mehr zurück, sondern ein Array mit einem Attribut "key", das es vorher nicht gab. Den direkten Vorteil sehe ich nicht, im Changelog sehe ich es nicht erwähnt (eine Änderung ja, aber nicht offensichtlicherweise diese - ok vielleicht ist sie gemeint), zusätzliche Bytes kostet es, aber so sei es. Es sieht ein wenig besser aus.

Irgendwas stimmt mit der Schaltung nicht. Ist es eine Idee, die Lampe am Ausgang des Shelly 1 anzuschließen?

Danke für den Hinweis im anderen Thread. Funktionieren die print()-Ausgaben auf diese Weise auch ohne Timer-Tricks? Eher nicht, oder? Möchtest du RunOnShelly.py nicht lieber in einem git verwalten, statt es bei Aktualisierung hier hochzuladen?

Meine Terrariensteuerung ist auf codeberg zu finden.

Szene? Ablaufen? Cloud? Oh Mann ... soll das Zeug nur funktionieren wenn eine Internetverbindung besteht oder was? Ich weiß schon, warum ich die App noch niemals installiert habe.

Meine Lösung hilft auch, wenn man den zweiten Shelly in dass WLAN des AP vom ersten Shelly hängt. Da braucht man nicht mal einen Router. Fällt das Internet aus, aber das WLAN funktioniert, geht auch alles. Und Aktionen und Szenen sind viel zu kompliziert. Eine URL aufrufen und Schluss.

Aber: Wenn der Shelly keinen Strom mehr hat, wenn die Lampe ausgeht, kann er ja gar nicht mehr senden, dass der Schalter aus ist ... es geht also nicht mehr nur ums WLAN, sondern es geht gar nicht anders als dass er dauernd Strom hat, wenn er IRGENDWAS aufrufen soll.

Edit: Wenn der Shelly beim Einschalten frisch Strom an L bekommt (überhaupt mit Strom versorgt wid und startet), kann es gut sein, dass das nicht bedeutet, dass der Schalter eingeschaltet wird. Sondern er ist an und bleibt an, wie er es auch war, als der Shelly keinen Strom mehr hatte. Warum solte das irgendetwas auslösen? Da ist keine Flanke.

OK, räumlich getrennt. Kein Thema, wenn WLAN aktiv ist. Aber wie es oben erwähnt wurde, würde ich den ersten Shelly immer mit Strom versorgen, damit er die WLAN-Verbindung nicht erst suchen muss, und die Lampe nur auf Input, nicht auf L setzen. Folgendes im Shelly 1 müsste dann helfen:

Button switched on URL: http://shelly2/relay/turn=off

Button switched off URL: http://shelly2/relay/turn=on

Besser?

Ja, ich habe es nicht verstanden.

Was ich verstanden habe: Der zweite Shelly hat einen Ausgang O, der ausgeschaltet werden soll, wenn am Eingang SW Strom anliegt. Das lässt sich über den Button Type regeln.

Wenn der 2. Shelly irgendwoher Strom auf L bekommt und diesen verwendet, um am Ausgang O Strom anzulegen, wenn an SW ein Signal anliegt, ist das dann noch nicht elektrisch getrennt? Wenn es das nicht ist, wieso hilft dann der erste Shelly, irgend etwas elektrisch zu trennen?

Habe ich einen Denkfehler?

Ehrlich gesagt verstehe ich nicht, wozu man überhaupt einen Shelly benötigt, wenn der nur Strom bekommt, wenn er Strom liefern soll. Reicht da nicht ein Kabel?

Wenn der zweite Shelly am SW Strom bekommt und dann mit dem Ausgang reagieren soll, reicht es normal aus, den Button Type richtig zu definieren. Da ist üblicherweise alles dabei was man braucht, und den Ausgang invertieren kann man auch.

Oh, hätte ich besser hier kommentieren sollen? Ich habe meinen imho recht schlichten Ansatz im anderen Teilbereich geschrieben.

Schließe ich es direkt am Computer an, sind die Störgeräusche ein wenig lauter. Weil der Computer mindestens 1m näher am Dimmer ist als der Monitor mit dem Hub (Anordnung von links nach rechts: Monitor 1 mit Hub an linker Seite, Monitor 2, Notebook, Dimmer).

Das ist völlig idiotisch: Das Problem gibt es weiterhin. Meine temporäre Lösung:

let doPrintArr          = [];

function doPrint(myString)
{
  doPrintArr.push(myString);
}

function doPrintLine()
{
  if(doPrintArr.length>0)
  {
    print(doPrintArr[0]);
    doPrintArr=doPrintArr.slice(1);
  }
}

Timer.set(50, true, doPrintLine);

Aufruf dann beispielsweise mit

doPrint("String"+wert);

Das klappt offensichtlich zuverlässig. Da programmiert man aufwändige Routinen, um Probleme zu umschiffen, die Resourcen sparen sollen. So ein Quatsch! Wenn ein print() nicht ausgegeben wird, erwarte ich wenigstens eine System-Log-Meldung deswegen ... aber stillschweigend wegwerfen! Meine Güte, die sollten mal einen Programmierer fragen und nicht die Projektmanager programmieren lassen.

Edit: Das Problem gibt es weiterhin ... Meint: Mindestens auf Shelly 2pm mit Firmware 1.4.4 oder 1.5.0beta1.

Edit2: Optimierte Version: Es wird sofort ausgegeben, wenn möglich, nur Ausgaben, die schneller als 50 ms sind, werden entsprechend verzögert.

let doPrintArr          = [];      // Delayed output because Shelly does not output multiple consecutive print()
let doPrintLast         = Date()-1000*Shelly.getComponentStatus('sys').uptime+5000; // last output time, initial last reboot+ 4-5 seconds
let doPrintDelay        = 50;      // not working with 30ms! Seems 50 is ok.

function doPrint(myString)
{
  let now=Date();
  let noTimer=(doPrintArr.length===0);     // Nothing to print means, no timer was scheduled.
  if(myString) doPrintArr.push(now.toISOString()+" "+myString);  // Add output to the end of output queue.

  if(now-doPrintLast >= doPrintDelay)      // Not too fast! The circular buffers rotates slowly.
  {
    let line=doPrintArr[0];                  // Avoid print/slice-race 
    doPrintArr=doPrintArr.slice(1);
    doPrintLast=now;
    print(line);
  }

  if(doPrintArr.length && (!myString || noTimer)) // Timer needed when: More output exists and we are in timer event or first timer needed
    Timer.set(doPrintDelay-(now-doPrintLast)+1, false, doPrint, null);
}

Wenn bei dem Headset irgendwas isoliert ist, wundert es mich. Ich habe nie behauptet, dass es hochwertig sei ... es ist dieses hier, das ich September 2023 für 10 Euro bestellt habe. War irgend so ein Cyberangebot. Ein neues Kabel wäre sicher teurer als das gesamte Headset . Aber dass der Dimmer Signale aussendet, die man dermaßen laut "empfängt" (das übertönt alles, wenn der Dimmer über 60% ist), wundert mich trotzdem.