Если у вас большой и серьезный ЦОД, то параметрия температурных режимов не является проблемой. Существуют проверенные решения, например, программируемые контроллеры TAC Xenta, которые работают через LonWorks. Именно так мы собираем данные в московском ЦОД Datahouse. Но непосвящённому смертному весьма непросто собрать правильные показатели из этой связки и выводить их в мониторинг в нужном виде. К тому же решение промышленное и достаточно дорогостоящее. Поэтому при строительстве новой гермозоны
в Екатеринбурге мы решили поэкспериментировать и внедрить альтернативное решение по измерению температуры в холодных и горячих коридорах.
Ничто не предвещало беды…
Так как множество систем в этом ЦОДе завязано на открытом коммуникационном протоколе Modbus мы решили заказать температурные датчики, работающие по этой шине, и собирать данные с дальнейшей интерпретацией в интерфейсе мониторинга. Недорогие датчики быстро нашлись на известном китайском сайте и были заказаны партиями в количестве 20 и 40 штук.
Первая партия из 20 штук пришла достаточно оперативно, но при детальном рассмотрении стало понятно, что датчики незначительно отличаются корпусами. Важно ли это, как выяснилось да.
![](https://habrastorage.org/getpro/habr/upload_files/369/650/c74/369650c74d7caa94c13d9cd81472219e.jpg)
Из первой партии завелось 15 датчиков. Так как острой потребности в остальных не было, пока работали с ними. К моменту прихода второй партии выявили, что часть уже установленных в шину датчиков имеет поведение новогодней елки: показывают некорректные данные, отдают checksum error или отваливаются по таймауту.
Анализ второй партии показал, что в ней процент брака в разы выше.
В итоге из 60 датчиков мы получили всего 8 стабильных с правильными показаниями.
Вот так это выглядело:
![](https://habrastorage.org/getpro/habr/upload_files/120/375/c57/120375c579dfb33f11f9b2102cc8eb35.png)
Самое простое решение — отказаться от этой затеи или заказать кучу датчиков и выбрать
из них не бракованные, но это не наш метод.
Не ищем легких путей…
Вскрыли, посмотрели: микросхемы идентичны. Значит дело в прошивке.
Кстати, обратите внимание на заводское крепление кабеля – оно было лишь на половине устройств. На остальных пришлось заливать кабель из термопистолета – получилось прочней
и надежней.
![](https://habrastorage.org/getpro/habr/upload_files/b1a/22b/45c/b1a22b45c142a142197b95eea5fed799.jpg)
![](https://habrastorage.org/getpro/habr/upload_files/31b/701/f20/31b701f20b565a8e958a4558c71ce954.jpg)
Пока разбирались с работоспособностью датчиков поняли, как без особых сложностей обнаружить «кривую» версию прошивки. Если кроме Modbus работают обычные текстовые команды READ, PARAM, AUTO, STOP — значит прошивка хорошая. В «мертвых» прошивках текст не отдается.
Решили взять прошивку с этих живых 8 датчиков, купили программатор Nu-Link,
но хитрые китайцы заблокировали чтение прошивки. То есть перезалить можно, а считать - нельзя. Запросы правильных прошивок у поставщика потерпели фиаско:
«Я продаван, я не разработчик».
И тут я психанул, схватил крепкие напитки и закрылся у себя.
Через пару дней вышел с прошивками и программой.
За основу был взят Keil, пакет С51, позволяющий работать с 8-битными MCU.
В начале я научил читать сенсор SHT 20 (который собственно и снимает температурные данные), потом научил передавать эти данные по Modbus. В виду того, что этот MCU ни что иное как Nuvoton N76E003AT20, то вся база знаний, видимо, сосредоточена в руках наши китайских друзей.
В итоге i2c и Modbus сделал быстро, а вот с таймерами пришлось повозиться. Чтобы не было коллизий в шине, добавил возможность смены SLAVE_ID без выключения датчика — в Китайской версии прошивки после смены адреса его нужно было обязательно выключать, что не очень удобно.
Начали шить новой прошивкой, из семи прошитых получили семь успешных и стабильных устройств. Так понемногу реанимировали все датчики, присвоили им номера и подключили витой парой в шину.
Так стало:
![](https://habrastorage.org/getpro/habr/upload_files/673/be5/a17/673be5a1799e0572bc8fbd8acb7e634c.png)
Если говорить про результаты измерений, то нормальные показания появляются только
в помещении с явной циркуляцией и движением воздуха. Без продува датчик показывает 30°С. Это объясняется тем, что внутри установлен стабилизатор напряжения, который преобразует 24В в 3.3В, переводя разность в тепло.
Относительно влажности, пока можно утверждать, что требуется дополнительная калибровка, но способа ее произвести мы пока не придумали. Тем не менее, прямое воздействие, например, дыханием – увеличивает показания влажности. В любом случае, через пару регистров это можно сделать по месту установки.
Несмотря на возникшие осложнения, данное решение имеет два очевидных преимущества: стоимость и гибкость. Датчики можно установить в любом удобном месте, точечно или объединить в гирлянды. Можно измерять как общую температуру, так и частные показания отдельных приборов и устройств. И самое важное, что все это отлично работает по Modbus.
Программа выложена на GitHub – кому интересно, можно забрать и поиграться.
Стоимость датчика всего 300 ?, правда, нужен программатор.
Javian
Не проще ли было повесить DS18B20 кучу на одну пару провода, с которого передавать в Modbus.
inforus Автор
Можно было, но DS18B20 на длинный провод не повесишь, и там нет влажности.
bios737
Ну влажность в серверных точно есть и даже требования по ним есть. Кстати у вас на сайте это тоже указано:
Необходимые климатические условия (температура 21±2°C, уровень влажности 50-60%) в гермозоне поддерживаются с помощью кондиционеров General Electric: 5 агрегатов на машинный зал. Схема резервирования N+2.
inforus Автор
так я и написал, что DS18B20 не вариант, они только температуру измеряют, sht20 и то и другое.