sis-pm + SiSPwCtrl und freetz

[xequtor]

es gibts den sispmctl im freetz aber es ist schon alt, es gibts eine neu Version hier
http://sourceforge.net/projects/sispwctrl , wäre es möglich den Paket in freetz-trunk zu integrieren?

Hat paar mehr Funktionen sogar für Mobile Browser (iPhone, Android) ne GUI

 

[meiser79]

Das ist keine neue Version, das ist ein anderes Projekt.

Das Bauen des Binaries ist kein Problem, die Integration des Web-Interfaces jedoch bedarf einer Untersuchung, da es komplett anders im Vergleich zu sispmctl realisiert wurde.

 

[olistudent]

Für was sind denn die beiden Webinterfaces?

Einmal das Control-Interface wie auf der Sourceforge Seite? Und das zweite ist das aus dem Screenshot oben? Benötigt man die dann beide?

Gruß
Oliver

 

[MaxMuster]

Versuche doch mal dieses tgz im freetz-Ordner auszupacken.
Danach einmal(!) "sed -i '/sispmctl/ asource make/sispwctrl/Config.in' make/Config.in " (um es im Menu einzufügen).

Gebaut wurde es bei mir, aber ob es was "Sinnvolles" tut?!? Das mit dem "Web" funktioniert so noch nicht (ist halt nur vom "sispmctl" kopiert...)

EDIT: Neue Version, die die Files für das WebIF nach /usr/share/sispwctrl kopiert. Es gilt weiterhin, keine Ahnung, ob/wie das funktioniert...

 

[xequtor]

Meine SIS-PM Stromleiste kann ich heute abholen und dann teste ich was und wie geht.

@olistudent

Die eine web gui zeigt den Status

und die andere zum aus/einschalten und auch status.

Ich glaube man braucht die beide nicht also nur web2

Edit: Man brauch beides, in web1 werden mehrere SIS-PM gezeigt wenn angeschlossen.

 

[hermann72pb]

Welche von den beiden kann von dem Windows-Client angesprochen werden? Hat da jemand Erfahrung? Ich habe nämlich diese SIS-PM im Einsatz, allerdings an einem Windows-Rechner angeschlossen. Ich wusste nicht, dass das Ding bereits in FREETZ integriert ist. Ich war schon kurz davor, mir die Quellen anzuschauen und selbst für FREETZ anzupassen. Aber wenn es schon gemacht wurde, dann danke! Ich würde es ausprobieren.

Diese SIS-PM ist echt eine geniale Sache und ist zudem relativ preisgünstig (40 Euro) z.B. bei Pearl zu beziehen. Reichelt hat z.B. ähnliche Leisten mit einem Netzweranschlüss. Sie kosten allerdings 100 Euro. Das Schöne an SIS-PM: Es gibt Linux-Quellen dafür und man kann die Leiste theoretisch von jedem Kleinlinux (NAS, Mediabox, Fritz!Box) steuern.

Meine praktischen Erfahrungen an einem Win7-Rechner zeigen jedoch, dass USB-Schnittstelle sich ab und zu "aufhängt". Dabei hilft es nur USB-Stecker ausziehen und wieder einstecken. Ich hoffe allerdings, dass es sich hierbei um ein reines Windows--Treiberproblem handelt.

MfG

 

[cuma]

Hm, für 40 Euro (bzw 34 bei Amazon) wird die Sache tatsächlich interessant

 

[olistudent]

Edit: Man brauch beides, in web1 werden mehrere SIS-PM gezeigt wenn angeschlossen.

web2 ist doch wahrscheinlich die Handy-Variante? Über web1 hat man alle Möglichkeiten.
Auf der anderen Seite sind das auch nur ein paar Tausend Bytes für das zweite Webinterface, daher könnte man auch gleich beide in unterschiedlichen Pfaden einbauen...

Gruß
Oliver

 

[hermann72pb]

...Neue Version, die die Files für das WebIF nach /usr/share/sispwctrl kopiert. Es gilt weiterhin, keine Ahnung, ob/wie das funktioniert...

Warum gerade in dieses Verzeichnis?
Das heißt, wenn wir ein WebIF dafür brauchen, müssen wir httpd mit einem bestimmten Port auf dieses Verzeichnis starten.
Ich habe gerade in meinem SIS-PM-Klient für Windows rumgeschaut. Dort gibt es eine Option SIS-PM per Netzwerk einzubinden:

Wenn ich es richtig verstanden habe, dürfte auf dem Port 5000 ein Dienst laufen, welcher sogar Passwörter beherrscht. Das würde bedeuten, dass man für SIS-PM auch ein rc-Skript braucht.

MfG

 

[fbfuser]

Dazu muss aber der WIN PC ständig laufen, was keinen Sinn macht.

Ich habe mir auch die SIS-PM gekauft um sie mit einer FBF7170 zu steuern. Das funktioniert auf Grund des verwendeten USB Chips in der BOX nicht.
Mit der FBF7270 ist eine (manuelle) Steuerung recht aufwändig mit den bisher in Freetz integrierten Funktionen.

Bisher funktioniert das bei mir nur, dass ich ein Telnet Fenster öffne und in dem das 'Webmenü' der SIS-PM Software die Steckdosen schalte. Sobald das Telnet Fenster zu ist, besteht auch keine Möglichkeit mehr die Ausgänge zu schalten.

 

[MaxMuster]

Warum gerade in dieses Verzeichnis?

Ich habe das nur aus Bequemlichkeit (oder Unnkenntnis, oder beiden ;-)) direkt so übernommen, weil die "Vorlage" (das Paket sispmctl) seine Web-Sachen nach /usr/share/sispmctl
kopiert hat...

 

[hermann72pb]

@fbfuser: Du hast mich nicht verstanden. Wenn du die Leiste direkt an den PC anschließt, dann muss der Rechner laufen. Das, was ich dort als Bild gezeigt hatte, ging allerdings in die andere Richtung: Die Leiste ist schon an der Fritz!Box angeschlossen, du steuerst sie aber von einem Windows-Rechner über diese Klient-Software und anscheinend über Port 5000. Aber so, wie ich dich verstanden hatte, gibt es diese Service-Funktionalität noch nicht auf dem Port 5000 der Box über diese Binary. Sprich, meine Befürchtungen waren schon richtig: Alles ist noch ziemlich in Kinderschuhen und bedarf noch viel Anpassung an FREETZ.
Zu deinen Behauptungen mit der 7170. Da verstehe ich es nicht so recht. Was soll an dem USB-Chip von einer 7170 anders sein als bei einer 7270? Ich würde eher behaupten, dass die Quellen für den Treiber mit einer 7170 nicht laufen, weil 7170 noch einen älteren Kernel benutzt. Das wäre natürlich schade... Aber danke für den Hinweis: Ich wollte nämlich mit meiner 7170 starten. Wenn es aber nicht geht, dann mache ich es gleich auf einer 7270.
Zu deinen Telnet-Sitzungen. Dieses Verhalten ist voll logisch. Wenn du in einer Session eine Anwendung startest und dann die Session schließt, dann "stirbt" diese Anwendung meistens. Lies dich bitte etwas im Netz dazu ein, wie in Linux Eltern-Kind-Beziehungen bei den Prozessen ablaufen. Deswegen meinte ich es mit dem Dienst: Man sollte einen Daemon haben, diesen Daemon mit einem rc-Skript starten. Oder eben inetd dafür nutzen, wenn es sich z.B. um ein WebIF handelt.


Edit: Ich hatte mir nochmal die Sourcen von beiden Paketen angeschaut. Meine Zusammenfassung: Beides ist für eine Fritz!Box ziemlich übertrieben gestaltet, was vor allem WebIF angeht.
sispmctl ist meiner Meinung nach für uns besser geeignet. Es gibt es mittlerweile in Version 2.7. Wir müssen bei uns also in den Sourcen von 2.6 auf 2.7 upgraden. sispmctl wird auch offiziell vom Hersteller empfohlen. Der Nachteil von sispmctl scheint die Benutzung von Python zu sein, wobei ich beim Diagonalllesen nich verstanden hatte, wofür denn Python da gut sein sollte.
sispwctrl scheint jedoch eine Nachaffung vom bestehenen Paket sispmctl zu sein und gilt in erster Linie größeren Servern / NAS, die einen laufenden Server mit PHP haben. Wenn ich es richtig beim Diagonalquerrlesen der Quellen / Skripte verstanden hatte, zielt es eher darauf hin ohne große Veränderungen am Linux-System selbst anhand den CGI-Sachen SIS-PM zum laufen zu kriegen. Das ist meiner Meinung nach ein komplett falscher Einsatz für FREETZ.
Meine Empfehlung wäre: Wir sollen beide Sachen vergleichen, uns für eine oder andere entscheiden, bei der wir mehr für uns gebrauchen können. Den Rest: Shell-Skripte, rc-Scripte, WebIF, basierend auf httpd/shell-cgis muss man speziell an FRETZ anpassen und wahrscheinlich neu schreiben.

Edit2: Je weiter ich lese, desto mehr bestätigt sich meine ursprüngliche Vermutung: sispmctl ist deutlich reifer und besser für uns geeignet als sispwctrl. Viel neuer ist die zweite auch nicht. Auch dort scheint die Entwicklung momentan eingeschlafen zu sein. Dass sispwctrl C++ anstatt C benutzt und angeblich objektorientierter als sispmctl ist, heißt für mich noch gar nichts. Dafür habe ich bei sispmctl die oben genannte Netzwerkfunktionalität gefunden:

....
-p     IP network port (default: 2638) for listener. There is no authentication implemented yet.
....

Also, alleine dies schon ergibt für mich mehr Wert, als alle Klicki-Bunti Android/IPhone WebIFs, die bei uns in FREETZ sowieso zum scheitern verurteilt sind, weil sie auf PHP bauen.

MfG

 

[olistudent]

Bitteschön: http://freetz.org/changeset/6671

Gruß
Oliver

 

[hermann72pb]

Danke, Oliver. Wärest du 5 Minuten schneller gewesen, hätte ich es mir ersparen können, MD5 selbst auszurechnen und bei mir lokal alles abzuändern. Jetzt wird mein Image wohl mit einem "M" dahinter leben müssen...
Kompilieren ist übrigens durchgelaufen. Ich werde gleich flashen und meine SIS-PM daran anschließen. Danach geht es an die 7170. Ich glaube nämlich nicht, dass sis-pm dort nicht läuft und gebe nicht so leicht auf...

MfG

 

[olistudent]

Du hast oben von LAN geredet? Es gibt welche mit Netzwerk-Anschluss und die günstigeren Modelle haben nur USB?

Die Größe spricht eindeutig für sispmctl. Das Binary ist winzig und man benötigt keine uClibc++. Man könnte die Steuerung ja sogar direkt in das Freetz Webinterface (Shell Skripte) einbauen...

Gruß
Oliver

 

[hermann72pb]

Hallo Oliver,

du hast Recht. Auf der Seite von SisPwCtrl gibt der Autor auch zu, dass sein Ding ziemlich buggy ist und eigentlich sehr, sehr gross ist. Von daher tendiere ich eher dazu, dass wir das Ding vergessen sollen und uns auf dem alt bekannten sispmctl konzentrieren.

sispmctl läuft auf meiner 7270 grundsätzlich. Mir ist binnen 5 Minuten gelungen mein SIS-PMs anzusprechen und von der Box heraus einzelne Steckdosen ein-/ und ausschalten. Man kann auch den Status abfragen und, und und. Also, Binary an sich läuft ganz gut und erfüllt ihre Hauptfunktionen.

Was allerdings etwas schleppend und nicht ganz zufriedenstellend läuft ist Listener-Mode mit dem eingebauten Webserver. Obwohl auch hier ist es mir schließlich gelungen das Ding im Listener-Mode zu starten. Über Firefox konnte ich ziemlich rudimentär die einzelnen Steckdosen per Klick ein- und ausschalten. Das Ding läuft allerdings nicht so richtig als Daemon (verschwindet nicht in den Hintergrund) und damit gibt es einige Probleme. Man kann es zwar mit dem & am Ende starten, aber auch dies scheint noch nicht so ganz sauber zu laufen. Da muss man noch Paar Schleifen drehen, bis man es herausbekommt, wie man das Ding richtig als Listener-Daemon starten kann.
Was auch schlecht bzw. gar nicht funktioniert: Client-Verbindung vom Windows-Klient zu diesem gelisteten Webserver auf Port 2368. Interessanterweise sagt der Windows-Klient, dass er ein Device im Netzwerk gefunden hat und meldet auch "verbunden". Kurz darauf scheint jedoch sispmctl in seinem Listener-Modus abzustürzen. Die Ursachen dafür können darin liegen, dass die Klient-Software vor kurzem überarbeitet wurde. Auf der Webseite zu sispmctl schreibt der Autor auch dass der eingebaute Webserver (der dann auf dem Port 2368 lauscht) ziemlich rudimentär ist und z.B. mehrzeilige Anfragen usw. nicht ab kann. Ist auch nicht verwunderlich, schließlich ist das Binary so klein, um da noch einen vernünftigen Server einzubauen. Ich vermute, dass da etwas mit der Verbindung zwischen dem Klient und dem Server nicht passt und muss gefixt werden.
Zu Not kann man aber diese Webserver-Funktionalität mit httpd und Shell-Skripten nachbilden, wenn es anders nicht gehen sollte. Auf jeden Fall sehe ich da mehr Chancen als bei dem anderen überzogenen "Nachfolger".

Das, was oben als Hauptvorteil verkauft wird, dass man angeblich zwischen mehreren Devices umschalten kann, sehe ich gar nicht als Vorteil. Bei sispmctl wird diese Funktionalität dadurch gelöst, dass man pro Device einen eigenen Port spendiert und dort Listener startet. Denn zu Einem: Wer wird schon mehr als eine Vierfachsteckdosenleiste an eine Fritz!Box anschließen. Und zum Anderen: Wenn er das schon tut, dann kann er sie auf unterschiedlichen Ports auch aufrufen.

Ich kämpfe noch weiter und berichte später über meine Erfolge / Misserfolge.

MfG

 

[RalfFriedl]

Um ein Programm richtig im als Daemon laufen zu lassen, braucht es nur einige wenige Anweisungen, die man schnell herausfinden kann, und die Quellen sind ja anscheinend vorhanden.

Möglicherweise wäre es sinnvoll, das Programm über inetd aufzurufen, oder als cgi von einem vorhandenen Webserver aus.

 

[hermann72pb]

Naja, wie man es über inetd aufrufen kann, das weiß ich nicht. So wie ich es den Aufrufparametern entnehmen konnte, ist sowas zunächst nicht vorgesehen.
cgi in einem vorhandenen Webserver würde genau das bedeuten, was ich oben ansprach: Eine eigene httpd-Instanz dafür starten, WebIF an unsere Bedürfnisse umstricken (wenn überhaupt nötig) und den Rest mit Shell-basierten CGIs erledigen.

Edit: Zu deiner Frage von oben Oliver. Du hast Recht: Webserver ist nicht die Schnittstelle, über die Windows-Klient auf dem Port 2368 agiert. Da scheint der Austausch irgendwie anders als HTTP zu funktionieren. Lässt man den Klienten auf diesen Port los, so stürzt der eingebaute HTTP-Miniserver. Diese Erkenntnis würde für mich so viel bedeuten, dass der eingebaute HTTP-Server ziemlich instabil gegen undefinierte Aufrufe ist. Man sollte vielleich in die Quellen reinschauen und die Reaktion etwas "abschwächen", dass solche Anfragen einfach ignoriert werden und nicht gleich zu einem Abstürz führen. Ansonsten ist dieser Mini-Web-Server an sich ok und man könnte darauf aufbauen.
Starten mit einem & am Ende scheint mittlerweile auch zu klappen. Man könnte also schon damit anfangen und eine FREETZ-Umhülung dafür zurecht basteln. Mit der Umhülung verstehe ich rc-Skripte, Parameter und Namen abspeichern, WebIF für die Einstellungen und evtl. noch ein alternatives WebIF mit httpd. Obwohl dies auch wirklich nice-to-have wäre und nicht dringends notwendig.
Was mich deutlich mehr interessieren würde: Diese Netzwerk-Schnittstelle zum Windows-Klient hacken und dafür einen Listener entwerfen. Denn so könnte man diese USB-Steckdosenleiste nach außen als eine SIS-PM-konforme Netzwerksteckdosenleiste darstellen. Der Windows-Klient (insbesondere die neue Version) bietet sehr viele Möglichkeiten, die über diese Web-IF-basierte Steuerung deutlich weiter hinaus gehen. Schafft man diese Schnittstelle zwischen diesem Tool und der Steckdosenleiste, dann hat man viel gekonnt.

Edit2: Ich bin gerade auf Sourceforge von sispmctl gewesen. Das Ding scheint weiter zu leben. Die Jungs werkeln momentan an Version 3.0. In deren Trunk gibt es eine Version, die Timer unterstützt. Zwar noch nicht per WebIF, aber über Commandozeile.
Dagegen sieht es mit Bluetooth- oder Netzwerkvarianten der gleichen Steckdosenleiste düster aus. Sowohl Netzwerk- als Bluetoothvarianten scheinen auf eine ähnliche Kommunikation aufzubauen, die allerdings über Netzwerk oder Bluetooth-Seriell erfolgt. Es gibt leider keine Erkenntnisse darüber, wie es genau funktioniert. Diese neue Windows-Klient-Software scheint gerade alles zu unterstützen (auch Bluetooth und Netzwerk), allerdings nach einem uns noch unbekannten Protokoll.

Edit3: Auf meiner 7170 läuft sispmctl tatsächlich nicht. Hängt es wirklich mit einem speziellen USB-Treiber von 7170 oder liegt es am alten Kernel? Wie kann ich es debuggen? Ich habe leider an der Stelle überhaupt keine Ahnung, wie ich die Erkennung von USB-Geräten loggen kann, um festzustellen, wo es hackt.

Edit4: Unter dem Windows-Klient kann man neben LAN-SIS-PM per Netzwerk ansprechen (was ich oben meinte) noch eine SIS-PM "freigeben" und vom anderen Rechner "einbinden". Genau das hatte ich getan: Von einem Windows-Rechner die SIS-PM des anderen Windows-Rechners gesteuert und die Netzwerk-Gespräche mit Wireshark aufgezeichnet. So kompliziert ist die Geschichte nicht:
Anhang anzeigen kommunikation_netzwerk-device.txt
Man spricht die Leiste mit einem Namen an (hier hatte ich "SIS-PM" vergeben) und schon ist alles in Ordnung und die Verbindung steht. Allerdings scheint mir dieses Ping-Pong-Spiel zwischen dem Klient und Server ziemlich oft und intensiv zu sein. Es wird darauf laufen, dass man die Server-Funktionalität in C schreiben muss und am Besten in sispmctl-Binary reinintegrieren.

MfG

 

[hermann72pb]

Naja, irgendwie scheint das Thema keinen mehr besonders zu interessieren...
Nach meinen 4 Edits bin ich jetzt zunächst am Ende mit meinen Experimenten. Ich persönlich kann sogar mit der jetzigen Lösung schon bereits leben, bis mein Leidensdruck so hoch steigen wird, dass ich letztendlich mir was besseres auf FREETZ-Ebene zurech bastele.

Nun beschreibe ich, wie ich mit der jetzigen Lösung lebe. Vielleicht hilft es jemanden:

1. An meiner Steckdosenleiste ist zunächst ein Scanner (1) und ein Laserdrucker (2) angeschlossen.
2. Bis jetzt wurde SIS-PM per USB mit dem Win7-Rechner verbunden und darüber verwaltet.
3. Seit heute habe ich die 5 Meter an USB-Leitung bis zu meiner 7270 verlegt und steuere darüber die SIS-PM. Erstaunlicherweise funktioniert es gut, obwohl zwei zusammengesteckte USB-Leitungen nicht von bester Qualität sind und 5 Meter schon was heißen sollen. Dazwischen sitzt noch ein HUB passiver natur, wo noch ein USB-Stick drinne hängt. Also, ziemlich harte Randbedingungen.
4. Früher hatte ich alls über Klient-Software zu SIS-PM verwaltet. Teilweise konnte man pm.exe per Commandozeile starten, teilweise konnte man Ereignisbedingungen in dem Wächter pm.exe selbst festlegen. Jetzt geht das alles nicht. Ergo: Ich musste basteln. Später werde ich irgendwann mal einen Listener für FREETZ zu Recht basteln, jetzt habe ich aber keine Zeit zu, bastele ich auf Windows-Seite.
5. Als Erstes lege ich auf dem Desktop beliebig viele Verknüpfungen der Art "http://fritz.box:2638/on2.html" "http://fritz.box:2638/off2.html" usw. und benenne sie als "Drucker ON", "Drucker OFF" usw. Damit kann ich schon mal per Mausklick die Geräte ein- bzw. ausschalten.
6. Für Scripting besorge ich mir Linux-Tools für Windows. Eins davon ist wget.exe. Wenn man googelt, wird man fündig. Diese exe-Datei lege ich mir irgendwo ab, z.B. unter p:\linux und kann sie nacher als:

p:\linux\wget -q http://fritz.box:2638/on1.html -O q:/temp/tmp.html

ausführen. Antworten landen in meinem temp-Verzeichnis unter q:\temp
Unter Windows7 muss man die wget.exe über Eigenschaften als "vertrauenswürdig" frei schalten, sonst wird man von den pop-up-Sicherheitswarnungen ständig genervt.
7. Es macht Sinn unter c:\windows\system32\GroupPolicy\Machine\Scripts\Shutdown einen Shutdown-Script z.B. turn_all_off.cmd mit folgendem Inhalt anzulegen:

p:\linux\wget -q "http://fritz.box:2638/off1.html" -O "q:/temp/tmp.html"
p:\linux\wget -q "http://fritz.box:2638/off2.html" -O "q:/temp/tmp.html"
p:\linux\wget -q "http://fritz.box:2638/off3.html" -O "q:/temp/tmp.html"
p:\linux\wget -q "http://fritz.box:2638/off4.html" -O "q:/temp/tmp.html"

Dies bewirkt, dass beim Herunterfahren vom Rechner alle Steckdosen in Kalaschnikov-Takt abgeschaltet werden. Diese Funktionalität hat die Klient-Software von SIS-PM für Windows und das wollte ich in meinem Fall nicht vermissen. Denn in meinem Fall macht es schon Sinn alle Nebengeräte abzuschalten, wenn man den Rechner herunterfährt. Ist aber Geschmacksache...
8. Nun kommen wir zur eigentlichen sispmctl auf der Box. Zunächst rufen wir:

root@fritz:/var/mod/root# sispmctl -s
Gembird #0 is USB device 009.This device is a 4-socket SiS-PM.
Accessing Gembird #0 USB device 009
This device has a serial number of 01:00:4b:3b:19

Und sehen, dass die Steckdosenleiste da ist. Nun starten wir den eingebauten Webserver:

root@fritz:/var/mod/root# sispmctl -q -l &

und können uns von der Box abmelden.

Diese Webserver-Instanz ist leider ziemlich empfindlich, stirbt ziemlich oft und muss nachher wieder zum Leben erweckt werden. In meinen anfänglichen Experimenten musste ich es ständig machen. Kann aber damit zusammen hängen, dass ich den WebServer von Außen nicht immer korrekt angesprochen hatte. Deswegen bitte möglichst wenig Verkehr auf Port 2638! Nur in der Syntax, wie oben dargestellt. Dann lebt der Webserver länger.

Ich lasse es so bei mir über Paar Tage laufen und beobachte es erstmal so. Danach kann man sich entscheiden und erstmal einen WebIF für Konfiguration basteln. Als zweites kommt dann Listener, der mit dem Windows-Klient reden kann (s. mein Edit4 von oben). Dann ist die Sache ganz rund.

MfG

 

[cuma]

Vielleicht ist es einfacher eine Freetz-"Status" Seite zu machen auf der sich Buttons für die Steckdosen befinden? Dann kann man den eingebauten Webserver weglassen.