Beiträge von eiche

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.

    Das müsste gehen.

    Eine Action anlegen.

    Wenn Schalter auf ein geändert wird, per URL Methode Script.Start verwenden. Angenommen die Id des Skripts ist 1.

    Code
    http://localhost/rpc/script.start?id=1

    Entsprechend, wenn der Schalter auf aus geändert wird, Skript anhalten.

    Code
    http://localhost/rpc/script.stop?id=1

    Bei Verwendung eines physikalischen Tasters ist ein zusätzliches Skript erforderlich, das bei Tastendruck den Skript 1 Zustand (running?) abfragt und diesen ändert. Das gelingt auch mit einer virtuellen Komponente.

    Allerdings wirken die üblichen Taster in der Web-UI und der App/Clloud afaik unmittelbar auf den Ausgang. Wenn du diesen Ausgang brauchst, gelingt es mit einem solchen Taster nicht. Dann bleibt ab Generation 3 ein zusätzlicher virtueller Schalter (boolean) oder Taster(button).

    Man könnte auch ein Temperatur gesteuertes Luftverteilungssystem einbauen. Ok, technisch vielleicht zu viel Aufwand, aber möglich könnte es sein.

    1. im Inneren zwei Temperatur Messstellen und
    2. ein kleiner Lüfter
    3. außen ein Shelly, welcher alles (Kompressor, Lüfter) steuert

    Am Shelly ein Add-On oder ein Plus UNI. Ich täte per Skript steuern, vermutlich gelingt es auch per Actions - aber keinesfalls per Cloud.

    Alternativ könnte ein längerer Kühlkörper zwecks Temperaturausgleich dienen, oder ein langes Alu-Blech, damit es in den Schrank passt.

    hemnes84

    Ich verstehe dich so:

    Der Magnetschalter (Endlagenschalter) hat nichts mit der bisherigen Torsteuerung zu tun?

    Wie die Torsteuerung weiss, wann der Motor aufhören soll zu arbeiten, kann ich nicht erkennen :(

    Vermutlich so, wie der Shelly Plus 2 PM im Cover Modus es tut. Dieser misst die Last (Stromaufnahme). Wenn diese deutlich ansteigt, bringt der Motor gegen den Widerstand am Anschlag ein höheres Drehmoment auf. Dann wird abgeschaltet.

    Deine Schaltung sollte passen. Ich sehe darin keinen Fehler.

    Leider ist es aber so, dass das Relais immer schaltet. Egal welchen Zustand der Magnetschalter hat.

    Ja, das kann das Skript nicht verhindern, wenn der Shelly auf eine Sprachanweisung oder die virtuellen Buttons der App/Web UI reagiert. Das Skript beendet aber den Impuls umgehend, wenn das Tor auf Grund des Magnetschalterzustandes nicht fahren soll. Der vom externen Relais gegebene Impuls sollte so kurz sein, dass die Torelektrik nicht darauf reagiert. Entscheidend ist, ob das Tor bei einem sehr kurzen Impuls gefahren wird. Das musst du feststellen. Ich kann dafür das passende Skript (Version 0.1) beisteuern.

    Die Dauer für einen wirksamen, längeren Impuls stellst du im Skript als Wert für die Variable "duration" ein. Für Testzwecke habe ich dort 2000 (ms) notiert. Diese Impulsdauer kommt nur dann zustande, wenn das Tor wirklich gefahren werden soll.

    Den kurzen Impuls solltest du mit zwei oder vielleicht nur einem Klicken der Relais hören können. Danach muss das externe Relais auf Aus stehen.

    Ist der Magnetschalter oben (bei offenem Tor geschlossen) oder unten (bei geschlossenem Tor geschlossen) montiert? Das Skript verwendet den unteren Montageort.

    Bob2000

    Option

    Zusätzlich kann man den KVS (key value storage, nichtflüchtiger Speicher) zum Eintragen des Zählerstandes zum Beginn der Shelly Plus UNI Nutzung verwenden. Ein Skript kann diesen Wert lesen und die Pulse dazuzählen. Das ist relativ einfach.

    Worüber der Shelly mit deinem übergeordneten System kommunizieren kann, musst du wissen. Möglicherweise fragt das System periodisch den Schelly nach dem Zählerstand. Ein Skript kann jedenfalls MQTT und HTTP. Ob man per Skript den Zählerstand manipulieren kann, weiß ich derzeit nicht.

    Eine Skriptlösung hätte den Vorteil, dass es auch alleinstehend betrieben werden kann, incl. Webseite per Skript generiert. Mit der USV, bspw. die von thgoebel aufgezeigte, gelingt die Abfrage sogar während eines Stromausfalls per Smartphone. ;)

    Edit:

    Maßnahme für Stromausfälle

    Man kann auch einen herkömmlichen CMOS Zähler zur Impulszählung einsetzen, welcher irgendwie Energie gepuffert ist. Dieser kann vom Shelly mit jedem Impuls rückgesetzt werden. Bei Stromausfall zählt der CMOS Zähler, bei Stromwiedereintritt und Power On Reset des Shelly holt sich das Skript seriell den Zählerstand des externen Zählers und macht weiter. Diese Lösung sollte bei Stromausfall sehr wenig Leistung aufnehmen. Ggf. ist noch ein CMOS Schieberegister erforderlich, falls der Zähler keinen seriellen Ausgang besitzt.

    Folgerichtig wäre es, wenn die Cloud-Nutzung auf reiner Kundenverantwortung beruhe.

    Die Firmware solcher Shelly für Handwerkerinstallation und Gewährleistung müssten dem Handwerker ermöglichen, jedwede Konfigurationsänderung sowie ggf. Skriptänderung zu sperren. Afaik gibt es solche Shelly derzeit nicht.

    Inzwischen habe ich auf meiner o.a. Website dokumentiert, wie man folgendes erreichen kann.

    Angenommen, man hat zwei per je einem Shelly Plus 2 PM (oder neuere Generation) gesteuerte Rollladenantriebe, typischerweise in einem Raum. Dann ist es möglich, beide per einer einzigen Zeitplanzusammenstellung (schedule job set) wie o.a. zu steuern. Das schedule job set besteht nach wie vor aus den aufgeführten Zeitplänen. In drei dieser Zeitpläne (id: 2, 4 und 5) kann man eine HTTP.GET Methode hinzufügen, welche den anderen Shelly beauftragen, dessen Rollladen zu öffnen oder zu schließen.

    Nachteil: Die Zusammenstellung der URL Komponente im Parameter ist etwas komplex.
    Mit meiner unterstützenden Webseite ist dies weniger schwierig.

    Vorteil: Man braucht nur auf einem der beiden Shelly die Zeitpläne zu konfigurieren und bei Bedarf zu ändern, was eine höhere Servicefreundlichkeit mit sich bringt. Die Zeiteinstellungen der Schedule Jobs ist mit herkömmlichen Mitteln leicht zu bewerkstelligen.

    Nun mag jemand versucht sein, anzumerken, dass er solches bereits mit Actions und dort eingetragenen URLs realisieren kann. Diese Annahme ist nicht treffend. Per Actions lassen sich bspw. beide Rollläden gleich steuern, was folgendes bedeutet.

    Wird der "Master"-Rollladen geöffnet/geschlossen, tut dies dann immer auch der "Slave"-Rollladen. Die Flexibilität der getrennten Steuerung geht mit solchen Actions verloren.

    Meine Zeitplansteuerung greift ausschließlich in den Zeitplänen auf beide Rollläden zugleich zu. Die individuelle Flexibilität der Rollladensteuerung bleibt erhalten.

    In diesem Zusammenhang wäre folgende bisher nicht vorhandene RPC-Methode wünschenswert:

    Name: "Schedule.AddMethod", Parameter: Id des Jobs, zusätzliche Methode

    Die Wunschliste ließe sich fortsetzen, etwa so:

    Methodenname: "Schedule.DeleteMethod", Parameter: Id des Jobs, Index des Eintrags in "call"

    Methodenname: "Schedule.UpdateMethod", Parameter: Id des Jobs, Index des Eintrags in "call", {"method":<neue Methode>,"params":<Parameter>}

    tvbshelly

    Von dort bezog ich die noch weitestgehenden Informationen. Was ein retained bei einer LWT bewirkt, weiß ich noch nicht genau. Dazu fand ich nichts. Ich kann somit nur vermuten, dass diese Nachricht bleibt, wenn sich der Client erneut mit dem Broker verbindet, ohne eine LWT mitzuteilen. Die LWT muss nativ bereits gespeichert sein, andernfalls täte dieser Mechanismus nicht funktionieren.

    Dem Broker sind die Inhalte von MQTT Nachrichten völlig wurscht, er muss nur "wissen", wann er eine LWT Nachricht an Subscriber senden soll/muss.

    Leider muss ich mich hier mal selbst zitieren.

    Das trifft auf die LWT-Nachrichten nicht zu.

    Meine Aussage bezieht sich unmissverständlich auf die Inhalte.

    Jo_Be Deine Aussage widerspricht diesem. Ich weiß nicht, warum du hier klugscheißt und absolut nichts Konstruktives an dieser Stelle beiträgst. Falls du in meinen Beiträgen nach Krümeln suchen solltest, empfehle ich dir, dies sein zu lassen. :cursing:

    Das trifft auf die LWT-Nachrichten nicht zu.

    Seit wann?

    Wenn ich die betreffende Firmware selbst programmiere, incl. MQTT Kommunikation, kann ich die LWT Nachricht selbst festlegen, d.h. deren Topic und deren Payload. Der Broker muss einzig wissen, dass es sich um die LWT Nachricht des Clients handelt, dessen MQTT Id der Broker registriert hat.

    Den Inhalt der LWT Nachricht hat den Broker nichts anzugehen.