FHEM von außen steuern - Overhead

[bartman121]

Aber das eigentliche Problem ist doch nicht das bisschen Traffic? Deine Netzwerkverbindung ist unbrauchbar. Was ist das Problem dort anzusetzen?

[Det20]

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.

[Wernieman]

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?

[Det20]

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.

[Otto123]

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

"echo set lamp on|nc DeinHost -w 1 7072"

Aber wenn Du "knausrig" bist und die Verbindung schlecht ist: MACH ES MIT MQTT!

Edit:

Ich 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:

FHEM2FHEM 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.

[bartman121]

also ich hab mal fix mit http-api aus #15 getestet ....

Aber wie mehrfach betont, ohne funktionierendes Netzwerk wirst du selbst damit Probleme bekommen.

[Wernieman]

Sorry aber jetzt stehe ich auf dem Schlauch. Kannst Du mir bitte die Grafiken erklären?

[bartman121]

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....

[Wernieman]

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 ...)

[bartman121]

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

[Det20]

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