Список пакетов SKABEN

Пакет представляет собой объект, который состоит из двух частей:

topic - служит для адресации внутри очередей.
состоит из типа устройства, адреса устройства, команды.
в случае отправки со стороны клиента добавляется префикс ask.
представлен как bytes, десериализуется в строку

payload - несет полезную нагрузку в виде конфигурации устройства или информации для сервера. обычно содержит в себе поля datahold (основное содержимое полезной нагрузки), timestamp, дополнительные сервисные флаги в зависимости от пакета (overwrite, task_id)
представлен как bytes для MQTT, десериализуется в json и далее - в dict

репозиторий с библиотекой пакетов

https://github.com/skaben/skabenproto

---

название пакета	описание	действия при отправке	действия при приеме
PING (server → client)	device_type.all.ping Опрос устройств в сети, передача текущего серверного времени.	Отправляется раз в N времени в каналы для всех типов устройств, с payload { 'timestamp': <текущее время сервера> }	Клиентское устройство записывает полученный таймстемп локально в файл, чтобы иметь возможность сохранять его при нештатном отключении питания.
PONG (client → server)	ask.<device_type>.<device_mac>.pong Ответ клиентского устройства на PING-пакет со значением предыдущего таймстемпа сервера.	Ответ на PING, отправляется с payload { 'timestamp': <предыдущее-сохраненное-локально-время-сервера> }	Сервер обрабатывает разницу между серверным и клиентским таймстемпом. Если эта разница превышает допустимый интервал - settings.DEVICE_KEEPALIVE_TIMEOUT - генерируется новое сообщение CUP во внутреннюю очередь событий сервера. Таймстемп устройства в БД принимает значение серверного времени.
CUP (client → server)	ask.<device_type>.<device_mac>.cup Запрос конфигурации со стороны клиента	Клиент отправляет пакет в случае необходимости срочно синхронизировать конфиг с серверным. Вызовы такого типа довольно редки, основная механика обновления конфигов реализована через PING/PONG	Обновляется таймстемп устройства в БД, затем инициализируется процедура CUP server → client (см. ниже)
CUP (server → client)	<device_type>.<device_mac>.cup Отправка конфигурации клиенту	Отправляется при сохранении конфига устройства (при редактировании через web-интерфейс; при прямых изменениях через админку нужно дополнительно прожать “синхронизация” в веб-интерфейсе), а также при инициализации этой процедуры PONG-обработчиком или CUP-пакетом от сервера.	Клиент обновляет локальную конфигурацию содержимым поля datahold в переданном payload. В случае тупого устройства - переданная внутри datahold строка становится новой конфигурацией клиента. В случае умного устройства - переданный внутри datahold dict мерджится с текущей конфигурацией. ВНИМАНИЕ: умные устройства по умолчанию сохраняют конфигурацию методом merge, если в payload не передан ключ overwrite: true.
SUP (client → server)	ask.<device_type>.<device_mac>.sup Отправка конфига клиента для сохранения на сервере	Отправляется при изменении локального конфига клиента в результате действий игроков. Конфигурация передается в payload, поле datahold	При получении сервер валидирует и сохраняет данные. Если сработали триггеры в сценарии - на основании них может быть сгенерирован INFO пакет в очередь внутренних событий.
INFO (client → server)	ask.<device_type>.<device_mac>.info Отправка сообщения от клиента для обработки сервером. Касается любого действия, не связанного с сохранением конфигурации клиента. Это основной эвент-пакет.	Отправляется с клиентского устройства при действиях игроков, не требующих сохранения локального конфига (отправка сообщения, пароля, и так далее). Может быть сгенерирован самим сервером для внутренней очереди.	При получении сервер обрабатывает данные, если сработали триггеры в сценарии - может обновиться глобальное состояние или быть запущены доп. команды (см. раздел Сценарии).
ACK	не используется	-	-
NACK	не используется	-	-