ZitatOur weather stations can only upload data to Weather Underground (WU) and WeatherCloud (WC) via wifi and then view the data on WU and WC or on an app.
Immer der gleiche ärgerliche Mist. Vendor-lockin pur ![]()
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.
ZitatOur weather stations can only upload data to Weather Underground (WU) and WeatherCloud (WC) via wifi and then view the data on WU and WC or on an app.
Immer der gleiche ärgerliche Mist. Vendor-lockin pur ![]()
Ja, das ist auch meine Beobachtung bezüglich Skripting - siehe #34
Bei 1.7.0-beta1/2 führt dies sogar zu Abstürzen - diesen Bug habe ich bereits gemeldet.
There is a length restriction for the output lines. The lines are then wrapped accordingly.
In addition: The console output only has a limited buffer to print things. Therefore, they are sometimes cut off.
Have a look here for a workaround:
Einspeisung ist dank Selbstanpassung eines der Speicher sehr gering (~0,1 kW pro Tag).
Dann wundert mich auch nicht mehr, warum bei dir die Werte halbwegs passend sind.
Gute Anregung - reiche ich mal witer.
Bisher gibt es nur das hier - müsste auch mal aktualisiert werden
:
Das stimmt zwar, aber was nutzen mir die falschen Zahlen?
Es ist der Kleine (mini) und der Schaltplan widerspricht eigentlich der Aussage "nicht SELV konform", oder liege ich hier falsch?
Nein, der Schaltplan ist korrekt, aber das ist elektrotechnisch etwa knifflig:
Wichtig: Für Anwendungen bei denen SELV verpflichtend ist, darf der Mini nicht verwendet werden.
Warum dann Angabe der DC-Schaltleistung? - DC schalten ist technisch möglich, aber mit Einschränkungen:
Das Relais selbst kann rein mechanisch/technisch auch DC schalten - dafür wird die DC-Schaltleistung angegeben (z.B. 30V DC bei 5A).
Das bedeutet nicht, dass man es sicher in einer SELV-konformen Installation verwenden darf, sondern nur, dass das Relais mit DC funktioniert, wenn man die Schutzmaßnahmen und Umgebung entsprechend einhält:
Eine 30 V-DC-Schaltung kann man damit steuern: Du musst nur sicherstellen, dass die DC-Seite nicht von Netzspannung beeinflusst werden kann.
Fazit:
Wenn du mit dem Mini einen Schalter betätigst / "simulierst", der für 5V ausgelegt ist und den ein Mensch anfassen kann (kann man von SELV ausgehen) ist es nicht zulässig den Shelly Mini mit 230 V zu betreiben.
Ich habe leider keinen Plug zur Hand, deshalb kann ich hier nichts ausprobieren.
Möglicherweise geht es auch nicht über Switch.SetConfig sondern über PLUGS_UI.SetConfig:
https://shelly-api-docs.shelly.cloud/gen2/Devices/Gen3/ShellyPlugSG3
Müsste man testen:
in der ich geschildert und dokumentiert habe, dass der Shelly 2PM im Cover-Modus mit der 1.6.2 nach einiger Zeit in Unbedienbarkeit versinkt.
Einfach so oder wenn Skripts laufen?
Edit: Okay, verstanden. Das ist ein Script, damit ich die BLE-Adresse auslesen kann.
Genau. Den Code für den Farbwechsel musst du noch ergänzen: Das kannst du aber vermutlich einfach aus deinem Skript übernehmen.
Müsste ungefähr so gehen (kopiert & ungetestet
) :
// Shelly Plug S Script: Ändere LED-Farbe je nach Tür-/Fensterstatus (Shelly BLU Door/Window)
let bleDeviceMac = "AA:BB:CC:DD:EE:FF"; // MAC-Adresse vom Shelly BLU Door/Window Sensor
let lastState = null;
// Funktion: LED-Ring Farbe setzen
function setLedColor(r, g, b) {
Shelly.call("Switch.SetConfig", {
id: 0,
config: {
led_status: {
mode: "switch",
color_on: { r: r, g: g, b: b },
color_off: { r: 0, g: 0, b: 0 }
}
}
});
}
// BLE-Advertisement verarbeiten
function bleCallback(event, res) {
if (event !== 2) {
return;
}
if (!res.addr || res.addr !== bleDeviceMac) return;
let adv = res.adv;
if (!adv || !adv.service_data) return;
let sd = adv.service_data["fcd2"]; // Shelly BLU Vendor Service UUID
if (!sd) return;
let doorState = sd[0] & 0x01 ? "open" : "closed";
if (doorState !== lastState) {
lastState = doorState;
print("Türstatus:", doorState);
if (doorState === "open") {
// LED: Rot
setLedColor(255, 0, 0);
} else {
// LED: Grün
setLedColor(0, 255, 0);
}
}
}
BLE.Scanner.Start({duration_ms: BLE.Scanner.INFINITE_SCAN});
BLE.Scanner.subscribe(bleCallback);
Alles anzeigen
Deine Zahlen sind 1.8.0, sprich Verbrauch, nehme ich an? Speist du nie was ein, weil du alles selbst verbrauchst (ggf. Batterie)?
Dabei hat der Shelly 3EM-3CT63 bei beengten Einbauverhältnissen den großen Vorteil, dass die Klötzer durch ein gut durchdachtes Drei-Loch-Element ersetzt wurden
Das ist in der Tat sehr nützlich.
Nun teilt mir der Anker-Service mit, das die 3CT63-Variante mit der SOLIX Solarbank 3 Pro nicht kompatibel ist.
Meine Fragen sind:
- Trifft diese Aussage zu?
- Falls JA, was ist der entscheidende Unterschied?
Leider trifft diese Aussage zu wie auch schon einige andere Nutzer hier berichtet haben.
Anker pflegt in ihrer Integration eine Liste der kompatiblen Geräte: Hier steht war die Geräte-ID des "Pro 3EM-120" drin, aber nicht die des "Pro 3EM-3CT63".
Jedes Shelly Gerät hat eine eigenständige Produkt-Kennung / Geräte-ID, welche die Geräte für die Shelly Cloud und das Provisionieren (Wandler-Einstellungen etc.) unterscheidbar macht.
Die beiden Shellys sind technisch identisch, weshalb es für Anker ein leichtes sein müsste, auch beide zu unterstützen. Aber Anker zieht es leider vor, hier Shelly den schwarzen Peter zuzuschieben. Anker meint, Shelly könnte für 2 "logisch" unterschiedliche Geräte doch einfach die gleiche Kennung zu nutzen.
Das kann man jetzt kontrovers diskutieren, hilft den betroffenen Nutzer so wie dir nur leider sehr wenig. Aus meiner Sicht wäre es für Anker sehr leicht, einfach eine 2. Geräte-ID zu erlauben. Bei Shelly wäre der Aufwand durchaus größer und auch nicht nachvollziehbar.
Was dir bleibt ist den Anker Support "zu nerven", je mehr Leute dort meckern, desto besser.
Hier kannst du ein wenig weiter lesen:
und
Erstmal Herzlich willkommen bei uns im Forum.
Da es hier mehr um Inhalt als Vorstellung geht, verschiebe ich das mal in den passenden Bereich
Im Grunde drehen sich gefühlt 90% der Artikel um die gleiche Problematik.
Mal auf die schnelle 2 Artikel rausgesucht: Hoffe die Erklärungen helfen dir weiter.
Kurzfassung BLE Scanner Code: device.addr ist die BLE MAC des Shelly BLU
function bleCallback(event, device) {
if (event !== 2) {
return;
}
print (device.addr + " " + device.rssi + " " + device.local_name);
}
BLE.Scanner.Start({duration_ms: BLE.Scanner.INFINITE_SCAN});
BLE.Scanner.subscribe(bleCallback);
Mit Beta-Firmware 1.7.0-beta2 könntest du den BLU auch als BTHome Komponente verbinden. Möglicherweise erleichtert das deinen Anwendungsfall.
Achtung / Wichtig: Es gibt KEIN zurück zur Standard Firmware, da die mit dem Shelly ausgelieferte Fabrik-Firmware aktuell nicht via Update-Server als Downgrade verfügbar ist.
Suche -> "Saldieren" ![]()
Kurzfassung: Leistungswerte (kW) stimmen beim Shelly, Energiewerte (kWh) werden phasenbezogen addiert, nicht saldiert und stimmen daher nicht mit dem Zähler vom MSB überein.
Was mach ich falsch
Nochmal: Es liegt nicht an dir.
1. Saldiert Shelly nicht,
2. ist das PV Dashboard eine Alpha und hat noch Bugs.
Gleiches bzgl. Bugs gilt auch für die Echtzeit Übersicht: da ist bei Einspeisung z.B. "Verbrauch nach Gerätetyp: Unbekannt" falsch berechnet.
Haben die beim Saldieren ein Vorzeichenfehler?
Nein: Shelly addiert phasenbezogen, ein Stromzähler vom MSB saldiert (d.h. verrechnet Bezug & Erzeugung über alle Phasen direkt) - das sind 2 gänzlich verschiedene Verfahren mit entsprechend unterschiedlichem Ergebnis.
Have you read and understood the linked example?
Pls. try this as a starting point to find the BLE mac of your Beacon device: