[98_AUTOREMOTE] - Modul für Tasker AutoRemote (Android)

Begonnen von vbs, 20 Mai 2017, 12:01:03

Vorheriges Thema - Nächstes Thema

ToM_ToM

Hey vbs,

das ist ein gutes Beispiel. Ich werde das heute Abend direkt mal ausprobieren.

Vielen Dank dafür.
Hardware: BananaPi, Busmaster CUL, SanDisk 16GB Ultra SD, 16 GB USB-Stick | Software: Armbian, FHEM 5.8

ToM_ToM

Hallo vbs,

habe das jetzt getestet, aber bei mir will das nicht.

Sobald ich in meinem Dummy ein Event auslöse, bekommt mein RemoteGateway ein Event welches Ok zurück gibt, was ja schon mal gut ist.
Dem Tablet interessiert das aber nicht. Weder Tasker reagiert, noch zeig der Eventlog von der Autoremote irgendetwas an.

Ich denke, mein Fazit wird sein, mir nun doch mal Automagic und AMAD anzusehen.

Trotzdem vielen Dank!

VG, Thomas
Hardware: BananaPi, Busmaster CUL, SanDisk 16GB Ultra SD, 16 GB USB-Stick | Software: Armbian, FHEM 5.8

Schlimbo

Wenn du Nachricht direkt übers LAN auf dem Androiden empfangen willst musst du sicherstellen, dass dort auch der AutoRemote Wifi service läuft.
Der muss nämlich erst über einen Task gestartet werden.
Plugin --> AutoRemote --> Wifi

AlexBV

Hallo zusammen,

kann Mal jemand bestätigen, dass das Modul noch funktionsfähig ist? Über die URL aus der AutoRemote App kann ich einwandfrei Nachrichten an mein Handy senden. Über FHEM geht gar nichts. Die Definition ist wie folgt:


defmod arGateway AUTOREMOTE tu4VAuz5r5JPnlo,.*temp.*



vbs

Ja, Modul ist bei mir weiterhin im Einsatz. Ich würde mal ins (verbose-)Log gucken.

AlexBV

Einfacher aber guter Hinweis. Ich hatte schlichtweg den falschen Schlüssel  ::)

Sehr schönes Modul. Jetzt weiß ich unterwegs, was Zuhause los ist  ;D

AlexBV

Hi,

ich habe festgestellt, dass der stateFilter anders funktioniert, als der Filter-Parameter in der Definition. Mein Filter lautet:

(Esp32.*temp|Helligkeit|Sunset).*

In der Definition funktioniert er einwandfrei, aber als stateFilter nur sporadisch. Insbesondere das Esp32.*temp macht hier Probleme. Könnte hier noch ein Bug sein oder ist es grundsätzlich beabsichtigt, dass der Filter-Parameter und stateFilter unterschiedlich funktionieren?

vbs

Klar, ein Bug ist nicht ausgeschlossen. Aber eigentlich münden beide Varianten im gleichen Code und *sollten* sich daher auch identisch verhalten. Ich kann da nur wieder aufs Log verweisen (ins Log zu gucken ist immer eine gute Idee). Dort kannst du sehen, welcher Filter mit welchem Ergebnis verwendet wurde.
Wenn ich was dazu soll, dann bitte auch hier posten mit einem List des Devices.

AlexBV

Hi,

ich habe mir jetzt das Log mit Verbose 5 näher angesehen. In deinem Modul und dem Regex sieht alles gut aus. Ich vermute eher ein Performanceproblem. Die notify Loop scheint manchmal unterbrochen zu werden, wenn mehrere MQTT Messages gleichzeitig eintreffen. Das ist bei mir beim Filter "Esp32.*temp.*" der Fall. Nach der Temperatur kommt noch Luftdruck und die rel. Luftfeuchtigkeit. Die auf die Temperatur folgende Nachricht unterbricht manchmal die Notify Loop der Temperatur-Message, so dass alte Events nicht weiter verarbeitet werden, was wiederum erklärt, warum manche Temperatur-Events bei mir nicht übermittelt werden.

Leider habe ich aktuell keine Lösung des Problems.

vbs

Eigentlich sollte da in FHEM nichts verloren gehen. Da FHEM intern single-threaded ist, verbleiben unverarbeitete Daten einfach in den IO-Buffern, bis sie verarbeitet werden. Ich würde erstmal gucken, ob wirklich alle MQTT-Daten auch zu FHEM-Events werden per Event-Monitor, aber das hast du ja wahrscheinlich schon gemacht? Wenn da Daten fehlen, dann ist da irgendwo ein Bug mMn. Sowas darf nicht passieren.

AlexBV

Hi,

ziemlich sicher ist es kein Thema deines Moduls. Ich habe festgestellt, dass auch ein ganz normales Notify bei meinen Esp32-Events (MQTT-Messages) nicht auslöst, obwohl sie im Event Monitor angezeigt werden. Das ist mir bisher nicht aufgefallen, da keine solchen Notifys angelegt waren.

Nachdem ich Megabytes an Logs durchgesucht habe, ist meine Geduld auch am Ende. Ich versuche mir einen Workaraund mit doif o.ä. zu basteln.

vbs

Zitat von: AlexBV am 07 Oktober 2019, 17:21:40
Ich habe festgestellt, dass auch ein ganz normales Notify bei meinen Esp32-Events (MQTT-Messages) nicht auslöst, obwohl sie im Event Monitor angezeigt werden. Das ist mir bisher nicht aufgefallen, da keine solchen Notifys angelegt waren.
Also Events, die im Event-Monitor auftauchen aber trotzdem das notify nicht triggern, halte ich eigentlich für eher unwahrscheinlich. Ist das evtl. doch irgendwas blödes drum herum? Passiert ja immer mal...
Ansonsten, wenn das wirklich so sein sollte, dann ist das mMn ein Bug ziemlich tief drin in FHEM. Ist natürlich nie auszuschließen. Aber da notify so verbreitet ist, einfach unwahrscheinlich.

Aber das müsstest du doch recht einfach mit einem Test-notify, welches eine Logzeile erzeugt (bzw. im Fehlerfall dann eben auch nicht) belegen können. Also man sieht das Event im Event-Monitor, man sieht die Definition deines notify-Devices und man sieht im Log, dass es nicht getriggert hat? Mit dem Befehl "trigger" kannst du ja auch testweise beliebige Events erzeugen.