Сообщить об ошибке

Что-то не работает. Прежде чем сообщать об этом разработчику, необходимо ответить на один вопрос, и он важнее всего остального на этой странице: действительно ли проблема в программе?

Путь от проблемы к сообщению. Большинство обращений в конечном итоге попадают на форум, и это хорошо.

Во-первых: это ошибка в программе?

Большинство проблем на самом деле вовсе не проблемы. Они возникают из-за настроек, устаревшей версии, неработающего устройства или неправильного понимания принципа работы чего-либо. Давайте разберемся по порядку:

1. Попробуйте самостоятельно сузить круг поиска. Работает ли экземпляр? Получаются ли значения? Что говорится в журнале? Процедура описана в разделе «Устранение неполадок» .
2. Спросите на форуме . Там быстро выяснится, связана ли проблема с вашей конфигурацией. Очень часто ответ находится там, и никому не нужно ничего менять в программе.

Общее правило: сначала проверьте форум , если неясно, действительно ли существует ошибка. Сообщайте разработчику только после того, как ошибка будет воспроизводима и станет ясно, какой адаптер затронут. Если сомневаетесь, сначала проверьте форум. Если окажется, что это действительно ошибка, кто-нибудь там, как правило, укажет вам правильное направление.

Затем: проверьте три вещи.

• Всё ли обновлено? Адаптер и JS-контроллер обновлены. Многие ошибки давно исправлены.
• Можно ли воспроизвести эту ошибку? Если да, укажите, как именно. Это самая ценная информация во всем отчете.
• Он уже зарегистрирован? Инструкции по проверке приведены ниже.

Что такое проблема?

О проблемах сообщается не по электронной почте, а в виде записи в журнале ошибок программы. Такой журнал есть у каждого адаптера, js-контроллера, административного интерфейса и даже у этой документации. Он хранится на GitHub, платформе, где управляется исходный код ioBroker.

Важно знать две характеристики.

Проблема является общедоступной . Любой может её прочитать, она постоянно находится в сети, и поисковые системы могут её найти. Это сделано намеренно, чтобы следующий человек, столкнувшийся с той же проблемой, мог её найти. Однако это также означает, что никакие учетные данные для входа в систему указывать не следует.

И это не договор о поддержке . Адаптеры пишутся и предоставляются бесплатно в свободное время автора. Сообщение о проблеме — это уведомление тому, кто её создал, а не гарантия ответа в определённые сроки.

Найти подходящий список

Самый быстрый способ найти репозиторий адаптера — это воспользоваться списком адаптеров на этом сайте: выберите адаптер; кнопка с логотипом GitHub переведет вас непосредственно в репозиторий. В качестве альтернативы вы можете выполнить поиск на GitHub по запросу "адаптер".ioBroker.<name> .

Адаптеры поддерживаются разными людьми, поэтому репозиторий не всегда находится под [соответствующей учетной записью пользователя].ioBroker Ключевой момент заключается в том, что имя должно быть указано.ioBroker.<adaptername> конец.

Создание проблемы, шаг за шагом

1. Создайте учетную запись. Для написания статей требуется учетная запись GitHub. Она бесплатна; чтение возможно и без нее.
2. Перейдите в репозиторий и откройте вкладку «Issues» вверху.
3. Сначала выполните поиск. Поле поиска над списком отображает только открытые записи. Для поиска закрытых записей используйте фильтр.is:open удалить иis:issue <stichwort> Введите ответ. Часто решение уже есть.
4. НаNew issue Щёлкните. Некоторые адаптеры предложат вам на выбор несколько шаблонов, например, для отчёта об ошибке или запроса на добавление функции . Выберите сообщение об ошибке. Шаблон запросит именно то, что необходимо; заполните все поля и не удаляйте просто строки с информацией.
5. Напишите заголовок и текст. Что должно входить в него, объясняется в следующем разделе.
6. Отправить сSubmit new issue .

После ответа вы получите электронное письмо. Ответы на дополнительные вопросы — самая важная часть: отчет должен оставаться неизменным после закрытия первого вопроса. Наконец, создатель отчета закрывает запись. Если ошибка повторится, к той же записи можно добавить комментарий или открыть ее заново.

Что должно быть внутри

1. Заголовок, который точно описывает проблему. «hm-rpc теряет соединение с CCU3 после перезапуска» — полезный заголовок, «не работает» — нет.
2. То, чего вы ожидали , и то, что произошло на самом деле . Два предложения, но отдельные.
3. Как вызвать ошибку , шаг за шагом.
4. Версии : адаптер, js-контроллер, Node.js, операционная система.iobroker version Информация доступна на вкладке «Хосты» .
5. Выдержка из протокола на уровнеdebug из загруженного файла журнала. Способ изменения уровня описан в разделе «Устранение неполадок» .

Протоколы следует включать в текстовом виде, а не в виде скриншотов: длинные строки будут обрезаны на экране, и поиск или цитирование с изображения будут невозможны. Для сохранения форматирования заключите текст в три обратные кавычки.

```
2026-09-08 14:02:11.431  - error: hm-rpc.0 (1234) Cannot connect to 192.168.1.20
```

Для выявления ошибок в пользовательском интерфейсе достаточно скриншота. Его можно просто перетащить в текстовое поле.

!> Проверьте перед отправкой. Пароли, ключи доступа, токены, серийные номера и UUID установки не должны содержаться в публичном отчете.

Язык

Английский язык доступен всем разработчикам. Для разработчиков-адаптеров из немецкоязычных стран немецкий язык вполне подходит. В обоих случаях адаптер представляет собой работу, которую кто-то передал бесплатно, и тон часто определяет скорость выполнения задачи.

Автоматические сообщения об ошибках

Многие адаптеры автоматически сообщают о сбоях в Sentry, если эта функция включена в системных настройках . Передаётся история сбоя программы, а не личные данные. Это позволяет разработчику видеть, что ошибка произошла и как часто, но не то, что вы делали в момент её возникновения. Поэтому составленный вручную отчёт остаётся ценным.

А если вы сможете починить это сами

Следующий шаг — это запрос на слияние (pull request) : предлагаемое изменение исходного кода, которое затем может реализовать сопровождающий проекта. Как это работает, объясняется в разделе «Работа в команде» . Правила для адаптеров описаны в разделе «Лучшие практики» , а правила для документации — в разделе «Написание статей» .