так че, чят оживлять будем? или будем сидеть как ардуинобоги и молчать?

я вот например хочу что то жирное сделать, чего нельзя на мк, но не связаное с медиакаропкой

но хз что

Игрища с компьютерным зрением

камеры нет. думал с торону полоумного дома что то, webui на ней, сбор и обработка данных. Но это как то банально

Дело не в банальности, а в том, что все решения по УД сейчас абсолютное дерьмо

Из всей этой тусовки только node-red крутой, но это лишь часть решения

лоджик машин недерьмо

иоброкер недерьмо

Оно же на своих железках, разве нет?

дык речь о каких решениях?

Связанный с малиной

иоброкер

дело в том. что мне и автоматизировать толком нечего. То, что хочу — законодательно нельзя, а остальное вторично. Так же и с датчиками, хотя больше места для маневров

а как вкатится в mqtt? что почитать для начала? какие плюсы? какие минусы?

петрушку растишь?

а что там вкатываться? простейший pubsub

отопление, а в газовый котел лазить нельзя

ты не поверишь, но мне это ничего не говорит

MQTT is a Client Server publish/subscribe messaging transport protocol. It is light weight, open, simple, and designed so as to be easy to implement. These characteristics make it ideal for use in many situations, including constrained environments such as for communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts where a small code footprint is required and/or network bandwidth is at a premium.

The protocol runs over TCP/IP, or over other network protocols that provide ordered, lossless, bi-directional connections. Its features include:

·         Use of the publish/subscribe message pattern which provides one-to-many message distribution and decoupling of applications.

·         A messaging transport that is agnostic to the content of the payload.

·         Three qualities of service for message delivery:

·         "At most once", where messages are delivered according to the best efforts of the operating environment. Message loss can occur. This level could be used, for example, with ambient sensor data where it does not matter if an individual reading is lost as the next one will be published soon after.

·         "At least once", where messages are assured to arrive but duplicates can occur.

·         "Exactly once", where message are assured to arrive exactly once. This level could be used, for example, with billing systems where duplicate or lost messages could lead to incorrect charges being applied.

·         A small transport overhead and protocol exchanges minimized to reduce network traffic.

·         A mechanism to notify interested parties when an abnormal disconnection occurs.