Друзі привіт - як ваш день?Чучуть хотів повернутися до протоколів і я особливо думаю не дуже буде зрозумілий до всіх саме цей протокол)Протоколи для 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-інженером. Але зобов’язаний розуміти, коли проблема саме там.Бо інакше половина “дивних” багів так і залишаться магією.Сильні💛Обняв🤗