Autor Thema: Ein paar Verständnisfragen zur API  (Gelesen 345 mal)

Offline Adimarantis

  • Developer
  • Full Member
  • ****
  • Beiträge: 284
Ein paar Verständnisfragen zur API
« am: 31 Januar 2021, 12:43:22 »
Hallo,

bei meiner Weiterentwicklung von Signalbot (als Ersatz für SiSi ohne forking) bin ich auf ein paar Themen in der API gestossen, die nicht verstehe:

1) Select Loop
Mein Modul nutzt eine Filehandle und die Möglichkeit mich per X_Read() von FHEM aufrufen zu lassen. Dies passiert aber aktuell manchmal ohne das wirklich Daten anliegen. Insbesondere bekomme ich zwei Trigger wenn ich per Putty eine neue Shell auf dem Raspberry aufmache und zwei weitere wenn ich mich dort wieder auslogge.
Schadet jetzt nicht weiter. Ist das ein erklärbares Verhalten oder liegt das evtl. an meinem UseCase (Abfragen vom Dbus interface via Net:DBus)

2) AnalyzeCommandChain()
Ich habe mir von Telegrambot abgeschaut, wie man über Streams SVG Plots holen (und dann verschicken) kann.
Laut Doku liefert dieser Aufruf "undef" wenn alles ok ist, sonst eine Fehlermeldung.
Wenn ich aber Perl Code mit Rückgabewerten drin habe, so werden diese auch zurück geliefert (was ja auch gut ist).
Dadurch ist aber die einzige Möglichkeit für mich auf "Fehler" zu prüfen ein Match auf /^Unknown command/ - ist das so gewollt und nur nicht dokumentiert?

3) Temporary Files
Gibt es eine konforme Methode temporäre Dateien zu erzeugen? ich habe
use File::Temp qw( tempfile tempdir );
my ($fh, $tmpfilename) = tempfile();
versucht, aber keinen Weg gefunden die Datei für andere Nutzer lesbar zu machen (und bei mir muss signal-cli die Datei lesen).
Daher nehme ich jetzt doch
my $tmpfilename="/tmp/signalbot".gettimeofday().".".$type;Bessere Ideen?

Danke schon mal für Rückmeldungen,
Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL
70+ Homematic/HMIP, Diverse 433Mhz Sensoren und Schalter
Module: 52_I2C_ADS1x1x (offiziell), 50_Signalbot, 50_SPI_MAX31865

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24137
Antw:Ein paar Verständnisfragen zur API
« Antwort #1 am: 31 Januar 2021, 13:05:23 »
Zitat
Verhalten oder liegt das evtl. an meinem UseCase (Abfragen vom Dbus interface via Net:DBus)
Vermutlich Letzteres. Ich gehe davon aus, dass das Protokoll selbst weitere Daten benoetigt, die nicht immer in Benutzerdaten resultieren.
Z.Bsp. sowas wie PING.

AnalyzeCommandChain ist fuer den Endbenutzer gedacht, und nicht fuer Module, insb. nicht fuer Welche, die bestimmte Fehlermeldungen  abfangen wollen. Sowas muss explizit programmiert werden.

tempfile: deine letzte Methode funktioniert unter Windows nicht.
Wenn es nicht ohne tempfile geht, wuerde ich die Datei ins log-Verzeichnis schreiben (siehe Logdir() bzw. attr global logdir)

Offline Adimarantis

  • Developer
  • Full Member
  • ****
  • Beiträge: 284
Antw:Ein paar Verständnisfragen zur API
« Antwort #2 am: 31 Januar 2021, 13:32:02 »
Danke Rudi,

Irgendwo habe ich was gelesen, das mich vermuten lässt, das es eine Art restart auf dem DBus gibt wenn man sich einloggt. Finde ich zwar trotzdem seltsam, da ich mit als "pi" einlogge, der service aber unter "signal-cli" läuft und FHEM eben unter "fhem". Wie gesagt, schadet nicht, meine Routine stellt fest das nichts zu tun ist und kehrt sofort zurück.

Zitat
AnalyzeCommandChain ist fuer den Endbenutzer gedacht,
Dafür ist es aber unter den Modulentwicklern ganz schön beliebt:
/opt/fhem/FHEM $ grep AnalyzeCommandChain *.pm | wc -l
121
Ich hab jetzt aber auch keinen besseren Vorschlag, da jede Änderung eben diese 121 Nutzungen potentiell brechen würde.
Solange man sich drauf verlassen kann, das der Fehler mit "Unknown command" anfängt und der Fall ggf. in die Doku kommt?
Es macht ja was es soll und ich würde das Rad deswegen nicht neu erfinden wollen.

Das mit dem Tempfile muss ich mir noch überlegen. Ich habe auf meinem Raspberry /tmp in die Ramdisk verschoben um die SD-Karte zu schonen. Das FHEM log Verzeichnis liegt aber noch drauf, das würde ich jetzt ungern ständig mit temporären Bildern strapazieren. DBus unter Windows scheint höchstens experimentell zu sein - und signal-cli unterstützt es wohl gar nicht (obwohl Java ist da eine proprietäre lib.so drin). Daher weiss ich nicht ob ich jetzt den Aufwand betreiben würde auf Windows Nutzer Rücksicht zu nehmen (testen werde ich das sicher nie).
Interessant wäre halt jetzt gewesen, wie man die offizielle Methode verwenden kann (die landet unter Unix sowieso auf /tmp), aber das tmpfile world-readable bekommt.

Gruß,
Jörg

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL
70+ Homematic/HMIP, Diverse 433Mhz Sensoren und Schalter
Module: 52_I2C_ADS1x1x (offiziell), 50_Signalbot, 50_SPI_MAX31865

 

decade-submarginal