Beiträge von eiche

Am besten gelingt das Cloud unabhängig. Ich nutze für solche Dinge Node-RED, InfluxDB (zeitbasiertes Datenbanksystem) und Grafana zur grafischen Darstellung. Diese Kombination ist der Cloud-Aufzeichnung um Klassen überlegen.

s.a. meine Signatur

Wenn der Plug S zu warm wird, dann liegt das bestimmt nicht am Verbraucher, weil im Plug S ein herkömmliches Relais schaltet. Dann täte ich mal die Umgebung des Plug S unter die Lupe nehmen und ggf. versuchen, vorsichtig das Gehäuse des Plug S zu öffnen. Hilfreich wäre es auch, den Temperaturverlauf des Chip aufzuzeichnen, um diesen analysieren zu können.

Jo, bspw. mit einem Ruuvi Sensor und einem Skript. Ein geeignetes Skript hat ein früheres, hier leider nicht mehr mitwirkendes, Forum-Mitglied geschrieben. Ich habe derzeit keinen Ruuvi, weshalb ich das nicht implementieren kann. Die Feinheiten einer solchen Regelung müssten evtl. angepasst werden.

Danke Thomas. Alles klar MIHO

Nun warte ich auf die Schaltskizze von hemnes84 .

Frage an einen Moderator: Sollen hemnes84 und ich hier weiter kommunizieren oder per PN?

hemnes84

Ich habe ein wenig experimentiert.
Gerät: Shelly Plus 2PM, zunächst noch ohne Add-on, im Cover Modus

Die Konfiguration sieht u.a. vor, einen oder zwei Taster zur Steuerung zu verwenden. Soweit ich verstand, wird der Torantrieb ursprünglich mit einem Taster bedient. Da du bisher den Ausgang des Plus 1 PM parallel zum vorhandenen Taster geschaltet hast (richtig?) und auch der Plus 2 PM einen solchen Taster emulieren soll, sind vermutlich die Eingänge auf Schalter zu konfigurieren. Dann könnte der Schaltsensor vermutlich mit einem Shelly-Eingang verbunden werden. Sicher ist das noch nicht. Das hängt letztlich auch von der finalen Schaltung ab. Der Taster kann auch mit einem Shelly-Eingang verbunden werden, dann aber als Taster statt Schalter. Der Schaltsensor ist vermutlich als Schalter zu behandeln. Der Plus 2 PM lässt aber keine unterschiedliche Eingangskonfigurationen zu.

Gibt es einen oder zwei Schaltsensoren an deiner Anlage? Die Skizze dazu sollte vollständig sein!
Diese Steuerung lässt keine Kalibrierung des Shelly zu, weil der Shelly nicht den Motor schaltet und somit dessen Leistungsaufnahme nicht messen kann. Falls der Shelly den Motor direkt steuern könnte/sollte, könnte eine Kalibrierung möglich sein. Ich weiß aber bisher nicht, ob dies auch bei 24V Versorgung gelingen kann. Mit einer Kalibrierung kann das Tor auch teilweise geöffnet werden.

Im Skript werden Ereignisse mit Informationen verarbeitet. Diese können u.a. sein

1. Tor wird bewegt ("opening" oder "closing").
2. Eingang 0 (S1) hat sich verändert ("toggle"), Zustand geöffnet (false) oder geschlossen (true).
3. Eingang 1 (S2) siehe Eingang 0.
4. Quelle der Aktion: u.a. Eingang vs. Shelly Cloud - der Sprachassistent steuert über die Shelly Cloud.

An Hand dieser Ereignisse kann das Skript wie gewünscht arbeiten.

Hinweis: Es ist auch möglich, statt des bisherigen Tasters am Shelly zwei Schalter zu verwenden, einen zum öffnen, den anderen zum schließen des Tors.

Du wirst von mir nicht auf Anhieb ein Skript erhalten, welches bereits die gesamte Funktionalität implementiert.
Grund: Ich kann derzeit deine Umgebung nicht hinreichend nachbilden.

Bewährt hat sich aber ein schrittweises Annähern an das gewünschte Verhalten. Ich habe somit vor, dir ein anfängliches kleines Skript zur Verfügung zu stellen, dessen Ausgaben im Skriptfenster unter Console du mir dann mitteilen solltest. Auf Grund solches Ausgaben kann ich dann das Skript weiterentwickeln. Abhängig von deiner zeitlichen Investition und meiner Freiheit/Muße kann das Skript innerhalb weniger Tage bis hin zu einigen Wochen in einen funktional befriedigenden Zustand wachsen.

Der Vorteil einer solchen Lösung liegt in einer Cloud unabhängigen Arbeitsweise, mit der Option, einen Sprachassistenten (Amazon Echo, Google, Apple Iris) über die Cloud nutzen zu können. Du wirst also dann deine Torsteuerung bei fehlendem Cloud-Zugriff - aus welchen Gründen auch immer - manuell nutzen und zugleich bei Cloud Verfügbarkeit den Komfort einer Bedienung per Sprachassistent genießen können. So jedenfalls der Plan.

Zunächst warte ich noch auf deine Schaltskizze, da das weitere Vorgehen eine geeignete Schaltung voraussetzt.

hemnes84

Wie thgoebel bereits schrieb, wäre für den Plus 2PM eine 24V Versorgung zu bevorzugen.

Zitat von hemnes84

komme hier aber leider nicht mehr mit

Auf konkrete Fragen könnten konkrete Antworten folgen.

Ich habe in #11 eine sehr wahrscheinlich funktionierende Lösung angeboten. Vielleicht beziehst du deine Fragen darauf. Da ich keine Garage habe, kann ich nicht letztlich von einer sicheren Lösung sprechen. Meine Programmiererfahrung, insbesondere mit den Shelly , lassen mich aber sehr zuversichtlich sein.

Ich habe nicht wirklich verstanden, was die Steuerung tut, wenn sie auf AUS geht.

Zitat von Akman75

Was kann ich beim shelly einstellen das nur kurz ein Taster Signal kommt

Du kannst in der Konfiguration des Shelly Ausgang einen Timer aktivieren und dessen Dauer einstellen, bspw. auf 1s.

In deinem Screenshot ist die LWT-Nachricht deines Shelly zu sehen - online = false. Das erscheint wenigstens merkwürdig.

In der letzten Zeile steht user_1 als Topic. D.h. der Shelly hat offenbar geantwortet - "user_1" ist dein src-Wert.

Sorry, ich sah jetzt erst, dass dein Problem gelöst ist.

Zitat von mastercheef

So, bei jeder änderung im MQTT Reiter muss das Passwort neu eingegeben werden.

mastercheef

Die kleine Analyse deiner Payload steht unten.

Ich verwende gerne ein Skript, in welchem ich sowohl Topic als auch die Nachrichtenstruktur (Payload) nach meinen Wünschen in der Subscriber Funktion festlegen kann. Du verwendest die von der Firmware bereitgestellte MQTT Kommunikation. Diese Implementation bildet eine Peer to Peer Kommunikation über den Broker nach, weshalb die Payload komplexer ist, als dies bei üblicher MQTT Kommunikation der Fall ist.

Ich habe in einem meiner Node-RED Flows mal nachgeschaut. Dies ist eine funktionierende Testnachricht.

{"id":"switch_off","src":"smartcenter","method":"Switch.Set","params":{"id":0,"on":false}}"

Die vordere id- und die src-Komponente sind ausschließlich für die Geräte zu Geräte Kommunikation erforderlich/zielführend. Beide Komponenten setzt die Shelly Firmware in ihrer Rücknachricht ein, damit der Empfänger per id erkennen kann, zu welchem Auftrag (RPC) die Rücknachricht gehört. Antwort statt "Rücknachricht" wäre kein geeigneter MQTT Begriff.

src gibt an, von welchem Gerät die Nachricht stammt. In der Rücknachricht unter dst (destination) zu finden. Der src-Wert wird in der Rücknachricht im Topic verwendet, in meinem Beispiel Topic = "smartcenter/rpc". Dies muss man wissen, wenn man die Rücknachricht empfangen und ggf. auswerten will.

id wird in der vom Empfänger gesendeten Rücknachricht als Auftrags-id eingesetzt. Sie hat nichts mit der Komponenten-id des Shelly zu tun und ist frei wählbar. An Hand dieser id kann der Empfänger der Rücknachricht erkennen, zu welchem Auftrag letztere gehört.

Ab "method" beginnt der für den Schaltauftrag entscheidende Teil der Payload. Nach der Shelly-Doku sind alle Parameter außer params.id optional. Damit müssen auch Schaltzustand und Helligkeit in einer Nachricht auf dem Shelly verarbeitet werden.

Hast du mal einen MQTT Protokollierer (MQTT Explorer bspw.) genutzt, um die Kommunikation zu beobachten?

Zitat von mastercheef

{ "id": 0, "src": "mqtt_client", "method": "Light.Set", "params": { "id": 0, "on": true, "brightness": 55 } }

Ein id-Wert (vorne) 0 ist kein String. Hier ist ein String erforderlich/vorgesehen - ob dies auch mit einer Number gelingt, habe ich allerdings nicht getestet. Der src-Wert sollte auf das Auftrag gebende Gerät hinweisen, damit es menschlich verständlich ist. "mqtt_client" erscheint mir nicht wirklich erhellend. Hier täte "Loxberry" besser passen.

Ich hoffe, nicht verwirrt und ein wenig Licht in deine Angelegenheit gebracht zu haben.

Dank an tvbshell und thgoebel .

Na, umso besser. Dann müsste sich das Addon des TE ja auch am Plus 2 PM verwenden lassen. Dann kann er einfach seinen Plus 1 PM gegen einen Plus 2 PM austauschen - wenn er noch an einer Lösung interessiert sein sollte.

hemnes84

Vermutlich gelingt die Steuerung auch mit einem einzigen Shelly Plus 2 PM - etwa wie folgt.

Wie ist die Betriebsspannung deines bisherigen Shelly Plus 1?

1. Der Tor-Schaltsensor wird an einem der beiden Switch-Eingänge genutzt, bspw. Switch:0.
2. Ein Bedienungstaster wird mit dem anderen Switch-Eingang, bspw. Switch:1, verbunden.
3. Beide Eingänge werden als detached konfiguriert.
4. Ein Skript reagiert auf die Aktionen sowohl des Schalt-Sensors als auch des Tasters.
   1. Da der Sensor den Öffnungszustand mitteilt, speichert das Skript diesen Zustand.
   2. Eine Aktion am Bedienungstaster sorgt (per Skript) für das Öffnen bzw. Schließen des Tors, abhängig vom gespeicherten Öffnungszustand.
5. Wenn eine Nachricht zu öffnen/schließen vom Sprachassistenten (bzw. dessen Cloud) eintrifft, registriert auch dies das Skript und sorgt ggf. für das Öffnen/Schließen/Nichtstun, abhängig vom Öffnungszustand.

Auf diese Weise kann das Tor manuell, per Sprachbefehl oder sonstiges gefahren werden. Ein Skript kann erheblich mehr als irgendwelche Szenen einer Cloud.

Falls du dich damit anfreunden kannst, könnte bspw. ich dir ein solches Skript schreiben. Für die elektrische Sicherheit ist es noch wichtig, wie die Teile deiner Toranlage geschaltet sind und mit welchen Spannungen diese betrieben werden. Ein Addon gibt es afaik für einen Plus 2 PM nicht.

Vielleicht kann ich dir "auf die Sprünge helfen", wenn du mir "auf die Sprünge hilfst".

Ich war hier lange nicht mehr on und weiß nicht mehr, worum es in deinem Fall geht.
Bist du mit deinem Anliegen in diesem Thread richtig?

MIHO

Deshalb habe ich den Plus 2PM in's Spiel gebracht. Dieser täte mit beiden parallel geschalteten Ausgängen den Torantrieb steuern und kann den Zustand des Schaltsensors berücksichtigen.

Ah, nun habe ich verstanden. Der Shelly emuliert somit einen einzigen Taster.

Das wird per Sprachbefehl vermutlich schwierig, wenn nicht gar unmöglich.

Per Skript und MQTT oder ein angepasstes Dashboard (ich bevorzuge Node-RED), ginge dies durchaus, weil das Skript den Schalterzustand abfragen kann.
Eine Cloud lose Lösung wäre auch aus technischen Gründen besser, die optional durch die beiden Clouds ergänzt werden kann.

Mit Cloud basierten Szenen kenne ich mich sehr wenig aus, weil ich lokale Lösungen bevorzuge.

Für den Sprachassistenten wäre eine Rollladensteuerung (bspw. per Shelly Plus 2PM) geeignet. Dein Plus 1PM könnte den Zustand des Schalters an den Plus 2PM übertragen und im Plus 2PM dann zustandsabhängig der Torantrieb gesteuert werden. Damit ließe sich auch der Sprachassistent wie gewünscht nutzen. Hierfür wäre zumindest ein Skript auf dem Plus 2PM erforderlich/zielführend. Das Skript kann die Ursache des Startens erkennen und passend reagieren. Vielleicht täte das Tor kurz ruckeln aber umgehend stehen bleiben. Das wäre meine Lösung.

Leicht off topic

Der Shelly Scanner ist wirklich sehr gut. Ich fand bisher nichts, was mir an Anzeigen fehlt. Man kann sogar so manchen Konfigurationseintrag ändern.

Im KVS und den Schedule Jobs lässt sich nichts editieren, aber das ist "nörgeln auf höchstem Niveau".

swankmueller

Der Tipp mit Shelly Scanner ist ja schonmal nützlich. Bei 50 Geräten gibt es allerdings einiges mit den Augen abzutasten.

Mit einem kleinen Skript ließe sich so etwas automatisieren. Allerdings nutze ich die Cloud/App sehr eingeschränkt und optional, weshalb ich nicht weiß, ob und ggf. wie ein Skript eine Nachricht an die Cloud senden könnte. Das folgende kleine Skript gibt nur etwas auf der Konsole des Shelly WebUI aus. Es gibt zunächst ausschließlich etwas aus. Stattdessen ließe sich auch etwas senden, an wen oder was auch immer.

let TempLimit = 30 // Temperatur Grenzwert, ab der die Temperatur angezeigt wird
Name = "Dieser Shelly",
Periode = 10000; // in ms

function getStatus() {
  Shelly.call("Cover.GetStatus", {id:0}, // Statt Cover eine passende Component nutzen!
  function(res) {
    let tC = res.temperature.tC;
    if(tC>TempLimit) print(Name + ": " +tC + "°C");
    else print("ok");
  })
}

getStatus();
Timer.set(Periode, true, getStatus); // Regelmäßig die Chip-Temperatur abfragen.

Afaik lässt sich auch eine Push Nachricht senden. Dies tat ich bisher aber noch nicht. Name, Temperatur Grenzwert und Periode lassen sich auch in den KVS eintragen und per Skript einlesen. Dann braucht nichts im Skript angepasst zu werden. Ein solches Skript kann weitgehend an die vorhandene Umgebung angepasst werden. Auch Datum und Uhrzeit ließen sich in der Nachricht einbauen.

Alternativ bieten die RPC auch die Möglichkeit, den Shelly Status abzufragen, wozu ein externes Programm zielgerichtet genutzt werden kann - bspw. ein Shell Skript.

hemnes84

Verständnisfrage:
Wozu ist es erforderlich, den aktuellen Zustand des Garagentors (offen/geschlossen) zu kennen? Wenn du es öffnen/schließen lassen willst, dann gelingt dies doch unabhängig von gegenwärtigen Zustand.

Hinweis:
Es erscheint sehr problematisch, ein Tor bewegen zu lassen, dessen Umgebung, und somit auch das Tor selbst, man nicht sehen kann. Hast du eine Versicherung, welche dies abdeckt?

I would monitor the MQTT messages, for example, with MQTT Explorer. A better approach would be to use Node-RED. In a simple flow, an MQTT subscriber node (mqtt in) can receive and count the messages. Perhaps the messages are being sent too frequently.

Zitat von haitauer

The devices are really great but the firmware is crap.

I think the firmware, especially the underlying operating system, is very good. There are always bugs because the firmware is constantly being updated. Older firmware is not an alternative.

Titty-Twister

Ich habe in #8 mein Skript in Zeile 24 korrigiert. Vermutlich ist damit die Anzeige wie gewünscht.

Im Beitrag #8 habe ich den Hinweis ergänzt.