Beiträge von tvbshelly

Du könntest auch die Firmware vom 2PM Gen3 aktualisieren, seit 1.5.0 ist das BLU Gateway standardmäßig aktiv:

Zitat von Michael Kerkhoff

Wollte dann mit dem 2PMGEN3 verbinden, wird aber nicht gefunden und ich kann die beiden Sensoren nicht verbinden...

Stift oben rechts beim BLU auswählen und auf der 2. Seite des Wizards alle Shellys auswählen (da werden alle mit aktivem Gateway angezeigt).

-

Edit: Flutschi war schneller

Aktuell gibt es einen Bug, bei der Szenen mit %-Angabe nicht korrekt funktionieren, nur auf/zu geht.

Warum bei dir nur ein Shelly das Problem hat, verstehe ich aber nicht.

Das ist echt cool   eiche Eröffnet ganz neue Möglichkeiten.

Die Abfrage brauchst du nicht: Statt ein oder aus kannst du auch toggle nehmen.

Dann wechselt jeder Tastendruck einfach hin und her.

Eigentlich sollte der Code über die WebUI abrufbar sein. Ich meine gelesen zu haben, dass der Code allerdings nicht mehr angezeigt wird, wenn das Gerät schon mit einer Zentrale verbunden ist - ich hoffe, das ist nur ein Bug.

Hast du mal in der App / Cloud nachgeschaut, ob man dort den Code findet?

Ansonsten probier mal das hier:

http://<shelly-ip>/rpc/Matter.GetSetupCode

Da kommt hoffentlich sowas raus:

{
  "qr_code": "MT:00000O-O03.3QG5.000",
  "manual_code": "00576700759"
}

Zitat von hahgeh

Eine Frage: der plus 1 kann ja auch dry contact, also 230v auf i und 12v auf Ausgangsseite. Verliert er das mit dem flashen, oder warum wird dann direkt ein 12v Input genutzt

Nachfolger: Shelly 1 Gen3 -> https://www.shelly.com/de/products/shelly-1-gen3

Der hat genauso ein potentialfreies Relais = dry contact und ist SELV konform. Sprich man darf ihn mit 230 V versorgen und trotzdem gefahrlos 12 V mit dem Relais schalten. Das ist ein Hardware-Feature, da hat Tasmota keinen Einfluss.

Und du hast Glück: Tasmota kann man immer noch flashen: https://github.com/tasmota/mgos32…ses/tag/v14.1.1 ("add Shelly 1 gen3")

-

Edit Nachtrag: SELV ist nicht im Kontext der in #1 vorgestellten Schaltung via GPIO gegeben!

Und natürlich herzlich willkommen

Warum? Der http Aufruf nutzt die Shelly Cloud.

Die gesamte BLE Funktionalität wurde seit 1.5.0 umgebaut. Obiges Beispiel wird daher nicht mehr funktionieren.

Doku: https://shelly-api-docs.shelly.cloud/gen2/Scripts/S…uetooth-support

Ich habe es jetzt nur mit einem BLU Button testen können, hier mal grob skizziert (local_name gibt es beim Button anscheinend nicht):

let BLE_DEVICE_ID = "------------------"; // MAC-Adresse des Shelly BLU Door
let WEBHOOK_URL = "http://---------------------"; // Ziel-URL

// Überwache BLE-Broadcasts

function bleCallback(event, device) {
  if (event !== 2) {
    return;
  }
  if (device.addr !== BLE_DEVICE_ID) {
    return;
  }

  let open = device.service_data.state === 1;

  if (open) {
    print("Tür geöffnet - sende Web Request");
    Shelly.call("HTTP.GET", { url: WEBHOOK_URL }, function (res, err) {
     if (err) {
       print("Fehler beim Senden des Requests: ", err);
     } else {
       print("Webhook gesendet, Antwortcode: ", res.code);
     }
    });
  }
}
BLE.Scanner.start({duration_ms: BLE.Scanner.INFINITE_SCAN});
BLE.Scanner.subscribe(bleCallback);

Edit - - - 2025-06-23

Addendum for firmware 1.6.x and higher:

The names of the start and stop methods must begin with a uppercase S:

BLE.Scanner.Start() and BLE.Scanner.Stop()

Der TE möchte das als Fallback haben, falls mal HA ausfällt und ansonsten via BLU Button über HA steuern - hoffe, ich habe das richtig verstanden.

Da sehe ich eine gewisse Überschneidung. Leider kenne ich mich mit HA nicht aus, um was sinnvolles beizutragen.

Gute Idee mit dem Hersteller "nerven".

OT und Spaß: Du könntest einfach einen größeren Unterverteiler installieren . Auf dem Foto sieht es so aus, als wenn du noch Platz hast.

Hast du den Fehler schon gemeldet? Bekka420  casi239

Sieht für mich nach Fehler in der Android App aus:

-> https://support.shelly.cloud/de/support/tic…report_an_issue

Und in deinem lokalen WLAN funktioniert das? Das ist seltsam

Zitat von AlexAn

ja das wurde mir angeboten

Im WebUI oder der App?

Zitat von AlexAn

In keinem Fall darf aber ein Script verschwinden!

Definitiv - volle Zustimmung.

Man müsste genauer einkreisen können, was genau passiert ist.

Bei mir sind auf einem Pro 3EM keine Skripte verschwunden beim Update von 1.6.0-beta2 auf 1.6.0 (und auch vorher nicht von 1.5.1 -> 1.6.0-beta1 -> beta2)

Äh, was? Du hast von 1.6.0 auf 1.6.0 aktualisiert? Oder zw. Matter und Zigbee gewechsel? Bin verwirrt ...

Welche Firmware Version war vorher drauf? Die beta2?

Er möchte das aber über eine Automation machen, die er durch das NFC Teil auslöst. Sprich nicht über die Shelly App.

Ich hoffe ich habe das richtig verstanden

Zitat von AlexAn

Was gar nicht geht ist dass die Scripte beim Update rausgeschossen werden

Komme nicht mehr ganz mit: Was ist jetzt genau beim Update auf 1.6.0 passiert?

Zitat von Mechanoid1

Muss ich bei der Fritz Box irgend ne Portfreigabe beachten? Aber es läuft ja eigtl über die cloud.

Eigentlich nicht.

Genau, der Shelly sollte den Befehl über die Cloud bekommen. Da macht es keinen Unterschied, ob du den Befehl im lokalen WLAN abschickst oder von unterwegs.

Kannst du das mal in einem anderen WLAN testen, z.B. an irgendeinem Hotspot oder bei einem Freund das WLAN nutzen und den Cloud https Aufruf machen?

Zitat von hdreislampl

mehrere Shelly 2PM Gen3 für die ROllläden mit dem RC4 Button steuern als Backup

Einzelner 2PM Gen3: Grundsätzlich ja - Problem wird aber sein, dass sich das mit HA ins Gehege kommt, wenn sowohl der Shelly selbst auf den BLU reagiert als auch HA irgendwas macht.

Mehrere Shellys zusammen: Ich vermute, das geht nur per Skript (was auf dem Shelly läuft) - Problem bzgl. Doppelsteuerung bleibt

Zitat von hdreislampl

BLU Devices (Bewegungsmelder) mit dem Shelly BLU Gateway

Ein BLU Gateway ist bereits in jedem 2PM Gen3 eingebaut, das brauchst du nicht extra.