Beiträge von eiche

Korrektur

Die per Shelly Generation 3 vom System gesendete MQTT Nachricht für Sensordaten:

• Topic: <Shelly Pretopic>/events/rpc
• Payload - ein Objekt
  • bthomesensor:<id> - der Schlüssel zum nachfolgenden Objekt
    • id: <id>
    • last_updated_ts: <timestamp>
    • value: <Sensorwert>

Hinweis

Ich nutze Node-RED und kann damit über ein Workaround per Stringverarbeitung, was suboptimal ist, aus der Payload den Schlüssel "bthomesensor:xxx" in "bthomesensor" transformieren. Ich kenne derzeit keine andere Möglichkeit.

Ich verstehe absolut nicht, warum im Schlüssel die id enthalten ist. Das ist in anderen Components auch so. Dies ist redundant, weil im dazugehörigen Wert (ein Objekt) noch einmal die id enthalten ist. Aber das ist ein anderes Thema.

Nun weiß ich allerdings noch immer nicht, wie ich diese Daten per RPC abfragen kann.

Auch täte ich diese gerne in eine Action packen, bspw. um diese einer Skriptfunktion als Parameter zu übergeben.

Ein Eventhandler bekommt von den BLU Daten leider nicht mitgeteilt.

???

Heureka, ich glaube, es gefunden zu haben ...

In der MQTT Konfiguration "Generic status update over MQTT" aktivieren.

Dann kommen mit anderen Id die Werte, der Rest ist Selektion.

Ich gab wohl hier mal bereits nach 2h vorläufig auf, was ich sonst sehr selten tue.

Also zunächst Problem gelöst.

Ich experimentiere mit Shelly BLU Geräten. Ich nutze die Web UI der Shelly Geräte. Auf einem Shelly 1 Gen 3 habe ich unter Components u.a. den Shelly BLU H&T hinzugefügt. Die Web UI zeigt mir brav gemessene Werte (Temperatur, rel. Luftfeuchtigkeit) an. Diese Werte möchte ich ohne Cloud übertragen lassen.

Ziel: Ereignisse, auch denen der BLU Geräte, per Topic <Shelly Pretopic>/events/rpc mit Nutzdaten per MQTT empfangen

Das gelingt mir bisher: Ich erhalte MQTT Nachrichten, in denen folgendes enthalten ist - am Beispiel BLU H&T:

• Im Payload Objekt:
  • params.bthomedevice:200
    • id: 200
    • last_updated_ts: <Zeitstempel>
    • packet_id: <laufende Nummer>
    • rssi: ...

Damit kann ich für mein Ziel nichts anfangen. Ich konnte bisher nicht herausfinden, wie ich per Shelly Gen 3 die Nutzdaten übertragen bekomme. Auch per Action gelingt mir das noch nicht, auch nicht, wenn ich per Methode Script.Eval eine Skriptfunktion aufrufen lasse. Ich weiß schlicht nicht, wie ich an die Daten herankomme. Per Eventhandler (Skript) gelingt mir das auch nicht.

Frage: Wie gelange ich an die Daten eines BLU Gerätes zwecks Übertragung, ob per MQTT oder HTTP?

Dann möchte ich ergänzen.,dass (Shelly) BLU Geräte Nachrichten von einem skriptfähigen Shelly, wie Plus 1 oder Plus Uni oder ..., per Auswahl aus bereits vorhandener Skripten verarbeitet werden können. Alle diese Skripte, wovon man nur ein oder zwei braucht, müssen für eigene Zwecke angepasst werden.

Btw, Michael (Nickname: ostfriese) hat mal ein Skript für Ruuvi Sensoren erstellt, welches eine komfortable Weboberfläche und darüber Einstellmöglichkeiten bietet. Die Ruuvi sind erheblich genauer kalibriert - Michael sprach gar von "geeicht", als die Shelly BLU Sensoren.

Das sei nur der Information wegen mitgeteilt.

Wer vorgegebenen Shelly Konsumstandard nutzen will, muss, wie horkatz feststellte, die Cloud mit deren eingeschränkten Möglichkeiten nutzen.

funkenwerner

Sorry, ich habe länger an meinem letzten Beitrag gesessen und erst jetzt deinen gesehen.

smrthme

Das Zitat von mir interpretierst du vermutlich als Belehrung. Wer den kompletten Punkt 1 liest, dem sollte klar werden, dass ich versucht habe, deinen Text als nicht verständlich zu erklären und nur zu diesem Zweck das von dir Gemeinte hinzugefügt.

Zitat von smrthme

Das lässt dir aber auch gar keine Ruhe ... oder?

Vermutlich kannst du dir nicht vorstellen, wieviel Geduld ich aufbringe, um dir etwas zu verdeutlichen.

COM = common = gemeinsamer Anschluss, der mal entweder mit NC oder mit NO verbunden ist.

NO = normally open = in Ruhestellung (= stabiler Zustand bzw. nicht hineingedrückt) ist dieser Anschluss nicht mit COM (oder C) verbunden.

NC = normally closed = in Ruhestellung (= stabiler Zustand bzw. nicht hineingedrückt) ist dieser Anschluss mit COM (oder C) verbunden.

Zitat von smrthme

Ergo müssen rein logisch die beiden mit NC bei OFF verbunden sein, egal was das heißt

Mir ist diese Aussage völlig unklar, und schon gar nicht mit Logik behaftet.

Welche "beiden mit NC" sind gemeint? Taster und Schalter? Wenn ja, ist deine Schaltung mit diesen beiden von dir noch immer nicht dargelegt. Oder habe ich etwas übersehen?

Ich habe vorsichtshalber noch einmal deine Beiträge in diesem Thread gelesen und finde keine Klarheit.

Beispiel:

Zitat

• "NO an den zweiten Eingang des Shelly" => falls du damit INT(2) meintest stimmt das - das kann man da aber nur reinlesen, nicht rauslesen.

Man kann sehr wohl den Zustand an einem solchen Eingang abfragen.

Ich bin kurz davor, endgültig aufzugeben.

Na dann los! So wie ich es oben beschrieben habe.

Wenn der Magnetschalter auch eine NC Klemme hat, dann klemme dessen C (bzw. COM) an Analog In!

NO an GND und NC an Vcc oder umgekehrt.

Offene analoge Eingänge sind für Messungen schlecht. Also soll der Schalter entweder High oder Low an Analog In legen.

Soweit klar?

Sollte der Schalter über nur zwei Klemmen verfügen, muss ich noch etwas prüfen.

Nachgereicht:

Mit nur zwei Schalterklemmen legst du von Vref + R1 Out einen Widerstand von bspw. 10kOhm an Analog In und den Schalter zwischen Analog In und GND. Statt Vref + R1 Out kann selbstverständlich auch Vcc verwendet werden.

Zitat von Mistral11

Ich hab N.O. und COM belegt, Könnte hier ein Fehler sein ?

Nur dann, wenn, anders als beschriftet, es sich nicht um einen Umschalter handelt.

Ansonsten kommt es zunächst nur auf eine Änderung an.

Ich will wissen, wie du den Schalter am Add-On angeschlossen hast.

Dan skizziere bitte mal, wie du den Magnetschalter am Add-On angeschlossen hast, evtl. ergänzt durch ein Foto!

smrthme

1. Du schreibst in #1:
   Es gibt immer offen bei ON und geschlossen bei ON. Gemeint ist:
   Es gibt immer offen bei NO und geschlossen bei NO.
   Auch das Gemeinte ist mir unverständlich.
2. Der Schaltplan in #47 war nie gemeint und bringt hierzu auch absolut nichts, weil dieser nichts mit deinem Anliegen zu tun hat.

3. 

   Zitat von smrthme

   Ich denke so viel Vorstellungskraft kann man erwarten dass wenn einer schreibt er legt IN1 und GND auf die beiden NO-Pins des Schalters jedermann in der Lage ist das nachzuvollziehen.

   Nein, noch immer nicht. Was soll das heißen?

   Ich versuche zu deinem Text mal einen unvollständigen Schaltplan::
   

   Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

   Darin sind die LED nicht eingezeichnet. Wie leicht erkennbar ist, sind beide Teilschaltpläne total sinnfrei.

   Nur horkatz hat einen Plan zu deinen Taster und Schalter vorgelegt, den ich hierher kopiere.

   Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

   Und ich denke, soviel Vorstellungskraft kann man erwarten, dass, wenn einer schreibt: "Schaltplan bitte!", dann ein Schaltplan gebraucht wird.

Zitat von chrishl1976

Diese 3 Rolladen würde ich gerne, wenn die Sonne zu sehr scheint

Vermutlich hat er das nur als Anlass für sein Ziel und nicht etwa als Automatismus verstanden wissen wollen.

Zitat von Mistral11

Auch hier immer der gleiche Wert ?!

Und welcher Wert wird angezeigt?

Ja, das las ich.

Meine Frage sollte sich auf ausschließlich kurze, imho intuitivere, Tastendrücke beziehen.

Damit müsste der Anwender sich nicht kurz vs. lang ... merken.

Ich habe nur das Prinzip beschrieben. Etwas zum genau nachmachen erfordert einen erheblichen Aufwand meinerseits, insbesondere dann, wenn du nichts von dem in #2 verstehst. Für solchen Aufwand habe ich derzeit keine Muße, sorry.

Wenigstens kannst du annehmen, dass mit mehr Aufwand, als es Standardmittel wie Cloud, App und Klicken erfordern, das gelingt, was du haben willst.

Vielleicht findet sich hier jemand, der dir ein Skript dazu schreibt und dir auch noch erklärt, wie du dieses installierst.

Stichwörter: Skript, HTTP Endpoint, Methode HTTP.Get mit URL

Nachgereicht: Zur Dokumentation der Shelly API

Hallo Thomas.

Hab's gelesen. Gelingt auch eine Steuerung der folgenden Art?

Button gedrückt -> hochfahren (bspw.)

Während der Fahrt derselbe Button gedrückt -> stop

Zitat von Hertmond

Das Problem bei deiner Lösung ist, dass wir nicht über die IP an das Thermostat kommen, nur lokal.

Das stimmt. Das habe ich nicht berücksichtigt.

Ich verwende dafür dann eben auf meinem Endgerät VPN zu mir nach Hause, was vermutlich bei euch nicht angemessen wäre.

Dann bliebe statt VPN nur dynamisches DNS und ein lokaler kleiner Server.

Oder MQTT mit einem öffentlichen MQTT Broker verwenden. Ob und wie MQTT in WordPress gelingen kann, weiß ich absolut nicht.

Edit:
Ich kenne und nutze auf meinem Android Smartphone MQTT Dash. Diese App ist zwar in die Jahre gekommen, ich fand aber bisher nichts Flexibleres. Damit gelänge die MQTT Kommunikation über einen öffentlichen Broker. Die "Kacheln" dafür sind per MQTT sehr leicht auf andere Smartphones übertragbar. Diese App gibt es aber ausschließlich für Android Systeme.

mycroft

Jemand hat kürzlich eine Lösung gesucht, per Shelly Device die Tastenkontakte seiner vorhandenen Fernbedienung zu überbrücken, um so steuern zu können. Das dürfte mit zwei Plus Uni oder einem XMod1 Entwicklungsboard gelingen - am sichersten das mit Relais.

Falls Interesse besteht, versuche ich den Link zum Thread nachzureichen.

Zitat von chrishl1976

3 Rolladen habe ich in eine Gruppe zusammengefasst.

Das ist wohl eine Cloud Gruppe. Ich kenne derzeit nur alle rauf, alle runter oder alle stop.

Alternative:

Ein Skript auf einem der Shelly, welches eine speziell zu definierende Nachricht per HTTP oder MQTT empfängt und alle drei Rollladen Shelly mit dem RPC beauftragt. Der RPC für die beiden anderen Shelly lautet per HTTP so.

http://<IP Adresse des Ziel Shelly>/rpc/cover.gotoposition?id=0&pos=<Prozentwert>

Ich weiß, Skripte sind oft ungeliebt. Bei dir auch?