Beiträge von marco.gr

Nein, die vom Shelly unter Advanced/Diagnostics.

Dort siehst du, ob der Request zum Tasmota getriggert wurde.

Hallo,

wenn der Aufruf im Browser funktioniert, sollte er natürlich auch über die Action funktionieren.

Was steht denn in der Diagnostics Konsole?

Ich habe es für dich einmal nachgestellt:

Kurzer Einwurf: Bei Android Smartphone liegt es manchmal auch am Handy selbst:
https://dontkillmyapp.com/

Bei meinem Smartphone muss ich z.B. jede App nach dem Geräteneustart manuell starten. Es sei denn, es handelt sich um Mainstream Apps.

Timer.clear(handle) ist die korrekte Methode, um einen Timer zu beenden:

    // Wenn wir noch ein Handle haben
    if(AUTO_OFF_ALERT_HANDLES[switchId]) {
	  // Beende den Timer und entferne das Handle    
      Timer.clear(AUTO_OFF_ALERT_HANDLES[switchId]);
      AUTO_OFF_ALERT_HANDLES[switchId] = null;
    }

Das ist in meinem Script so gebaut, weil es zwei Stellen zum beenden der Timer gibt. Einmal 'regulär' über das Script und einmal von extern z.B. via RPC Call. Sonst könnte das Script auch das Limit der Timer erreichen.

Hallo Hanutaminator,

in das Problem mit zu vielen Timern läuft man schnell, wenn man ein Flackern als Abschaltindikator haben möchte.

Ich kann dir hier als Inspiration mein eigenes Script verlinken. Mein Script läuft auf dem jeweiligen Shelly selbst und benötigt somit max. 4 Timer.
Diese sind nur für das Flacken notwendig, da ich für den Rest die Timer vom Switch selbst nehme. Das Script unterstützt auch das Pro Gerät mit 4 Relais.

Das Script selbst hat mehrere Features, weil ich es in verschiedensten Anwendungsfällen verwende. Z.b. schaltet mein Garagentor via MQTT das Garagenlicht ein. Und im Treppenhaus bleibt tagsüber das Licht bei Single-Push dunkel um mich daran zu erinnern, dass ich gar kein Licht brauche.

Ich bin mir jetzt nur nicht sicher, ob mein Script auch dann flackert, wenn man via RPC Call einschaltet. Vielleicht muss das noch angepasst werden. Per MQTT geht es definitiv.

Wenn Interesse besteht, stelle ich die Features und Konfigurationsmöglichkeiten auch ausführlich vor.

https://github.com/mgrie/shelly-s…-lightswitch.js

Viele Grüße,
Marco

Guten Abend teryoXin ,

leider fehlt mir diese Woche etwas Zeit um dir mehr unter die Arme zu Greifen. Ich habe etwas entdeckt:

Die Komponente "meter:0" gibt es bei diesem Device nicht.

Ich weiß, dass es nicht einfach ist das Komponenten und Service Modell bzw. die Doku zu verstehen.

Wenn man aus der Doku nicht schlau wird, so ist es erstmal ratsam, das Verhalten vom Shelly auf der Konsole anzusehen, z.B:

Shelly.addEventHandler(function(event){
  print(event);
});

Shelly.addStatusHandler(function(event){
  print(event);
});

Und mit KIs wirst du nach meiner Erfahrung oft an Grenzen stoßen. Denn die verstehen die Doku auch kaum.

Für den Moment kann ich dir leider nur "Hausaufgaben" mitgeben.

Zitat von teryoXin

Daher habe ich eine Frage an die Shelly-Community gestellt – vielleicht könnt ihr herausfinden, wo ein Fehler im Skript liegt.

Die Beschreibung hilft doch schon mal.

Vielleicht finde ich heute Abend ein paar Minuten Zeit dafür.

Was mir noch aufgefallen ist: Wenn du einen Mini verwendest, sollte der Geschirrspüler nicht mehr als 2000 Watt haben. Andernfalls müsstest du auf den größeren Shelly mit 16A umsteigen.

Zitat von HighFive

Mit Sicherung raus->rein und ein neuer Tag mit 2 Zyklen hat begonnen?

Ja, genau das meinte ich.

teryoXin dies lässt sich in einer späteren Iteration vermeiden, indem du die Werte im KVS speicherst. Aber erines nach dem anderen.

Haben die Mitbewohner herausgefunden, wie sie dein Script umgehen können?
Ein Wettrüsten innerhalb der WG?

Hallo Mike,

ich habe meine bestehenden Wechselschaltungen auf Stromstoß umgestellt und einen Shelly verbaut. Auch wenn das i.d.R. nicht nötig ist, so hat es doch den Vorteil, dass du dann unterschiedliche Zeiten für einfach, zweifach, dreifach und langes Drücken hinterlegen kannst. Außerdem bist du dann mit dem Ort, an dem der Shelly verbaut werden soll flexibler. Dies hat zwecks der WLAN Abdeckung Vorteile.

Um keine neuen Schalter zu kaufen, hab ich meine bestehenden Busch-Jäger Schalter mit einer Feder zu einem Taster umgestellt.

Da ich gerne übertreibe, habe ich noch dafür gesorgt, dass manche Lichter bei entsprechendem Tageslicht deaktiviert sind.

Ja, das ist alles lösbar. Oft auch ohne an den Leitungen etwas zu Ändern. Normal sollte ein Shelly pro bestehender Schaltung (Lampe) reichen. An manchen Stellen, wie z.B. Schlafzimmer mit Leselampe, konnte auch ein Shelly 2PM zwei Schaltungen abdecken.

Allerdings halte ich mich bei Aussagen zu elektrischen Schaltungen etwas zurück. Das können andere besser als ich wiedergeben.

Viele Grüße,
Marco

Die Actions der WebUI reagieren auf die Events vom Shelly.

Soweit ich weiß, werden die Events zur Energiemessung nicht bei jeder kleinsten Änderung gefeuert. Das ist ja auch sinnvoll. Man würde das System schnell überlasten - je nachdem welche Trigger implementiert sind. Deshalb versucht man das etwas zu entprellen und entzerren. Dabei dürfte nicht nur die Abweichung zum vorherigen Wert, sondern auch die Zeit eine Rolle spielen.

Einen Teil kannst du unter 'Diagnostics' als Notifications mitlesen.

Wenn dir das nicht reicht und du die tatsächlichen Events mitlesen möchtest so hast du viele Möglichkeiten:

• Ein kleines Script, welches dir die Events auf der Konsole ausgibt.
• Den Shelly mit einem MQTT Broker verbinden und unter 'Debug' MQTT aktivieren.
• UDP Debug. Dazu ist ein Tool in der Dokumentation beschrieben.
• Websocket Debug.
• Home Assistent (sollte alle Events abgreifen)
• (Eine Action die dir das gewünschte Event an einen Service postet)

Zitat von MauDa

Haben dann gemeint Tasmota drauf flashen

Die Software ändert ja an der Schaltung nichts. Dieser Schritt wird nicht zum Erfolg führen.

Mein Setup läuft ohne Shelly:

Ich betreibe eine UAP1 mit einem ESP32 und einer eigenen Schaltung, da ich alle I/Os der UAP1 anschließen wollte. Als Firmware habe ich ESPHome verwendet. Der ESP32 hat eine externe WLAN Antenne. Die Standard WLAN Antennen der ESP Module sind schlechter als bei den Shellies.
An die internen 24 Volt habe ich mich erstmal nicht getraut, da laut Hersteller nur wenige Watt unterstützt werden. Ich werde es aber noch nachholen.

Hallo Stromyi ,

nun habe ich den Zusammenhang zwischen Actions und Webhooks verstanden.

Die WebUI der Actions ist ein Editor für die RPC Schnittstelle 'Webhooks'. Oder einfacher ausgedrückt: Möchte man eine Action deaktivieren, so geht dies über den RPC Service 'Webhooks'.

Dieses Wissen kann man sich zunutze machen, um die Zeitschaltung sicher und ohne Script von einem anderen Shelly zu starten und zu beenden.

Angenommen, du möchtest die folgende Action deaktivieren oder aktivieren:

So musst du zunächst die ID der Action herausfinden. Dazu rufst du folgenden RPC Call auf:

Request:
http://192.168.7.78/rpc/Webhook.List

Response:
{
  "hooks": [
    // ... gekürzt
    {
      "id": 2,
      "cid": 0,
      "enable": true,
      "event": "switch.on",
      "name": "on -\u003E 5 sec -\u003E off",
      "ssl_ca": "ca.pem",
      "urls": [
        "http://127.0.0.1/rpc/switch.set?a2=1&on=true&toggle_after=5&id=0"
      ],
      "condition": null,
      "repeat_period": 0
    },
    // ... gekürzt
  ],
  "rev": 29
}

Im Response sucht man sich den Hook mit der passenden ID heraus. Dies erkennt man am am einfachsten am Namen.
Hier sieht man, dass eine Action nichts anders ist, als ein Webhook auf den Shelly selbst in Form eines RCP Calls. Und man erkennt das Event, welches als Trigger dient.

Daraus leiten wir folgende RPC Calls zum deaktivieren der Action ab:

http://192.168.xxx.xxx/rpc/Webhook.Update?id=2&enable=false

Vorschlag zum Schalten via HTTP RPC - ohne SW

Shelly 1 startet Shelly 2:

1. http://192.168.xxx.xxx/rpc/Webhook.Update?id=1&enable=true
2. http://192.168.xxx.xxx/rpc/Webhook.Update?id=2&enable=true
3. http://192.168.xxx.xxx/rpc/Switch.Set?id=0&on=true

Shelly 1 stoppt Shelly 2:

1. http://192.168.xxx.xxx/rpc/Webhook.Update?id=1&enable=false
2. http://192.168.xxx.xxx/rpc/Webhook.Update?id=2&enable=false
3. http://192.168.xxx.xxx/rpc/Switch.Set?id=0&on=false
   

Natürlich müssen die korrekten IDs eingetragen werden.
Wenn man verstanden hat, wie das funktioniert, dann kommt man auch ohne Script sehr weit.

Mir selbst ist für diesen Anwendungsfall (egal ob über SW oder HTTP) ein Script lieber. Denn dies könnte schön parametrisiert werden und würde sich auf je einen Befehl zum Starten und Stoppen beschränken.

Ach ja: Die von mir verworfene Idee, die Action temporär zu deaktiveren, funktioniert wohl über folgenden Call:

https://shelly-api-docs.shelly.cloud/gen2/Component…k#webhookupdate

Allerdings muss ich mir das selbst erst noch in Ruhe durchlesen.

Hallo Klaus,

mit auto_off war ich leider auf dem Holzweg. Dieser Parameter existiert und bei 'Switch.SetConfig' nicht bei 'Switch.Set'.

Wenn deine Endlosschleife über zwei Actions Ping-Pong spielt, so hast du bereits den richtigen Befehl:

http://192.168.178.106/rpc/switch.set?id=0&on=false

Allerdings funktioniert dieser nur, wenn der Status gerade 'false' ist. Das lässt sich auch Erklären: Wenn du vom Status "aus mit toggle_after / flip Timer" zu "aus ohne Timer" (der obige Befehl) wechselst, so wird die Action nicht getriggert. Diese Triggert nur bei einem Wechsel von 'on'. Somit wird die Schleife unterbrochen.

Die Variante vom verlinkten Post von thgoebel macht das gleiche, nur mit perfektem Timing. Hier könnte sogar die Reihenfolge der Actions in der GUI eine Rolle spielen. Wie beim Kartenspiel - wer sticht wen aus?

Eine unelegante Möglichkeit wäre es also, wenn du den o.g. Befehl 2-3 mal in schneller Folge absendest.

Wenn du die Möglichkeit hast, den beschriebenen Workaround umzusetzen, so wäre dies die bessere Wahl.

Sollte das beides für dich keine zufriedenstellende Option sein, so benötigst du ein Script. Ein Script hätte hier die volle Kontrolle über den Schaltvorgang.
Steuern könnte man dies dann über Virtuelle Komponenten.

Viele Grüße,
Marco

ChatGPT hat einen zu alten Datenstand. Gemini wechselt manchmal zu Python und sagt mir ein RPI wäre besser für meinen Anwendungsfall.

Ich bin immer froh, wenn ich die Fehler gleich sehe.

Krauskopp das macht mich ja ein bisschen neidisch. Immer wenn ich denke, ich lasse mir einen Teil meiner Scripte von einer KI generieren (egal welche) kommt nur Müll raus, den ich mühselig debuggen und korrigieren muss.

Zitat von bp4willi

Oder habe ich was übersehen?

Da habe ich leider keine Erfahrungen und müsste das alles selbst durchspielen. So wie ich es sehe gibt es hier schon entsprechende Möglichkeiten.

Du müsstest mal herumprobieren und Herausfinden ob man hiermit deine Wünsche erfüllen kann.

Auch UND und ODER sind prinzipiell in der GUI vorhanden.

Danke euch, jetzt schließt sich diese Wissenslücke auch endlich bei mir.

BTHome baut auf BLE auf. Das Gateway, welches man in Home Assistant aktiviert, nutzt den BLE Scanner und ist somit nicht auf BTHome Geräte beschränkt.

Wenn ich ein Gerät direkt mit einem Gen3 Shelly verbinden möchte (statt Cloud oder Home Assistant), so benötige ich ein Gerät mit BTHome.

Dies wiederrum erklärt, weshalb ein Firmwareupdate relativ einfach für BTHome Unterstützung sorgen kann.

apreick heißt dass, der Goove unterstützt auch BTHome? Ich hatte darüber nichts gelesen. Die Teile scheinen ja sehr interessant zu sein.