Обновить
187
0
DataArt@DataArt

Пользователь

Отправить сообщение
Спасибо за уточнение, обсудим с коллегами!
Мы не планировали использовать REST для выявления изменения состояния пинов в текущей версии.
AccessKey — это ключ доступа к серверу, общение с сервером без него не возможно. Да, его нужно прописать в каждое устройство. Если использовать только локальный REST, то AccessKey — это фактический пароль для доступа к API. Если оставить этот пароль пустым — к чипу смогут обращаться все.
Вы что-то путаете. Blynk не наш. DeviceHive наш и все протоколы в нем открытые.
Здравствуйте! Вы правильно определили — прерывания не доступны через RESTful API, это описано здесь: https://github.com/devicehive/esp8266-firmware/blob/master/DeviceHiveESP8266.md#restful-api
-> Any notifications are not supported, so commands for subscribing on it also don't available.
Вопросы напрямую можете задавать на сайте http://devicehive.com/ (справа внизу есть кнопка сообщений) или через форму обратной связи (меню сайта -> contact us).
1. Большое спасибо за ссылку!

2. Конечно, есть разные способы решения. Exists и неявный join будут работать везде, включая mysql.

3. Производительность не рассматривалась.
«Провальные по производительности» запросы успешно решали реальные задачи в тестировании. Хотя, конечно, кое-где произвидительность станет узким местом.
На вашем примере горсти esp8266+raspberry pi, вы можете подключать все ваши датчики и исполнительные устройства к esp8266. Затем написать приложение для raspberry pi, которое будет ходить по REST-сервисам чипов в локальной сети и исполнять бизнес-логику всего комплекса. Можно вообще без raspberry pi, разместив сервер DeviceHive где-нибудь в интернете, чипы смогут подключаться к нему хоть из любой точки мира. Бизнес-логику вам также нужно будет разместить на сервере.
Там установлен чип ESP32. Это следующее поколение Wi-Fi-чипов с более мощным процессором. Данная прошивка не совместима с такими.
DeviceHive — это целая платформа, включающая в себя облачный сервис, библиотеки, фраймворки и в том числе данную прошивку.
Про NodeMCU и ESP-01 вы верно все поняли.
Плату, как но фото, можно найти по ключевым словам «esp8266 nodemcu» например на алиэкспрессе. На самом чипе флеш-памяти нету вообще. Прошивка загружается на внешний чип флеш-памяти, распаянный на плате и подключенный по SPI-интерфейсу. Как правило это 25Q40BT — 512 КиБ. Чип может быть и больше, но чтобы использовать пространство на нем, нужно модифицировать прошивку. Плата может быть любая с чипом от 512 КиБ или более. Про камеры точно не скажем, возможно, что-то можно приделать/уже приделали, однако учитывая производительность чипа, разрешение и качество картинки будет очень плохое. Для камер нужны более мощные процессоры.

Разница между прошивка в самой идеи использования чипа. Если совсем на пальцах, то NodeMCU позволяет писать свои скрипты на LUA которыми управляется весь алгоритм прошивки. DeviceHive прошивка предоставляет доступ к подключенным устройствам через облачный сервис/локальный REST.
Данная прошивка — это адаптер между микросхемой и сервером DeviceHive. Можете управлять всем централизовано с сервера. Более подробная техническая документация о серверной части находится в этом разделе — http://devicehive.com/restful/. Начиная с последней версии прошивки(0.5) это еще дополнительно и адаптер между микросхемой и локальным REST сервисом.
Вы еще упомянули об адаптере в DBUS. Такое у нас тоже есть. IoT-Toolkit, он же IoT-Framework. Он предназначен для работы на более мощных платах с ОС Linux. Он как раз является адаптером различных интерфейсов в DBUS. Его можно найти здесь — https://github.com/devicehive/IoT-framework
Вероятно, скорости не хватало на то, чтобы получить звук с сервера и затем передать его в обработанном виде.

Да, к сожалению, это оказалось сложно(
Общение мы, конечно, продолжили. К сожалению, техническое собеседование по конкретным технологиям он в данный момент не прошел. Но мы желаем ему успеха!
Будет, но чуть позже. :)
Жаль, что не приедете) Но мы позже выложим запись.
Здравствуйте! Мы обязательно выложим записи выступлений, просто немного позже. Надеемся, что вы сможете присоединиться к нам лично в следующий раз!
В виду особенностей прошивки девайсов, каждый девайс инициировал 2 соеднинения к облаку. В одном соединении девайс отсылал данные раз в секунду, они валидировались, предобрабатывались и сохранялись в базу, во втором — раз в минуту принимал. Для кластера использовали EC2 c4.4xlarge инстансы.
Чтобы реализовать выключение, нужно средствами OpenElec назначить кнопку KEY_POWER. Получив эту команду, OpenElec «захалтит» плату. А все что происходит на пине для включения, когда плата уже включена — просто нигде ничем не используется.
Да, вы все верно поняли, это пробуждение из halt. IR-приемник способен пробудить при таком включении. Это возможность реализована в бутлоадере.
1. При таком включении появляется возможность пробуждения платы из спящего режима. Подробнее в тексте. И вывод тот поменять нельзя.
2. Это дефолт драйвера. Его можно поменять, передав драйверу параметр gpio_in_pin, это можно сделать добавив чуть другую строку в файле /flash/config.txt. Нужно через запятую передать параметр, вот так:
dtoverlay=lirc-rpi,gpio_in_pin=10
Лицевая панель может очень сильно отличаться в различных устройствах. Поэтому детально описывать её реализацию автор не стал. Если в двух словах, то платы лицевых панелей таких устройств — это, как правило, обычные семиразрядные индикаторы, которые еще имеют какую-то электронную обвязку — начиная от банальных ключей на транзисторах, заканчивая специализированной микросхемой, реализующей динамическую индикацию. В зависимости от этой обвязки метод подключения будет очень сильно различаться, и всех их не описать. В случае автора, на плате был установлен сдвиговый регистр для восьми сегментов, т.е. пришлось последовательно записывать байт по одному проводу, описывающий какой набор сегментов зажечь, и затем зажигать весь разряд, чтобы его было видно. И так четыре разряда. Такая плата требует очень много переключений из нуля в единицу и обратно при реализации динамической индикации, а учитывая жесткие требования по времени зажигания разрядов (иначе дисплей будет мигать различными светоэффектами) это возможно реализовать только на аппаратном уровне. В Raspberry Pi есть DMA. В двух словах это работает так: можно выделить какой-то буфер в памяти и указать с какой скоростью его читать — содержимое этого буфера будет выводиться в GPIO-порт (можно работать не только с GPIO), причем без участия CPU, это будет делать отдельный аппаратный модуль в процессоре. Таким образом, можно положить в буфер последовательность, какие ножки GPIO и в какие моменты времени дергать, чтобы отобразить нужные нам цифры, используя динамическую индикацию. Чтобы использовать эти возможности, нужно записать нужные флаги в регистры процессора, доступные по физическим адресам процессора. Автор взял готовую библиотеку RPIO, в которой именно этот метод был использован для генерирования ШИМ, чтобы не писать свои инициализации этих регистров, чуточку подправил под свои нужды и использовал. Исходные коды этого проекта доступны здесь — https://github.com/Nikolay-Kha/seven-segment-clock

Информация

В рейтинге
Не участвует
Откуда
США
Дата рождения
Зарегистрирован
Активность