Hallo,
ich ändere innerhalb meines FHEM Systems einige Readings von 'außen', also einem anderen System, mit "fhem?cmd=...&XHR=1". Das funktioniert super, allerdings wird als Antwort von FHEM jedesmal die gesamte Oberfläche (HTML) zurückgegeben, was natürlich für unnötig Last im Netzwerk sorgt. Kann man das so ändern, dass nur "ok" oder "1" oder so zurück gegeben wird?
In dem Du z.B. über terminal oder mqtt gehst .... gibt bestimmt auch noch mehr Möglichkeiten
Terminal war mir zu instabil. Das Gerät, was die Daten zum FHEM sendet (ebenfalls ein FHEM), ist per WLAN im Netz. Und WLAN am Raspberry ist so eine Sache: Dauernd war die Verbindung weg. mit &XHR=1 läuft es super, allerdings benötige ich den ganzen Feedback-Overhead nicht.
ZitatTerminal war mir zu instabil.
Sorry aber dem kann ich zu 100% Wiedersprechen. Wenn man nicht mit fhem.pl, sondern ncat (o.Ä.) Arbeitet, geht es supereinfach und superstabil. habe es hier mehrfach im Einsatz.
Wenn Du aber so große Netzwerkprobleme hast, ist gerade der Einsatz von MQTT die große Alternative. Gerade das Protokoll ist entwickelt worden für instabile Netze ....
P.S.
Du hast eventuell eine FritzBox-Wlan und verwendest die Interne Raspi-WLan-Hardware?
Dann ist klar, warum Du WLAN-Probleme hast ....
P.S.S.
Erst jetzt gelesen: Du willst also eigentlich Daten von FHEM zu FHEM bringen?
Ja, von FHEM (Heizungszähler im Stromkasten ohne LAN) an FHEM (außerhalb Stromkasten mit LAN).
FHEM2FHEM war völlig instabil, das habe ich aufgegeben.
FHEM2FHEM nutzt das Terminal, aber Terminal muß nicht gleich FHEM2FHEM sein. Du hast danach gefragt, Werte in FHEM reinzupusten. Das geht eben mit dem Terminal super .....
Hast du ein praktisches Beispiel?
- Hast Du im Telnet ssl aktiviert oder nicht?
- Mit oder Ohne Passwort?
Ohne SSL: Zitiere mich mal selber: https://forum.fhem.de/index.php/topic,80371.msg723862.html#msg723862 (https://forum.fhem.de/index.php/topic,80371.msg723862.html#msg723862)
P.S. Sufu benutzt?
Zitat... von FHEM (Heizungszähler im Stromkasten ohne LAN) ...
wie kommen denn die daten aus dem schrank raus?
wlan, oder?
Ja
????? Was willst Du uns damit sagen ?????
War die Antwort auf "wlan, oder?".
Die Frage ist halt: Kann ich "fhem?cmd=...&XHR=1" verwenden, ohne den ganzen Kladeratsch als Rückwert zu bekommen?
[Edit]
Wobei mir gerade einfällt, vielleicht geht es mit "HEAD" statt "GET".
Antwort: Nein, bei HEAD statt GET kommt auch ganz viel zurück
[/Edit]
Mir nicht bekannt .... was aber diesbezüglich nichts heißt ....
Na dann mache ich doch mal einen Feature-Request @RudolfKoenig. Vielleicht über einen Parameter "output=0" / 1 / 2 steuerbar. 0 = Leere Seite, 1 = "OK", 2 = "wie aktuell". Default dann halt 2.
Ob der dieses hier liest ist Fraglich ....
Aber mal ein kurzer Blick in die Doku:
https://fhem.de/commandref.html#HTTPAPI (https://fhem.de/commandref.html#HTTPAPI)
Zitat von: Det20 am 30 November 2022, 12:11:42
Die Frage ist halt: Kann ich "fhem?cmd=...&XHR=1" verwenden, ohne den ganzen Kladeratsch als Rückwert zu bekommen?
Ich würde Dir MQTT empfehlen. Aber wenn Du das nicht willst, kannst Du per HTTP und einem Script das ganze erledigen:
https://heinz-otto.blogspot.com/2019/02/fhem-http-client.html
Gruß Otto
Ach, auf die Idee mit Telnet bin ich noch garnicht gekommen. Wie schicke ich den Befehl denn von 'innen' los?
So?
use Net::Telnet();
my $tab = new Net::Telnet (Timeout => 50,Port => 7072);
$tab->open("192.168.100.29");
# $t->login($username, $passwd);
$tab->print("setreading a test 1");
return "OK";
FHEm Telnet macht nicht das Login wie Standard Telnet, sondern einfach, in dem das PW gesendet wird .. siehe meinen Link ein paar Beiträge oben ...
Zitat von: Wernieman am 01 Dezember 2022, 12:58:50
FHEm Telnet macht nicht das Login wie Standard Telnet, sondern einfach, in dem das PW gesendet wird .. siehe meinen Link ein paar Beiträge oben ...
Habe es versucht, funktioniert super und schnell, allerdings nur synchron. Bekommt man das auch asynchron hin? Und was meinst du mit PW?
Zitat"fhem?cmd=...&XHR=1"
Schon mal folgendes probiert:
"fhem?cmd=...&XHR=0"
Wie ...? XHR=0 ist ohne Output? Das wäre zu einfach.
Aber so einfach ist es...
Nope, bringt nix, kommt alles genauso wie mit xhr=1
Zitat von: Det20 am 01 Dezember 2022, 13:06:31
Habe es versucht, funktioniert super und schnell, allerdings nur synchron. Bekommt man das auch asynchron hin?
Was meinst Du mit synchron oder asynchron ? ???
Hast Du eigentlich meinen Beitrag #15 gelesen?
Zitat von: Otto123 am 01 Dezember 2022, 16:58:20
Was meinst Du mit synchron oder asynchron ? ???
Dass fhem während der telnet Ausführung nicht blockiert
Also, soweit ich weiß hat fhem keine Rest-API. Es ist mir auch unklar was hier wirklich die Anforderung ist.
Geht es wirklich nur darum Daten aus einem fhem an ein zweites fhem zu senden?
Warum wird das per http-GET gemacht? Es gibt doch auch andere Wege ohne Overhead.
Aber hier ist schienbar eine Rest-API Mal entwickelt worden: https://github.com/matgoebl/FhAPI
BTW, du schreibst, dass fhem bei "ohne Output" ein ok liefern soll? Wozu dann doch Inhalt im Body? Wenn der Response-Header mit 200 bereits sagt "okay!"?
Zitat von: Det20 am 01 Dezember 2022, 18:13:28
Dass fhem während der telnet Ausführung nicht blockiert
Dabei wird FHEM nicht automatisch blockiert. Da wird ein Befehl an FHEM gesendet. Wenn dessen Ausführung FHEM blockiert ist es genauso wie wenn der Befehl auf anderem Weg zu FHEM gelangt.
Also mMn ist besteht kein Unterschied zwischen Befehlen über FHEM, übers Web Interface oder über die Telnet Schnittstelle.
Ne, ich meine das System, das sendet. Einen HTTP-Request kann ich NonBlocking abschicken. Habe ich einen Timeout von 2 Minuten, geht das (FHEM-) Leben trotzdem weiter.
Habe ich bei Telnet einen Timeout von 2 Minuten, dann bleibt die (FHEM-) Welt solange stehen und löst ggf ein Watchdog-Event aus. Ich könnte es höchstens in einen Thread auslagern, weiß aber nicht, wie FHEM damit umgehen kann.
Aber das eigentliche Problem ist doch nicht das bisschen Traffic? Deine Netzwerkverbindung ist unbrauchbar. Was ist das Problem dort anzusetzen?
Doch, genau das ist es. Von der Logik her macht das ja auch keinen Sinn: Ich nutze die direkte Ansteuerung ja, um *ohne* die Oberfläche etwas zu schalten. Zurück bekomme ich aber die *gesamte* Oberfläche. Das ist doch sinnfrei, wenn ich das wollte, dann könnte ich mich ja auch direkt einloggen. Also wird automatisiert etwas von außen aufgerufen, um zu schalten. Dieser Automatismus bekommt aber etwas zurück, mit dem er sowieso absolut garnichts anfangen kann: Unnötige Bytes in Form der gesamten Oberfläche. Wenn ich auf diese Art nun 20 Readings von außen aktualisiere und das im 10 Sekunden Intervall, dann bekomme ich pro Minute 6*20*ca-12 KB unnötige Daten geliefert. Macht bei Gigabit vielleicht nicht viel aus, bei einer schlechten WLAN Anbindung aber schon.
Nutze ja in einer Datenbank auch kein 255 Zeichen VARCHAR Feld für eine Postleitzahl, einfach nur weil es geht. Vielleicht bin ich aber auch einfach nur von der alten Schule und achte auf Platzverschwendung. Stamme halt aus Zeiten, als man sich noch Gedanken über Speicher-Optimierung machen musste.
Aber davon ab ist die Telnet-Lösung eleganter und hat deutlich weniger Overhead. Müsste halt nur noch klären, inwiefern das öffnen/verbinden/schließen FHEM auf Sender-Seite blockiert.
Kannst Du ja dafür ein Modul scheiben und es non-Blocking ausführen ;)
Aber worauf ich von Dir noch keine Antwort bekommen habe, frage ich zum letzten mal: Dir meinen Beitrag #15 angesehen?
Btw:
Und MQTT ist auch keine Möglichkeit für Dich?
Ja, #15 angesehen, bringt mir aber nix. Ich kann mit HTTP Daten abrufen. Wenn aber 12 KB zurückkommen, dann kommen die zurück, egal wie ich abrufe. Das ist doch genau mein ursprüngliches Problem. Ich glaube wir drehen uns im Kreis.
Ich glaube wir drehen uns im Kreis.Ich glaube Du baust Problem auf wo keine sind ::)
Du willst Telnet von FHEM aus machen? (Sorry aber der eigentliche Use Case ist irgendwie wegen der ganzen Problemwellen verloren gegangen)
https://fhem.de/commandref_modular_DE.html#command
So ein FHEM Aufruf blockiert nicht sondern wird im Hintergrund (extra Prozess) aufgeführt:
"echo set lamp on|nc DeinHost -w 1 7072"Aber wenn Du "knausrig" ;) bist und die Verbindung schlecht ist: MACH ES MIT MQTT!
Edit:
ZitatIch kann mit HTTP Daten abrufen...
Ich meine die FHEM HTTP API arbeitet anders, da wird ja nicht FHEMWEB abgefragt. Du solltest Dir das wirklich anschauen und nicht einfach mutmaßen :)
Edit:
ZitatFHEM2FHEM war völlig instabil
das nutzt allerdings die Telnet Schnittstelle. Ich fürchte aber eher das instabil war durch falschen Einsatz / Konfig begründet? Wie zeigte sich diese Instabilität? Wie war die Konfig?
Aber wenn dies alles richtig konfiguriert war, dann setze bitte wirklich auf MQTT. Das ist dafür designed.
also ich hab mal fix mit http-api aus #15 getestet ....
Aber wie mehrfach betont, ohne funktionierendes Netzwerk wirst du selbst damit Probleme bekommen.
Sorry aber jetzt stehe ich auf dem Schlauch. Kannst Du mir bitte die Grafiken erklären?
Das sind die Entwicklertools vom Browser... Das waterfall-diagramm ist in diesem fall nicht sehr umfangreich, damit analysiert man Webseiten um zu schauen wann was vom Browser geladen wird und wie lange es jeweils dauert....
In der Tabelle unten steht quasi, was was ausgeführt wurde, was geladen wurde und auch woher. Wichtig ist size und die Zeit wie lange es gedauert hat.
Ich wollte nur zeigen, dass er nur 109byte übertragen hat.....
Im zweiten Beispiel habe ich zwei Kommandos aufgezeichnet, jeweils 109byte....
Also genau das, was der Threatersteller wollte .....
Danke für Deine Erklärung! (Wobei ich die Entwicklertools kenne, nur hatte ich irgendwie das Diagramm nicht verstanden ...)
Mich interessiert jetzt schon noch was daraus geworden ist. Die httpapi aus #15 müsste ja die zufriedenstellende Lösung gewesen sein?
Oder ist der TE jetzt doch darauf gekommen, dass das eigentliche Problem das Netzwerk ist?
Viele Grüße
Andreas
Also, nimm es mir nicht übel, aber du kannst jetzt noch 100 mal schreiben, dass das Netzwerk das Problem ist, ändert jedoch nichts an der Tatsache, dass KEIN LAN KABEL IM STROMKASTEN ist. Nix. Null. Nur WLAN. Punkt.
Und eine api Schnittstelle gibt keine Kilometerlangen Resultate zurück. Weder in pascal noch c# noch c++. Nur 0,1 oder tatsächlich angeforderte Daten. Weiß ich, bin Entwickler. Darum ging es ursprünglich.
Ich habe es mit telnet gelöst. Es wird alle 10 Sekunden eine Verbindung geöffnet und alles auf einmal verschickt. Kommt es zu einem Fehler (eval), dann wird alles in einen Cache geschrieben und beim nächsten mal mit übertragen