I’ve got some strange behaviour on the hermes wake listener.
I have set the siteid to “default”, now, when a message comes in with:
{"siteId": "default"}
I get this message:
DEBUG:HermesWakeListener:Got detected message, but wrong site id (default)
This is incorrect, but when a message is send with:
{"siteId": "test"}
then the hotword is detected:
DEBUG:HermesWakeListener:Hotword detected (default)
In the last message, default is not the siteID but the wakeword, might be a bit confusing.
I can’t reproduce this here. When I set the site ID to “default”, it all just works and I don’t get the HermesWakeListener message. I’m running the latest Rhasspy version from GitHub with some of my modifications for Rasa, but those shouldn’t affect this issue as they only change the intent training and parsing.
Checking the code looks ok to me as welll… strange 
Oh wait I misread this: I’m not using the Hermes wake listener, only the audio.
Ah ok, well that works fine indeed
This might sound odd, but could you try and give you Docker container access to /tmp?
I forgot a not 
Really? I was checking the code and seemed fine. Maybe I was looking in old code 
Glad you found it!
I am using porcupine now by the way, which works well! Haven’t tried other wakewords yet.
Currently having some crashes with my Audio Streamer when playing sound, but I does play now and converts mono to stereo 
Still only supports 44100, but in my current setup that is now problem.
I am hoping to push the new version to github soon
Upgraded to 2.17.5, now getting this error:
file “/usr/share/rhasspy/rhasspy/wake.py”, line 710, in in_listening
chunk = bytes(struct.unpack_from(self.chunk_format, chunk))
ValueError: bytes must be in range(0, 256)
I have hermes as audio recorder (nothing changed) and previous version worked ok.
Any thoughts?
Got it fixed. Bad attempt to appease mypy.
Stumbled over this while searching for a solution myself.
I just tried it and mount /tmp (host) to /tmp (container) but it still shows the same error:
ERROR:PorcupineWakeListener:loading wake handle
Traceback (most recent call last):
File "/usr/share/rhasspy/rhasspy/wake.py", line 685, in to_started
self.load_handle()
File "/usr/share/rhasspy/rhasspy/wake.py", line 749, in load_handle
sensitivities=self.sensitivities,
File "/usr/share/rhasspy/porcupine.py", line 69, in __init__
library = cdll.LoadLibrary(library_path)
File "/usr/lib/python3.6/ctypes/__init__.py", line 426, in LoadLibrary
return self._dlltype(name)
File "/usr/lib/python3.6/ctypes/__init__.py", line 348, in __init__
self._handle = _dlopen(self._name, mode)
OSError: /profiles/en/porcupine/libpv_porcupine.so: failed to map segment from shared objecti just tried to play with your hermes client again.
and i cant really figure it out. I got the player in daemon mode to run a few minutes ago but only once and not again.
Nothing more in the log tho (even with -v).
The recorder i cant get working in daemon mode at all.
Both are stuck on the message “Starting daemon…” but work fine when not using daemon mode (tried as pi user as well as root)
Killing a the player daemon process in this “stuck” state throws up this error:
pi@raspberrypi:~ $ killall hermes-audio-player
pi@raspberrypi:~ $ Traceback (most recent call last):
File "/usr/local/bin/hermes-audio-player", line 20, in <module>
plac.call(main)
File "/usr/local/lib/python3.5/dist-packages/plac_core.py", line 330, in call
cmd, result = parser.consume(arglist)
File "/usr/local/lib/python3.5/dist-packages/plac_core.py", line 207, in consu me
return cmd, self.func(*(args + varargs + extraopts), **kwargs)
File "/usr/local/bin/hermes-audio-player", line 16, in main
cli.main(PLAYER, verbose, version, config, daemon)
File "/usr/local/lib/python3.5/dist-packages/hermes_audio_server/cli.py", line 55, in main
context.open()
File "/usr/local/lib/python3.5/dist-packages/daemon/daemon.py", line 375, in o pen
close_all_open_files(exclude=exclude_fds)
File "/usr/local/lib/python3.5/dist-packages/daemon/daemon.py", line 960, in c lose_all_open_files
fd_ranges = _get_candidate_file_descriptor_ranges(exclude=exclude)
File "/usr/local/lib/python3.5/dist-packages/daemon/daemon.py", line 923, in _ get_candidate_file_descriptor_ranges
this_range = this_range._replace(high=high)
File "<string>", line 26, in _replace
File "<string>", line 19, in _make
File "/usr/local/lib/python3.5/dist-packages/hermes_audio_server/cli.py", line 37, in exit_process
server.stop()
NameError: free variable 'server' referenced before assignment in enclosing scop e
No error with the recorder.
Really weird, I have it working here both on my Pi and on my Ubuntu laptop, in daemon mode as well as interactively. I’ll investigate if I can reproduce your issue here.
Looking at the traceback it seems the server object isn’t even initialized, so the program must have got “stuck” while creating the daemon.
Do you have a symbolic link /dev/log on your system?
Ok if figured it out:
Wonder why i didnt find this post the last time 
The HDD with all my dockerstuff was mounted with noexec, remounted it with exec and restarted the rhasspy container and now porcupine works fine.
Is this an error with how porcupine was compiled? Because i never had any errors with other containers before.
Checked and fixed!
@synesthesiam
I have 2 small feature request for the next release.
Would it be possible to modify the wake signal sound through the ui in the upcoming releases?
Would it be possible to add a functionality to repeat the last tts message throug the api?
Thanks for keeping investigating.
It is a default raspian system with the following symlink on /dev/log:
lrwxrwxrwx 1 root root 28 Nov 3 2016 /dev/log -> /run/systemd/journal/dev-log
I have just pushed a new version of my Audio Streamer:
It supports Audio Output now, I have Rhasspy setup with GoogleWavenet set to 44100 samplerate.
The software converts mono to stereo, but due to some hardware issue does not play samplerates other than 44100 very well. Either to fast or to slow
A way to automatically generate training sentences for all the switches in your configuration.yaml file (these work with the built-in HassTurnOn/Off intents)
An intent handler that lets you ask about the state of any named sensor (e.g., “Is the garage door open?”)
I’ve searched through some of the examples and this thread but haven’t been able to find anything. Was this ever developed? If not, what’s the best practice for doing this now? I have rhasspy just setup (with porcupine wakeword + sending events to HASS), and while setting up a few custom queries sounds reasonable, the idea of having to manually create training phrases for every entity+action combination I want seems somewhat daunting, and maybe not what’s intended.
I wonder if they’re generating code at runtime and need to mark it as executable?