Комментарии 16
Интересная идея, я так понимаю это будет не одноранговая сеть?
Да, в простейшем случае это сервер и железки которые льют на него данные и им управляются (что не мешает им общаться друг с другом). В более крупных системах это несколько серверов сбора данных и управления, которые координируются друг с другом. В этом случае один из серверов выделяется как управляющий, который обслуживает сессии операторов, собирает KPI и статистику. В качестве управляющего может быть установлен и отдельный сервер, условно «выше рангом».
Мда, подключения к облакам актуальная тема, но я ничего не понял из статьи.
Так можно Arduino подключить к вашему серверу и что там можно будет увидеть?
Так можно Arduino подключить к вашему серверу и что там можно будет увидеть?
Arduino подключить можно, например если на нем поднять SNMP агента, или Modbus slave. Можно также использовать наш C++ API чтобы сделать его агентом AggreGate, но придется поколдовать с библиотеками (используются Boost и OpenSSL).
После этого вы объявляете, что в вашем Arduino-устройстве можно читать (например, температуру), что можно читать/писать (например, аппаратные параметры какого-то датчика), какие есть операции (например, перезагрузиться) и какие на сервер будут отправляться события (например, что была прочитана RFID карта).
Дальше в коде реализуется набор callback'ов, которые собственно считывают значение температуры, считывают и записывают параметры датчика, перегружают модуль по команде сервера. Код, которые считывает RFID карты, будет асинхронно слать события на сервер.
Соответственно, сервер даст возможность всем этим пользоваться, т.е. хранить, обрабатывать и визуализировать историю измерения температуры и чтения карт, перезагружать устройство, менять его конфигурацию. Все это либо в ручном режиме, либо в автоматическом, в зависимости от настроенной на стороне сервера логики.
Вот еще пара ссылочек по теме:
После этого вы объявляете, что в вашем Arduino-устройстве можно читать (например, температуру), что можно читать/писать (например, аппаратные параметры какого-то датчика), какие есть операции (например, перезагрузиться) и какие на сервер будут отправляться события (например, что была прочитана RFID карта).
Дальше в коде реализуется набор callback'ов, которые собственно считывают значение температуры, считывают и записывают параметры датчика, перегружают модуль по команде сервера. Код, которые считывает RFID карты, будет асинхронно слать события на сервер.
Соответственно, сервер даст возможность всем этим пользоваться, т.е. хранить, обрабатывать и визуализировать историю измерения температуры и чтения карт, перезагружать устройство, менять его конфигурацию. Все это либо в ручном режиме, либо в автоматическом, в зависимости от настроенной на стороне сервера логики.
Вот еще пара ссылочек по теме:
Т.е. как я понял у вас нет легковесной портируемой библиотеки на C-и для малых встраиваемых однокристальных дивайсов подобных Arduino.
Вы ориентированы продавать вспомогательные аппаратные устройства-конвертеры.
А жаль.
Могли бы реализовать в сорсах пару популярных IoT протоколов как это делает Digi.
Вы ориентированы продавать вспомогательные аппаратные устройства-конвертеры.
А жаль.
Могли бы реализовать в сорсах пару популярных IoT протоколов как это делает Digi.
Конвертеры в основном применяются когда есть железка с RS232/RS485 или простые датчики с токовым выходом, т.е. требуется конвертация физического интерфейса. Большинство наших партнеров разрабатывает собственное железо на Linux, Android или Windows Embedded.
API на C/C++ у нас появился сравнительно недавно и теперь он позволяет нам подключать совсем простые железки встраивая в них собственную коммуникационную библиотеку. Однако стандарты мы стараемся поддерживать по-максимуму и у нас уже немало драйверов для протоколов из мира управления ИТ, АСУ ТП, да и универсальных, таких как SOAP и HTTP.
А какие IoT протоколы имеет смысл напрямую поддерживать в первую очередь? MQTT, XMPP, AMQP, CoAP или DDS? Какие-то еще?
API на C/C++ у нас появился сравнительно недавно и теперь он позволяет нам подключать совсем простые железки встраивая в них собственную коммуникационную библиотеку. Однако стандарты мы стараемся поддерживать по-максимуму и у нас уже немало драйверов для протоколов из мира управления ИТ, АСУ ТП, да и универсальных, таких как SOAP и HTTP.
А какие IoT протоколы имеет смысл напрямую поддерживать в первую очередь? MQTT, XMPP, AMQP, CoAP или DDS? Какие-то еще?
Почему вы называете это API?
Это сбивает с толку.
Это исходники, библиотеки для определенных микроконтроллеров или что?
Это «API», оно портируемое? Инструкции по портированию есть?
А так, конечно, MQTT, XMPP хотелось бы видеть.
Это сбивает с толку.
Это исходники, библиотеки для определенных микроконтроллеров или что?
Это «API», оно портируемое? Инструкции по портированию есть?
А так, конечно, MQTT, XMPP хотелось бы видеть.
В первую очередь хотелось-бы MQTT ибо уже достаточно отлажено на ESP8266 модулях у нас это дело. С учётом стоимости модуля и его прошивки, может получиться достаточно интересный комплекс в совокупности с вашим ПО.
Странно, но на вашем сайте нет демо для HTML клиента, только для Java. Пытался открыть на java, но в 10 минут не уложившись, оставил свои попытки. Всё таки это больше для предприятий, для массового использования уровень вхождения тяжеловат будет.
Мы тоже понимаем, что с Java-клиентом в IoT мире делать нечего. Развиваем сейчас HTML5-интерфейс, за ним будущее. Можно скачать полноценный сервер версии 5.2 (Early Access Program) с нашего сайта, поставить и попробовать, как новый веб интерфейс сейчас выглядит.
А демку обновим, как только не стыдно будет за HTML5 UI — сейчас почти все жалуются на косяки его производительности и мы это лечим.
А демку обновим, как только не стыдно будет за HTML5 UI — сейчас почти все жалуются на косяки его производительности и мы это лечим.
Какие новости у вас? С 15 года вроде не видно больше, хотя проект у вас вроде как крутой
Спасибо :) У нас все хорошо, платформа быстро развивается, много крупных партнеров и заказчиков, в т.ч. в РФ.
Новости мы сейчас публикуем в блоге (http://blog.aggregate.tibbo.com/ru/) и соцсетях, но планируем вернуться на хабр.
Новости мы сейчас публикуем в блоге (http://blog.aggregate.tibbo.com/ru/) и соцсетях, но планируем вернуться на хабр.
Не планируете ли усилить направление «умный дом» платформа у вас готова, но по аналогии других платформ-концентраторов для умного дома, конечно, нужно в разы больше протоколов-драйверов для подключения домашних девайсов (zigbee, wifi, MQTT, telegram и т.д и т.д.)
Ой, кажется MQTT у вас уже есть)
В индустрии «умных частных домов» денег мы не видим, поэтому обдумываем бесплатное предоставление платформы для DYI проектов. В общем-то по запросу готовы предоставлять лицензии в обмен на короткое описание проекта с несколькими картинками по его завершению.
А вот автоматизация зданий совсем другое дело, там мы активно работаем и развиваем это направление.
А вот автоматизация зданий совсем другое дело, там мы активно работаем и развиваем это направление.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Концепция Tibbo AggreGate – платформы для Интернета вещей