Hallo,
ich würde gerne eine WAV-Datei via MQTT an meinen Sprachassistenten schicken, der diese dann ausgeben soll. Ich finde aber nicht raus, wie ich die in Perl richtig umwandeln könnte, damit ich sie via JSON versenden kann. Meine bisherigen Versuche mit open und read schlugen alle fehl.
Ziel soll ein Ersatz für
mosquitto_pub -p 12183 -t hermes/audioServer/$siteId/playBytes/$requestId -s < /path/to/file.wav
sein.
Könnte mich bitte jemand auf die richtige Fährte schicken?
Danke
Stefan
Hallo Stefan,
mosquitto_pub -p 12183 -t \'hermes/audioServer/$siteId/playBytes/$requestId\' -f /path/to/file.wav
Das Topic muss in Hochkommatas gefasst werden und die Datei übergibt man mit "-f". Die Backslashes vor den ' beachten, sonst werden die Variablen nicht übernommen.
mosquitto_pub schickt die Daten dann im RIFF-Format zu Rhasspy.
Gruß Jens
Ja, danke. Mir geht's um's Umwandeln der Datei und Versenden via Perl. Damit ich das Zeug ins Modul einbauen kann.
RIFF wäre das Suchwort. Im Zusammenhang mit MQTT und Perl habe ich nicht allzuviel gefunden. Daher der altbackene Versand über mosquitto_pub.
Keine Ahnung, ob das klappt, aber im FHEM-Kontext kann man auch Binärcode mit FileRead lesen.
Auszug aus MYSENSORS_DEVICE betr. Einlesen einer firmware-file:
my ($err, @lines) = FileRead({FileName => "./FHEM/firmware/" . $filename, ForceType => "file"});
K.A., ob das Array dann als Payload verschickt werden kann...
https://metacpan.org/pod/File::Format::RIFF (https://metacpan.org/pod/File::Format::RIFF) habe ich gefunden.
Anfängerfragen passt genau - wie installiere ich dieses Modul? :-[
"cpan -i File::Format::RIFF" kennt das Modul nicht und "apt-cache search perl riff" bringt auch keine brauchbare Ausgabe.
Zitat von: Beta-User am 12 Februar 2021, 20:28:54
Keine Ahnung, ob das klappt, aber im FHEM-Kontext kann man auch Binärcode mit FileRead lesen.
Das gibt den Inhalt dann als zeilenweises Array aus. Eine Idee, wie ich das dann als Ganzes verschicken könnte?
Mit Zeilen einfach in einer foreach aneinander zu hängen, bin ich nicht weiter gekommen.
Ein join ohne irgendwas hast du vermutlich schon versucht?
Generell vielleicht noch eine Anmerkung: MQTT ist eigentlich für "lightweight" Kommunikation gedacht; da Megabyte an Daten drüberzuhauen ist eventuell nicht so top (v.a., wenn man die dann noch irgendwie in größere Rohdatenstreams konvertiert (falls riff in die Richtung gehen sollte)).
Eigentlich wäre es besser, man könnte über MQTT irgendwie einfach "nur" eine Art Referenz übergeben, wo die Daten dann abgeholt werden können (notfalls mit FHEMWEB als Webserver).
Join habe ich natürlich noch nicht versucht. Ich bin ja jetzt nicht so der Programmier-Guru ;)
Danke, ich sag jetzt mal, das würde so funktionieren. Auch wenn ich noch keine Ausgabe höre. Was aber nichts mit unserem Code zu tun haben muss.
Und ja, das Zeug über MQTT zu versenden, ist keine optimale Lösung. Wird bei dem Sprachassistenten aber generell so gemacht.
edit:
Korrigiere, das Zeug wird noch immer als "String" verschickt. Ich grabe mal im Source Code des Assistenten und schaue, wie die das machen. Eventuell kann ich das dann ja in Perl übersetzen.
Ich korrigiere nochmal. Ich bin schuld, dass die Bytes in String umgewandelt wurden. Hatte das ganze aus einem Denkfehler heraus mit toJSON umgewandelt.
Es wird jetzt etwas ausgegeben. Nicht das, was ich hören will. Nur komisches Kratzen. Aber immerhin einen Schritt weiter.
Danke!
Na ja, wenn du irgendwas in JSON versenden mußt, dann musst du das schon irgendwann irgendwie passend einpacken, und es kann durchaus sein, dass ein "doppeltes Einfachquote " als joiner auch unpassend ist...
Was das "per MQTT" angeht: evtl. mal die Datenmengen kritisch beäugen und erforderlichenfalls dann auf eine externe Brokerlösung (ggf. auch nur beschränkt für diesen Teil) ausweichen. Es gibt zum publishen in Perl auch separate libs, damit könnte man das ggf. nonblocking in eine eigene .pl auslagern...
Zitat von: Beta-User am 15 Februar 2021, 15:52:55
Na ja, wenn du irgendwas in JSON versenden mußt, dann musst du das schon irgendwann irgendwie passend einpacken, und es kann durchaus sein, dass ein "doppeltes Einfachquote " als joiner auch unpassend ist...
Hmmmmm
Andere Ideen, was ich da nehmen könnte?
nicht wirklich... Habe irgendwo kurz aufgegabelt, dass "doppelte Doppelquotes" wohl besser wären wie undef, aber das wäre dann mein last resort... Bin aber auch nur "copy/paste-Perler"...
Gibt's irgendwo eine Doku, wie die Gegenstelle die Daten denn genau haben will, das kann doch eigentlich auch keine Geheimwissenschaft sein...?
if (-e $filename) {
open($handle, "< $encoding", $filename)
|| warn "$0: can't open $filename for reading: $!";
while (read($handle,my $file_contents,100000) ) {
MQTT::send_publish($hash->{IODev}, topic => $topic, message => $file_contents, qos => 0, retain => "0");
}
close($handle);
}
Mein allerallererster Versuch funktioniert. Wenn ich das File in einem Rutsch schicke. Also, wenn LENGTH groß genug ist. Jetzt müsste ich also nur noch irgendwie schauen, dass das zu sendende File nicht zu groß ist. Aber das kann ja keine Herausforderung sein.
Aua. Das ist für 00_MQTT.pm als IO, wenn ich das Puzzleteil richtig verstehe?
MAn. sollte man das heutzutage nicht mehr zwangsweise so verdongeln. Lieber andersrum vorgehen, und MQTT2_CLIENT zwangsweise vorsehen für die, die noch die alte Implementierung verwenden. (just my2ct.)
(Falls du alternative Wege vorsehen wolltest, kannst du in den Code von MQTT_GENERIC_BRIDGE sehen, da ist beides möglich und auch die Abhängigkeit dann mit einem ander richtigen Stelle vercodeten require hinterlegt).
Hehe, siehst du richtig. Aber ist eine andere Baustelle. Die MQTT Bausteine in FHEM sind für mich noch viel verwirrender, als Perl. Ich verwende es zwar, weiß aber eigentlich nicht, was ich tue. Und befürchte, das ist so eines der Dinge in meinem Leben, die ich einfach nicht lerne (n kann). Wie bügeln.
8) Cool - läuft!
Zitat von: JensS am 15 Februar 2021, 17:07:20
8) Cool - läuft!
Dann wäre m.E. wirklich dringend anzuraten, das direkt in Richtung M2C kompatibel zu machen, wenn wir jetzt die erste Variante kennen, die funktioniert!
Zitat von: drhirn am 15 Februar 2021, 16:50:05
Hehe, siehst du richtig. Aber ist eine andere Baustelle. Die MQTT Bausteine in FHEM sind für mich noch viel verwirrender, als Perl. Ich verwende es zwar, weiß aber eigentlich nicht, was ich tue. Und befürchte, das ist so eines der Dinge in meinem Leben, die ich einfach nicht lerne (n kann). Wie bügeln.
Wenn "wir" es nicht hinbekommen, dem User die Wahlfreiheit zu lassen, wird es auf ewig unglaublich verwirrend bleiben. Heutzutage Module für (nur) 00_MQTT als IO zu bauen, grenzt jedenfalls an Körperverletzung ;) ...
In https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_MQTT_GENERIC_BRIDGE.pm#L2469 findest du die alternative Form für M2-IO's (oberhalb des send_publish für 00_MQTT). Über diese Stelle sollten dann auch auch Codebausteine für das Identifizieren der IO-Type usw. zu finden sein. Falls man das an mehreren Stellen braucht, wäre es vermutlich auch kein Problem, das als lib bereitzustellen...
Zitat von: Beta-User am 15 Februar 2021, 17:17:07
Heutzutage Module für (nur) 00_MQTT als IO zu bauen, grenzt jedenfalls an Körperverletzung ;) ...
Das ist ein eher altes Modul, dass ich einfach am Anpassen auf einen neuen Sprachassistenten bin. Zuerst sollen die Basisfunktionen tun. Dann kann optimiert werden.
Aber grundsätzlich hast du natürlich Recht.
Na ja, im svn ist es nicht, oder? Von daher ist es "neu"...
Und wenn jetzt jemand einsteigt, ist er ggf. froh, sich nicht mit "seltsamen Perl-Abhängigkeiten" rumschlagen zu müssen. Das universell für beide IO-Typen umzubauen, ist daher aus meiner Wahrnehmung eine "Basisfunktion".
Sendet das Modul nur oder empfängt es auch? Wenn ja, wäre das nämlich ein Grund mehr, es nach M2-IO umzubauen...