Modul für WLAN Radios mit Frontier Silicon Chipsatz (SilverCrest/Medion/Hama...)

Begonnen von mumpitzstuff, 07 November 2017, 00:21:27

Vorheriges Thema - Nächstes Thema

mumpitzstuff

Super!

Das mit next/previous ging irgendwie nicht, warum auch immer. Es gibt zwar dlna Kommandos dafür, aber mein Radio reagiert darauf leider nicht. Das mit dem Stop muss ich noch mal gucken.

Wie sieht denn deine playlist für den Webserver aus? Was passiert wenn du im Browser eine der urls aus der Playlist eingibst? Wird dann ein Stream gestartet?

mumpitzstuff

@Lichti: Bei dem Radio wo die erste Silbe verschluckt wird, auf welchen Werten stehen volume und ttsVolume? Probier mal bitte aus, ob es einen Unterschied, wenn beide Werte gleich sind oder nicht. Oder du kommentierst die Zeile nach dem Kommentar "# mute before poweron" mal aus. Was passiert wenn das Radio bereits an ist, eventuell sogar schon dmr als Input ausgewählt ist?

Ansonsten kannst du vielleicht eine kurze Sequenz mit Nichts erzeugen und als Jingle abspielen lassen. Oder du kannst du dem Text auch irgendwas wie Punkte oder Ausrufezeichen voran stellen, so das Google selbst eine kurze Pause einbaut.

Ich finde ansonsten nicht wirklich was das ich ändern könnte.

mumpitzstuff

@raiderxxl: Das Problem mit Stop habe ich identifiziert, die Lösung ist leider nicht so einfach. Ich habe aber eine Idee, die vielleicht funktioniert und dann vielleicht auch das Problem mit den Timeout Nachrichten im Logfile löst. Next/Previous sollte mit dem Mechanismus ebenfalls gehen. Im Prinzip geht es darum, den geforkten Prozessen irgendwie Nachrichten zu schicken und damit letztendlich durch FHEM Kommandos zu steuern. Bisher rennen diese Prozesse einfach immer weiter, weil das Modul Blocking von Hause aus keinen Datenaustausch zwischen Client/Parent erlaubt. Ich habe deshalb immer versucht rein passiv zu erkennen was passiert. Bei den Playlisten kommt man da aber an eine Grenze... Zumindest in der Theorie sollte eine Kommunikation aber mit Pipes funktionieren. Ich bleibe dran...

Das mit dem Webserver schaue ich mir noch mal genau an und falls ich es hinbekomme, dann beschreibe ich genau wie ich zum Ziel gekommen bin. Eventuell füge ich auch noch ein paar erweiterte Log Messages ein, dann sieht man das Problem hoffentlich schneller.

Lichti

Also das Noxon Radio verhält sich schon sehr seltsam:

- Wenn ich den input von dab auf dmr umschalte, wird beim Reading zwar als input dmr angezeigt, der DAB-Sender ist aber weiter zu hören
- Wenn ich einen Jingle vor den Text setze, wird nur der Jingle (auch gekürzt) abgespielt, aber nicht der Text
- bei gleichen Werten von volume und ttsVolume gleiches Verhalten
- auch kein Unterschied ob Power on oder off
- wenn ich einen Punkt vor den Text setze, funktioniert es meistens. Manchmal wird aber trotzdem etwas verschluckt. Bei 2 Punkten wird der 2. Punkt als "Punkt" vorgelesen
- beim stream-Kommando wird nichts verschluckt

Bei den anderen beiden Radios funktioniert alles bestens. Also wohl doch veraltete Hardware beim Noxon A110+

mumpitzstuff

Das mit dem Jingle nutzt wahrscheinlich ein Feature das dein Radio ebenfalls nicht unterstützt. Ist irgendwie blöd. Ich vermute das die dort irgendwas eingebaut haben das bei der ersten Ausgabe die Lautstärke auch die Ziellautstärke hochrampt, also leise anfängt und dann erst nach 1-2s die gewünschte Lautstärke erreicht. Versuch doch mal .<Space>. oder Kombinationen verschiedener Sonderzeichen. Irgendwo hatte ich auch im Forum darüber mal was gelesen.
Frag doch mal im Anfängerbereich, vielleicht hat dort jemand eine Idee wie man eine Pause hinbekommt.

Lichti

Hab so einiges gegoogelt. Gibt zwar einiges zu dem Thema, aber keine richtige Lösung.

Mit .<Space>.<Space>.Text läuft es jetzt aber ganz gut.
Man hört einen  kleinen Rest von "Punkt", stört aber kaum.

Future001

Guten Morgen!

seit 2 Tagen stürzt mein Fhem regelmäßig ab. Ich habe da den verbose auf 5 gesetzt und mal geguckt. Das letzte, was man vor einem Start im Log sieht ist folgendes:


2018.10.12 20:37:17 5: HttpUtils request header:
GET /fsapi/GET/netRemote.sys.power?pin=1234 HTTP/1.0
Host: 192.168.134.xxx
User-Agent: fhem
Accept-Encoding: gzip,deflate

2018.10.12 20:37:17 5: HttpUtils request header:
GET /fsapi/GET/netRemote.nav.state?pin=1234 HTTP/1.0
Host: 192.168.134.xxx
User-Agent: fhem
Accept-Encoding: gzip,deflate

2018.10.12 20:37:17 5: HttpUtils request header:
GET /fsapi/GET/netRemote.nav.numItems?pin=1234 HTTP/1.0
Host: 192.168.134.xxx
User-Agent: fhem
Accept-Encoding: gzip,deflate

2018.10.12 20:37:17 5: HttpUtils request header:
GET /fsapi/GET/netRemote.sys.caps.volumeSteps?pin=1234 HTTP/1.0
Host: 192.168.134.xxx
User-Agent: fhem
Accept-Encoding: gzip,deflate

2018.10.12 20:37:17 5: HttpUtils request header:
GET /fsapi/GET/netRemote.nav.status?pin=1234 HTTP/1.0
Host: 192.168.134.xxx
User-Agent: fhem
Accept-Encoding: gzip,deflate

2018.10.12 20:37:17 4: http://192.168.134.xxx:80/fsapi/GET/netRemote.sys.power?pin=1234: HTTP response code 200
2018.10.12 20:37:17 5: HttpUtils http://192.168.134.xxx:80/fsapi/GET/netRemote.sys.power?pin=1234: Got data, length: 82
2018.10.12 20:37:17 5: HttpUtils response header:
HTTP/1.0 200 OK
Content-Type: text/xml
Access-Control-Allow-Origin: *
Content-Length: 82
2018.10.12 20:37:17 5: Radio2: URL http://192.168.134.xxx:80/fsapi/GET/netRemote.sys.power?pin=1234 returned:
<fsapiResponse>
<status>FS_OK</status>
<value><u8>0</u8></value>
</fsapiResponse>

2018.10.12 20:37:17 5: Radio2: Power GET successful.
Can't use string ("
") as a HASH ref while "strict refs" in use at ./FHEM/17_SIRD.pm line 1976.
2018.10.12 20:40:03 5: Initializing Type Library:
2018.10.12 20:40:03 1: Including fhem.cfg


Danach sieht es wohl so aus, dass scheinbar das SIRD Modul den Fhem crashen lässt. Der Restart übrigens wurde vom Eventhandler meines Nagios automatisch gemacht, deshalb hab ich es nicht gleich mitbekommen.
Aber nun hab ich es mal ausgewertet und am Tag sind es ca. 3-5 Abstürze.

Ich habe ein Lidl SIRD C14. Dort wurde seit einiger Zeit keine neue Firmware installiert. Das einzige, was ich vorher gemacht hatte, war ein Fhem Update am 08.10..
Vom Modul ist die Version 1.1.10 installiert. Wie es scheint, ist da auch ein Update des Moduls der Version 1.1.6 ersetzt worden, wo alles noch funktionierte.

Danke schonmal.
FHEM auf Raspi3, CUL868, RFXTRX433
MAX! mit Cube eingebunden, Temps, und viele weitere Geräte

mumpitzstuff

Das verstehe ich nicht. Power wird doch mit jedem Update ausgeliefert. Warum sollte das nur 3-4 Mal am Tag schief gehen. Der Response sieht auch gut aus soweit ich das sehen kann:

Kannst du bitte folgendes versuchen und die Zeile 1976 durch folgendes ersetzen?

Alt:
if (('GET' eq $param->{cmd}) && exists($xml->{fsapiResponse}{value}->{u8}{value}))

Neu
if (('GET' eq $param->{cmd}) && exists($xml->{fsapiResponse}{value}{u8}{value}))

Falls sich danach der Absturz von zeile 1976 in die Zeile 1978 verschieben sollte, dann wüsste ich woran es liegt und könnte was ändern.

Future001

Hi,

schläfst du eigentlich auch mal  ;)
Hab ich geändert. Ich melde mich - wenn's läuft oder eben nicht läuft!

Ich hatte nach meinem Post die alte Version (v1.1.6) genommen und da war bis eben alles gut.

FHEM auf Raspi3, CUL868, RFXTRX433
MAX! mit Cube eingebunden, Temps, und viele weitere Geräte

mumpitzstuff

Okay danke! Ich kann sowas immer nur machen wenn das Kind im Bett ist,deshalb antworte ich meist so spät. Außerdem brauche ich nur noch rund 5h Schlaf...

Future001

Hallo,

mit den 5h kann ich mithalten - aber eher, weil ich nicht mehr bekomme :(

Also, heute früh nach geschaut - und gecrasht. Gecrasht haeißt, das auf meinem Raspi komplett der perl-Prozess gekillt ist. Dadurch, dass die PID-File noch existiert gibt es leider Probleme mit dem "restart".
Ich fange das aktuell über das Restart-Script ab.

2018.10.14 07:46:11 5: Radio1: Power GET successful.
Can't use string ("
") as a HASH ref while "strict refs" in use at ./FHEM/17_SIRD.pm line 1976.
*** Error in `/usr/bin/perl': free(): invalid next size (fast): 0x03a583e0 ***
2018.10.14 07:53:50 1: Including fhem.cfg


Vielleicht kannst du ja irgendwie mit einer Fehlerbehandlung den Crash verhindern.

VG
FHEM auf Raspi3, CUL868, RFXTRX433
MAX! mit Cube eingebunden, Temps, und viele weitere Geräte

Lichti

Habe vor ein paar Tagen einen FHEM-Update gemacht und seitdem ebenfalls Abstürze von FHEM.
Ist mir nicht gleich aufgefallen, weil danach automatisch neu gestartet wird.
Allerdings setze ich für diesen Fall eine LED am Raspi, die mir jetzt ins Auge gestochen hat.

Einzige Meldung bei Loglevel1:
Not a HASH reference at ./FHEM/17_SIRD.pm line 1570.

Ist das evtl. das gleiche Problem ?

Future001

Hallo,

meine Raspis sind im Schrank, Lampen und LED's sehe ich da keine - will ich ja auch nicht.
Ich müsste raten, ob es sich hierbei um das selbe Problem handelt - der letzte Fehler kam mit der Änderung der Zeile durch mumpitzstuff. Vorher war es auch "nur" ein Hash ref Fehler, was ja nun ein Perl Fehler geworden ist  :-\

Abwarten... Zur Not funktioniert ja eine alte Version.
FHEM auf Raspi3, CUL868, RFXTRX433
MAX! mit Cube eingebunden, Temps, und viele weitere Geräte

mumpitzstuff

Verstehe ich nicht. Weshalb führen jetzt Updates von Fhem zu Abstürzen in dem Modul? Ist mir aktuell völlig unbegreiflich.

@Lichti: Kannst du bitte das Modul mit Verbose 5 laufen lassen und den letzten XML Output vor dem Absturz zukommen lassen falls möglich?

Irgendwie wird der XML Ouput sporadisch zerstört und ich habe keine Ahnung weshalb. Sowas an allen Stellen sinnvoll abzufangen, ist ein enormer Aufwand und die Ursache dafür wäre dann immer noch unklar.

Future001

Moin!

wie kann ich den verbose eines Moduls einstellen? Ich hab das jetzt für die betroffenen Devices gemacht, was natürlich aufwändiger ist.
Ich hab heute insgesamt 5 nicht selbst provozierte Abstürze gehabt. Ich versuche das mal einzugrenzen - aber komme vmtl. erst heute abend dazu.
FHEM auf Raspi3, CUL868, RFXTRX433
MAX! mit Cube eingebunden, Temps, und viele weitere Geräte