timer set for null minutes.

[SXXXR]

when I set a timer it gives no error, it just returns: "timer is set for null minutes" and actually no timer is set.
using default Google stt
language: "de-de"
no other changes since fresh install

did I miss something?

[krisgesling]

Hi there, I've posted in the German Chat Channel to see if others are seeing the same thing.

[gras64]

you got en error like this ?
File "/home/andreas/mycroft-core/mycroft/skills/mycroft_skill/event_container.py", line 66, in wrapper handler(message) File "/opt/mycroft/skills/mycroft-timer.mycroftai/__init__.py", line 662, in handle_start_timer_padatious self.handle_start_timer(message) File "/opt/mycroft/skills/mycroft-timer.mycroftai/__init__.py", line 577, in handle_start_timer secs, utt_remaining = self._extract_duration(utt) File "/opt/mycroft/skills/mycroft-timer.mycroftai/__init__.py", line 133, in _extract_duration duration, str_remainder = extract_duration(utt, self.lang) TypeError: 'NoneType' object is not iterable

[SXXXR]

I remember I got it once in the beginning,
so this is a known thing?

[gras64]

this is due to linguia franca. I think that should be fundamentally revised and updated. I'm too unqualified for that. post it under linqua franca. the function extract_duration, _convert_words_to_numbers_de, _extract_numbers_with_text_de..... are not available

[emphasize]

I'm at it. The structure is a bit messy, so i try to restructure the german lingua franca to fit in. But don't expect too much, i solely tackle the issues described. (extract_duration, _convert_words_to_numbers_de, _extract_numbers_with_text_de)

It doesn't seem to be that complicated (the regex pattern being the major issue besides the missing functions), but we'll see. I may run into problems since the LF is more narrowed down (maybe a positive) than other languages while some parts are fundamently different.

[emphasize]

That said, i think it would be beneficial if we had something like "skill-alarm" in place that prevents such outcome - if someone typed uninterpretable stuff

#
if (when is None or when.time() == today.time()) and not is_midnight:
in case a query is fired which asks for compatible timeframe

On the other hand, i don't expect the skills' lifespan to be that long lasting because it overlaps too much with skill-alarm (maybe i'm missing something)

[krisgesling]

I think we'll always have both the Timer and Alarm Skills. Even though they are both Skills that emit a sound at a given point in time, they are conceptually different. A timer counts down and you may want to know how much time as elapsed and how long left until it's finished etc. An alarm is a way to make a sound at some specific point in time and may be recurring - eg every weekday morning at 8am, but until that time you usually don't care about it or want to interact with it.

Definitely makes sense to catch this and handle it appropriately (as well as fixing the cause in LF)

[emphasize]

Brought it to life. But several things have to be adressed in mycroft-core in regard of duration handling to "fully" embrace lingua franca

• mycrofts parser (#) (extract_duration) has to be pointed to lingua franca

• the formatters' duration handling (#) (most likely) stands in the way to format durations lingua franca style. I got the very german eins, eine, einer problem that should be tackled by format_de.py (resp. format_en)

If this is not already issued. i'll start one over there. (will be adressed with PR#108)

Edit: I thought more of merging the two.

[forslund]

The first of the points has been resolved.

The second I'm not quite sure, it's newer than the nice duration in LF. We'll see after the big LF refactor if those changes should be merged over to LF so core can stop handling it.

[ChanceNCounter]

The big LF refactor would raise an exception here, too, just a more explicit one ("function... has not been localized to language 'de'.") mycroft-core #2703 might bridge the gap, by allowing skills to force a language in which they've been tested.

Unless another language is specified in function calls, the new LF will always call the user's "default" language, the only difference in that respect being that it used to call English. In this case, the default language would still be 'de-de', and you'd still get FunctionNotLocalizedError.

I don't think it'll be hard to write a layer that handles those cases, but it's above LF's paygrade as it concerns user config and skills. I think it should probably be part of the linked issue.