Squeezebox Modul - erste Version

Begonnen von bugster_de, 17 Dezember 2013, 22:12:10

Vorheriges Thema - Nächstes Thema

bugster_de

Hi,

da es hier mit Fehlermeldungen doch nun echt ruhig geworden ist könnte man daraus schliessen, dass das Modul nun annähernd fehlerfrei funktioniert. Sollte man es nun in den Standardumfang von FHEM übernehmen?

Tedious

IMHO gerne, das funktionier so sauber und perfekt...!!
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

FHEm2005

Ich bin absolut dafür, dass das Modul die höheren Weihen empfängt!!  8) 8)  Was spricht eigentlich dagegen. Muss noch was geleistet werden, was (noch) nicht da ist? Wir helfen gerne!

Es ist wirklich ruhig geworden und hatte die Befürchtung, ich sei der Einzige, der das Modul noch nutzt.

Gruß Eberhard
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

heppel

#1158
Nein, ich nutze es auch !

Ich habe da aber noch einen (Mini-) Bugreport:

Von Zeit zu Zeit sehe ich im Log:

Zitat
2016.08.25 11:51:11 1: PERL WARNING: Argument "?" isn't numeric in addition (+) at ./FHE/98_SB_PLAYER.pm line 1108.

Offenbar gibt es Umstände, unter denen der LMS selber nicht weiss, auf welcher Track einer Playlist er ist und dann kommt statt einer Zahl ein "?".  Ich höre übrigens überwiegend Webradio mit dem LMS.

Mein (ungetesteter) Reparaturvorschlag ist:


readingsBulkUpdate( $hash, "playlistCurrentTrack",  $args[ 1 ] eq '?' ? 0 : $args[ 1 ]+1 );


oder man akzeptiert nichtnumerische Werte im Reading (ebenfalls ungetestet):


readingsBulkUpdate( $hash, "playlistCurrentTrack",  $args[ 1 ] !~ /^\d+$/ ? $args[ 1 ] : $args[ 1 ]+1 );


Viele Grüße,
  Heppel

Edit: Im ersten Anlauf hatte ich den Test für den zweiten Lösungsansatz genau falsch rum.

ChrisD

Hallo,

@bugster_de: Aus meiner Sicht können die Module in den offiziellen Teil übernommen werden. Bisher war dies nicht möglich da die Dokumentation nicht vollständig war. Dank der Mithilfe von verschiedenen Usern ist sie es (fast).

@Heppel: Ich habe die 1. Version übernommen da an anderen Stellen im Code davon ausgegangen wird dass das Reading numerisch ist. Ich konnte das Verhalten bei mir aber nicht nachstellen, kannst du mir den Link zu einem Webradio schicken ?

@Tedious: Ich habe in der neuen Version den alivecheck geändert, kannst du nach dem Update und Neustart das Attribut internalPingProtocol beim Server auf none setzen und schauen ob die Meldungen weiterhin auftreten ?

@ Ronny: Ich habe eine Reihe Änderungen beim TTS in Verbindung mit gesyncten Player gemacht, kannst du mit der neuen Version testen ob die Wiedergabe jetzt korrekt funktioniert ?

Ich habe die Module aktualisiert, Änderungen:

97_SB_SERVER (0021)
- Alivecheck nur ausführen wenn während vorgegebener Zeit keine Daten mehr empfangen wurden
- optional Alivecheck ohne Ping ausführen (internalPingProtocol none)
- item_summary für Dokumentation hinzugefügt

98_SB_PLAYER (0056)
- Status wurde nach sync nicht immer aktualisiert
- Kommunikation zwischen gesyncten Playern bei TTS korrigiert
- resetTTS korrigiert
- restore nach TTS korrigiert
- vermeiden dass mehrere Player den gleichen Namen bekommen
- Änderung des Syncmasters im statusrequest an Sync-Gruppe weiterleiten
- item_summary für Dokumentation hinzugefügt
- Fehlermeldung bei ungültigem Playlist Index behoben (heppel)

Achtung, der Punkt
- vermeiden dass mehrere Player den gleichen Namen bekommen
kann dazu führen dass die Namen der Player im Internal PLAYERNAME ändern wenn mehrere Player im LMS den gleichen Namen haben. Der FHEM-Name ist nicht davon betroffen.

Zum Aktualisieren kann
update force https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/sb/controls_squeezebox.txtverwendet werden.

Grüße,

ChrisD

heppel

Hallo ChrisD,

die Meldung kommt nicht oft. Ich habe sie in diesem Monat acht mal in meinen Logs. Wo ich die Meldungen jetzt gerade noch mal rausgesucht habe, fällt mir auf, dass alle Meldungen zwischen 11:50 und 11:53 auftraten. Zeitlich in der Nähe liegt bei mir nur ein tägliches "at", das um 11:45 einige Player abschaltet.

Im Normalfall gibt der LMS das Radio auf eine Syncgruppe mit vier Playern aus. Montags bis Samstags schaltet das "at" drei von den vier Playern auf "off". Ca. 20 Sekunden später wird einer von den dreien per "shutdown" ganz entfernt. Wo dann fünf bis acht Minuten Verzögerung her kommen, weiss ich auch nicht.

In einem Drittel der Fälle ist die Fehlermeldung aufgetreten. Ich schlage vor, dass ich die neue Version einspiele und mal beobachte. Wenn die Fehlermeldung nicht wieder kommt, lassen wir es so.

Viele Grüße,
  Heppel

FHEMAN

Hallo ChrisD,

ich habe es mit 4 gesyncten Playern (2 davon ausgeschaltet) gleich getestet - mit einem super Ergebnis! Nur ganz zu Beginn wurde mein Testtext Hallo Welt nicht komplett zu Ende ausgesprochen. Seit Neustart der Soft Squeezeplayer tuts aber wunderbar.
Nun kann ich die Deckenlautsprecher im Flur endlich wieder für Musik verwenden.
Ein großes Dankeschön nochmal für Deine 1A Arbeit!

Ronny
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

FHEMAN

Eine Frage noch am Rande:
Ich habe in letzter Zeit (bereits vor dem letzten Update) auf einmal Probleme mit dem TTS Modul bei deutschen Umlauten. Ich habe die Voicerss Klamotte konfiguriert. Wenn ich
set Player talk Küche
eingebe, würd das ü in %FC umgeandelt und das Wort deshalb nicht vorgelesen, sondern Wort buchstabiert. Hier der Log
2016-09-03 00:49:59 SB_PLAYER SB.Essen currentTitle: http://api.voicerss.org/?key=XXX&src=K%FCche.&hl=de-de&f=48khz_16bit_stereo

Langue de habe ich eingestellt. Irgendwelche Ideen, woran das liegen könnte oder was ich einstellen kann?

Gruß
Ronny
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

ChrisD

Hallo,

Der Fehler kommt von der Codierung der Umlaute, das Modul versucht zu erraten in welchem Format der Text vorliegt und ihn in UTF-8 zu konvertieren. Dabei müsste ü durch %C3%BC ersetzt werden. Leider scheint es in deinem Fall nicht zu funktionieren. Welchen Browser verwendest du für die Eingabe und auf welchem System läuft FHEM (OS, Perl Version) ?

Grüße,

ChrisD

FHEMAN

Hi ChrisD,

ich verwende die aktuellste Chrome Version. Habe aufgrund Deiner Aussage mit IE 11 getestet - mit gleichem Ergebnis.
FHEM läuft auf einem Debian Wheezy (Igor Image).
Perl Version ist 5.020002 (ermittelt mit {$]})

Gruß
Ronny
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

ChrisD

Hallo,

Ich habe eine neue Version erstellt (0057). Kannst du nach einem Update und Neustart zuerst debug in ttsOptions setzen
attr SB.Essen ttsOptions debugund anschließend die Ausgabe nochmal testen.

Im Log sollten dann Meldungen mit utf-8 zu finden sein, kannst du die posten ?

Grüße,

ChrisD

FHEMAN

Moin ChrisD,

bin wie empfohlen vorgegangen (1x talk, 1x saytext):


2016.09.04 12:51:43 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: wait for power on
2016.09.04 12:51:43 0: SB_PLAYER_Set: SB.Essen: no utf-8
2016.09.04 12:51:43 0: SB_PLAYER_Set: SB.Essen: utf-8
2016.09.04 12:51:43 0: SB_PLAYER_Set: SB.Essen: add to ttsqueue: http://api.voicerss.org/?key=xxx&src=K%C3%BCche.&hl=de-de&f=48khz_16bit_stereo
2016.09.04 12:51:44 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: save state
2016.09.04 12:51:44 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: load playlist
2016.09.04 12:51:44 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: wait for play
2016.09.04 12:51:44 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: playing
2016.09.04 12:51:50 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: stopped
2016.09.04 12:51:50 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: restore state
2016.09.04 12:51:50 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: idle
2016.09.04 12:52:50 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: wait for power on
2016.09.04 12:52:50 0: SB_PLAYER_Set: SB.Essen: no utf-8
2016.09.04 12:52:50 0: SB_PLAYER_Set: SB.Essen: utf-8
2016.09.04 12:52:50 0: SB_PLAYER_Set: SB.Essen: add to ttsqueue: http://api.voicerss.org/?key=xxx&src=K%C3%BCche.&hl=de-de&f=48khz_16bit_stereo
2016.09.04 12:52:50 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: save state
2016.09.04 12:52:50 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: load playlist
2016.09.04 12:52:51 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: wait for play
2016.09.04 12:52:51 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: playing
2016.09.04 12:52:55 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: stopped
2016.09.04 12:52:55 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: restore state
2016.09.04 12:52:55 0: SB_PLAYER_SetTTSState: SB.Essen: ttsstate: idle


Danke und Gruß
Ronny
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

ChrisD

Hallo,

Die Codierungsrc=K%C3%BCcheist richtig.

Ist die Ausgabe noch immer falsch ? Was steht im Reading currentTitle ?

Welche Version des LMS verwendest du ?

Grüße,

ChrisD

FHEMAN

Ja, die Ausgabe ist noch falsch. currentTitle und currentMedia sind trotzdem noch falsch codiert:

http://api.voicerss.org/?key=xxx&src=K%FCche.&hl=de-de&f=48khz_16bit_stereo

Die LMS Version ist 7.9.0. (Ich bin zuletzt vom QNAP NAS auf den Cubietruck umgezogen; es könnte sein, dass damit erst der Fehler auftauchte.)
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

ChrisD

Hallo,

Kannst du auf 0058 updaten, neu starten, das Attribut beim Player in
attr SB.Essen ttsOptions debug,nouriescapeändern und erneut testen ?

Grüße,

ChrisD