Чучуть хотів повернутися до протоколів і я особливо думаю не дуже буде зрозумілий до всіх саме цей протокол)
Протоколи для QA - MQTT
Що я маю вам сказать.
шо це за такий MQTT - це не “ще один HTTP для галочки”. Це реально легкий протокол для обміну повідомленнями, який дуже часто живе там, де є: IoT, датчики, телеметрія, смарт-девайси, промислові системи, робототехніка, всякі пристрої які постійно щось шлють і слухають.
І тут КУА дуже часто впирається в стіну бо MQTT працює не так, як звичний REST чи API-запит.
саме тут вам важливо зрозуміти, що MQTT = це модель publish / subscribe. тобто один клієнт публікує повідомлення
broker його приймає а інші клієнти підписані на topic і отримують це повідомлення
Не “запит-відповідь”, а події. ну я думаю всі знають про вебсокіт так??
Умовно є датчик температури шле в topic: factory/sensor1/temp
Саме повідомлення типу:
{ "temp": 23 }І вже інша система це читає і реагує.
Тобто якщо MQTT не працює як треба - ніякий “перезапусти UI”, “глянь API” або “а в Postman ок” не допоможе. Бо саме тут логіка асинхронна.
Самі типові симптоми MQTT-проблем:
повідомлення інколи не доходять, або приходять із затримкою, або дублюються, або subscriber нічого не отримує, або після reconnect все перестає працювати, або один клієнт бачить дані, а інший ні.
і так тут все на низах, пару прикладів якщо колись будете стикатися з цим
Чи взагалі приходить повідомлення:
mosquitto_sub -h localhost -t "factory/sensor1/temp"
Чи можете самі відправити тестове:
mosquitto_pub -h localhost -t "factory/sensor1/temp" -m '{"temp":23}'Чи не губляться повідомлення, чи немає дублювань, який QoS, що буде при reconnect, що буде якщо broker впаде, чи правильно працюють retained messages.
Звісно КУА не зобов’язаний піднімати брокер і ставати IoT-інженером. Але зобов’язаний розуміти, коли проблема саме там.
Бо інакше половина “дивних” багів так і залишаться магією.
Сильні💛
Обняв🤗