HS-Parameter am PC über MQTT einstellen

Bei AWS IoT gibt es dafür Shadow Devices, die dem Status speichern. 
Gefüttert werden sie mit MQTT oder Rest Updates.
Also irgendwo brauchst Du ein digitales Abbild, das gepflegt wird und 
jede Änderung irgendwo wird per MQTT verteilt und dort festgehalten.

Nachtrag:
Liest sich danach als wolltest Du den ESP zum Server / Steuerzentrale 
machen, das ist keine gute Idee. Der ist nicht dafür geeignet eine DB 
von Shadow Devices / Zuständen mitzuführen, er ist nur als Client 
geeignet.
Für so eine Management Konsole, die Stati über alles zu managen solltest 
Du einen „richtigen“ Server nehmen, zB einen Raspberry Pi oder einen 
richtigen PC.

Versteh das Problem auch nicht ganz...

Eventuell wirds anhand eines konkreteren Beispiels klarer, fiktives 
Heizungsthermostat auf ESP-Basis:

Ein Topic:

wohnzimmer/heizung/soll

für den Soll-Wert (Retained)

und ein Topic

wohnzimmer/heizung/ist

für den Ist-Wert.

Ob ich den Soll-Wert nun per App, oder per Webseite, per selbstgebautem 
Wand-Modul, per FHEM/OpenHAB-Uhrzeitregel oder sonstwie verstelle ist 
doch egal, MQTT speichert ihn.

Wenn sich der MQTT-Server resettet: Kein Problem, er holt den letzten 
Stand aus seiner persistence-Datei.

Wenn sich der Thermostat-ESP resettet: Kein Problem, der MQTT-Server 
liefert ihm sofort seinen Soll-Wert.

Wenn sich das Bedien-Modul resettet, Webseite neu geladen wird, App 
geöffnet wird: auch kein Problem, MQTT kennt schließlich den zuletzt 
eingestellten Soll-Wert.


Ich wüsste nicht, an welcher Stelle man da sinnvoll eine 
PHP(-Textfile)-Datenbank o.Ä. mit einbauen könnte, außer zu 
Visualisierungs-Zwecken (rrdtool &co)

Hallo zusammen,

also was ich momentan mache:
- Webseite bei einem Hoster
- MQTT läuft bei einem CloudMQTT
- kein RasPi o.ä. eingebunden
- der µC kontrolliert Haus und kommuniziert mit ESP
- ESP ist auf die MQTT Messages abonniert; werden Daten empfangen, 
leitet dieser sie nur weiter (kein Webserver)
- Rolladen können direkt angesteuert werden (setzte Wert in MQTT), geht 
gut
- für Rolladenprogramme sollen Zeiten eingestellt werden. Hier kommt 
meine Problem in's Spiel:
* die Zeiten werden eingestellt und dann published
* bevor ich was eingebe, wäre es gut, die aktuellen Settings zu sehen

Hoffe, das hilft beim Verständnis

@ mqtt-sn: Ich weiß jetzt nicht genau, was "retained messages" macht, 
muß ich mal nachlesen
[https://www.hivemq.com/blog/mqtt-essentials-part-8-retained-messages]
Scheint fast zu machen was ich brauche?!?

Timo R. schrieb:
> - für Rolladenprogramme sollen Zeiten eingestellt werden. Hier kommt
> meine Problem in's Spiel:
> * die Zeiten werden eingestellt und dann published
> * bevor ich was eingebe, wäre es gut, die aktuellen Settings zu sehen

Da gibt's jetzt zwei Möglichkeiten.
a) Jedesmal vom UI einen Request für die Parameter schicken und auf die 
Antwort warten
b) Irgendwo die Settings speichern, z.B. in einem Shadow Device, das die 
UI im Zugriff hat.

Das Shadow Device gibt Dir jederzeit den Gesamtstatus eines Geräts, ohne 
dass Du mit dem Gerät direkt sprechen müsstest.

Conny G. schrieb:

> a) Jedesmal vom UI einen Request für die Parameter schicken und auf die
> Antwort warten

Ja, aber genau das bietet MQTT von Haus aus nicht (war nicht dafür 
gedacht) - oder liege ich da falsch?

Timo R. schrieb:
> Conny G. schrieb:
>
>> a) Jedesmal vom UI einen Request für die Parameter schicken und auf die
>> Antwort warten
>
> Ja, aber genau das bietet MQTT von Haus aus nicht (war nicht dafür
> gedacht) - oder liege ich da falsch?

Kann man sicher so machen, aber es ist schon vom Architekturansatz her 
ungünstig.
Man würde über eine Strecke, die für asynchrone Kommunikation konzipiert 
ist quasi-synchron kommunizieren. Und das viel häufiger als man es über 
eine MQTT Strecke machen will.
Müsste man immer alle Parameter von allen Geräten ad hoc abfragen, 
würden sich riesige Datenübertragungsmengen ergeben, da sieht man schon 
das das nicht im Sinne des Konzepts ist.

Timo R. schrieb:
> Ja, aber genau das bietet MQTT von Haus aus nicht (war nicht dafür
> gedacht) - oder liege ich da falsch?

Doch, genau das kann MQTT. Es muss aber beim Senden des Werts mitgeteilt 
werden, dass es sich um einen "aufhebenswerten Wert" handelt, nicht beim 
Abonieren des Topics.

kein Problem du abonnierst das Thema und der Broker sendet dir die 
letzte gespeicherte Messages. Du musst also mit deiner Anfrage das Thema 
abonnieren -> der Broker sendet die letzten Werte und wieder 
abbestellen. So kommst du an die Werte.

Das mit den Schatten funktioniert nur im AWS und da braucht man bloß per 
GET sich den Schatten holen. Was im übrigen extra kosten verursacht.

Marco H. schrieb:
> kein Problem du abonnierst das Thema und der Broker sendet dir die
> letzte gespeicherte Messages. Du musst also mit deiner Anfrage das Thema
> abonnieren -> der Broker sendet die letzten Werte und wieder
> abbestellen. So kommst du an die Werte.

Kann man machen, ist aber Lösungstyp "Hack".

> Das mit den Schatten funktioniert nur im AWS und da braucht man bloß per
> GET sich den Schatten holen. Was im übrigen extra kosten verursacht.

Das war als Lösungskonzept gemeint, nicht als konkrete Lösung, das im 
AWS zu machen. Aber die Shadows ist wie es gemeinhin gemacht wird, auch 
bei Apple Homekit oder bei Homematic.

Habe nun die  "retained messages" Option in einem anderen Projekt 
ausprobiert und scheint mir bei meinem Problem zu helfen, sprich darauf 
kann ich bauen (hoffentlich!)

Danke allen!

Er hat offenbar nicht verstanden das man mit zwei themen arbeiten kann. 
Abonniert wird die diejenige wo das Device erfolgreich den Status 
zurückmeldet. Per Publish  auf dem Thema das des Device abonniert hat.

Du kannst per HTTP request nicht auf auf die Antwort warten. Den Status 
mußt du per Javascript und GET immer wieder abfragen. Natürlich das in 
ein json verpacken. Dynamische Webinhalte nennt man so etwas. Warum ? 
weil der Status sich ja auch vom einen anderen Client ändern könnte. Per 
Ajax fragt du alle 1sec den Status des Themas ab. Da deine Gateway das 
Thema ja abonniert hat wird er eine Änderung auch mitbekommen. 
Alternativ kann man das auch so Lösen wie im AWS mit dem Schatten. So 
das dein Client auch mitbekommt wenn zwar ein Status gesetzt wurde aber 
das Gerät nicht diesen zurückgemeldet hat.

Das Rücklesen des eigenen Themas bringt nicht sehr viel um zu wissen ob 
das Gerät den Status auch erhalten hat.

Wie will ein HTTP Client sonst eine status Änderungen feststellen? In 
dem der User die Seite neu lädt? Mit Header ist die Trafic auch gering 
da ich ja sagte in json verpacken. Nicht die Seite neu laden.

Er kann auch per Websocket das Protokoll wechseln. MQTT über den Browser 
fahren.

www.hivemq.com/demos/websocket-client

Schau bis zu dem Punkt in dem der Client äußert das Protokoll zu 
wechseln ist das ein Webserver. Ob man das nun als Front-End oder als 
Back-End einsetzt ist relativ Wurst. Per Javascript wird die Seite dann 
dynamisch verändert wenn eine Abonnierte Message empfangen wird.

Probiere es aus das funktioniert auch mit einen lokalen Broker :).

Der Webserver stellt nur die Ressourcen zu verfügung und der Browser 
führt das Javascript dann aus.

Mit iobroker habe ich am Anfang experimentiert und der MQTT Teil war 
grauenhaft. Es kam einige mal Müll zurück der zu anderen Modulen 
gehörte.