ESP8266/MQTT Aktoren/Sensoren Bridge (AktSen)

Begonnen von Pf@nne, 22 Dezember 2015, 00:49:10

Vorheriges Thema - Nächstes Thema

Pf@nne

ZitatBei mir im Blog hat man mir den Tipp gegeben alles über http laufen zu lassen, geht angeblich auch.

viele Wege führen nach Rom......
Oder wie meine Frau immer fragt: "kann man denn "hinterher" das Licht immer noch am Lichtschalter schalten?"

Das wesendliche ist der MQTT-Broker, der kümmert sich darum wer, wann, was, wie oft bekommt.
Jeder kann, was auch immer für eine Information, dem Broker mitteilen "publish".
Dieses "publish" bekommen dann ALLE (also auch mehrere) Abonnenten, die dieses Topic abonniert haben "subscribe".
So kannst du mit einem "publish" z.B. Taste-gedrückt auch mehrere Abonnenten erreichen.
Auch "verschluckte" Pakete kann MQTT handeln.

Ich persönlich finde MQTT universeller und übersichtlicher.
FHEM auf: DS415+ (Master), Raspberry Pi 2

Bapt. Reverend Magersuppe

Ich finde MQTT auch ganz hervorragend, besonders für diese Datenkrümel für Lichtschalter und solche Zustände.

Allerdings weiss ich nicht genau, was passiert wenn der ESP mal abstürzt und neu startet. Wer in der Kette ist dafür verantwortlich dass er den Zustand bekommt den er vor dem Reboot/Absturz hatte?
--
If I was born in 1453, Leonardo da Vinci would be jealous of me.
Reverend Paul Egon Magersuppe
Aus versicherungstechnischen Gründen sind sämtliche Beiträge von mir rein spekulativer und theoretischer Natur und sollten nicht in die Tat umgesetzt werden!
Bin hier selten DRIN. AUS GRÜNDEN!

fh168

Danke für die Infos.
Und die Frage Deiner Frau ist berechtigt!
Ich bin ja von MQTT gar nicht abgeneigt, ich habe hier bei mir alles laufen: MySensors, Jeelink, 433 MHz Steckdosen, FS, CUL 868 usw. Irgendwie läuft das alles. Und jetzt läuft eben noch eine Software (der Broker) noch im Hintergrund. Der Raspi 3 langweilt sich sowieso.
Was ich nicht mag ist dieses Subscriben per MQTT und Publishen via http. Entweder oder sage ich mir da. In meinem Blog habe ich zwar dieses schlechte Beispiel gegeben, aber irgendwann muss man ja mal zu Potte kommen.

LG
/robin
Hue, Lacrosse, PCA301, MySensors, V 1.67 CUL 868 V3.4, Lacrosse-WLAN-Gateway, Tasmota RF-

Pf@nne

Zitat von: Bapt. Reverend Magersuppe am 23 März 2016, 18:56:40
Allerdings weiss ich nicht genau, was passiert wenn der ESP mal abstürzt und neu startet. Wer in der Kette ist dafür verantwortlich dass er den Zustand bekommt den er vor dem Reboot/Absturz hatte?

Dieses Problem kann dir MQTT nicht direkt abnehmen. Was nach einem Reboot des Clients passiert regelt im Normalfall seine eigene Firmware.
Bei einigen Clients ist es sinnvoll den Zustand vor Reboot wieder anzunehmen, bei Anderen sollte unbedingt der Nutzer entscheiden das etwas neu gestartet werden soll.
Die Zustände nach einem Reboot könnten dann z.B. im Flash bzw. EEPROM des Clients abgelegt werden.

Es ist aber auch möglich über MQTT den Status des entsprechenden Aktors abzufragen, dann würde FHEM "wissen" was zuletzt los war.
In jedem Fall muss man sich die Frage stellen, darf der Aktor nach einem Reboot "selbsttätig" den letzten Zustand wieder annehmen?

MQTT kümmert sich vorrangig darum, wer welche Informationen in welcher Qualität erhalten soll (wer hat was abonniert).
Der QoS- (Qualitiy of Service) Level regelt wie oft ein subscibe vom Broker versendet wird:


  • At most once (0) "fire and forget"
    Hier wird das "subcribete" Topic NUR  1 x vom Broker weitergeleitet.
    In der Regel ist dieses ServiceLevel ausreichend. 
  • At least once (1)
    Hier wird garantiert, dass die Nachricht MINDESTENS 1x beim Client ankommt.
  • Exactly once (2)
    Hier wird garantiert, dass die Nachricht GENAU 1x beim Client ankommt.

Je höher das QoS-Level desto aufwändiger der Kommunikationsverkehr. 

Eine weitere Möglichkeit der Kommunikationsüberwachung bietet der

  • LWL "Last Will and Testament"
    Hier gibt es die Möglichkeit andere Clients über den Kommunikationsverlust des eigenen Clients zu informieren.
    FHEM wüsste dann ob der Client "mal weg war".

Komplettiert werden die Kommunikationsparameter durch die

  • Retained Messages "Last known good value"
    Mit dieser Option kann das subcribe eines z.B. 5 Minuten-Intervall-Wertes forciert werden.
    Hier wird unmittelbar nach dem subscribe der letzte bekannte Wertübertragen, so umgeht man die 5 minütige Wartezeit.

All das ist natürlich auch mit einem http-Protokoll möglich, jedoch nicht fest implementiert.
D.h. man muss sich die Mühe selber machen, aber warum das Rad neu erfinden, MQTT macht das ja schon.......


Zitat von: fh168 am 23 März 2016, 19:27:34
Was ich nicht mag ist dieses Subscriben per MQTT und Publishen via http.

D.h. du versendest dein publish über html?
FHEM auf: DS415+ (Master), Raspberry Pi 2

fh168

Hallo

vielen Dank für die Infos.
Retained Messages hört sich gut an. Muss ich mir mal anschauen.
Bei meinem Nebler/Diffusor (-> https://blog.moneybag.de/erfahrungsbericht-ultraschall-nebler-luftbefeuchter-diffuser/)
und Witty-Board Projekt (https://blog.moneybag.de/fhem-witty-board-einfache-iot-funktionen-schnell-gebaut/) schubse ich die Anforderungen via Http rüber. Mein ESP-8266-01 zermurckst mir mein MQTT Subscription und Publishing String immer, wenn ich Openhab MQTT wähle. Ich mache jetzt alles mit ESP Easy.

LG
/robin
Hue, Lacrosse, PCA301, MySensors, V 1.67 CUL 868 V3.4, Lacrosse-WLAN-Gateway, Tasmota RF-

fh168

Ich habs hinbekommen,

getestet mit meinem Witty-Board und mqtt-spy.
Meine Meinung nach ein ideales Test-Board mit quasi 2 Inputs (Taster, Licht von außen -> LDR) und 4 Outputs (5050 LED).
Der "Fhem-Schalter" und die Icons geht aber noch nicht.
Was ist auch noch nicht hinbekomme, mit Fhem den Publish zu emulieren.. also so set WittyBoard publish blau  oder so.
Die Einstellungen (name des Devices wurde in newdevice geändert) habe ich aus meinem Blog-Beitrag übernommen: https://blog.moneybag.de/fhem-witty-board-einfache-iot-funktionen-schnell-gebaut/

# Device Lichtsensor und LED Schaltung nachLicht
define WittyBoard MQTT_DEVICE WittyBoard
attr WittyBoard IODev MyBroker
attr WittyBoard autoSubscribeReadings /newdevice/#
attr WittyBoard devStateIcon 1:10px-kreis-rot off:10px-kreis-gruen
attr WittyBoard eventMap 1:1 0:0
attr WittyBoard publishSet 1 0  /newdevice/gpio/12
attr WittyBoard room MQTT
attr WittyBoard stateFormat Licht: Analog Taste: Taster
attr WittyBoard subscribeReading_gruen /newdevice/gruen/Switch
attr WittyBoard subscribeReading_blau /newdevice/Blau/Switch
attr WittyBoard subscribeReading_rot /newdevice/rot/Switch
attr WittyBoard subscribeReading_Analog /newdevice/LichtabhWiderstand/Analog
attr WittyBoard subscribeReading_Taster /newdevice/OnBoard-Taster/Switch
Hue, Lacrosse, PCA301, MySensors, V 1.67 CUL 868 V3.4, Lacrosse-WLAN-Gateway, Tasmota RF-

Pf@nne

Moin,

einen einfachen Schalter implementierst du z.B. so:

define WP_Zirkulation MQTT_DEVICE
attr WP_Zirkulation IODev MQTT_Broker
attr WP_Zirkulation alias WP Zirkulation
attr WP_Zirkulation devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr WP_Zirkulation publishSet on off  /Aktoren/WP/state/set
attr WP_Zirkulation room Aktoren
attr WP_Zirkulation stateFormat state
FHEM auf: DS415+ (Master), Raspberry Pi 2

fh168

Hallo,

ich habe einen kurzen Blogbeitrag über ein Testboard mit einem Beispiel für MQTT geschrieben.

https://blog.moneybag.de/angetestet-esp-8266-testboard/

LG
/robin
Hue, Lacrosse, PCA301, MySensors, V 1.67 CUL 868 V3.4, Lacrosse-WLAN-Gateway, Tasmota RF-