Упорядочиваем 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 — ну так у меня его и нет, не проблема.