Die Nutzung eines Shelly Gen 3 zur Weiterleitung von BLU H&T Nachrichten gelingt vorzüglich und relativ leicht.
Alternativ zu den MQTT Nachrichten durch das System kann man Actions nutzen. Inzwischen gelingt es mir auf unterschiedliche Weise, per Actions und sehr einfaches Skript Nachrichten frei zu gestalten. Hiermit kann ich auch den doofen Schlüssel "bthomesensor:<id>" vermeiden und "leicht verdauliche" Schlüssel in der JSON Payload selbst kreieren.
Sind die 18V Gleich- oder Wechselspannung?
18V DC zur Versorgung eines Shelly Plus 1 habe ich nie versucht. Dazu kann sicher thgoebel etwas mitteilen. Ich kann dir aber dafür einen Shelly Plus Uni empfehlen. Der arbeitet sehr gut mit 18V, hat u.a. zwei binäre Eingänge und zwei per Optokoppler potentialfrei schaltende Ausgänge. Dies habe ich afaik bereits weiter oben angemerkt.
Alternativ kannst du sicherheitshalber zur Shelly Plus 1 Versorgung einen (einstellbaren) Gleichspannungswandler 18V DC -> 12V DC nutzen.
und den freien SW für den Magnetschalter verwende
Das geht dann jedenfalls, wenn der Magnetschalter funktioniert. Letzteres stelle ich auf Grund deiner dbzgl. Probleme an Analog In in Frage.
Die per Shelly Generation 3 vom System gesendete MQTT Nachricht für Sensordaten:
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:
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.
Sorry, ich habe länger an meinem letzten Beitrag gesessen und erst jetzt deinen gesehen.
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.
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.
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:
- "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.
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!
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::
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.
Und ich denke, soviel Vorstellungskraft kann man erwarten, dass, wenn einer schreibt: "Schaltplan bitte!", dann ein Schaltplan gebraucht wird. 
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.
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
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.
