Wäre es möglich das auch bei einer Webhook Instanz das Debug gleich bei den anderen Instanzen befüllt wird ?
zzt. bleibt das Fenster (zumindest bei mir) einfach leer.
Perfekt wäre es wenn es im DebugFenster optional ein zuschaltbares json_decode(). Soweit ich mitbekommen habe ist json ja fast Standard für Anfragen per Webhook.
Und noch was: zzt. wird ja der Standardoutput eines per Webhook aufgerufenen Scriptes (also echo(), print()) direkt an den Aufrufer zurückgesendet. Ich fände es besser wenn dies nicht geschehen würde, sondern nur durch eine explizite Funktion Daten an den Host gesendet würden.
Das würde sowohl den Debug des Scriptes erleichtern, als auch unerwünschte Nebenwirkungen am Host verhindern welcher ggfls. durch unerwartete Responses ausgelöst wird.
Bin mir nicht sicher ob das aktuelle verhalten vielleicht aus irgendeinem Grund so sein muß, in diesem Falle vergiß den Vorschlag. Es ist da erste Mal das sich diese Instanz verwende.
Am Schluß noch eine kleine Kleinigkeit: Man kann einmal angelegte Hooks nicht editieren. Bei Änderungen muß man immer löschen und neu anlegen.
Wie meinst Du das genau? Wenn der Webhook an eine eigene Instanz geht, hast Du doch die Möglichkeit alle Informationen die Du brauchst mit SendDebug in das Debug Fenster zu schreiben.
Das hast Du doch selber komplett in der Hand was Du wie zurückgibst, aber zumindest eine Fehlermeldung sollte man schon erhalten wenn z.B. das Passort oder Username falsch sind.
Die erste Frage hat Fonzo ja schon geantwortet. Per SendDebug (WebHook innerhalb eines PHP Moduls) kannst du ja vorher auch die Ausgabe per JSON dekodieren.
Die andere Frage zur Ausgabe: Der WebHook ist ein simples Skript, welches nur das Resultat weiterleitet. Es gibt keinerlei andere Verbindung/Funktion die man dafür nutzen könnte. Falls du Fehler komplett abfangen willst, würde ich einen eigenen Error Handler dafür nutzen: PHP: set_error_handler - Manual
Ergänzend zur Ausgabe per Webhook:
IPS verhält sich immer identisch und liefert die Standardausgabe an den Aufrufer zurück.
Bei Ereignissen in das Log (IPS war ja der Aufrufende), bei Scripten im User Verzeichnis an den Browser, bei AktionsSkript und Skripten per WebFront an das WebFront usw…
Darum ist es korrekt das die Ausgabe des Webhook an den Aufrufenden (Browser, externe Software etc) geht.
Michael
Naja, praktisch alle mir bekannten I/O Instanzen zeigen den durchgeschleiften Datenstrom im Debug Fenster.
Beim Webhook bleibt es aber leer. Das ist inkonsequent. Wenn gar kein Debug Knopf da wär, OK aber da er nun mal da ist würde ich mir erwarten das er auch funktioniert.
Es gibt auch noch Leute die noch klassich mit Scripten arbeiten, da kann man dann nur mit IPS_LogMessage ins Meldungsfenster schreiben.
Wegen dem Standardoutput: OK, verstehe.
Wie gesagt ich wußte nicht welche Standards da im Hintergrund gelten. Die Anfrage kommt einfach daher, das echo(), print() und print_r() gerne zum debug genutzt werden. In diesem Falle, oder im Falle von unerwartete Warnungen gehen eben Daten irgendwohin wo sie nicht sollten. Letztlich führt es dazu das gerne mal die Ausgaben per @ komplett unterdrückt werden was wiederrum unsauberen Code hinterläßt.
Danke für den Hinweis auf den Errorhandler, mal sehen ob was ich damit anstellen kann.
Du kannst aber die Standardausgabe cachen, die Daten auslesen und woanders hinschreiben.
Dann geht nix zurück und das @ brauchst du dann auch nicht PHP: ob_start - Manual PHP: ob_get_contents - Manual PHP: ob_end_clean - Manual
Michael
PS: im WF Konfigurator und Webserver gibt es auch kein Debug und bei vielen anderen Modulen auch nicht. Und da das Webhook Control ja eine KernInstanz ist…
Aus meiner Sicht nicht. Primär kann ja der Webhook auf ein Skript verweisen, bei Skripten gab es aber noch nie eine Debug Fenster. Alternativ kann der Webhook ja auch auf eine Instanz verweisen und da ist das Verhalten genau so wie Du Dir das wünscht, Du kannst dort im Debug Fenster sehen was an Datenstrom reinkommt, ja Du hast sogar in der Hand was alles ins Debug Fenster reingeschrieben werden soll.
Nimm doch mal eines der vielen PHP Module als Beispiel z.B. hier
Da siehst Du wie Daten mit
jetzt verstehe ich das mit dem Debug. Ja - du hast Recht, dass es konsequent wäre dort alle Daten anzuzeigen (insbesonderen z.B. Daten von Aufrufen, die durch keinen Hook bedient werden) Leider verhindert der interne Aufbau der Hook Instanz dies. Die Hook Instanz (und auch OAuth Instanz) ist/sind nur ein Hilfsmittel für eine Erweiterung des internen WebServers. Sobald der Hook mit den Parametern registriert wurde, hat die Hook Instanz nichts mehr damit zu tun und kennt die Daten leider nicht. Somit kann man auch wie Nallchan/Fonzo argumentieren, dass dies keine I/O Instanz mit Datenfluss ist, sondern nur eine Kern Instanz, welche diese Funktion nicht zwingend haben muss.
Servus
Danke für eure Erläuterungen, jetzt verstehe ich die Hintergründe und ziehe meinen Antrag zurück.
Für mich war nicht ersichtlich, das das Webhook Instanz nur zur Konfiguration verwendet wird. Ich dachte da „gehen Daten durch“.
Vieleicht sollte man irgendwann andenken solchen (Kern ?) Instanzen ein passenderes Fenster zu spendieren. Vermutlich ist auch „Ereignisse " Statusvariablen“ und eben „Debug“ für viele Kerninstanzen nicht zutreffend. Also weg damit oder zumindest ausgrauen.
Falls es euch interessiert erzähle ich kurz was mir passiert ist.
Nun, ich wollte eine Arduino Anbindung von ClientSocket auf Webhook umstellen. Zusätzlich sollte der Arduino dann irgendwann außerhalb des LAN stehen, im Code sind also schon einiges dafür drin.
Nun, soweit alles nach bestem Wissen und Gewissen eingerichtet und teilweise getestet, aber beim Empfangsscript kahm nichts an.
Also begab ich mich auf die Suche: Da eben auch das Webhook Debug Fenster nichts ausspuckte lag erstmal der Schluß nahe das gar nichts bei IPS ankommt. Daraus wurde es ziemliche mühsame Suche im Netzwerk/Firewall/DynDNS/Arduino Code Gestrüpp. Diese hat aber logischerweise nichts ergeben.
Was war Schuld: Wie immer ich selbst :rolleyes: Es ging eh alles, aber im Webhook hatte ich auf ein falsches Script verlinkt, somit konnte ich im produktv Script natürlich nichts empfangen.
Klar, wenn man den Fehler mal kennt wären sehr viele schneller Wege zur Ursachenfindung naheliegend.
Aber die „fehlende“ Debugausgabe beim Webhook schickte mich komplett in die Irre.
Mit dem Webhook bringst du mich gerade wieder auf eine Idee, ich wollte schon länger ein generisches Device als Modul bauen was json-Objekte direkt als Variablen verarbeitet.
Den Webhooks als Quelle hatte ich dabei nicht auf dem Schirm.
Ohje, so viele Ideen und so wenig Zeit
Michael
