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.
Wie thgoebel bereits schrieb, wäre für den Plus 2PM eine 24V Versorgung zu bevorzugen.
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.
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.
So, bei jeder änderung im MQTT Reiter muss das Passwort neu eingegeben werden.
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?
{ "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.
Vermutlich gelingt die Steuerung auch mit einem einzigen Shelly Plus 2 PM - etwa wie folgt.
Wie ist die Betriebsspannung deines bisherigen Shelly Plus 1?
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?
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".
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.
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.
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.
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.
Ich habe den Hinweis auf die Zeiteinstellung ja nicht so ernst gemeint, weshalb ich ein Augenzwinkern dazu setzte.
Weiß den einer von euch, warum der Text Netzspannung sich nicht mehr von Eingeschaltet in Ausgeschaltet ändert?
Ich werde das Skript an der betreffenden Stelle mal genauer analysieren.
Schon klar. Aber im Kommentar der Vorlage des TE steht 10s.
Deine Einschätzung meines Skriptes ist nicht ganz richtig. Mein Skript ist genau so aufgebaut wie deines zu Anfang. Es arbeitet asynchron, d.h. das Eintreffen der Infos vom anderen Shelly wird nicht abgewartet. Ich kann dies aber leicht per Timer einbauen. Das Skript von towiat hingegen arbeitet synchron, weil die Verarbeitung der Infos in der inneren Callback Funktion stattfindet.
towiat's Skript: RPC -> callback -> RPC -> callback (hierin werden beide Infos verarbeitet)
Wenn du towiat's Skript verständlich finden solltest, ist seines im Zweifelsfall die technisch etwas bessere Lösung.
Und an euch beide: 10 s sind 10000 ms und nicht etwa 6000 ms.
Es gibt auch Sonderregelungen und Ausnahmen von der Impressumspflicht. So sind beispielsweise rein private Webseiten, die keinerlei geschäftsmäßige Absichten verfolgen, in der Regel von der Impressumspflicht ausgenommen.
Gefunden unter Impressumspflicht für Webseiten: Regelungen und Beispiele - RECHTECHECK.DE
Um solche Webseiten handelt es sich bei mir. Auch las ich an verschiedenen Stellen, dass die Impressumspflicht zum Verbraucherschutz beitragen solle. Es gibt bei mir nicht einen einzigen Verbraucher, da ich hier ausschließlich Informationen zur Verfügung stelle, die für Interessierte gedacht sind und ich keinerlei Einnahmen damit erziele - im Gegenteil, diese Webseiten kosten mich monatlich ca. 13€. Ich trage damit also Verluste. Bekannterweise gibt es in diesem Forum auch einschlägige Geschäftsinteressen, was in vielen Fällen, so auch bei mir, in keiner Weise gegeben ist. Mehr Unkommerzionalität kann ich mir nicht vorstellen. Wenn ich gleich eine Art Impressum beifüge, dann keinesfalls mit meiner Adresse oder gar Email-Adresse und Telefonnummer.
Ich beschäftige mich bereits seit ca. 1994 mit dem WWW und veröffentlichte Webseiten, alle ohne geschäftliche Zwecke. Damals schrieb ich meine Email-Adresse noch hinein, woraufhin ich Jahre später massenhafte Spam-Mails erhielt und mich gezwungen sah, meine Email-Adresse zu ändern. Man muss mir also nicht von WWW bezogen relativ unerfahrener Seite kommen und etwas vom Pferd erzählen. 
Eine Real Time Clock mit Batteriepufferung wäre ja bereits eine zielführende Erweiterung. Damit sollte ein solcher Shelly auch ohne permanenten Zeitserverzugang auskommen - für den Zeitstempel.
Überzeugende Kombination, im Shelly vermutlich weniger wahrscheinlich - oder?
