Упорядочиваем MQTT
Лирическое отступление: когда-то при переходе с Windows на UNIX для меня стал открытием тот факт, что файловая система в UNIX намного более стандартизирована и упорядочена, чем в Windows (особенно в Windows того времени).
В самом деле, если в Windows было в порядке вещей свалить в один каталог саму программу, ее настройки, вспомогательные файлы, и всё это положить куда угодно как попало — то в UNIX была определенная иерархия файлов, что где должно лежать, чтобы было по фен-шую: bin, lib, var, etc…
Казалось бы, при чем тут MQTT и наши дни? При том, что при попытке организовать взаимодействие между устройствами при помощи MQTT сообщений я увидел тот же самый бардак, какой был когда-то в Windows: одна система отправляет сообщения как zigbee/#, другая как mesh/#, третья еще как-то, все самодельные устройства могут отправлять вообще любые топики, и если потом требуется связать одно с другим — то нужно помнить что на что реагирует и как что рассылает.
И чтобы превратить бардак в порядок — придумал сам для себя некую стандартизацию сообщений.
Например, если происходит какое-то событие — это топик event/XXX, если событие требует реакции — это alarm/XXX, если нужно отправить команду — command/XXX.
Просто сообщения, например, текущий статус, etc/XXX.
И оказалось, что такая мелочь сильно упрощает жизнь: скажем, если в ответ на событие «пропало напряжение» нужно отправить в телеграм текст — можно, конечно, написать отдельный обработчик для этого, и еще для 100500 событий.
А можно написать обработчик, который при появлении etc-сообщения от устройства контроля напряжения просто сформирует alarm/message с нужным текстом, и уже другой обработчик, слушающий конкретно alarm/message — отправит текст куда надо.
При этом блок контроля напряжения не заботится о способе доставки, скрипт доставки доставит любой текст, не в телеграм так в СМС, остается сделать скрипт, который отслеживает жалобу блока контроля и отправляет alarm.
Для одной задачи это конечно избыточно, но если подключить к той же схеме «контроль температуры», «контроль протечки», «контроль открытия ворот», «контроль срабатывания замка» — мы просто отслеживаем разные etc-сообщения и формируем alarm с разным текстом, всё остальное происходит само.
Если надо включить свет — отправим не alarm, а command/XXX — и реле, которое слушает конкретно этот command, сработает, хоть одно, хоть 10.
Если надо именить настройки котла отопления — достаточно просто отправить соответствующий command, который слушает именно котел — и снова всё происходит как бы само.
Причем даже неважно, в какой сети работает котел: простой WiFi, Zigbee или PainlessMesh — достаточно лишь запустить скрипт-драйвер, который преобразует, скажем, command/heat1 в mesh/to/141455135 или в команды Zigbee-протокола.
Получилось, что устройства работают независимо друг от друга, и в то же время их легко связать между собой, заставив реагировать как надо.
Ну, а реализация всего этого очень простая: любое самодельное устройство всегда можно заставить реагировать на свою команду и отправлять свое сообщение так как требуется, а интерфейс к «чужим» и скрипты автоматизации прекрасно пишутся всё на том же Perl:
#!/usr/bin/perl -w
$|=1;
use Net::MQTT::Simple;
use JSON;
use Data::Dumper;
$SIG{CHLD} = "IGNORE";
########################################
my $mqtt = Net::MQTT::Simple->new("127.0.0.1");
# send MQTT message
sub pub {
my ($topic, $message, $retain) = @_;
my $pid = fork();
if(defined $pid && $pid == 0){
if($retain){
$mqtt->retain($topic => $message);
}else{
$mqtt->publish($topic => $message);
}
sleep(2);
exit(0);
}
}
########################################
# MAC термодатчика на складе
my $term = '287d92440600144a7';
# температура по умолчанию
my $t0 = 7;
# processing
$mqtt->run(
'etc/stock1/control' => sub {
my ($topic, $message) = @_;
my $data = undef;
if($message =~ /^{.*}$/){
$data = from_json($message);
}
if(defined $data && defined $data->{ $term }){
my $t = $data->{$term};
my $m = {
dtm => $data->{dtm} || time,
temperature => $data->{ $term },
};
pub("state/temperature/stock1", to_json($m), 1);
if($t > $t0){
pub("command/stock1/control","off 1");
}
elsif($t < $t0){
pub("command/stock1/control","on 1" );
}
}
},
'command/stock1/settemp' => sub {
my ($topic, $message) = @_;
my $data = undef;
if($message =~ /^{.*}$/){
$data = from_json($message);
}
if(defined $data && defined $data->{ temperature }){
$t0 = $data->{ temperature };
}
},
#===============================
);
exit;
Этот скрипт просто слушает сообщения от блока контроля на складе, и занимается тем что включает или выключает обогреватель, поддерживая температуру 7 градусов.
При этом текущая температура помещается в retain-топик state/temperature/stock1, откуда ее можно всегда узнать, а команда command/stock1/settemp позволяет установить температуру, которую будет поддерживать автоматика.
Сам блок контроля умеет только отправлять температуру и включать-выключать реле (ну есть еще встроенная защита, температура не может быть выше 40, но это тут не важно).
Его можно переделать на Zigbee, нужно будет только дописать пару правил в скриптах Tasmota, не меняя всего остального.
Для запуска этого и подобных скриптов прекрасно подходит коробочка-TV-box: много памяти не требуется, производительности тоже, питание 5В через адаптер от аккумулятора, управление удаленное…
В эту схему не вписывается HomeAssistant — ну так у меня его и нет, не проблема.
