Hallo,
Ich hab von Anfang an Probleme mit der Zuverlässigkeit von PRESENCE, wenn ich das richtig verstehe kommt das so:
Da ich den Telnet Zugang als erstes dichtmach (Sicherheitstema, ich mags nicht unnötig viele aktive Module zu haben), kommt es zum aufhängen des Moduls wie hier http://forum.fhem.de/index.php?topic=27800.0 beschrieben.
Ich mach aber kein rereadcfg, das scheint auch beim save zu passieren.
Nun hängt zumindest für mich ziemlich viel an der Anwesenheit, darüber steuer ich die meissten Sachen.
Wäre es nicht sinnvoll das Modul irgendwie umzubauen, so das es vllt einen eigenen Thread benutzt aber nicht diese merkwürdige Geschichte über die Telnet Instanz ?
Programmieren und Debuggen von multithreaded Anwendungen ist aufwendig, und kann mAn nicht allen FHEM-Programmierern bzw. Endanwendern (siehe at/notify/etc) zugemutet werden. Viele FHEM-Module (z.Bsp. FHEMWEB) gehen davon aus, dass keine parallele Modifikation globaler Variablen stattfindet, weiterhin unterstuetzen die Fritzbox-Perl-Versionen (und vermutlich auch die fuer NAS) kein Threading.
Das von dem PRESENCE verwendete Blocking Modul unterstuetzt z.Zt. zwar weder Passwort noch SSL bei telnet, man kann aber die telnet-Instanz so anlegen, dass Verbindugen nur vom lokalen Rechner angenommen werden. Falls jemand mir konkrete Probleme mit dieser Methode aufzeigt, dann werde ich Blocking so erweitern, dass SSL + Passwort verwendet werden koennen.
Nunja das Modul wurde ja extra so gebaut, dass die Anwesenheitsprüfungen in einem separaten Prozess (Fork) stattfinden, da es sonst FHEM timing-technisch arg in Verzug bringt. Aktuell ist die einzige Möglichkeit dem Haupt-Prozess das Ergebnis mitzuteilen über telnet. Es gibt von Boris Neubert und von justme1968 bereits neue Ansätze sowas über Threads bzw. Forks mit Interprozesskomunikation zu machen, wo dieser telnet-Zugang nicht mehr notwendig wäre. Ich weis nur leider nicht, wie da momentan der Stand ist. Bisher ist es da etwas still geworden meiner Meinung nach.
Aktuell braucht PRESENCE allerdings einen loopback telnet-Zugang. Wenn aber keine brauchbare telnet-Instanz vorhanden ist (wg. SSL, Passwort,...) wird eine eigene telnet-Instanz erzeugt, die nur loopback-Verbindungen annimmt.
Gruß
Markus
Zitat von: Markus Bloch am 29 März 2015, 11:12:43
Es gibt von Boris Neubert und von justme1968 bereits neue Ansätze sowas über Threads bzw. Forks mit Interprozesskomunikation zu machen, wo dieser telnet-Zugang nicht mehr notwendig wäre. Ich weis nur leider nicht, wie da momentan der Stand ist. Bisher ist es da etwas still geworden meiner Meinung nach.
Ich wusste, dass auf SubProcess.pm referenziert werden würde. ;)
SubProcess.pm funktioniert. Andre und ich wollten uns noch überlegen, wie man die bereits jetzt mit SubProcess.pm mögliche Kommunikation im Freiformat durch eine standardisierte Kommunikation mit JSON ersetzen kann. Aufgrund Zeitmangel ist da noch nichts passiert.
Soll ich SubProcess.pm nach FHEM einchecken? Dazu gibt es auch ein edukatives Beispielmodul. Du könntest PRESENCE darauf testweise umstellen.
Grüße
Boris
Hallo Boris,
das wäre sehr nett, dann kann ich mal eine Version von PRESENCE basteln mit SubProcess.pm und schauen wie sich das ganze in der Praxis verhält.
Gruß
Markus
PS: wollte soeben nochmal höflich nach meinen TimeSeries.pm Bugs nachfragen, aber da kam soeben eine ganze Ladung E-Mails :-) Danke
Hallo Markus,
SubProcess.pm ist jetzt in FHEM und das Beispiel in contrib/SubProcess.
Wenn Dir bei der Verwendung Ideen kommen, wie man mit noch weniger Kodezeilen beim Verwender auskommt oder den Aufruf simpler gestalten kann oder wenn Du noch weitere Event-Funktionen (derzeit onRun und onExit) benötigst, dann sage bitte Bescheid.
Die Kommunikation zwischen dem nebenläufigen SubProcess und dem den SubProcess verwendenden Modul findet statt, indem der SubProcess irgendwas in der nebenläufigen onRun-Routine auf den Filedescriptor schreibt. Für das verwendende Modul sieht es so aus, als ob es spontan irgendetwas von einem Gerät empfangen hätte.
Andre und mir schwebt vor, dieses "irgendwas" über ein JSON-API zu standardisieren. Idealerweise verwenden wir irgendwann für die Kommunikation zwischen isolierten Bestandteilen (FHEMWEB - Javascript im Browser, Subprocess - Modul, etc.) immer nur einen Standard in einem noch zu schaffenden Modul JSONAPI.pm.
Bitte die Diskussion zum Modul Subprocess hier weiterführen:
http://forum.fhem.de/index.php?topic=34320 (http://forum.fhem.de/index.php?topic=34320)
Viele Grüße
Boris
Ich spiel gern Versuchskaninchen wenn nötig.
Nunja, da wird ein wenig Geduld von nöten. Ab nächste Woche beginnt das neue Semester, da muss ich wieder reinhauen ;-)
Nachdem ich den Fehler nun verstanden hab (zumindest ausrechend) lass ich einfach eine Telnet instanz offen, das sollte ja erstmal reichen um den Fehler zu umgehen. Zumindest für mich, aber warscheinlich schaltet sonst kaum jemand Telnet ab.