Closed maxemoose closed 8 months ago
Please update to version 1.8.0 of the container and let me know if this is still a problem. Thanks!
Updated. Will keep a passive eye on the logs. This did not happen again with 1.7.0 since I first reported it either.
I can observe the same behavior, however I use three Atom Echos and openwakeword in version (1.8.0). After a short time (sometimes directly at startup) I get the same error message:
openwakeword | INFO:root:Ready
openwakeword | INFO: Created TensorFlow Lite XNNPACK delegate for CPU.
openwakeword | ERROR:root:Unexpected error in wake word thread
openwakeword | Traceback (most recent call last):
openwakeword | File "/usr/local/lib/python3.9/dist-packages/wyoming_openwakeword/openwakeword.py", line 301, in ww_proc
openwakeword | ww_model.allocate_tensors()
openwakeword | File "/usr/local/lib/python3.9/dist-packages/tflite_runtime/interpreter.py", line 531, in allocate_tensors
openwakeword | return self._interpreter.AllocateTensors()
openwakeword | RuntimeError: /tensorflow/tensorflow/lite/kernels/reshape.cc:92 num_input_elements != num_output_elements (2 != 1)Node number 24 (RESHAPE) failed to prepare.
I run openwakeword in a Docker container:
openwakeword:
image: rhasspy/wyoming-openwakeword
container_name: openwakeword
restart: unless-stopped
ports:
- "10400:10400"
volumes:
- ./custom:/custom
command: --custom-model-dir /custom --threshold 0.4 --trigger-level 1
It seems that the error occurs more frequently when there is more than one Echo device active. When I have only one in use, the error occurs very rarely.
i have the same issue, before I was running only the assist-microphone addon, but after adding 1 echo , error appears and no more detection
I can confirm the same. I have an ESP32 with a microphone and it was working fine. After adding the the echo, I started getting this error and It completely stops listening. I have restart openwakeword to make it work again.
This is my command.
-m wyoming_openwakeword
--uri 'tcp://0.0.0.0:10400'
--preload-model 'ok_nabu'
--trigger-level '1'
--custom-model-dir /share/openwakeword
It may not be just because of echo. But it could be because of more than 1 microphone. Not sure though.
OK, I think this may apply just to certain wake words. Once there is more than one device streaming at a time (for the same wake word), everything is batched. Some models appear not to support batching...
OK, I think this may apply just to certain wake words. Once there is more than one device streaming at a time (for the same wake word), everything is batched. Some models appear not to support batching...
@synesthesiam I was trying with "Hey Jarvis".
By way of feedback on this issue - I have been testing the changes made to fix this issue with 5 Atom Echo's (running the wyoming-openwakeword service in docker) and I have not experienced the issue in 24 hrs of use. Prior to this change I would see the same crashes as reported by others within a few minutes of turning on multiple Atom Echo's.
+1 to Minty's comment. I've had stable container/Raspberry based satellites since v1.8.1 of OpenWakeWord with the batching removal.
My logs are also clear and have been for the last week. Closing this.
Using an ESP32 S3 Box running ESPHome voice assistant firmware paired with Home Assistant Voice Control. Wake word recognition was initially working and the S3 Box was left on and alone for a few hours while I was away. When I got back, wake word recognition was not working.
Checked the logs on the S3 Box and it didn't show any errors but was clearly not trying to recognize a wake word. Checked the logs for the wyoming-openwakeword Docker container and found this:
Rebooted the container and wake word recognition started working again.
Steps To Reproduce:
Apologies but I am not sure what triggered the error. I'll add more detail if I can catch it in the act.
Environment:
Raspberry Pi 4B 4GB:
Other: