Отправка уведомлений на majordomo

[Aculeasis]

Когда терминал активируется фразой и начинает запись, когда заканчивает запись, по таймеру (пинг?).

[majordomo-notify]
object_name = 
object_method = 
# Вопрос еще в том, что именно отправлять в property.
object_property = 
# 0 - не отправлять
heartbeat_timeout = 300

Будет работать только если name, property и method заданы.

[skysilver-lab]

object_property на стороне терминала, пожалуй лишний, и можно его не задавать, т.к. вся отправка будет через метод.

Если если name, и method заданы, то активировать фичу.

При вызове метода передавать в гет-запросе:
ip = IP терминала для его идентификации на стороне МДМ
status = start_record, stop_record (или как-то более узнаваемо, чтобы понимать в какое состояние перешел терминал)
uptime = системный аптайм

Как вариант еще слать уровни громкости (системной, mpd), если их не затратно получать.

[SergMicar]

Предлагаю еще добавить событие "закончил говорить"

[Aculeasis]

ip = IP терминала для его идентификации на стороне МДМ

Почему ip, а не terminal? IP то он и так узнает, сейчас можно задать terminal в конфиге и он будет его передавать в запросе (системное имя терминала).
При пинге просто не передавать статус?

Как вариант еще слать уровни громкости (системной, mpd), если их не затратно получать.

Наверное не очень, но я бы не стал. Ну или только с пингом слать.

[SergMicar]

плюс события "начало воспроизведение музыки", "пауза воспроизведения музыки", "стоп воспроизведения музыки" (majordroid API & MPD) - тогда будет полная обратная связь "команда от МДМ" -> "Подтверждение выполнения команды"

[skysilver-lab]

Почему ip, а не terminal? IP то он и так узнает, сейчас можно задать terminal в конфиге и он будет его передавать в запросе (системное имя терминала).

Можно и имя. Не суть. Лишь бы можно было идентифицировать (mac, id, имя и т. п.)

При пинге просто не передавать статус?

Аха.

[netman1ac]

Предлагаю отправлять на МЖД GET'ом статусы start_talking/stop_talking когда идет болтание терминалом функцией say/ask
чтобы было понятно когда например ставить телевизор на муть и снимать с него ну или прикольно мигать светом в туалете :)

[SergMicar]

Поддерживаю по статусам start_talking/stop_talking
Но ставить телевизор на мут думаю нужно сразу же после распознавания ключа (например "Алиса") по событию start_record, а вот снимать с паузы можно уже по stop_talking

[netman1ac]

Да собсно можно оставить вообще один stop_talking или im_talking
но на всякий и старт чтоб два раза не вставать

[SergMicar]

Вся идея в том, чтобы глушить звуки сразу после ключевика (по событию start_record), чтобы не вносить помехи при распознавании основной фразы....

[SergMicar]

Итого по предложениям на сегодняшний день имеем такой перечень событий
status=
start_record (by event)
stop_record (by event)
start_talking (by event)
stop_talking (by event)
start_playmusic (by event)
stop_playmusic (by event)

volume = current volume (on changed)

uptime = timems (by heartbeat_timeout)

Остается открытым вопрос как быть если терминал послал событие (напримерs start_record) и сразу же аварийно перезагрузился (например авария в сети питания) или стоп/старт вручную.
В общем после загрузки нужно посылать события определяющие его текущий статус....

[netman1ac]

Видимо непонятно написал
Глушить звук со старт_записываю и до стоп_болтаю
Те и те и те статусы нужны

[Aculeasis]

Кстати,

object_name = 
object_method =

Может лучше сделать одним параметром? Все равно используется один метод и имя объекта никак не используется отдельно. Типа:

handler = object.method

[Aculeasis]

Отправка уведомлений на сервер MajorDoMo