Отправка уведомлений на majordomo about mdmterminal2 HOT 13 CLOSED

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

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

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

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

from mdmterminal2.

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

from mdmterminal2.

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

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

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

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

from mdmterminal2.

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

from mdmterminal2.

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

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

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

Аха.

from mdmterminal2.

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

from mdmterminal2.

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

from mdmterminal2.

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

from mdmterminal2.

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

from mdmterminal2.

Итого по предложениям на сегодняшний день имеем такой перечень событий
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) и сразу же аварийно перезагрузился (например авария в сети питания) или стоп/старт вручную.
В общем после загрузки нужно посылать события определяющие его текущий статус....

from mdmterminal2.

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

from mdmterminal2.

Кстати,

object_name = 
object_method =

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

handler = object.method

from mdmterminal2.

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

from mdmterminal2.