[GELÖST] Überwachung / Zugriff auf zweiten Raspi

[Beta-User]

 
Klar, warum sollte MQTT2_DEVICE das nicht machen...

Tendiere aber dazu, den STATUS und ggf. (empfangsseitig....) den COMMAND-Pfad hinten anzufügen, und das dann bei der Auswertung in MQTT2_DEVICE anders zu lösen (readingList-Eintrag, wieder "auf Verdacht"):

Code Auswählen Erweitern

home/GPIO18/states {{"GPIO18"=>$EVENT?"on":"off"}}
oder gleich generalisiert:

Code Auswählen Erweitern

home/([^/]+)/states {{"$1"=>$EVENT?"on":"off"}}

[Markus.]

genial Ja genau so teste ich das. Muss es generalisiert machen mit dem Reading sonst müsste ich für jeden möglichen Pin manuell eins anlegen oder?
Im Skript wird ja die Pin Nummer geändert, je nachdem wer seinen Level geändert hat. Und eben für jeden pin der seinen Level geändert hat ein reading angelegt werden soll.
Was mir ehrlich gesagt nur nicht ganz klar ist ... was meinst Du denn mit dem COPMMAND-Pfad?

[Beta-User]

Na ja, vermutlich willst du den GPIO auch von FHEM aus steuern können . Warum dann nicht über MQTT, dann ist alles beieinander...?
Dafür wäre es nur wichtig, dass ein "Kreis" entsteht, also die Anweisung auf einem anderen Topic-Pfad liegt wie die Rückmeldung (deine heutige/gerade zu entwickelnde Statusmeldung). Dafür würde ich dann

Code Auswählen Erweitern

home/GPIO18/set mit Payload 0 bzw. 1 vorschlagen...
Hat den Vorteil, dass du ggf. dann auch nur einzelne Teile abbonieren kannst, wenn du den MQTT-Verkehr "von außen" mithören willst. Ist zwar für so ein "kleines" Device nicht soooo wichtig, aber es geht ja auch ein bischen darum, eine Referenz zu haben, falls mal was größeres ansteht oder jemand das beim Suchen findet...

Für den Fall, dass die komplizierte Variante nicht klappt, für den empfangsseitigen Testen auch noch eine einfachere Variante. Da schreibst du einfach den gewünschten Readingnamen dahinter, Zustand ist dann 0 bzw. 1:

Code Auswählen Erweitern

home/GPIO18/states GPIO18
(Hoffe, das Prinzip wird jetzt etwas klarer, wie die Verarbeitung innerhalb des Moduls abläuft.)

[Markus.]

mmh habs jetzt mal getestet. Er erzeugt zwar das Reading zb. GPIO22 aber den Wert 0 oder 1 zeugt er nicht an

Code Auswählen Erweitern


defmod MQTT2_LISAGW2 MQTT2_DEVICE LISAGW2
attr MQTT2_LISAGW2 DbLogExclude .*
attr MQTT2_LISAGW2 IODev MQTT2_Server
attr MQTT2_LISAGW2 readingList LISAGW2:home/([^/]+)/states {{"$1"=>$EVENT?"on":"off"}}\
LISAGW2:home/states/GPIO22:.* GPIO22
attr MQTT2_LISAGW2 room MQTT2_DEVICE

setstate MQTT2_LISAGW2 2019-12-20 17:01:21 GPIO22

Wenn ich das Reading wie vorgeschlagen ändere, wird bei der nächsten Änderung des Levels, das alte Reading hinzgefügt.

Code Auswählen Erweitern

LISAGW2:home/states/GPIO22:.* GPIO22
Gesendet (publish) wird der String wie folgt

Code Auswählen Erweitern

home/states/GPIO22 1

aber der String der gepublshed wird ist doch so korrekt oder ?
topictree leerzeichen wert

Im Eventmonitor sieht das so aus

Code Auswählen Erweitern


2019.12.20 17:28:53 4 : MQTT2_DEVICE_Parse: MQTT2_LISAGW2 home/states/GPIO22 => GPIO22
2019-12-20 17:28:53 MQTT2_DEVICE MQTT2_LISAGW2 GPIO22:



Gruß

Markus

[Markus.]

stop halt....
hab jetzt mal subscribed... da sieht das wie folgt aus

Code Auswählen Erweitern


home/states/GPIO22 (null)

Also macht der beim Publish irgendwas anderes mit dem Wert als beim client.publish.
Nun dann wieder zurück zum Skript und dem Publish Befehl

[Markus.]

so es wird nun wie folgt gepublished.

Code Auswählen Erweitern


home/states/GPIO22 0 (null)
home/states/GPIO22 1 (null)
home/states/GPIO22 0 (null)
home/states/GPIO22: 0 (null)
home/states/GPIO22: 1 (null)
home/states/GPIO22: 0 (null)
home/states/GPIO22: 1 (null)
home/states/GPIO22: 0 (null)


Das mit dem Doppelpunkt habe ich noch ausporbiert, aber geht immer noch nicht. Also Reading wird erzeugt aber wert 0 oder 1 wird nicht angezeigt.
im Log sieht es so aus:

Code Auswählen Erweitern


2019.12.20 17:46:33 3: MQTT2_LISAGW2: bad reading name 0:.* GPIO22_0 (contains not A-Za-z/\d_\.- or is too long)
2019.12.20 17:46:41 3: MQTT2_LISAGW2: bad reading name 1:.* GPIO22_1 (contains not A-Za-z/\d_\.- or is too long)
2019.12.20 17:46:46 3: MQTT2_LISAGW2: bad reading name 0:.* GPIO22_0 (contains not A-Za-z/\d_\.- or is too long)
2019.12.20 17:48:11 3: MQTT2_LISAGW2: bad reading name 0:.* GPIO22__0 (contains not A-Za-z/\d_\.- or is too long)
2019.12.20 17:48:21 3: MQTT2_LISAGW2: bad reading name 1:.* GPIO22__1 (contains not A-Za-z/\d_\.- or is too long)
2019.12.20 17:48:26 3: MQTT2_LISAGW2: bad reading name 0:.* GPIO22__0 (contains not A-Za-z/\d_\.- or is too long)
2019.12.20 17:49:46 3: MQTT2_LISAGW2: bad reading name 1:.* GPIO22__1 (contains not A-Za-z/\d_\.- or is too long)
2019.12.20 17:49:51 3: MQTT2_LISAGW2: bad reading name 0:.* GPIO22__0 (contains not A-Za-z/\d_\.- or is too long)



[Markus.]

so habe das Problem gefunden
Es lag daran, wie das gepublished wird vom Skript.

Code Auswählen Erweitern


home/states/GPIO22 0 (null)
home/states/GPIO22 0
home/states/GPIO22 1

Die Zeile mit dem (NULL) frisst der Broker irgendwie nicht.
Den Publish string im Skript habe ich dann anderes "zusammen gebaut" so das er auch nach der Syntax passt. die wie folgt aussehen muss:

Code Auswählen Erweitern

client.publish("house/light","ON")
Das ganze sieht dann so aus:

Code Auswählen Erweitern

client.publish (("home/states/GPIO{}".format(GPIO)),("{}".format(level))) 

Damit sollte dann eigentlich für jeden GPIO der nun seinen Status mal ändert ein neues Reading anglegt werden.
Dann wäre ich jetzt beim nächsten Schritt und zwar das Skript auf dem remote Raspi als service zu defineiren damit es auch immer schön läuft.

Gruß
Markus

[Markus.]

so läuft nun auch als Service.Nun bin ich gespannt wie stabil das ganze läuft.
Nochmals Danke an Otto und Beta-User

Gruß

Markus

[Otto123]

Hallo Markus,

das freut mich. Den letzen gemeinsamen Part von Dir und Beta-User hab ich nur mitgelesen und muss den für mich mal noch verständlich machen / nacharbeiten

Schöne Weihnachten
Otto

[Beta-User]

so läuft nun auch als Service.Nun bin ich gespannt wie stabil das ganze läuft.
Nochmals Danke an Otto und Beta-User

Gruß

Markus

Danke für die Rückmeldung!

Falls der Betrieb dann als "stabil" bezeichnet werden kann, wäre es nett, wenn du das ganze nochmal "nachbautauglich" zusammenfassen könntest; dann bau' ich's gerne in die "Praxisbeispiele" ein bzw. verlinke auf die Darstellung.

Gruß, Beta-User

[Markus.]

Hallo Beta-User,

ich muss das Skript noch ändern, damit es auch permanent läuft. Im Moment wird die Verbindung zum Broker nach der Keep-alive Zeit beendet und das Skript muss neu gestartet werden. Ich wollte das diese Woche noch machen, dann kann ich die Infos liefern.

Viele Grüße

Markus

[Beta-User]

Hi Markus.,

kein Ding, eilt ja nicht, und wer schnell war braucht, kann ja hier auch nachfragen...

Danke jedenfalls schon mal vorab!