Ошибка Error getting history: MQTT RPC request timed out

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

Добрый день!
Проверьте, сколько осталось свободного места, а если осталось мало, то куда ушло:

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

Не думаю, что мы сможем определить ошибку по описанию “ошибка была, но сейчас её нет. Данных по моменту, когда она была, тоже нет”.
Чтобы её не допустить, предлагаю наблюдать за размером /var/log/messages, иногда это вызывало проблемы.

Какие встроенные инструменты в wb есть для мониторинга свободного места?

Никаких. Можно написать своё правило в вызовом df, чтобы значение выводилось в виртуальное устройство.

Почему?

А что именно и в каком виде вы хотели бы видеть?

Хотел бы автоматическую отправку сообщения по почте о заканчивающемся месте, о превышении температуры и высокой загрузке процессора

Температура в интерфейсе есть, настроить уведомления о ней можно стандартными средствами: https://wirenboard.com/wiki/index.php?title=Notification_module
Добавить в интерфейс информацию о свободном месте и загрузке процессора можно через движок правил, а уведомления потом настроить тем же способом.
Делать это из коробки, наверно, не будем, потому что это первый такой запрос на моей памяти, и при этом его можно решить на уровне пользователя.

К сожалению я не нашел информацию, какая температура нормальная, а какая нет. Также в руководстве пользователя нет информации, сколько свободного места хорошо, а сколько плохо. Есть только куча сообщений на форуме о проблемах из-за закончившегося свободного места. Причем отсутствие свободного места в папке с логами делает устройство нерабочим.
Делать или нет - решать конечно вам, а никак не покупателям.
Но всем известен факт, что потребитель поощряет рублем.

С этим всё довольно просто: https://wirenboard.com/wiki/index.php/Wiren_Board_6

Эксплуатация: Рабочая температура 0…+70 °С / -40…+85 °С (в зависимости от комплектации)

Если у вас индустриальная версия, каких большинство, то до +85 °С.

У нас не стоит выбор “делать эту функцию или ничего не делать”. У нас стоит выбор “делать эту функцию или другую, которая нужна большему числу пользователей”.

Вот например здесь мы уже создали задачу по оптимизации логирования, и она сейчас ждёт свободного времени инженера.
При этом лично меня расстраивает вот какой факт: вместо того, чтобы вместе разобраться с источником проблемы (которая точно не одна), что я неоднократно предлагал, пользователи просто что-то удаляют, и больше их эта проблема не тревожит. Нам это, разумеется, никак не помогает увидеть причину проблем.

А почему вы таким способом не хотите решить вашу задачу?

С температурой разобрался, спасибо!

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

Если вы про проблему из сабжа, то к сожалению ответа тут я не получил, также задал вопрос в другой теме

Да, согласен, ответили не очень быстро. Сейчас дописал ответ в другую тему, чтобы все замечали. Но считаю, что если кончилось место, то довольно логично проверить, из-за чего именно.

defineVirtualDevice("freeDiskSpace", {
  title:"Free Disk Space, in kB",
  cells: {
  'mnt data': {
    type: "text",
    value: "1200000"
  },
  }
});

function updateFreeDiskSpace() {
  runShellCommand("df -k /mnt/data | tail -1 | awk '{print $4}'", {
    captureOutput: true,
    exitCallback: function (exitCode, capturedOutput) {
      dev["freeDiskSpace"]["mnt data"] = capturedOutput.toString();
    }
  });
};

updateFreeDiskSpace();
setInterval(updateFreeDiskSpace, 1000);

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

Чтобы нам понять, нужно ли это включать в стандартное ПО, давайте поступим так: каждый пользователь может отметиться в этой теме.

При этом нужно учитывать, что:

  1. Отдельная задача на исследование проблем логирования уже поставлена.
  2. Но сроки её выполнения неизвестны.

Спасибо! Для меня этого вполне достаточно.
Теперь я могу без использования микроскопа в качестве молотка получать уведомление по почте о превышении температуры и о заканчивающемся свободном месте.

Хорошо бы еще проверять, все ли обязательные демоны запущены, и сообщать письмом о явных проблемах (эдакий вочдог-failover). Да, все возможные проблемы не перебрать, но наиболее частые вполне.

Место закончилось из-за включенного режима отладки - вырос лог. Я предполагаю, что ошибка в сабже связана именно с нехваткой места. После отключения логирования и очистки лога свободное место появилось, но ошибка не исчезла сразу. Спустя несколько дней ошибка пропала.

Думаю, адаптировать мой пример (а это на самом деле адаптированное системное правило, которое выводит IP-адрес в интерфейс: https://github.com/wirenboard/wb-rules-system/blob/master/rules/network.js) не должно быть слишком сложно.

А какое у вас в целом применение? Мне казалось, что мониторинг по email не слишком часто используется.

Это звучит очень странно. В следующий раз лучше сразу установить причину проблемы.

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

Я настроил ежедневные отчеты о состоянии по почте - теплые ли полы, нет ли заморозков в колодце и др. Если письмо не пришло - значит проблема.