Modul SISPM (SIS_PM)

[Wernieman]

Hallo Kollegen,

wir eigentlich das Modul SISPM (bzw. SIS_PM) noch weiterentwickelt? Oder ist es verweist?

Mir sind da nur einige "Kleinigkeiten" Aufgefallen ... um es weiterzuentwickeln.

Gruß,
Werner

[nias]

bei mir funktioniert es nicht mehr, sobald ich das Modul SISPM hinzufüge (mit korrektem Pfad) stürzt fhem mit "Out of memory" ab.
Und das bei auf folgendem Rechner:

Code Auswählen Erweitern


# free -h
              total        used        free      shared  buff/cache   available
Mem:            15G        3,1G        1,8G        130M         10G         11G
Swap:          2,0G         13M        2,0G


sehr ärgerlich und ich hab noch keine Ahnung wie ich dem auf die schliche komme.
Auf ner bash geht das schalten (auch als fhem-user) problemlos....

[Wernieman]

Habe mittlerweile es anders gelöst. Da ich fhem nur zum schalten brauche, also nicht für Rückmeldung, lasse ich es mitlerweile mit einem externen Script laufen. Zusätzlich sind einige Dosen zu einem anderen Pi gewandert und das kann dasd Script gleich mit erledigen ...

Mann könnte das Modul auch ausbauen, nur ... bin ich kein guter Modulentwickler

[nias]

Hab den Fehler im Module gefunden,
da wurden "File-Descriptor" (wird abgelegt im Module-Hash $hash->{FD} für select-Aufrufe die durch fhem ausgeführt werden) und "File-Handle" (Ergebnis des open() calls und zum Lesen via sysread) völlig durcheinander gebracht.

Im Module-HASH ($hash->{FD}) wurde einfach das File-Handle abgelegt anstatt der File-Descriptor, fileno($fh).
siehe Module Code:

Code Auswählen Erweitern


open($FH, $tmpdev);
...
$hash->{FD}=$FH;
$selectlist{"$name.pipe"} = $hash;

Wie das überhaupt mal funktioniert hat ist mir noch unklar...

Das erklärt aber dann vermutlich auch das out-of-memory bei mir, fhem erzeugt eine Bitmask für alle FDs vor dem select Aufruf:

Code Auswählen Erweitern

vec($rin, $hash->{FD}, 1) = 1
Wenn in FD jetzt mal ein 64bit Pointer (das $FH anstatt fileno($FH)) drin steht kann der auch sehr groß werden und den Vector explodieren lassen...

Das Module 70_TellStick.pm macht es übrigens genauso falsch, stammt aber auch vom gleichen Autor.

Die SISPM (und TellStick) Module brauchen glaube ich einen kompletten Rewrite....

Was sind denn eigentlich deine "Kleinigkeiten" für das Module?

[Wernieman]

Muß gestehen .. habe es vergessen ;o)

[rudolfkoenig]

Das erklärt aber dann vermutlich auch das out-of-memory bei mir, fhem erzeugt eine Bitmask für alle FDs vor dem select Aufruf:

Ich habe mit einem Testprogramm (vec + select) herumexperimentiert:
- unter OSX gibt es einen Abbruch wg. "Negative offset to vec in lvalue context"
- unter Linux keine Fehlermeldung, das Testprogramm verbraucht 4 bis 10 MB mehr Speicher, als mit fileno($fd)
- strace vom Testprogramm stuerzt ab mit Abort / core dumped.
- habe TcpServerUtils.pm temporaer "kaputtgemacht": FHEM war extrem langsam (eine Minute warten im Telnet nach dem return), hat aber keine CPU, und "nur" 7MB mehr benoetigt.

Wie auch immer, es gehoert gefixt, nach einer ersten Suche scheint 70_TellStick.pm und 70_SISPM.pm betroffen zu sein.
Bin unsicher, ob und wenn ja wie fhem.pl sich dagegen wehren soll.

[Wernieman]

Weiß auch wieder einen Punkt, warum ich denh Thread eröffnet hatte.

Die SISPM-Dosen haben Probleme beim schalten Induktiver Lasten. Dabei können Sie sich kurzfristig verabschieden, wenn es zu häufig passiert sogar den USB-Bus "mitreißen". Es wäre eigentlich gut, diesbezüglich eine Fehlererkennung einzubauen.

Nur (s.o.) bin kein guter Modulentwickler ...