Beiträge von eiche

Ergänzend zu den gelungenen Mitteilungen von Krauskopp eine einfachste Lösung, die auch ohne WLAN funktioniert:

Verwende weiterhin deine Wechselschaltung, schalte damit aber einen Shelly! D.h. schließe die geschaltete Leitung , welche bisher zu den Lampen geht, an den Eingang des Shelly!

Der Ausgang des Shelly muss zur Lampe führen. Dann schaltet der Shelly wie gewohnt, auch ohne WLAN, und du kannst bei WLAN Präsenz zusätzlich HTTP Nachrichten, Button 1, App, Sprachassistent, ... verwenden, um die Lampen zu schalten bzw. zu steuern.

Die Funktionen anderer Varianten mit i4, 4 Tastern ... sind immer WLAN abhängig, allerdings u.U. auch recht komfortabel. Allerdings kannst du die Bulbs ja schon jetzt per App steuern, solange diese eingeschaltet sind.

Zitat von derRob21

Verständlich?

Nicht ganz.

Bei zwei unabhängig voneinander arbeitenden Stromkreisen kann nicht ein Shelly 1 genügen.

Vermutlich funktioniert einer dieser Stromkreise noch und der andere nicht mehr.

Wenn du nur eine Schaltfunktion erneuern willst, stellt sich noch die Frage nach dem von dir bevorzugten Bewegungsmelder.

Falls du einen Shelly Motion, BLU möchte ich hierfür nicht empfehlen, nutzen möchtest, dann gelingt dein Vorhaben.

Der Motion kann bei Bewegungserkennung ... geeignete HTTP Nachrichten an den Shelly 1 senden, ohne zusätzliches Sendegerät.

Vorteile: wenig Aufwand, BWM kann frei platziert werden.

Nachteil: Muss gelegentlich per USB aufgeladen werden.

Wenn du einen Bewegungsmelder mit Schaltausgang verwenden möchtest, dann kann es damit elektrische Schwierigkeiten geben, die behoben werden könnten.

Dann brauchst du tatsächlich noch ein Gerät, bspw. einen Shelly Plus 1, der die HTTP Nachricht an den schaltenden Shelly sendet.

Vorteil: Wegen dauerhafter Versorgung ist kein Aufladen erforderlich.

Nachteile: Nicht oder mit erhöhtem Aufwand frei platzierbar. Zusätzliches Gerät zum senden erforderlich.

Die erforderlichen HTTP Nachrichten können dieser Dokumentation entnommen werden. Hilfe hierzu können bei Bedarf hier einige Mitstreiter geben.

Es bleiben noch offene Fragen nach den bisher genutzten Schaltern.

Funktionieren diese noch zwecks Schalten der Beleuchtung?

Willst du evtl. Schalter an anderer Stelle platzieren?

Vielleicht wird dann ein zusätzlicher Shelly gebraucht, an welchen solche Schalter oder Taster anzuschließen sind.

Alles klar?

Zitat von Schubbie

Nicht empfehlen würde ich jedoch unterschiedliche Bedienkonzepte durch Mischung von Tastern und Schaltern.

Das ist eine Frage der Offenheit für eine andere Handhabung seitens des TE. Wenn der TE minimal investieren will, wird er auch keinen Vergleich anstellen können. Wenn er aber bereit ist, über den gewöhnten Tellerrand hinauszublicken, einschließlich der Möglichkeit einer temporären Fehlinvestition, dann sind die Taster an einem i4 zu empfehlen. Falls diese Tasterlösung nach ca. einer oder zwei Wochen eindeutig nicht gefallen sollte, dann kann er immer noch die Taster durch die bei ihm üblichen Schalter ersetzen.

Btw, ich bin nicht der Einzige, der ihn für eine Skriptlösung unterstützen könnte.

Metzgerjo

Mir sagt der Hinweis "(- Bezug Netz)" hinter dem Label "Shelly EM" nichts.

Hast du solches hineingeschrieben oder stammt dieser Hinweis von der Cloud, bezogen auf den Gerätetyp Shelly EM?

Was bedeutet das Minus, oder soll das ein Bindestrich sein?

Dann interpretiere ich mal deine Einstellungen auf der Grundlage von Krauskopp Erklärung in #30.

1. Einschalten, wenn 5 Minuten lang mehr als 200W geleistet wird.
2. Ausschalten, wenn 5 Minuten lang mehr als -500W geleistet wird.

Die Dauer von 5 Minuten lasse ich im weiteren außen vor, weil das nicht kritisch ist.

zu 1.

Der EM soll einschalten, wenn mehr als 200W vom EVU geleistet wird.

zu 2.

Der EM soll ausschalten, wenn mehr als -500W vom EVU geleistet wird, was bedeutet P < 500W für das EVU geleistet - als Teil von dem, was von der PV kommt.

Wenn diese Interpretation stimmt, dann willst du einschalten lassen, wenn du über 200W vom EVU nimmst und ausschalten lassen, wenn deine PV weniger als 500W dem EVU gibt.

Wenn ich da keinen Denkfehler habe, dann erscheint mir das nicht zielführend.

Ich täte dann folgendes versuchen.

1. P < -500W => einschalten, weil dann mehr von der PV kommt (-600W < -500W, mathematisch, rechnerisch geordnet)
2. P > 200W => ausschalten, weil dann mehr vom EVU kommt

Hier habe ich nur die Werte mit den Vergleichsoperatoren zurechtrücken wollen. Ob dies zur Leistung des eingeschalteten Verbrauchers passt, kannst du #30 entnehmen.

Sollte "(- Bezug Netz)" bedeuten, dass negative Werte Lieferungen vom EVU sind, ergibt sich eine andere zielführende Konstellation.

1. P > 200W => einschalten
2. P < -500W => ausschalten

In beiden Fällen ist selbstverständlich die Schalthysterese von hier 200W - -500W = 700W zu beachten, die gemäß Krauskopp in #30 über der Leistung des eingeschalteten Verbrauchers liegen muss - mit Berücksichtigung einer Messtoleranz bzw. Messfehlers.

Ist das nicht der Fall, dann kann das Einschalten des Verbrauchers zum ausschalten nach 5 Minuten führen, + Zeittoleranz wegen ggf. nicht sofort übermittelter Messwerte. Dies hängt selbstverständlich von den Schaltzuständen anderer Verbraucher in deinem Haushalt ab, weshalb solches Verhalten quasi zufällig auftreten täte.

Zitat von thgoebel

Du denkst an den JTAG Test…

Ja genau. Hast du dazu Equipment und schon einmal genutzt?

Es darf vermutet werden, dass der Chip einen Pin besitzt, über welchen der Zugriff auf seine Interna, zumindest Speicher, per anderer Pins möglich wird.

Dazu müsste entweder eine klammernde Fassung aufgesetzt oder der Chip ausgelötet ... werden.

Solches möchte ich Thomas nicht wirklich zumuten.

Außerdem sind hierzu vertiefte Kenntnisse über den Chip erforderlich.

thgoebel

Da aber der enabled Status im nichtflüchtigen Speicher abgelegt sein muss, könnte dessen Lokation vielleicht gefunden und geändert werden.

Das wäre vermutlich eine Detektivarbeit und ggf. zu aufwändig, aber vielleicht nicht unmöglich.

Die Entwickler werden eine solche Arbeit nicht tun wollen, weshalb einer solchen Äußerung in ihrer Absolutheit nicht vertraut werden muss.

Ok, ich meinte die Nutzung von Tastern. Inzwischen habe ich dies in #13 ergänzt.

Ob die Nutzung von Tastern statt Schaltern bereits per Actions gelingt, müsste ich erst testen, wozu ich derzeit keine Gelegenheit habe.

Mit einem relativ kleinen und einfachen Skript geht so etwas selbstverständlich.

Falls dies per Actions gelingen kann, wären für jeden von zwei Tastern zwei Actions erforderlich, beide mit unterschiedlichen zusätzlichen und komplementären Bedingungen.

Prinzip für einen Taster zum öffnen:

Wenn kurzer Tastendruck und Rollladen derzeit öffnet => anhalten

Wenn kurzer Tastendruck und Rollladen derzeit steht => öffnen

Btw, in einer Leerdose lassen sich auf diese Weise Taster zum steuern zweier Rollladenantriebe unterbringen oder es stehen noch zwei Taster für beliebige andere Funktionen zur Verfügung. Ich halte dies für bestechend.

Zitat von ostfriese

Ihr seht, dass ist schon aufwändig

Nö

Selbstverständlich ist mir bekannt, dass du weißt, was du codest.

Ich habe deine Skripte nun nicht analysiert. Trotzdem die Fragen:

1. Ist es erforderlich, dass nach dem Booten alle Skripte zugleich gestartet werden?
2. Könnten nicht zunächst zwei Skripte laufen? Das Konfigurationsskript könnte dann beendet und stattdessen ein Skript oder mehrere andere Skripte gestartet werden. Wir beide wissen, dass du ähnliches bereits gecodet hast.

Wie du siehst, halte ich deine Einwände für (zunächst) nicht ganz überzeugend, sorry.

Zitat von Flixer

und nicht wie z.B. bei einem Taster die Wippe für runter/hoch so lange drücken will, bis die Stellung erreicht ist

Wie Schubbie bereits mitteilte, ein solange drücken, wie der Rollladen bewegt werden soll ist

1. nicht erforderlich und
2. eher unbequem und
3. weniger ergonomisch als das Anhalten per erneutem Tastendruck.

Zitat von Flixer

Das möchten wir halt gern so, weil das überall im Haus so ist.

Es ist verständlich, eine gewohnte Handhabung beibehalten zu wollen. Dann wirst du aber den Vergleich mit der reinen Tasterhandhabung nicht erleben können. Deshalb und wegen der Bedienvorteile per Taster empfehle ich so wie Schubbie auch, an einer Stelle die Taster zusammen mit einem Shelly i4 zu installieren. Vermutlich werdet ihr feststellen, dass die Tasternutzung recht intuitiv ist und evtl. diese sogar bevorzugen.

Ich kann solche Screenshots nicht gut verstehend lesen. Deshalb meine Fragen.

1. Welcher Shelly soll einschalten? Der 3 EM selbst?
2. Hast du eine Szene, die bedingt ausschaltet, wenn eingeschaltet ist?

Zitat von Schubbie

Kann man da noch ein Delay einbauen, dass der Prozessor im Fehlerfall nicht ausgelastet wäre

Ja klar. Man kann einfach einen Timer erstellen, der bspw. alle 100 ms den Status abfragt und bei Erhalt der Konfiguration den Timer löscht. Das ist sehr einfach zu implementieren.

Um es konkreter zu beantworten.

// Michaels Fehler 
while(v.endpoin === undefined){};

// Die erwähnte Timer Sequenz mit dem Schreibfehler
let Th = Timer.set(100, true, function() {
    if(v.endpoin !== undefined) Timer.clear(Th);
});

Der Timer pollt schlicht die Existenz eines gültigen Eintrags und beendet sich, wenn der Eintrag vorliegt.

Ich habe den Timer-Code noch etwas schlanker gestaltet.

... und inzwischen noch ein wenig robuster, für den Fall dass v.endpoint mit null initialisiert wurde.

Sorry, war unsinnig ...

ostfriese

Interessant. Dazu habe ich folgende Fragen/Vermutungen/Vorschläge.

1. Du speicherst die Konfiguration in einer non-executable Skript Datei? Oder vielleicht doch im KVS?
2. Warum lässt du diese nicht einfach per Aufruf get_file() in v laden und lässt dies periodisch wiederholen?
3. Hast du mal darüber nachgedacht, die Konfigurationsfdatei executable zu machen und bspw. eine Kommunikationsfunktion "get_config()" darin unterzubringen, die per Methode "Script.Eval" aufgerufen wird und einfach das Konfigurationsobjekt als Resultat liefert?
4. Alternativ zu 3. könnte das Konfigurationsskript mit seinem Start ein Event auslösen, welches vom EventHandler deines Arbeitsskripts empfangen und die übertragenen Konfigurationseinträge in v gespeichert werden.
5. Dass an entscheidenden Stellen v auf Gültigkeit geprüft werden kann und der Robustheit wegen auch sollte, versteht sich eigentlich von selbst, oder?

Trotz alledem ist das Firmware Feature wie wir wissen zumindest nicht hinreichend implementiert, was aber inzwischen müßig ist, dies wiederholend festzustellen.

In another context (Node-RED, Arduino IDE) I found this note. A workaround could be to send the following message after a reconnect.

topic: shellytype-MACaddress/online

payload: true

I haven't tested it yet.

When I reboot the Shelly via Web UI, then I immediately receive the message online false via MQTT and online true about 2 seconds later. This is probably only possible with a good WiFi connection.

The smart control app is not very reliable.

You should use the Web UI instead.

ToLa62

Ich glaube, dass die Funktion dieses Dings dokumentiert ist.

Ich nutze in diesem Zusammenhang kein Bluetooth Gerät.

Zitat von Weesee

Kann ich damit z.B. ein Script schreiben, mit dem ich den Shelly schalte, wenn ein bestimmtes Bluetooth-Gerät (z.B. Smartphone) in Reichweite kommt?

Vermutlich geht auch solches. Aber zunächst wird ein Skript benötigt, welches ein Bluetooth Gerät erkennen kann und dessen Nachrichten in das WLAN überträgt.

Es gibt auf github ein bereits dafür geeignetes Skript, in welchem man für eigene Zwecke nur den Konfigurationsteil ändern bzw. anpassen muss.

Dieses Skript macht den Shelly Plus 1 zu Gateway Bluetooth --> WLAN, aber afaik nur für ein Bluetooth Gerät. Für bspw. 3 solcher Geräte kann man das Skript dreimal speichern, anpassen und starten. Ob dies auch in einem einzigen Skript gelingt, weiß ich mangels Erfahrung nicht.

Das Skript: https://github.com/ALLTERCO/shell…ther-devices.js

Zitat von Weesee

Was bedeutet RPC in diesem Fall genau?

RPC = Remote Procedure Call ist in der Dokumentation recht ausführlich beschrieben. Wenn man das Prinzip einmal verstanden hat, ist es relativ leicht anzuwenden.

Afaik muss man zum konfigurieren eines Shelly Blu Gerätes die App verwenden. Vermutlich kann man damit auf dem Blu Gerät die gewünschten RPC eintragen.

I've read the documentation again. Then I tested LWT with a Shelly Plus Plug S. As broker I used test.mosquitto.org:1883.

When I plugged in the Shelly, after a short time of 2 or 3 seconds I received the online message with the payload "true".

When I unplugged the Shelly, after about 90 seconds I received the online message with the payload “false”.

I suspect that this will work reliably if the supply is lost.

Occasionally the value "false" was displayed when trying with an unreliable connection.

I suspect that the cause of this behavior is due to a better or worse connection and cannot be eliminated.

Btw, on my Shelly Plus Plug S the topic looks like “shellytype-MACaddress/online” without the word “status”. It should be the same in your Shelly.

Ich schaute mir die MQTT Kommunikation per Firmware noch genauer an.

Wenn man in der MQTT-Konfiguration das Prefix ändert, dann gelingt die MQTT-Kommunikation unter Verwendung dieses Prefix.

Bsp.: Prefix = "mein/prefix"

Damit lautet das Topic, mit welchem man einen RPC Kanal des Shelly nutzen kann "mein/prefix/rpc"

Die Antwort des Shelly beinhaltet in der Payload als "src"-Wert trotzdem den von der Firmware vorgegebenen Prefix, welcher mit der MQTT Client Id übereinstimmt.

Dies tut er auch dann noch, wenn man diese Client Id ändert. Man kann somit den "src"-Wert in einer MQTT-Antwort nicht ändern. Dies erscheint mir als nicht konsequent.

Das muss dich nicht weiter stören, es kann aber verwirren, wenn man mit diesen Konfigurationseinträgen experimentiert.