FHEM - Entwicklung > FHEM Development

FHEM2FHEM und RFHEM zusammenführen

(1/3) > >>

Adimarantis:
Hallo,

ich hatte mit dem Gedanken gespielt die Maintenance von RFHEM zu übernehmen (Chris hätte nichts dagegen und hat keine Zeit mehr zu maintainen).
Allerdings stellt sich mir die Frage der Sinnhaftigkeit, denn in der Hauptsache überschneidet sich die Funktionalität weitgehend und FHEM2FHEM ist deutlich ausgefeilter implementiert.

Die meisten Anwender scheinen RFHEM dazu zu verwenden ein remote Kommando abzusetzen. Das liesse sich in FHEM2FHEM aber leicht implementieren (hab ich testweise auf 5 Minuten eingebaut - ok, natürlich nur quick&dirty).

FHEM2FHEM hat ja sowieso einen telnet port offen. Da jetzt noch ein "set cmd ..." anzubieten welches dann ein "syswrite" macht (mit evtl. ein paar Sicherheitschecks - z.B. sollte man evtl. nur "set" erlauben) würde RFHEM komplett obsolete machen.

RHFEM prüft halt noch über ping ob der gegenüber noch da ist. Ich hatte bei FHEM2FHEM (3 Systeme) schon mal den Fall, dass alle 3 blockiert waren, weil wohl eins kurz ausgefallen war. Evtl. kann man da noch etwas optimieren?

Ich möchte daher die entsprechende Erweiterung von FHEM2FHEM anregen und würde dann RFHEM in Rente schicken.

Was meint ihr (bersonders Rudi)?

Jörg

rudolfkoenig:
Ich habe kein Problem FHEM2FHEM zu erweitern, ich brauche dazu weniger einen Patch, eher Problem- bzw. Aufgabenbeschreibungen.

Adimarantis:
Ok,

Problembeschreibung:
- Anwender möchten auf einer Remote Instanz FHEM Befehle (wie set, setreading etc.) aus DOIF, notify etc. ausführen können
Lösungsidee:
- FHEM2FHEM stellt einen neuen set Befehl "cmd:Textfield" zur Verfügung.
- Dieser nutzt die bereits bestehende Verbindung um den übergebenen Befehl 1:1 an die remote Instanz zu schicken
- Falls möglich wird die Rückmeldung (üblicherweise nur bei Fehler) gelesen und im Logfile oder asynchron in einem "lastErr" Reading angezeigt
- Potentiell kann ein erster Plausicheck (gültiger Befehl) oder eine Einschränkung auf "einfache" Befehle erfolgen (wobei ich davon ausgehe würde das der Anwender hier weiss was er tut)

Nicht ganz so wichtig, weil selten, aber eine weitere Problembeschreibung:
- FHEM2FHEM bekommt potentiell nicht oder zu spät mit wenn die Verbindung zur Remote Instanz unterbrochen/wieder verfügbar ist
Lösungsvorschlag:
- Per Timer regelmässig (Attribut) einen Verbindungaufbau (open, ping...) durchführen und entsprechend den Verbindungsstatus aktualisieren
- Wenn eine unterbrochene Verbindung wiederhergestellt ist, automatisch reopen durchführen

Gruß,
Jörg

rudolfkoenig:
Habe beides implementiert,  bitte um Feedback.

Achtung: die Fehlermeldung bei "set F2F cmd bla bla" sieht man in FHEMWEB nur in dem mehrzeiligen Befehlsdialog. Oder in einer Telnet-Sitzung.
Meldungen sieht man generell nur dann, falls der Befehl sofort was produziert, d.h. verzoegerte Ausgaben (wie bei get in manchen neueren Modulen ueblich) koennten zu unerwuenschten Nebeneffekten fuehren (vulgo: das habe ich nicht getestet).

Adimarantis:
Hallo Rudi,

"cmd" und die unmittelbare Fehlermeldung im Log funktioniert in ersten Tests ganz gut.
Bei Signalbot habe ich einige asynchrone Aufrufe implementiert um FHEM nicht zu blockieren. Da es auch hier Fehler geben kann, schreibe ich die Rückmeldung dann in das Reading "lastErr", so dass der Anwender diese zumindest verzögert sehen kann (oder man sogar eine automatische Fehlerbehandlung über Event implementieren kann). Wäre eine Option um mit den verzögerten Ausgaben umzugehen. Fehlermeldungen sollte man ja von Events unterscheiden können.

Das "keepAlive" soll ja in der Hauptsache verhindern, dass eine bestehende Verbindung bein längerer Inaktivität geschlossen wird, richtig?

Der Ansatz den RFHEM hier verfolgt ist ein anderer:
Hier wird regelmäßig ein "ping" abgesetzt (ursprünglich über einen Shellaufruf des ping Kommandos, was ich schon mal durch Net::Ping ersetzt habe).  Dadurch soll wohl erkannt werden, ob der Kommunikationspartner noch da ist. Ich denke alternativ (und sogar noch zielgerichteter) wäre ein sysopen auf den Telnet Port.
Im Fehlerfall verbindet sich das ganze Modul neu.

Ob der ursprüngliche Autor hier ein echtes Problem beheben wollte weiss ich aber nicht.

Ich hatte nur selbst schon mal das Problem bei 3 Instanzen die mit FHEM2FHEM verbunden waren. Eine der Instanzen fiel aus und als sie wieder online kam musste ich feststellen, das eine der beiden anderen Instanzen komplett blockiert war und ich FHEM abschiessen musste. Ist jetzt aber nicht wirklich reproduzierbar.

Jörg

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln