Hallo liebes FHEM Forum,
ich habe eine Frage (weiß allerdings nicht ob es das richtige Unterforum ist).
Ich versuche schon seit einiger zeit verzweifelt für meinen Papa WLAN-Steckdosen von broadlink ins FHEM einzubinden.
Die Steckdosen werden derzeit von einer Android App gesteuert. Ich habe schon mit einem Paketsniffer die UDP Pakete
extrahiert und bin auch auf dem Raspberry PI in der Lage die Steckdosen zu steuern. Dazu habe ich für den Zustand An und Aus
jeweils eine eigene Datei. Diese schubse ich per cat einfach raus ... z.b. cat steckdose_an > /udp/192.168.2.70/80
In der Shell funktioniert das Prima. Allerdings schaffe ich nicht das ins FHEM einzubinden.
Die fhem.cfg sieht an der fraglichen Stelle so aus :
define WLANSteckdose dummy
attr WLANSteckdose webCmd on : off
attr WLANSteckdose room 1
define WLANSteckdose_on notify WLANSteckdose:on { `cat /opt/fhem/FHEM/steckdose_an.pak > /dev/udp/192.168.2.70/80`;; }
define WLANSteckdose_off notify WLANSteckdose:off { `cat /opt/fhem/FHEM/steckdose_aus.pak > /dev/udp/192.168.2.70/80`;; }
Ich habe schon in den Logdateien gesehen das wenn die Datei nicht existiert das er meckert und sagt : File doesnt exist.
Die Rechte der Script-Datei habe ich auch alle auf fhem gesetzt (mit chown fhem), und lesbar sind die dateien auch (chmod 777)
Mit der Konfig oben taucht beim "ein/ausschalten" nichts mehr an fehlermeldungen auf, aber es wird auch nichts geschaltet.
Was ich z.b. auch merkwürdig finde. Um zu testen ob beim Drücken des entsprechenden Tasters in FHEM das Shell Commando auch ausgeführt wird habe ich z.b. mal per echo "test" > /opt/fhem/FHEM/test.txt mir versucht eine Text-Datei erzeugen zu lassen. Aber diese taucht auch nicht im FHEM Ordner auf ?
Was kann das sein ? Ich bin langsam ein wenig am Ende mit meinen Ideen, zumal andere ja schon erfolgreich Systemkommandos ausgeführt bekommen, und ein cat bzw echo ist jetzt ja kein "großes" Kommando.
Jemand vllt eine Idee ?
Zitatattr WLANSteckdose webCmd on : off
Ich wuerde die Leerzeichen entfernen.
Zur Fehlersuche gibt es verschieden Strategien, in deinem Fall gäbe es zwei Annäherungsmöglichkeiten:
- Geht das Shellkommando bzw. geht der Perl (System) Ausdruck? Kann fhem das Kommando ausführen?
- Geht der Dummy?
Den Ausdruck den Du ausführen willst kannst Du völlig separat testen (http://fhem.de/commandref_DE.html#perl), Du bist der Meinung der geht nicht, aber wahrscheinlich geht der...
Den Dummy kannst Du mit etwas einfacherem testen, z.B. irgendwas direkt ins Log schreiben. Oder eine Lampe schalten ... --> { Log 1, "Hello" }
Hilfreich ist auch immer der eventmonitor, den darf man auch gern in einem zweiten Browserfenster zusätzlich öffnen 8)
Gruß Otto
Korrektur: die Leerzeichen in webCmd haben doch keinen negativen Effekt, mein Vorschlag von vorhin ist zu ignorieren.
Hallo Otto,
also der Ausdruck (cat steckdose_an > /dev/udp/... falls du das meinst) geht per Shell einwandfrei. Aber eben nur da.
Ursprünglich habe ich das ganze in ein Script gepackt, aber selbst wenn ich nur das einzelne "effektive" Kommando abgesetzt
habe hat FHEM es nicht ausgeführt bzw es irgendwo hängengeblieben.
Das mit dem Log habe ich schon getestet. Also sprich das ich statt `cat ....` ein Log (1, "geht dat ..") genommen habe.
Und das ist auch in der Log Datei gelandet. Nach 4 mal Schalten stand da 4 mal "geht dat .." am Ende der Logdatei.
Nur um sicher zu gehen das das die Config stimmt und der Befehl theoretisch ausgeführt werden müsste.
Rechte und Benutzer müssten für die Dateien auch stimmen (wie gesagt die Datei per chown und chmod zugreifbar gemacht).
Ok, also dann geht Dein Dummy.
Dann musst Du weiter testen warum Dein Shellkommando nicht geht.
Was passiert wenn Du { `cat /opt/fhem/FHEM/steckdose_an.pak > /dev/udp/192.168.2.70/80`;; } in der Kommandozeile, also in der Zeile oben im Browserfenster von fhem eingibst?
Die Rechte auf die Datei hast Du gesetzt, aber braucht deine Aktion root Rechte? Oder andere Rechte, die fhem nicht hat?
Hallo Otto,
ich bin nun wiedermal dazu gekommen an dem FHEM rumzuprobieren. Danke erstmal für den Hinweis mit der Kommandozeile oben im Browser. So lässt sichs ja doch ganz gut testen ... :-)
Aber mein Problem habe ich leider noch nicht lösen können. wenn ich den cat ... absezte passiert nüscht. Ich habe auch mal völlig "unkritische" Befehle wie z.b, touch ausprobiert die ja in jedem Fall gehen müssen und unabhängig von den Rechten sind. Auch da tut sich nichts. Wenn ich z.b. { ` touch /opt/fhem/FHEM/tester.txt`;; } in der Commandline eintippe dann passiert auch nichts. Es wird also nicht eine leere Datei mit dem namen "tester.txt" in /opt/fhem/FHEM erstellt. Wo kann ich denn überprüfen ob das an den rechten liegt ? Wobei mich ja schon wundert das ein popeliges touch auch schon nicht funktioniert.
Ich habe nochmal etwas rumprobiert und etwas merkwürdiges festgestellt.
Sobald ich folgende Zeile in der Kommandozeile versuche auszuführen, hängt sich der Browser-Teil vom Fhem anscheinend weg.
Jedenfalls komme ich per Web Browser nicht mehr auf das FHEM (es wird immer gesagt : Connection refused) und muß (als bisher einzige lösung) den Raspberry bzw Orangepi neustarten.
{ exec ("cat /opt/fhem/FHEM/stk80_on.pak > /dev/udp/192.168.178.80/80");; }
Egal wie ich es anstelle. Ich bekomme es nicht hin im FHEM die Datei "stk80_on.pak" per UDP an die Adresse 192.168.178.80 zu schicken.
Langsam verzweifel ich ...
Zitat von: TheMason76 am 26 Juni 2016, 13:08:47
habe auch mal völlig "unkritische" Befehle wie z.b, touch ausprobiert die ja in jedem Fall gehen müssen und unabhängig von den Rechten sind. Auch da tut sich nichts. Wenn ich z.b. { ` touch /opt/fhem/FHEM/tester.txt`;; } in der Commandline eintippe dann passiert auch nichts. Es wird also nicht eine leere Datei mit dem namen "tester.txt" in /opt/fhem/FHEM erstellt.
Muss an "Dir" liegen, das funktioniert bei mir ohne Probleme. 8)
Ich habe keine Idee was bei Deiner Installation falsch ist.
Kannst Du die Befehlszeile vom Terminal aus absetzen, mit anderem Benutzer?
Gruß Otto
Hallo Otto,
als "anderer Benutzer" hatte ich auch schon überlegt, aber noch nicht getestet. Das ganze hab ich bisher nur als Root
gemacht. Also das ich per Putty auf dem OrangePI bin und die UDP-Pakete per cat ... > /dev/udp/... rausschubse.
Was mich nur so stutzig macht ist das selbst ein einfaches touch was ja abgesehen von den jeweiligen Rechten
in dem Ordner wo man die Datei erstellen will ein Befehl ist der unabhängig von dem Benutzer funktionieren muß bzw sollte,
in der Kommandozeile beim FHEM nicht geht. Einen anderen Befehl wie z.b. Log 1, "geht das" per Kommando-Zeile oder auch
mit dem dummy-Schalter (weiter oben) kann ich absetzen und der Text landet auch im Log (auch z.b. ein unterschiedlicher Log mit
"Lampe an", "Lampe aus"). Nur alles (!) was mit der Shell zu tun hat interessiert den kein bischen, zumindest nicht bei der Ausführung.
Wenn ich z.b. den Befehl in ein Script packe und einen falschen Namen angebe (z.b. stockdose statt steckdose) sagt der im Log das
der die Datei nicht findet. Ist der Befehl dennoch richtig geschrieben taucht im Log nichts mehr auf (also Fehlermäßig), aber der Befehl wird
nicht ausgeführt. Von Hand auf der Konsole geht es ...
Na ja. Vllt liegt es ja wirklich an der Installation. Ich muß das bei mir mal gegentesten. Und erstmal das FHEM installieren. Mal schauen was die Banane davon hält ;D
Warum machst du das nicht lieber direkt aus FHEM. Du könntest doch einfach in einer eigenen Routine direkt die UDP-Pakete raus sschicken. Ich habe so etwas ähnliches für meinen LD382 LED controller gemacht... In diesem Fall spreche ich einen eigenen daemon auf dem RPi an, aber das ist ja ega. Das kurze Beispiel müsstest du doch leicht für deine Zwecke abwandeln können... ;)
sub dreamyFire(@) {
my @params=@_;
foreach (@params) {
my $duration = $_;
my $cmdBlock = "e,fire,$duration";
my ($socket,$client_socket);
$socket = new IO::Socket::INET (
PeerHost => '127.0.0.1',
PeerPort => '5382',
Proto => 'tcp',
) or die "ERROR in Socket Creation : $!\n";
$socket->send($cmdBlock);
$socket->close();
InternalTimer(gettimeofday()+$duration,'dreamyFire',$duration, 0);
}
}
Ist irgendwie schöner, als so ein Hack über die CLI, finde ich.
Gruß,
Stephan
Hallo budy,
erstmal danke für dein Code Schnipsel. Ich bin was Perl angeht nicht so wirklich fit.
Daher war für mich ein einfaches cat auf dem UDP Port die einfachste Lösung.
Zumal Linux ja 1001 Weg bietet und dieser Weg für mich am einfachsten erschien
weil das wirklich universell ist (soweit ich weiß ist auf jedem Linux System mit
Netzwerk ein /dev/udp/... vorhanden) und ich das ganze ursprünglich nur mal eben
mit einem Ubuntu getestet hatte und letzenendes auf die cat ... > /dev/udp/... gekommen bin.
Im Prinzip kopiere ich einfach nur ein UDP-Paket was ich als Datei habe auf einen UDP
Port auf einer angegebenen IP Adresse.
Aber mit dem Perl-Schnipsel probiere ich mal aus. Wie die Daten dahin kommen ist letztenendes
egal. Hauptsache ist das ich die jeweilige Datei (ich habe für jede Steckdose eine für einschalten und ausschalten,
diese habe ich per Paket Sniffer von der Handy App extrahiert) per UDP auf Port 80 an eine angegebene Adresse
geschubst bekomme. Nur weiß ich unter Perl eben nicht wie das geht. Danke soweit schonmal.
Kann ich dem Socket ohne weiteres ein Proto von 'udp' verpassen ? Eine Rückmeldung brauche ich
erstmal nicht.
Moin,
Zitat von: TheMason76 am 26 Juni 2016, 23:06:25
Kann ich dem Socket ohne weiteres ein Proto von 'udp' verpassen ? Eine Rückmeldung brauche ich
erstmal nicht.
Ja, das müsste so gehen. Probiers mal aus uns wenn's nicht geht, dann sag nochmal Bescheid, aber meiner Meinung nach reicht es aus den Transport auf UDP zu stellen.
Gruß.
Stephan
Ansonsten ... wegen der shell-Probleme:
Versuche es doch mal nicht als root, sondern als fhem-user. Eventuell must Du nur in der passwd dem User noch eine shell zuweisen.
Hattest du Ottos Tipp probiert?
ZitatGeht das Shellkommando bzw. geht der Perl (System) Ausdruck? Kann fhem das Kommando ausführen?
So setzt man in FHEM standartmäßig Shellbefehle ab.
Das wäre dann:
{system("cat /opt/fhem/FHEM/steckdose_an.pak > /dev/udp/192.168.2.70/80")} oder
{system("sudo cat /opt/fhem/FHEM/steckdose_an.pak > /dev/udp/192.168.2.70/80")} Gruß
Frank
So ...
Erstmal danke für die vielen Tipps und Hints.
Nach viel Versucherei hab ich es bei der Shell aufgegeben.
Ich nutze da eigentlich immer die Backticks, also { `bla bla` ;; } in der
Kommandozeile im Browser. Egal wie ich es angestellt habt. Geht nicht.
Ich habe zwischenzeitlich mal auf nem BananaPi ausprobiert, ebenfalls Fehlanzeige.
Letzenendes hab ich dann an eine kleine Perl-Routine zusammengeschnipselt
und das läuft nun. Hier mein zusammengekopiertes Code-Schnipsel. ;D 8)
sub SendUDP (@) {
my $FileName = $_[0];
my $IP_Address = $_[1];
my $IP_Port = $_ [2];
my $AnzahlBytes = -s $FileName;
my $Speicher;
my ($socket,$client_socket);
open(FILE, "<", $FileName) or die("File not found $!");
binmode(FILE);
my $geleseneBytes = read(FILE, $Speicher, $AnzahlBytes);
close(FILE);
$socket = new IO::Socket::INET (
PeerHost => $IP_Address,
PeerPort => $IP_Port,
Proto => 'udp',
) or die "ERROR in Socket Creation : $!\n";
$socket->send($Speicher);
$socket->close();
}
Achtung an Kopierer: der Funktionsaufruf die() ist generell keine gute Idee in FHEM-Funktionen.
Auch wenn Deine Funktion jetzt gelöst ist würde ich an Deiner Stelle noch schauen warum so etwas wie { ` touch /opt/fhem/FHEM/tester.txt`;; } nicht geht. Das muss gehen und irgendeine Ursache in Deiner Installation haben!
Gruß Otto
Hallo TheMason76,
kannst du mir eine kleine Anleitung zum Mitschneiden der Pakete zum Steuern der Steckdosen geben.
Ich stehe zZ vor dem gleichen Problem.
mfg
Mike
Hallo Civioid,
kann ich gerne machen. Kann wohl vllt noch 1-2 Tage dauern. Weiß noch nicht genau wann ich dazu komme.
Gruß
Rene
Das klingt doch super ...
... bin schon gespannt wie ein Flitzebogen :D :D
Hi Civicoid,
sry, bin erst jetzt dazu gekommen zu Antworten ....
Aaaalso ...
Ich hab das so gemacht. Zu den Broadlink Steckdosen gibt es die App "e-control". Mit der werden die Steckdosen ja gesteuert. Ich habe um die Pakete mitsniffen zu können mir die App "Pocket Capture" installiert.
Zuerst startest du die e-control App und gehst auf die Steckdose die du schalten willst. Dann startest du den Pocket Sniffer und kannst über das "Play" Symbol das sniffen starten. Dann gehst du wieder auf die "e-control" App, schaltest die Steckdose 2 mal an und aus (um nachher die Pakete einfacher zu finden), gehst dann wieder in den "Pocket Capture" und stoppst über das "Stop" Symbol das sniffen. Mit jedem Start/Stop macht Pocket Control eine neue Session bzw einen neuen Eintrag mit Datum/Uhrzeit.
Wenn du auf diesen Eintrag gehst siehst du alle Pakete die das Handy in der Zeit so rausschubst. Du suchst dann in dem Eintrag nach UDP Paketen mit der länge 176 Byte und Port 80. das sind (höchstwahrscheinlich) die Pakete die an die Steckdose gehen. Wichtig ist dabei das du dir die IP Adresse in dem Lokalen Netzwerk merkst.
Wenn du auf die UDP Pakete drückst, siehst du den ausgehenden Traffic und die eingehende Antwort dazu. Diese sind in Summe 176 Byte. Das (interessante) ausgehende Paket hat immer 72 Byte. Du speicherst nun den "Upload" über "Save upstream" (also das was vom Handy zur Steckdose geht) und speicherst es auf deinem Handy ab. (gut merken wo man es gespeichert hat und an welche IP Adresse im lokalen Netzwerk das Paket geschickt worden ist).
Am besten gibst du dem auch direkt "sprechende namen" also z.b. steckdose_kaffemaschine_104_0x ... da du nicht direkt weißt ob das das Paket fürs einschalten oder ausschalten ist, am besten einfach mit fortlaufender Nummer und IP Adresse speichern. Als nächstes mußt du die gespeicherten Upload Pakete irgendwie auf deinen Rechner (oder direkt den Raspberry oder welches System auch immer du nutzt) kopieren (Ich habs mit der Total Commander- und Filemanager-App gemacht).
Ich hab bei mir zuerst auf den Laptop gespeichert und bin unter Ubuntu hingegangen und habe die Pakete per "cat steckdose_xxx > /dev/udp/192.168.xxx.xxx/80" an die entsprechende Steckdose gesendet und konnte dann auch herausfinden welche der laufenden nummern für ein und ausschalten zuständig war und habe diese dann umbenannt.
Wichtig ist auf jeden Fall das du dir die IP adresse merkst da in den Paketen wohl noch etwas "versteckt" ist was verhindert das du ein Paket was für eine bestimmte Steckdose (also mit einer bestimmten IP Adresse) ist, an eine andere schickst. Sprich : Du musst das gezumpel für jede Steckdose einzeln machen und dir merken an welche IP Adresse das ging. Ich bin nachher hingegangen und habe schon beim Abspeichern die IP-Adresse (in meinem Subnetz) im Namen drin gehabt. Also z.b. Steckdose_104_01 für das erste Paket was an die Steckdose 192.168.2.104 ging.
Durch das versenden der Pakete unter Ubuntu konnte ich dann sehen ob _01 die Steckdose ein oder ausgeschaltet hat und habe die Dateien dann umbenannt in "steckdose_104_an" und "steckdose_104_aus". Jede Datei ist bei mir 72 Byte groß (die 176 Byte die ich oben erwähnt habe kommen vom gesamten Traffic, also eingehend und ausgehend).
Mit diesen zwei Dateien pro Steckdose (die ich dann auf den Raspberry kopiert habe) brauchte ich dann nur das kleine Perl Snippet und konnte die Dateien direkt an die Steckdose senden. Praktisch ist wenn man die IP Adresse direkt im Dateinamen mitspeichert, dann kann man sich über die Perl Routine den passenden Dateinamen und die dazugehörige IP Adresse direkt zusammenbauen. Also steckdose_104_an an 192.168.2.104 verschicken.
Hoffe ich habe das halbwegs verständlich erklärt. Wenn du noch fragen hast ... feel free ... :-)
@rudolfkoenig
Ach ja .. jetzt wo ich es sehe ... das "or die" ist ja in "normalen" Perlprorgammen bzw Perlsnippets ja so "üblich" (zumindest exemplarisch). Aber was wäre unter Fhem der beste Weg bzw sinnvollste ? Ein "or die" ist ja schon ziemlich bruteral, aber wie gesagt bin was Perl angeht ein ziemlicher newbie. Komme aus der C Welt und hätte jetzt eine endlos verschachtelte if () { } else { } Anweisung daraus gebastelt. Ist das unter Perl praktikabel oder was bzw wie fängt man die Fehlerfälle am sinnvollsten ab ?
@TheMason76: die() ist normal in perl Programmen, die nicht als daemon laufen. die() ist auch deswegen doof, weil es direkt auf STDERR schreibt, was dann ungefiltert im FHEM-Log landet. Loesung fuer FHEM: alles, was die() verwendet, mit eval ausfuehren, auf $@ pruefen, es per Log/Log3 melden, und passenden return generieren.
Du kannst in perl auch endlos lange if-elsif-else Kaskaden bauen, aber wenn elsif mehr als 3-mal vorkommt, dann ziehe ich andere Kostrukte vor, wie Programmcode in Liste oder Hash was per eval ausgefuehrt wird. Ich wandele damit Code in Daten um, wie das am Anfang von 10_ZWave.pm in %zwave_class zu sehen ist.
Achtung: ich bin kein perl-Papst, ich verwende nur perl seit mehreren Jahren.
P.S.: ab und zu ein return erleichtert das Lesen. Deinen bestimmt lesenswerten Beitrag habe ich deshalb bei der Haelfte abgebrochen.
Danke für die Perl-Tips. Werds mal wenn ich mich wieder mit Perl befasse beherzigen :-)
Aber stimmt ... jetzt wo du es sagst hätten ein oder zwei Return nicht geschadet. Ich hols mal ganz fix nach. War schon was spät gestern Abend :-)
Edit : habs mal "entzerrt". Schaut direkt besser aus :-) Danke noch
@TheMason76
Danke für deine umfangreiche Anleitung. Leider befindet sich zZ kein Android-Gerät in meiner Reichweite um die von die beschriebene App zu testen. Wir sind im Haushalt eher mit angebissenen Äpfeln unterwegs. :-)
Um an die Pakete zu kommen habe ich jetzt mit Wireshark etwas mitsniffen können. Hierbei werden kontinuierlich Pakete von ~90Byte gesendet.
Im Falle eines Schaltzustandwechseln laufen vier Pakete ein. Diese wollte ich nun von einem im Netzwerk befindlichen Raspi schicken.
Wenn ich den Befehl
sudo cat /opt/fhem/FHEM/steckdose_an.pcap > /dev/udp/192.168.xxx.xxx/80
absende passiert leider noch nichts.
Weißt du, ob ich beim Raspi noch etwas nachinstallieren muss, um UDP-Pakete über den Befehl zu versenden.
In meinem /dev-Ordner gibt es nämlich kein /udp.
Hallo Civicoid,
hast du mal versucht die Pakete von deinem angeknabbertem Apfel einfach zurückzuschicken um sicher zu gehen das die Steckdose sich so überhaupt ansprechen lässt ? Hast du denn auch die Steckdosen von Broadlink ?
Mir kommt das komisch vor das permanent etwas gesendet wird. Alelrdings weiß ich auch nicht mit welchem Programm du das machst. Vllt das die Steckdosen sich dann auch anders angesteuert werden. Das UDP-Paket hab ich einfach mal als "gottgegeben" hingenommen. So richtig was an "Systematik" konnte ich den Daten nicht entnehmen, selbst wenn es "nur" 20-30 Bytes waren die sich jeweils verändert haben. Hab mir aber auch nicht weiter MAC Adresse und dergleichen angeschaut oder versucht da "rauszuinterpretieren".
Einfach gesnifft, gespeichert und rausgeschubst :-) Bei dem Android Handy von meinem Papa wurden z.b. auch ganz andere IP Adressen "verwendet" die mal so gar nicht mit 192.168.x.x übereingestimmt haben. Bin was das analysieren bzw "reverseengineeren" von Datenpaketen angeht bin ich leider kein Experte.
Das Problem mit dem fehlenden UDP-"Verzeichnis" hatte ich bei einem Raspberry (ich glaub ein Raspi Pi 3) auch. Daher das Perl-Skript. Mit /dev/udp/.... hab ich das auf nem BananaPi, nem OrangePI und unter Ubuntu getestet.
Was sind es denn für IP-Adressen?
Am optimalsten fürs Reverse-Engenieren wäre es, wenn Du die Steckdosen hinter einem Linux-Router packn könntest. Dann hättest Du die beste Möglichkeit, die entsprechenden Packete mitzuschneiden.
Hallo,
leider komme ich erst jetzt dazu euch zu antworten.
Die Lösung mit meinen Apfel-Geräten war eher weniger zufriendenstellend.
Schlussendlich habe ich ein GalaxyTab als zukünftige Komandozentrale günstig ersteigert.
Aber hier meine funktionierende Lösung:
1. Pakete per "Packet Capture" mitsniffen, speichern und auf den FHEM-Server packen
> bei mir heißen die Pakete 1on.pak und 1off.pak und liegen testweise im /root
2. Fhem den sudoers hinzufügen
> /etc/sudoers
fhem ALL=(ALL) NOPASSWD: ALL
3. zwei Dateien anlegen
1on.sh
#!/bin/bash
echo "Steckdose 1 an"
cat /root/1on.pak > /dev/udp/192.168.2.x/80
und 1off.sh
#!/bin/bash
echo "Steckdose 1 aus"
cat /root/1off.pak > /dev/udp/192.168.2.x/80
und mit
chmod +x 1on.sh
chmod +x 1off.sh
ausführbar machen
4. in FHEM
define LEDLicht dummy
attr LEDLicht setList on off
define LEDLichtAn notify LEDLicht:on "sudo /root/1on.sh&"
define LEDLichtAus notify LEDLicht:off "sudo /root/1off.sh&"
und was soll ich sagen, bei mir schaltet es auf einmal die Steckdosen wie gewolt :-)
PS:
Nun fehlt nur noch der automatische Statuswechsel wenn ein anderer Teilnehmer schaltet :-[
EDIT:
- Entschuldigung für diese Majestätsbeleidigung. Änderungen werde ich testen und umgehend anpassen. Danke!
-- getestet, funktioniert, geändert
- Die *.sh müssen noch ausführbar sein
Fuer die Nachahmer: bitte statt {system("bla&");;} einfach nur "bla" verwenden, sonst bin ich traurig, dass der fuer diesen Zweck extra seit 10 Jahren in FHEM eingebaute Code von keinem verwendet wird. Von commandref.html nicht zu lesen will ich gar nicht reden.
Ich war nicht ganz untätig und habe es mit einer eher quick'n'dirty-Lösung geschafft auch den Status der Steckdosen beim Betätigen zu empfangen. Zusammengefasst:
- FHEM mit Dummys für die einzelnen Steckdosen und dem sende-Skript
- ein Pythonscript welches continuierlich die einzelnen Steckdosen über UDP nach seinem Status abfragt
- ein weiteres Pythonscript, welches auf dem UDP-Port auf die Antwort lauscht und via telnet-Port Fhem steuert
(alles recht rudimentär, aber funktioniert)
todo:
- wenn Steckdose nicht erreichbar?
Wenn Interesse besteht, gerne mehr.