Vermutlich ist der Eingangs-Laststrom für den Bewegungsmelder-Ausgang zu schwach.
Hast du mal einen Widerstand als Grundlast parallel zum Shelly-Eingang geschaltet?
Das hätte den Vorteil, dass keine Induktivität geschaltet würde.
Vermutlich ist der Eingangs-Laststrom für den Bewegungsmelder-Ausgang zu schwach.
Hast du mal einen Widerstand als Grundlast parallel zum Shelly-Eingang geschaltet?
Das hätte den Vorteil, dass keine Induktivität geschaltet würde.
Alles klar erst einmal. ![]()
Hast du die Schaltung vorher ohne Schütz getestet?
Wo lag ggf. damit das Problem?
Ich würde erwarten, dass ein Bewegungsmelder an einem Shelly-Eingang funktionieren sollte, kenne aber die Ausgangsschaltung des Bewegungsmelders nicht.
Vielleicht könnte auch eine Triac-Schaltung helfen.
Ein "Eingangsschaltstatus" sollte ein Zustand sein, unabhängig von irgendeiner Vorgeschichte. Wenn er von einer Historie abhängt, ist das schlicht eine Sch... Einrichtung.
Das hilft nun zwar nicht weiter, könnte aber ein Wegweiser zur Abhilfe sein.
ZitatVorher hatte ich den Bewegungsmelder einfach parallel zum Ausgang des Shelly geschaltet. Das hat ohne Probleme funktioniert, ist aber so garnicht Smart.
Wieso ist deine vorherige Schaltung nicht smart? Der Bewegungsmelder schaltet und du kannst den Shelly smart schalten. Hm ...
Das Schütz schaltet potentialfrei, sollte somit kein Problem sein.
Hast du im Shelly einen Timer aktiviert?
Ich habe einige Shellies aber keinen solchen.
Ja! ![]()
Mal im Ernst. Du willst ein Tor, aus welchen Gründen auch immer, per Cloud steuern?
Das ist etwas für (ungeübte) Seiltänzer.
Geht das nicht direkt am Shelly - ohne Cloud? Ich habe deine Konstellation nicht, vermute aber stark, dass dies ohne Zusätze wie Cloud ... möglich ist.
Und dann ... welchen Shelly hast du verbaut und wie angeschlossen?
Es braucht wohl genauere Infos von dir.
Ungetestet:
Scheduler nutzen, siehe https://github.com/mongoose-os-libs/cron, Schedule Job mit Methode Script.Eval
Kleines Skript dazu, welches die vom Scheduler aufzurufende Funktion enthält, die dann das veranlasst, was gewünscht ist.
Ich verstehe den Sinn deiner Zusammenstellung nicht.
Du lässt einen Bewegungsmelder einen Shelly schalten, damit Letzterer schaltet? Wozu?
Und dann ... Welcher Shelly? Welche Einstellungen? Schaltskizze?
Ok, die Shellies haben den Vorteil, dass für deren Betrieb kein Netzteil erforderlich ist. Evtl. kenn hier jemand sehr kleine Schaltnetzteile, möglichst mit Potentialtrennung. Vermutlich geht dies sehr klein mit Potentialtrennung nicht.
Vielleicht könnten sehr kleine Thyristoren (statt Relais) zur Ansteuerung der Eingänge eingesetzt werden, evtl. mit eingangsseitigen Optokopplern.
Hierzu können die "Elektroniker" DIYROLLY , thgoebel oder andere hoffentlich etwas sagen. Meine aktive Elektronikzeit liegt dafür zu weit zurück.
Ich täte jedenfalls für deine Zwecke nach Optokopplern mit Thyristoren/Triacs recherchieren.
Ich hole mal etwas aus.
Rein schaltungstechnisch täte ich eine Gruppe von 2 bis 64 (oder mehr
) solcher Eingänge mit Niedrigspannung und Multiplexer bzw. Demultiplexer und einem ESP 32 Board und Tasmota32 zusammenstellen. Statt Tasmota32 zu nutzen, kann man auch direkt in C++ programmieren, s. Arduino.
Die Eingänge können per Polling in einer Endlosschleife abgefragt werden. Auch eine sog. Interrupt-Steuerung statt Polling ist möglich.
A B E R ...
Die Fragen sind:
Energie sparend wäre der Einsatz eines einzigen Mikrocontrollers für alle Fenster ... ![]()
Gruß
Gerhard
Edit:
Ich sehe bisher nicht, wie die Eingänge des AddOn beschaltet sind. Und nein, das AddOn ist dafür eher nicht erforderlich. Das Hauptproblem ist eher die Netzspannung.
Ich setze i4 110V bis 240V ein, zusammen mit den 4fach Tastern. Nach Schaltplan werden die Eingänge dieses i4 mit Netzspannung geschaltet, es liegt somit 230V an - nicht potentialfrei.
Du könntest einen UNI prüfen oder einen Shelly Plus 1 mit AddOn. Mit letzterem habe ich ausschließlich Erfahrung mit Temperatur- und Luftfeuchtigkeitsmessung.
Ich will mal nachschauen, wie das AddOn für deinen Zweck nutzbar ist.
Entschuldige bitte mein leicht außenseiterisches Gebahren. ![]()
Ich klinke mich hier noch einmal kurz ein, weil das Problem noch nicht gelöst ist.
Eine Heizungssteuerung mit selbstständig arbeitenden Geräten ohne zusätzliches System und erst recht ohne Cloud halte ich nach wie vor für erstrebenswert. Und genau das kann die von mir oben ins Spiel gebrachte Implementation. Vielleicht ist diese doch noch einen Gedanken wert. Ich arbeite für und mit einem anderen Forumsteilnehmer an einer solchen Lösung und sie funktioniert bereits grundlegend.
Gruß
Gerhard
Es wäre gut, wenn du erst einmal zeigtest, was du bisher versucht hast. Ich nutze die i4 u.a. zur Rollladensteuerung, was gut funktioniert. Aber mein Skript ist komplexer als i.a. erforderlich.
Das Prinzip
Im Skript erfasst der Eventhandler die Tastendrücke.
Du selektierst die von dir genutzten Tasten Id (0 und 1).
Du steuerst im Eventhandler die 2.5er per HTTP.
Hallo helmi55
Etwas an deiner Frage vorbei, aber durchaus nutzbar.
Ich nutze kein fertiges übergeordnetes System, kann dazu somit nichts schreiben.
Wenn dein "ESP32" ein Shelly Plus (2. Generation) ist, gelingt das, was du anstrebst, per Skript auf dem Shelly Plus. Das hat zudem den Vorteil, dass diese Implementation autark arbeiten kann.
Wenn es sich bei dem ESP32 nicht um einen Shelly handelt, welche Firmware läuft dann auf ihm?
Falls dich diese Implementation interessiert, darfst du mich gerne per PN kontaktieren.
Gruß
Gerhard
@AlexAn Ok, ich ziehe mich zurück.
Deine Hinweise passen nicht zu meinen Bedenken.
Ich habe versucht, den TE darauf hinzuweisen, dass es mit diesem MQTT Id zukünftig Probleme geben kann.
Ein ankommendes Topic hat damit absolut nichts zu tun, da afaik der MQTT Id eines publishers den Anwender eines Shelly nicht interessieren kann.
Somit beende ich hier mein offenbar unerwünschtes Engagement und überlasse dir das Feld.
Ich mag mich irren. Afaik hat der Client Id nichts mit einem Topic zu tun sondern dient dem MQTT Broker zur Identifikation eines abonnierenden Client.
@AlexAn
in #6 sehe ich in der MQTT Konfiguration unter Client ID "shellyplus1pm". Darauf bezog ich mich. Es kann schnell baugleiche Geräte geben. Wenn der TE dann denselben Client Id wählt ...
Hello Tom,
ok that's fine. I only know of KVS as global storage, afaik there is no way to share variables script independent. I think such a global sphere don't you need.
I wish you success
best regards
Gerhard
Hallo linus40 ,
ich kenne loxberry nicht und auch nicht deinen MQTT Broker (hast du nicht mitgeteilt).
Dein MQTT Client Id gefällt mir nicht, weil es nicht sehr spezifisch ist. Besser ist hier ein Id, welcher vom Shelly bereits vorgegeben ist oder einer, den du leicht von anderen solcher Shelly Geräten unterscheiden kannst.
Schedule jobs are not very popular here. ![]()
Just look at https://shelly-api-docs.shelly.cloud/gen2/Component…rvices/Schedule and https://github.com/mongoose-os-libs/cron !
You can create such two jobs , one for sunset the other for sunrise.
Each Job calls a function in your script, which set a global variable or variables to appropriate values, which other function may use.
Of course you can implement other methods, but this method works.
Btw, the called functions may immediately process the desired behavior.
Global variables are those that are declared/defined outside of any function or object in the script. This is very basic knowledge, sorry. ![]()