Radiowecker via FHEM steuern

[Rince]

Die Komandos die das Skript anlegt, sind die für die 1.49 gültigen, soweit ich weiß.
Parameter dazu gibt es imho keine bis jetzt.

Hast du jetzt das Connection refused in den Griff bekommen? (Radio muss eingeschaltet sein)

[ritchie]

Ups,

Du warst schneller. Siehe oben.

Radio läuft jetzt erstmal.

Gruss R.

[ritchie]

Hi,

hier die verbesserte Routine. Diese Routine warte nur wenige ms und hat den Vorteil, das sie die Antwort des Radios abwartet.
Hierdurch ist die Wahrscheinlichkeit, das sich das Radio bei einer schnellen Abfolge von Kommandos verschluckt, vermindert.

Code Auswählen Erweitern


use strict;
use warnings;
use POSIX;
use CGI qw(:standard);
use IO::Socket;
use IO::Socket::INET;
use MIME::Base64;
use Time::HiRes qw(usleep nanosleep);             <---- Neu für den usleep()

#
# Listenlive Radio
#
sub radio($)
{
  my ($socket,$client_socket);
  my $response ="";

#
# Create a socket object for the communication with the radio
#
  $socket = new IO::Socket::INET (
PeerHost => '192.168.5.56',
PeerPort => '8080',
Proto => 'tcp',
  ) or die "ERROR in Socket Creation : $!\n";

#
# Send the given command into the socket
#
  $socket->send(@_);
#
# get the radio some time to execute the command (10ms )
#
  usleep(10000);

#
# get the answer of the radio
#
  $socket->recv($response, 2);

  if($response !~  m/OK/)
    {
Log 1, "Error from radio ! Response from Radio : $response" ;
}

  $socket->close();
}


Wie wäre es, wenn wir eine Wiki Seite hierfür aufmachen.

Ich wollte mir heute eine kleine Lib schreiben, welche mir es ermöglicht das Radio in groben Zügen
zu steuern. Zuerstmal die hier, damit ich morgens immer automatisch begrüsst werde in der Küche.

- Radio sender x an der Fav. an
- Radio aus.



Gruss R.

[Rince]

Habe es mal versucht, mit dem Wiki Eintrag.

Muss noch rausfinden, wie die richtigen Tags aussehen. Im Quelltext sieht es gut aus :)

Finde es toll, dass du dich dem Code angenommen hast :)

Danke :)

[Rince]

Radio einschalten:
Wäre es ein möglicher Workaround, die Weckzeit zum Aufwecken des Radios nach einem Stromausfall zu nutzen?

Dann könnte man Nachts den Strom abdrehen (Schaltsteckdose :) ), um Strom zu sparen?

[ritchie]

Hi Rince,

ich habe mich jetzt mal mit der Steuerung des Radios versucht zu beschäftigen.

Derzeit habe ich noch ein das Problem, das das Radio die Einstellung verliert für die WLAN Verbindung.

Hierbei muss ich erst am Gerät die WLAN Parameter wieder neu eingeben. Das macht die ganze Sache sehr schwierig.

Läuft das bei Dir korrekt ?

Ansonsten versucht ich das Radio dann mittels gezielte Kommandos aus jedem Menuepunkt
in die gewünschten Menüs zu bekommen. Hoffentlich reagiert das Interface korrekt, da
wenn man z.B. in den Einstellungen das Radio setzt, das Kommando "home", "Menu" nicht arbeitet.
Hier arbeitet nur "exit".

Ob die Sache mit dem Weckalarm gehen würde, wäre eine Überlegung wert, hat aber den Nachteil,
das Du keine variablen Weckzeiten steuern kannst. Dies wollte ich eigentlich FHEM überlassen.

Wenn ich die Sache mit der stabilen Internetverbindung im Griff habe, dachte ich eigentlich.
das Display für den Nachtmodus auf AUS zu stellen, hierdurch habe ich einen geringen Stromverbrauch,
aber trotzdem die Möglichkeit das Gerät per TCP/IP zu steuern. Schliesslich soll es ja auf "Anwesenheit" reagieren.

Zudem muss es noch mehr Kommandos geben, aber auf einer Anfrage einer kompletten Liste habe ich keine
Antwort bekommen. Auch wurde der Eintrag nicht sichtbar geschaltet. Der scheint ja echt jeden Eintrag
zu lesen, bevor in das Forum kommt.

Ich wollte mich mal im Netz auf die Suche des Quellcodes machen, da er ja irgendwo eine Basis gehabt haben muss.
Bis jetzt habe ich aber noch nichts gefunden.

Ohne die stabile WLAN Verbindung habe ich aber ein Problem, da er auch plötzlich seine Favorits verliert und somit
keine Radiofunktionen vorhanden sind.

Das Teil wird eine harte Nuss werden.

Edit:
Wo hast Du die Wiki hingelegt ? Kann ich da auch mit dran arbeiten ?



Edit 1:
Kleine Update, damit man nicht ständig Einträge im Logfile bekommt, wenn man ein Webcmd ausführt.

Code Auswählen Erweitern


#### Listenlive Radio
sub radio($)
{
my ($socket,$client_socket);
$socket = new IO::Socket::INET (
    PeerHost => '192.168.10.40',
    PeerPort => '8080',
    Proto => 'tcp',
) or die "ERROR in Socket Creation : $!\n";

# send iTach command
my $data = $ARGV[0]."\r\n";
$socket->send(@_);
sleep (1);
$socket->close();
return;                 <------ Einfügen!
}



Viele Grüße

R.

[Rince]

Hi,

logisch kannst du den Artikel verändern. Besteht er doch aus deinem Code :-)
http://www.fhemwiki.de/wiki/Listenlive

Was das WLAN betrrifft, ich habe gelesen, dass einige Leute das Problem haben, bei mir trat der Fehler nie auf. Verwende DHCP, wenn ich nicht irre.

Das mit dem Stromsparen ist genau der Grund.

Nachts und tagsüber kann er ruhig völlig aus sein. Ohne Strom.

Für mich ist ok, wenn er sich um 6 Uhr einschaltet und um 19 Uhr. Einschalten in Form von "hat Strom und kann Befehle ausführen".
Die eigentliche Weckzeit würde ich eher über FHEM steuern. Macht mehr Sinn :-)

Ob FHEM dann um 6.05 Uhr oder 9.00 Uhr die Musik anwirft, ist mir egal. Die 3 Stunden zuviel die der Radio dann die Uhrzeit anzeigt, ertrage ich. Würde mir aber dennoch über ein Auto an freuen. William scheint die Idee aber nicht zu gefallen. Weiß der Geier warum.

[herrmannj]

Ola,

das geht ja richtig voran :) Cool :-)

WLAN Abbruch und Verlust der Favoriten und WLAN Einstellungen:
Tritt bei mir nicht auf, kann das Radio auch vom Netz nehmen und es behält die Einstellungen. Einzig zu beachten, nach einem Nustart braucht es einen Augenblick bevor er die Verbindung zum ll Server hat und sich die Favoriten von dort holt.

Sourcecode:
Soweit ich das verstanden habe hat er das selbst geschrieben, Basis war reverse engineering der original firmware und Studium der Chips. Wenn Du die FW auspackst (war glaub ich tar oder sowas) findest Du ein busybox linux. Die Apps sind kleine C progs. Du bräuchtest die busybox toolchain um da was zu schreiben. Ist imho machbar, aber mit hohem Zeiteinsatz.

TCP Control:
Die aktuellen FW Funktionen sind ja darauf ausgerichtet mit einem Smartphone eine FB zu ersetzen, das bremst den Spass leider etwas. Was helfen würde wären "discrete codes", also Funktionen die unabhängig vom aktuell angezeigten Menu greifen. Beispiel Radiosender: da würde es meiner Meinung nach ausreichen (und besser sein) wenn das Radio einen Befehl in der Art von "play <adresse>" versteht. Dann wäre es möglich die Favoriten in fhem zu hinterlegen und/oder auch Spachausgabe zu realisieren. Du kannst das ja im ll forum nochmal stressen, steter Tropfen ... ;-)

viele Grüße
Jörg

[ritchie]

Hallo Jörg,

welche Firmware Version hast Du. Ich verwende ein XORO 350 RM2 denke ich.

Die Sache mit der Steuerung ist ein "krampf". Ich test gerade das absetzen einer Kombination von Kommandos.

So sollte z.B.
"POWER" -> "HOME" -> "OK" -> "OK" -> "OK" den ersten Sender einschalten.

Das Radio wird zwar eingeschaltet und obwohl ich die Antwort abwarte, verschluckt er das Ausführen.
Derzeit hebe ich die erwartete "Ausführungszeit" nach oben.

Code Auswählen Erweitern


#
# get the radio some time to execute the command (300ms )
#
  usleep(300000);   Hiermit scheint das Kommando korrekt ausgeführt werden



Aber es wäre sehr viel einfacher, wenn eine klar Schnittstelle vorhanden ist.

Den die oben gezeigte Kombination arbeitet leider nicht aus allen Menubereichen heraus. Ich muss ja davon ausgehen,
das der Bediener manuell eingreift.

Code Auswählen Erweitern


#
# Switch the radio off
#
sub SwitchRadioOff
{
  radio("POWER");
  return;
}

#
# Power on with the first radio sender
#
sub SwitchRadioOn
{
  radio("POWER");
  radio("HOME");

  radio("OK");
  radio("OK");
  radio("OK");

  return;
}


Beispiel AT (kommt noch wochenende für einschalten rein und not presence für ausschalten)

Code Auswählen Erweitern


define RadioMorgensEin at *07:15:00 { SwitchRadioOn() }
define RadioMorgensAus at *07:15:00 { SwitchRadioOff() }


Was die Sache mit den eigenen Apps angeht, muss ich Dir recht geben, so viel Zeit habe ich dann auch nicht.

Gruss R.

[herrmannj]

Hallo Ritchie,

ich finde es übrigends auch sehr gut das Du Dich dem code angegommen hast !

FW:
müsste die aktuelle sein, überprüfe ich aber nochmal.

Ich würde jetzt erstmal abwarten bis die neue firmware da ist weil

Penbex am 13.5. im ll forum: play : server//garagedooropen.mp3 are ok for me.

Ich hatte damals mal gegoogelt und voicerss.org als tts gefunden.

Das würde ja schon folgendes Scenario möglich machen:

fhem kalkuliert die Weckzeit (Basis Wochentag, Feiertag, Ferien, Kalender...), schickt zur vorgesehen zeit einen "play http://api.voicerss.org?src=Guten Morgen&key=xxx" und anschließend einen link zu einem stream.


viele  Grüße
Jörg
 

[ritchie]

Hallo Jörg,

das hört sich ja gut an.

Generell würde ich aber planen, diese Datei auf die SD Karte zu legen,
um die Netzlast zu senken, aber das sollte jeder wie er will machen,
wenn es das Radio unterstützt.

Ich will als nächste, folgendes noch für das Radio machen

- Steuerung des Radios via Presence als Beispiel

- Stromverbrauch messen, lohnt sich ein Switch Off
  (Switch Off Verhalten nochmals prüfen)

- Netztraffic des Radio mir anschauen, macht das Radio
  evtl. nachts noch was anderes. Da ich ja jetzt
  einen "Rechner" in meinem Netz habe, der evtl.
  von LiveListen gesteuert werden kann.
  Quellcode kann nicht eingesehen werden!
  Hier werde ich wohl in meiner Fritzbox zuerst die
  Kindersicherung für dieses Radio aktivieren.

Da ich einen Wiki Zugang für FHEM Wiki beantragt habe,
will ich dann die Sachen in die Wiki schreiben und Rince
ein wenig unter die Arme greifen.

Wenn die Basisfunktion arbeiten, kommt dann ein seperates Modul
dran (ist auch Neuland für mich).

Hat Penplex schon was über die Messagebox gesagt ?

Gruss R.

[Rince]

Ich klinke mich hier wieder ein:
TTS Engine: schaut doch mal in RasPi Bereich, da ist ein Thread wie der RasPi aufs Wort hört.

Die TTS Funktion ist jetzt ausgelagert und in FHEM ansprechbar, im Endeffekt ist es schlicht ein Aufruf vom mplayer mit einem Rattenschwanz an Parametern, welche sofort mit der Stimme von Google Translate wiedergegeben wird.

Ich bin mir sicher, wenn wir Text an das Radio senden könnten, wäre das machbar.


Bezüglich BusyBox:
Die Toolchain brauchen wir nur, wenn wir selber kompilieren wollen, oder? Den Quellcode könnte man auch so an Penbex schicken, wenn er die App dann mit einbaut, aht er keinen Aufwand und wir die App. Oder sehe ich das ganze falsch?

[ritchie]

Hallo Rince,

TTS Engine: schaut doch mal in RasPi Bereich, da ist ein Thread wie der RasPi aufs Wort hört.

Leider ist die ausführende Maschine nicht der Raspi. Derzeit sind halt nur die Kommandos möglich,
welche Du aus dem System ermittelt hast. In wieweit William sein System öffnet ist fraglich.

Bezüglich BusyBox:
 Die Toolchain brauchen wir nur, wenn wir selber kompilieren wollen, oder? Den Quellcode könnte man auch so an Penbex schicken, wenn er die App dann mit einbaut, aht er keinen Aufwand und wir die App. Oder sehe ich das ganze falsch?

Aber auf dem Testsystem müsste man vorher die App auch selber testen, daher müsste man auch selber kompilieren.

Das wäre für mich kein Problem, da mein Desktop selber eine Linux System ist und ich bereits eine Toolchain für einen Arm am laufen habe.

Wenn das Zielsystem auch ein ARM Prozessor ist und ich z.B. ein Beispielprogm einer App haette, könnte man hier langsam was aufbauen.

Nur ist hier der Zeitaufwand nicht ohne, das wird also was dauern.

Kennt jemand von euch das Passwort für telnet oder ssh des Radios ?


Viele Grüße

  R.

P.S.: Wieso einklinken, Du bis doch voll dabei :-)

[herrmannj]

also ich komm bei mir einfach mit telnet root auf drauf, kein pwd. Ist eine mips cpu. Und wget ist auch drauf, insofern könnte man...

Auf der einen Seite würde ich das schon nicht unspannend finden da selber Hand anzulegen, würde einen halt von penbex etwas unabhängiger machen. Der hat ja seine eigene Agenda, das ist ja auch verständlich.

Auf der anderen Seite stellt sich ja schon die Frage wie viel Zeit man da aufbringen möchte, selbst die Umsetzung von einem simplen "play <adresse>" ist ja nicht ganz trivial. Braucht einen deamon der auf sockets hört, http muss implementiert werden und für die wiedergabe brauchts codecs...

Sicher gibt es Bibliotheken, aber zwischen Theorie und wirklich laufen liegen ja doch oft einige Wochen arbeit :)

Für mich persönlich stellt sich die Bilanz so dar: noch 4 Wochen warten bis penbex das hat, dann in den Dialog gehen um zu verfeinern. Oder 100h+ Arbeit reinstecken und in 6 Wochen selber verfeinern. Wenn jemand die skills hat das schneller umzusetzen ist es eine attraktive Option, ich selber würde eher auf penbex warten.

Zum tts: bei mir läuft fhem auch auf der FB. Das tts (voicerss) funktioniert über die Wolke so gut das ich da keinen Bedarf sehe selber Hand anzulegen. Die api ist echt simple (nur http-get mit params), musst Dir eine kostenlosen key holen und gut ist.

viele Grüße
Jörg

[herrmannj]

gerade eben hatte ich noch so 'ne idee ;-)

da telnet ja geht:

unter /usr/jz-project liegt ein mplayer und auch andere files (zB audio-play und cximage ;-).

Vielleicht lösen wir das einfach mal ganz pragmatisch - oder ? Die Clock bzw brightness werden wohl irgendwo in den dev ihre Entsprechung haben. Die keys werden über stdin reinkommen und nc ist auch drauf ... Eigentlich ist ja alles da :-)

Werde ich heute Abend mal genau untersuchen.

viele Grüße
Jörg