Ja du sagst keine Kaufempfehlung, meine laufen ja bisher ohne Probleme. Machen genau das was Sie sollen. Also könnte ich jetzt eine Kaufempfehlung aussprechen.
Beiträge von Devil
VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
-
-
Keine Kaufempfehlung für TRV
umbenannt wird,und das soll dann was genau bringen?
-
Ja dann frag doch mit diesen Werten mal genau das den Support. Ist ja bei der ganzen Sache auch das was ich merkwürdig finde. Dann muss doch der TRV, das irgendwie erkennen und wenigstens einfach mal neustarten.
-
elektroman wir sind hier beim Shelly Plus 1PM aber ja meine 3 Stück laufen wie ein Schweizer Uhrwerk

-
Ich kann mich zwar irren, glaube aber nicht das hier noch in diesem Jahr etwas kommen wird. Der fokus wird aktuell leider eher auf Matter liegen. Wobei ich lieber erst mal ipv6 Support hätte
-
Ja deshalb Prinzipiel, wäre Blau aber nun wirklich N und der Shelly würde sich starten, was er nicht tut und der TE würde Schalten macht es peng.
-
-
Welcher Firmware stand ist nun drauf?
Sind noch weitere Szenen aktiv?
Oder zusätzliche Geräte die diese Shellys schalten?
Wie wurde die Funktion hinterlegt, über Szene oder über die Auto-Off funktion?
Läuft der Timer in der Ansicht normal durch und eine Sekunde entspricht nicht einer Sekunde oder wird dort abgebrochen?
-
Autschi !!!!!
Du sagst du hast das nach Plan angeklemmt? Wo hast du denn diesen Fehlerhaften Plan her?
Du hast nen Schalter an der Wand der hat nicht L1 N PE sondern wenn auch geklemmt PE und einmal L1 sowie deinen Schaltdraht zur Deckenleuchte selbst.
Prinzipiel hast du einen Kurzschluss gebaut. Aber allein deine Erkennung der einzelnen Adern sagt mir, hole dir einen Fachmann zum Anschließen!
-
aufgrund eines selbst erstellten Zertifikats oder aufgrund der fehlenden SSL Verschlüsselung erhalte, ist ja wohl egal.
Und genau da liegt dein denkfehler, was bringt es mir dann wenn ich sowieso einen Zertifikatsfehler bekomme. Auch kommen hiermit 95% der User doch eh nicht zurecht wenn das nicht voll Automatisch geht. Und da sind wir halt leider noch sehr weit davon entfernt. Also aktuell eher unpraktikabel und nicht mehr als eine Neard spielerrei.
Ich glaube da tust du dir leichte ein Seperates IOT VLAN zu nehmen und den Datenverkehr über nen NGINX proxy zu leiten. Und auch das sehe ich als Spielerrei.
Jeder der es schafft seine eigenen Zertifikate zu signieren muss sich auch keine Gedanken darüber machen das jemand den Datenverkehr zwischen seinem Handy und dem Shelly Plug mitliest, der bekommt sein Wlan auch save.
Falsch, SSL Verschlüsselung ist heutzutage der Standard die meisten meiner HeimNetz Geräte lassen ihr Interface über SSL laufen, auch Iobroker und NodeRed bietet das an.
Und Falsch SSL ist leider noch nicht der Standard!
-
Hab ja nicht gesagt unmöglich nur ist es über die IP schwieriger.
-
Naja aber wie greifst du auf das Webui zu? Wahrscheinlich über die IP und da wird es mit dem Zertifikat sowieso schwierig. Wenn dann müsstest du über den Hostname Arbeiten und diese dann noch selbst signieren was erst mal zum SSL Fehler führt wenn du dieses nicht zusätzlich in deinem Browser als Vertrauenswürdig hinterlegst. Ich glaube da lohnt der Aufwand nicht wenn man am Schluss 100 Shellys hat und die Zertifikate auch immer mal wieder Aktualisieren muss!
-
@dekat win mag sein das es nicht mehr ganz zum ui passt wobei alle wichtigen infos vorhanden sind.
-
So anbei noch das Script wie gesagt fehlt mir jetzt noch die Daten in HA zu bekommen werde aber auf MQTT gehen müssen. Aber Grundsätzlich wird das Device gefunden.
Ist halt erst mal nur grob hingeknallt 🤣
Code
Alles anzeigenlet CONFIG = { room: "Büro", prefix: "presence", topic: "/presence", rssiPresent: -40, rssiNotPresent: -99, mfdID: 0x004c, handoff: 0x0c, nearby: 0x10, phone: 0x0e, watch: 0x0f, handoffActive: true, debug: true }; let DeviceParser = { getData: function (res) { if (res === null) return null; let rssi = null; let data = BLE.GAP.ParseManufacturerData(res.advData); packedStruct.setBuffer(data); let device = packedStruct.unpack('<HB>BB', ['mfdID', 'data0', 'data1', 'data2']); if (device.mfdID !== CONFIG.mfdID) return null; if (device.data0 === CONFIG.nearby) return null; if (device.data0 === CONFIG.handoff && CONFIG.handoffActive === true){ rssi = Math.max(res.rssi, rssi); if (CONFIG.debug === true) { print ("Found Apple boradcast for handoff"); print ("mac=",res.addr,"; rssi=",res.rssi); } } if (device.data2 === CONFIG.watch){ rssi = Math.max(res.rssi, rssi); if (CONFIG.debug === true) { print ("Found Apple Watch"); print ("mac=",res.addr,"; ac=",device.data2,"; rssi=",res.rssi); } } if (device.data2 === CONFIG.phone){ rssi = Math.max(res.rssi, rssi); if (CONFIG.debug === true) { print ("Found iPhone"); print ("mac=",res.addr,"; ac=",device.data2,"; rssi=",res.rssi); } } if (rssi === null) return null; let rm = { addr: res.addr, rssi: res.rssi }; return rm; }, }; function scanCB(ev, res) { if (ev !== BLE.Scanner.SCAN_RESULT) return; let presence = DeviceParser.getData(res); if (presence === null) return; presence.presence = true; presence.room = CONFIG.room; print (JSON.stringify(presence)); if (presence.rssi > CONFIG.rssiPresent){ //presence.presence = true; //Shelly.emitEvent("ble_presence", presence); if (CONFIG.debug === true) { print("present", JSON.stringify(presence)); } } else if (presence.rssi < CONFIG.rssiNotPresent){ //presence.presence = false; //Shelly.emitEvent("ble_presence", presence); if (CONFIG.debug === true) { print("not_present", JSON.stringify(presence)); } } } BLE.Scanner.Start({ duration_ms: BLE.Scanner.INFINITE_SCAN, active: true, interval_ms: 1200, window_ms: 50 }, scanCB); let packedStruct = { buffer: '', setBuffer: function(buffer) { this.buffer = buffer; }, utoi: function(u16) { return (u16 & 0x8000) ? u16 - 0x10000 : u16; }, getUInt8: function() { return this.buffer.at(0) }, getInt8: function() { let int = this.getUInt8(); if(int & 0x80) int = int - 0x100; return int; }, getUInt16LE: function() { return 0xffff & (this.buffer.at(1) << 8 | this.buffer.at(0)); }, getInt16LE: function() { return this.utoi(this.getUInt16LE()); }, getUInt16BE: function() { return 0xffff & (this.buffer.at(0) << 8 | this.buffer.at(1)); }, getInt16BE: function() { return this.utoi(this.getUInt16BE(this.buffer)); }, unpack: function(fmt, keyArr) { let b = '<>!'; let le = fmt[0] === '<'; if(b.indexOf(fmt[0]) >= 0) { fmt = fmt.slice(1); } let pos = 0; let jmp; let bufFn; let res = {}; while(pos<fmt.length && pos<keyArr.length && this.buffer.length > 0) { jmp = 0; bufFn = null; if(fmt[pos] === 'b' || fmt[pos] === 'B') jmp = 1; if(fmt[pos] === 'h' || fmt[pos] === 'H') jmp = 2; if(fmt[pos] === 'b') { res[keyArr[pos]] = this.getInt8(); } else if(fmt[pos] === 'B') { res[keyArr[pos]] = this.getUInt8(); } else if(fmt[pos] === 'h') { res[keyArr[pos]] = le ? this.getInt16LE() : this.getInt16BE(); } else if(fmt[pos] === 'H') { res[keyArr[pos]] = le ? this.getUInt16LE() : this.getUInt16BE(); } this.buffer = this.buffer.slice(jmp); pos++; } return res; } }; -
Verwendest du ein Addon?
Hatte ich auch hatte alles angeschlossen auch den AddOn. Hatte dann noch die 0.9. irgendwas drauf. Hab Update gemacht. AddOn aktiviert und es ging irgendwie nichts.
Nach einem Werksreset lies sich alles richtig konfigurieren und läuft nun.
-
In der offiziellen Dokumentation ist eigentlich alles zu finden.
https://shelly-api-docs.shelly.cloud/gen2/General/S…oundConnections
-
Samsung habe ich leider nicht, beim iPhone ist es auch nicht so simpel aber es funktioniert. Kann mal das Script raussuchen und mal posten. Bin aktuell noch daran ohne MQTT die Daten in HomeAssistant für weitere auswärtung zu bekommen. Was über den Shelly.Call leider nicht möglich ist da der Bearer zu lang ist.
-
Bei den Plus Geräten lässt sich sowas über BLE realisieren. Dort muss man dann etwas mit dem rssi spielen.
-
dadurch defekte übermittlung oder abbrüche, die die TRV config beschädigen.
?? Wie soll denn das bitte gehen?
-
Ist halt wirklich immer auch die Frage die schreiben was von Silabs chips oder so. Kann durchaus sein das es da ein bekanntes Problem mit irgendwelchen Wlan Chips oder so gibt die AVM einsetzt.
Und da können sich jetzt beide gegenseitig den Schwarzen Peter zuschieben wie Sie möchten und nervt am Schluss nur den Endverbraucher.
Aber zumindest sollte der TRV so Intelligent sein das er dann ab nem gewissen Punkt entweder einen AP aufmacht oder Neustart durchführt und nicht irgendwo fest hängt.
Auch wenn ich hier dann doch in gewisser hinsicht schon darauf Tendiere das der Auslöser nicht der TRV bzw. die TRV Firmware ist. Sonst hätte das problem auch wirklich jeder.