Getting worse. Now I still get “attemping fallback” even with the hardwired network, and sometimes the wakeword prompt comes on and just sits there (the green line around the screen) in a totally silent room.
Any chance that somehow the Mycroft servers can be brought back? That at least was usable for me!
Share your neon.yaml file, please?
at this point, no. You might be able to hack together a backend and use hosts file entries to make something work, but that’s its own pile of effort. I’d probably swap to neon or ovos.
Yeah, @baconator that’s what I have been trying to do since my Mark II arrived, but as I said above, Neon has just never worked as well as the Picroft did. Right now I am using iPhone Home to control my Hubitat instead.
It is just the default:
skills:
blacklisted_skills:
- skill-ovos-setup.openvoiceos
- skill-messaging.neongeckocom
- skill-custom_conversation.neongeckocom
- skill-instructions.neongeckocom
- skill-audio_record.neongeckocom
- mycroft-wiki.mycroftai
and just a few minutes ago I tried again the simplest command I can think of “hey neon, what time is it”. This is with wifi disabled and cat5 plugged in. Since I can ssh to it, obviusly the network is working. The voice log shows as follows:
2024-02-19 09:50:37.929 - voice - ovos_dinkum_listener.voice_loop.voice_loop:run:252 - INFO - speech finished
2024-02-19 09:50:38.015 - voice - ovos_dinkum_listener.voice_loop.voice_loop:_get_tx:635 - INFO - Attempting fallback STT plugin
2024-02-19 09:50:38.579 - voice - ovos_dinkum_listener.voice_loop.voice_loop:_after_cmd:671 - INFO - nothing transcribed
Just for the heck of it, I rebooted my fiber modem and the Mark II answered right away. But it was still doing a fallback, except the fallback was fast and worked. I thought the fallback was local and the main/fast STT was over the net somewhere. So multiple mysteries going on here, including my fiber internet (which claims to be going full speed!)
2024-02-19 12:35:31.890 - voice - neon_speech.service:handle_internet_connected:496 - INFO - Internet Connected, Resetting STT Stream
2024-02-19 12:45:22.348 - voice - ovos_dinkum_listener.voice_loop.voice_loop:run:222 - INFO - Wakeword detected
2024-02-19 12:45:24.418 - voice - ovos_dinkum_listener.voice_loop.voice_loop:run:252 - INFO - speech finished
2024-02-19 12:45:24.423 - voice - ovos_dinkum_listener.voice_loop.voice_loop:_get_tx:635 - INFO - Attempting fallback STT plugin
2024-02-19 12:45:26.369 - voice - ovos_dinkum_listener.voice_loop.voice_loop:_after_cmd:669 - INFO - transcribed: what time is it
@NeonDaniel maybe you have some suggestion for @burns if @mikejgray hasn’t already asked you about it? Thanks!
This is an odd one since there’s no indication of why STT has failed. A couple things to double-check for troubleshooting:
ping api.google.com comes back okay? An example of normal output is included below.(venv) neon@neon:~$ ping api.google.com
PING api.l.google.com (142.250.217.68) 56(84) bytes of data.
64 bytes from sea09s29-in-f4.1e100.net (142.250.217.68): icmp_seq=1 ttl=116 time=8.27 ms
64 bytes from sea09s29-in-f4.1e100.net (142.250.217.68): icmp_seq=2 ttl=116 time=18.4 ms
64 bytes from sea09s29-in-f4.1e100.net (142.250.217.68): icmp_seq=3 ttl=116 time=10.4 ms
^C
--- api.l.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 8.271/12.370/18.411/4.361 ms
~/.config/neon/neon.yaml and then make sure the recordings at ~/.local/share/neon/listener/utterances/ sound okay (play ~/.local/share/neon/listener/utterances/ will play it back on the Mark2)? I don’t expect there to be an issue here since fallback worked, but just to eliminate any potential microphone/recording issues.listener:
save_utterances: True
Oh oh. First, the pings seem ok:
(venv) neon@neon:~$ ping api.google.com
PING api.l.google.com (172.217.13.132) 56(84) bytes of data.
64 bytes from yul02s05-in-f4.1e100.net (172.217.13.132): icmp_seq=1 ttl=116 time=13.7 ms
64 bytes from yul02s05-in-f4.1e100.net (172.217.13.132): icmp_seq=2 ttl=116 time=13.1 ms
64 bytes from yul02s05-in-f4.1e100.net (172.217.13.132): icmp_seq=3 ttl=116 time=13.1 ms
64 bytes from yul02s05-in-f4.1e100.net (172.217.13.132): icmp_seq=4 ttl=116 time=13.5 ms
64 bytes from yul02s05-in-f4.1e100.net (172.217.13.132): icmp_seq=5 ttl=116 time=13.5 ms
64 bytes from yul02s05-in-f4.1e100.net (172.217.13.132): icmp_seq=6 ttl=116 time=13.1 ms
But then I modified the neon.yaml file as you suggested (at the very end with listener all the way to the left, and “save_utterances” indented below it. I rebooted the system with “sudo reboot now” and looking at it a few minutes later, the screen was dark, with two of the green leds lit and nothing obviously happening. No access via ssh. I then power cycled it and got what appeared to be the normal spash screen for a few seconds, then the screen went dark and I got a circle of green leds, a circle of red leds, and now all is dark. No accesses going on to the SSD.
Time to start over yet again?
Oh, wait! It just came back to life and is continuing to boot; ssh accessible. More soon.
No idea what happened with the reboot. But anyway, it is recording utterances. I would say this is related to the problem. I tried repeatedly with “what time is it.” This time it never did a fallback. But the STT stuff was pretty bad, as were the recordings. Here is the voice log:
2024-02-20 10:25:27.211 - voice - ovos_dinkum_listener.voice_loop.voice_loop:run:252 - INFO - speech finished
2024-02-20 10:25:27.328 - voice - ovos_dinkum_listener.voice_loop.voice_loop:_after_cmd:671 - INFO - nothing transcribed
2024-02-20 10:25:27.332 - voice - ovos_dinkum_listener.service:_save_stt:590 - INFO - Saving Utterance Recording
2024-02-20 10:27:21.676 - voice - ovos_dinkum_listener.voice_loop.voice_loop:run:222 - INFO - Wakeword detected
2024-02-20 10:27:24.085 - voice - ovos_dinkum_listener.voice_loop.voice_loop:run:252 - INFO - speech finished
2024-02-20 10:27:24.194 - voice - ovos_dinkum_listener.voice_loop.voice_loop:_after_cmd:669 - INFO - transcribed: what time is it
2024-02-20 10:27:24.196 - voice - ovos_dinkum_listener.service:_save_stt:590 - INFO - Saving Utterance Recording
2024-02-20 10:28:15.731 - voice - ovos_dinkum_listener.voice_loop.voice_loop:run:222 - INFO - Wakeword detected
2024-02-20 10:28:16.032 - voice - ovos_dinkum_listener.voice_loop.voice_loop:run:252 - INFO - speech finished
2024-02-20 10:28:16.787 - voice - ovos_dinkum_listener.voice_loop.voice_loop:_after_cmd:669 - INFO - transcribed: what time
2024-02-20 10:28:16.790 - voice - ovos_dinkum_listener.service:_save_stt:590 - INFO - Saving Utterance Recording
2024-02-20 10:28:46.944 - voice - ovos_dinkum_listener.voice_loop.voice_loop:run:222 - INFO - Wakeword detected
2024-02-20 10:28:48.060 - voice - ovos_dinkum_listener.voice_loop.voice_loop:run:252 - INFO - speech finished
2024-02-20 10:28:48.617 - voice - ovos_dinkum_listener.voice_loop.voice_loop:_after_cmd:669 - INFO - transcribed: what
2024-02-20 10:28:48.622 - voice - ovos_dinkum_listener.service:_save_stt:590 - INFO - Saving Utterance Recording
And listening to the playback, you can tell why it got these. The first time, I was reasonably close but spoke conversationally (always waiting for the post-wake-word prompt though). The recording just had a single partial syllable. The second time (when the log has it totally right) I spoke like I was talking to an ESL student and very close to the MkII: Each word distinct and with a space between them. It got that ok, although the playback was not very loud. (this is the one in the log at 10:27:24). The next one (10:28:16) was still fairly close but louder than normal, and a bit faster. You can see that it cut off the recording (and the audio shows this) although it did figure out what I wanted. And finally I stood back maybe 6 or 8 feet and spoke loudly. All it got was “what” and it proceeded to give me the date.
So to summarize, the STT transcription seems reasonably accurate given what it actually recorded. But it is simply not recording my voice very well. And of course this does not explain the fallbacks. Let me know if you want to hear the utterance recordings.
Ah ha, we’re getting somewhere…is the Mark 2 near a fan or something else noisy? I had to move one of mine away from a NAS because the fans were interfering with the microphone.
Hmm. Interesting. I do have a space heater not to far away. I’ll experiment.
I don’t see that the fan on the space heater makes any difference. No matter whether the fan is on, I generally have to be somewhat close and speak up a bit louder than my normal voice to get the MkII to record clearly. But here is something interesting, and I wonder if I am making the correct inference:
It seems that when my voice is softer or quicker, that is when it uses the fallback STT plugin and sometimes the fallback gets it ~correct. I have not seen lately the “wait for a minute or 2” behavior. But when it falls back, it appears to make the decision quickly. Here is the log (and I think the timing is the most interesting thing):
2024-02-21 09:59:29.099 - voice - ovos_dinkum_listener.voice_loop.voice_loop:run:222 - INFO - Wakeword detected
2024-02-21 09:59:30.982 - voice - ovos_dinkum_listener.voice_loop.voice_loop:run:252 - INFO - speech finished
2024-02-21 09:59:30.989 - voice - ovos_dinkum_listener.voice_loop.voice_loop:_get_tx:635 - INFO - Attempting fallback STT plugin
2024-02-21 09:59:31.776 - voice - ovos_dinkum_listener.voice_loop.voice_loop:_after_cmd:669 - INFO - transcribed: time is it
2024-02-21 09:59:31.778 - voice - ovos_dinkum_listener.service:_save_stt:590 - INFO - Saving Utterance Recording
2024-02-21 09:59:59.008 - voice - ovos_dinkum_listener.voice_loop.voice_loop:run:222 - INFO - Wakeword detected
2024-02-21 10:00:03.085 - voice - ovos_dinkum_listener.voice_loop.voice_loop:run:252 - INFO - speech finished
2024-02-21 10:00:03.183 - voice - ovos_dinkum_listener.voice_loop.voice_loop:_after_cmd:669 - INFO - transcribed: what time is it
2024-02-21 10:00:03.190 - voice - ovos_dinkum_listener.service:_save_stt:590 - INFO - Saving Utterance Recording
One other curiosity: How come sometimes Neon says “I don’t understand” when it gets an utterance that seems not to match anything, and other times it just silently ignores it?
I believe one-word utterances are ignored silently. This is intentional to avoid speaking “I don’t understand” if the user just says the wake word and nothing afterwards since a lot of STT engines will transcribe something if you pass any audio. It does log to skills.log:
LOG.info(f"Ignoring 1-word input: {utterance}")
I don’t think that explains what I have seen. For example, I was trying out the hubitat skill and said “turn on the bookcase lights”. I got exactly those words in the voice log, but no response at all from the MkII. The green light went around once or twice at most and then stopped. In the skills log I got this:
2024-02-21 14:46:32.689 - skills - neon_core.skills.intent_service:handle_utterance:261 - INFO - lang=en-us ['turn on bookcase lights', 'turn on the bookcase lights']
but it obviously did not find that in the hubitat skill. And it never said it did not understand.
Interesting… This seems to indicate that some skill did handle the intent, but didn’t respond in any way. If you enable debug logs, is there any helpful context around that utterance?
To enable debug logging, append to ~/.config/neon/neon.yaml:
log_level: DEBUG
Does that increase the info in existing logs, or add a new log?
Sorry, incomplete info on my part. After adding that line, you’ll want to restart the services (sudo systemctl restart neon) and then any DEBUG logs in the code that were previously ignored will start outputting to log files. It ends up being a lot of extra logs which is why its disabled by default.