Fhem von Android steuern mi MQTT

[kleinz]

Ich habe gestern gelesen und was probiert.
Aber mal für mich zum verstehen
attr GHoma_625e60 mqttGB1Subscribe state:stopic={"$base"} sorgt doch eigentlich dafür
das die antwort mit zurück gesendet wird ?
Nur auslesen kann ich nix .
Das Retain Flag verstehe ich nicht warum ist es wichtig das der topic gespeichert wird
der attr .... publish sagt doch was gemacht werden soll und attr subcribe gibt doch dann die antwort auf publish oder?
verstehe ich das falsch

[Beta-User]

attr GHoma_625e60 mqttGB1Subscribe state:stopic={"$base"} sorgt doch eigentlich dafür
das die antwort mit zurück gesendet wird ?

Nope. Es (subscribe+stopic) sorgt dafür, dass FHEM das, was auf den betreffenden Topic als payload kommt als "set $device $name $message" versteht.

Nur auslesen kann ich nix .

"Auslesen" ist eine Wortwahl, die nicht zu MQTT paßt. (Punkt!)

Das Retain Flag verstehe ich nicht warum ist es wichtig das der topic gespeichert wird

Das "retain" ist eher "auslesen": Der Server hält halt den letzten übermittelten Stand vor und löscht ihn nicht direkt, nachdem er allen angemeldeten Clients übermittelt hat, dass da was war... so kann man auch später noch mitbekommen, was der aktuelle/letzte übermittelte Stand ist.

Kann man machen, wie man lustig ist bzw. wie es zum eigenen Anwendungfall am besten paßt. Datenschutzmäßig ist es besser, _kein_ "retain"-flag zu setzen.

der attr .... publish sagt doch was gemacht werden soll und attr subcribe gibt doch dann die antwort auf publish oder?
verstehe ich das falsch

Falsch rum: publish ist (von FHEM aus) die Senderichtung. Und ob die Antwort auf eine aus subscription kommende Anweisung direkt versendet werden soll ("hab's bekommen") oder nicht, kann man durch ein spezielles Attribut am Gerät einstellen. In der Regel wird der geänderte Stand zurückgemeldet, allerdings hängt das auch davon ab, wie die das Zelmodul "tickt" und die Konfiguration als solche gestrickt ist. Bin an der Stelle auch noch nicht abschließend durch, aber z.B. ein ZWave-Thermostat scheint da anders zu reagieren wie ein CUL_HM...

[kleinz]

Dann würde ich ja fast sagen das mqtt retain für mich nix taugt.
Client 1 hat das Licht küche eingeschaltet und bekommt es mit retain mitgeteilt.
Jetzt verbindet sich client 2 .
Wie soll er wissen wie die state aller anderen Devices ist.?
Sogar das letzte von client 1 geschaltete Küchenlicht retain wurde ja über mittelt an client 1 und gelöscht.
Dann bleibe ich beim ssh read state .
Wenn ich meine App starte initialisiert sie sich und fragt alle state ab.
Dementsprechend werden die Button Rot oder Grün angezeigt.
Ein klick schaltet ein device ein ein langer klick schatet aus.
so bekomme ich alle paar Sekunden den state aller devices!
Es geht jetzt über einen ssh tunnel und dann per perl Befehl an den Fhem Server .Der Abfragetimer hat 1000ms   
So dauert die antwort auch schon mal 3000ms. Aber das ist akzetabel.
In 70 % der Fälle werden die Devices per script vom RPI gesteuert.
In ca 25% der Fälle ist man zuhause wenn man schaltet
Die 5 % wo man übers Internet schaltet da kann ich mit der Verzögerung leben.
Aber ich wäre nicht ich wenn ich da noch nach anderen wegen suche
Thank you verry verry verry much

[Beta-User]

Deine "Richtungsdenke" ist m.E. verquer. Nicht die Anweisung musst du ggf. auf dem MQTT-Server vorhalten, sondern das Ergebnis, also aus FHEM-Sicht das publish (egal, ob es eine Reaktion auf eine MQTT-Anweisung war, oder z.B. durch einen in FHEM verarbeiteten Tastendruck (notify uä.)).

Und "retain" bedeutet afaik eben "nach zustellung nicht löschen", was genau das ist, was du bei späterer Verbindung haben willst.

Aber mach' du nur, wie du denkst, schließlich musst du es verstehen, und nicht ich . Ich will aber nicht ausschließen, dass ich da in die MGB-Konfiguration noch einen "Fehler" eingebaut hatte...

Wenn ich es richtig deute, müsste es dann so sein:

Code Auswählen Erweitern

attr MGB1 globalDefaults sub:base={"FHEM_main/MQTT2FHEM/$device"} pub:base={"FHEM_main/FHEM2MQTT/$device"} pub:qos=0 sub:qos=2 retain=1

[kleinz]

Ich hab retain 0 in der attr
hm ok werde das noch mal testen.

[kleinz]

habe jetzt vom windows mqtt client mal getestet und ja jetzt mit 1 werden mir die state angezeigt .
Das letzte und wenn ich weiter runter gehe dann wurden die letzten nach dem umschalten auf 1 angezeigt.
Hm aber ich muss  noch lesen wie bekomme ich den webzugriff hin also aus dem internet. Da lehnt fhem die verbindung ab
Auf der Fritzbox habe ich den port geöffnet
Aber nicht mehr heute

[Beta-User]

Der MQTT2_SERVER lehnt die Verbindung aus gutem Grund ab:
Simples Portforwarding ist MIST, v.a., wenn man nicht GENAU weiß, was man tut!

Kannst du hier im Forum mehrfach finden, in der Regel aber unter dem Stichwort "Web-Zugriff" (auf FHEMWEB). Das "Problem" ist aber dasselbe: Du gibst den Haustürschlüssel jedem beliebigen "Nachbarn" in die Hand, der "zufällig" deinen Port findet.

Lösung (hier wie dort): vpn-Zugang einrichten!

Alternative: "allowed" und starke SSL-Sicherung (aber beschäftige dich damit bei Bedarf erst, wenn du gelernt hast, die FHEM-Doku genauer zu lesen!!!).

[kleinz]

Hi
Ich habe bewusst keine PAsswörter usw gesetzt.
Wenn alles wie es soll funktioniert ,dann sichere ich ab .
Dazu gehört auch ein MAc filter usw
Aber bis alles funktioniert ist mir egal ob mein nachbar der keine Ahnung von rpi oder ähnlichem hat eine LAmpe bei mir an oder ausschaltet.
Und meine Türen schließe ich mit einem Dekoder aus Messing auf und zu.
Ich werde mal schauen nach allow ob ich dem mqtt server weballow setzen kann

[Beta-User]

...ich wollte es nur anschaulich machen, was du mit der Info machst, ist deine Sache.

Wie gesagt, ich halte den vpn-Weg (auch für Tests, btw.) für einfacher und werde nichts supporten, was aus meiner Sicht eine unsichere Lösung darstellt. Das war im übrigen auch der Startpunkt bzgl. des "notify"...:

Ich kann dir helfen, das ganze mit MQTT_GENERIC_BRIDGE ohne notify etc. aufzugleisen, aber diesen anderen Unsinn (meine deutliche Meinung) supporte ich nicht. Daher hatte ich auch auf einen bestimmten Beitrag verwiesen und nicht auf den ersten Beitrag in diesem Thread...

Und offene Ports ohne nähere Kenntnisse von Absicherungsmechanismen und der QoS und Retain-Mechanismen beim Versenden von Nachrichten sind zwar für deine Nachbarn ein Hindernis, nicht aber für geübte Augen und automatisierte Scanner...

[kleinz]

So ich habe WEB allow den MQTT2Server aktiviert
In der App habe ich den Benutzernamen und das Passwort eingegeben (festverankert)
Nun kann ich von über alle meine LAmpen schalten.
ICh werde mich wenn mein HM MOD RPI richtig funktioniert mit dem Subscribe besser beschäftigen
Aber im grossen und ganzen habe ich nun eine Verzögerung von1 Sekunde.
Ich habe das überblendet indem die APp ein Lampensysmbol zeigt, für 1 Sekunde .

[Beta-User]

SSL hast du auch aktiviert?
Ohne das ist es weiter unsicher...

[OT]
Habe gesehen, dass du den CUL_HM-Thread "geschlossen" hast. Das ist hier nicht üblich, hier im Forum sollte man einfach ein [gelöst] vorne an den Titel hängen, siehe angepinnten Beitrag im Anfängerbereich.
[/OT]

[kleinz]

Ups sorry das mit dem schließen .
Ich dachte das macht man so.
werde versuchen es zu öffnen