Комментарии 89
А у вас нет в планах сделать управление по Wi-Fi и всем через облако управлять?
У меня в планах интегрировать модуль MTRF-64 с AMS для проводных контроллеров (Mega, Due, 101, M0, RobotDyn Mega+WiFi и т. д.) и беспроводных (ESP8266, Sonoff, RobotDyn Mega+WiFi, LYTKO AMS Home, ESP32 и т. д.), а у компании Ноотехника большие планы по выпуску новых изделий системы nooLite-F и разработки решений на них но подробности мне не известны.
Здраствуйте. Подскажите, может я просмотрел, а как по факту работает шифрование?
Если мы говорим про AES, то это симметричный криптоалгоритм, значит закрытый ключ должен быть распространен по всем узлам участвующим в обмене.
Соответственно вопросы:
1. Как устанавливаются/меняются ключи шифрования на узлах?
2. Какой алгоритм использования блочного шифра применяется ECB/CBC/CTR ...?
3. Какая длина ключа 128/192/256?
Если мы говорим про AES, то это симметричный криптоалгоритм, значит закрытый ключ должен быть распространен по всем узлам участвующим в обмене.
Соответственно вопросы:
1. Как устанавливаются/меняются ключи шифрования на узлах?
2. Какой алгоритм использования блочного шифра применяется ECB/CBC/CTR ...?
3. Какая длина ключа 128/192/256?
Я думаю производитель скрыл все эти тонкости от конечного пользователя, вся работа с устройствами системы сводится к нажатию кнопок на блоках. Но я перешлю ваш вопрос ведущиму инженеру-конструктору Ноотехники и опубликую его ответ из первых рук здесь, как только он придёт ко мне.
НЛО прилетело и опубликовало эту надпись здесь
Коллеги, прошу не понять меня неправильно. Я интересуюсь безопасностью IoT с профессиональной точки зрения и не в коем случае не хочу критиковать вашу разработку. Но…
Пугают собственные алгоритмические решения. В подавляющем большинстве случаев подобные решения гораздо хуже стандартных с точки зрения безопасности. Это общеизвестное мнение доказанное практикой и неоднократно озвученное и доказанное метрами в криптографии, такими как Б. Шнаеер, да и отчетами pentest-ров. Надеюсь что у вам не так. Можно узнать чем конкретно вы оказались довольны?
ECB — алгоритм использования блочного шифра, допускающий применение при передаче данных размером не больше размера блока шифра. На практике применяется довольно редко и указан в запросе для того чтобы было понятно о чем спрашиваю.
CBC — применяется довольно широко, в том числе браузерами для TLS соединения. Американская налоговая FATCA принимает отчеты зашифрованные с использование данного режима шифрования
CTR — тоже широко используемый режим, позволяющий использовать блочный шифр как потоковый
Указанные режимы использования блочных шифров приведены в самом последнем госте по криптографии — ГОСТ 34.13-2015. Поэтому утверждать про отсутствие нормальной защиты… ну вы поняли :)
А как они тогда распространяются / согласовываются?
Поясню на примере. Указанная вами схема криптографической защиты с применением блочных симметричного шифра будет похожа на передачу файла зашифрованного с помощью архиватора, так называемый архив на пароле.
Например, я хочу послать файл вам, придумал случайный ключ (пароль), зашифровал файл и отправил его вам по эл. почте. Но как вы его расшифруете? Вам каким-то образом нужно будет узнать ключ (пароль)
Это и есть то о чем я спрашиваю.
Режимы использования блочных шифров, механизмы согласования ключей обычно являются частями комплексных протоколов прикладного уровня, таких как например IPSec, OpenVPN, TLS и др. Данные протоколы проанализированы вдоль и поперек, что позволяет сделать суждение об их безопасности.
В тоже время закрытые разработки подобной уверенности не дают.
Можете ли вы опубликовать полную схему использования криптографической защиты?
P.S. Одно из древнейших правил криптографии гласит, что безопасность криптосистемы должна базироваться на конфиденциальности ключей нежели применяемых алгоритмов.
ECB+CBC+собственные алгоритмические решения. В итоге я остался доволен,
Пугают собственные алгоритмические решения. В подавляющем большинстве случаев подобные решения гораздо хуже стандартных с точки зрения безопасности. Это общеизвестное мнение доказанное практикой и неоднократно озвученное и доказанное метрами в криптографии, такими как Б. Шнаеер, да и отчетами pentest-ров. Надеюсь что у вам не так. Можно узнать чем конкретно вы оказались довольны?
ECB/CBC/CTR в чистом классическом виде нормально при постоянной передаче данных не защищают.
ECB — алгоритм использования блочного шифра, допускающий применение при передаче данных размером не больше размера блока шифра. На практике применяется довольно редко и указан в запросе для того чтобы было понятно о чем спрашиваю.
CBC — применяется довольно широко, в том числе браузерами для TLS соединения. Американская налоговая FATCA принимает отчеты зашифрованные с использование данного режима шифрования
CTR — тоже широко используемый режим, позволяющий использовать блочный шифр как потоковый
Указанные режимы использования блочных шифров приведены в самом последнем госте по криптографии — ГОСТ 34.13-2015. Поэтому утверждать про отсутствие нормальной защиты… ну вы поняли :)
Ключи создаются случайным образом.
А как они тогда распространяются / согласовываются?
Поясню на примере. Указанная вами схема криптографической защиты с применением блочных симметричного шифра будет похожа на передачу файла зашифрованного с помощью архиватора, так называемый архив на пароле.
Например, я хочу послать файл вам, придумал случайный ключ (пароль), зашифровал файл и отправил его вам по эл. почте. Но как вы его расшифруете? Вам каким-то образом нужно будет узнать ключ (пароль)
Это и есть то о чем я спрашиваю.
Режимы использования блочных шифров, механизмы согласования ключей обычно являются частями комплексных протоколов прикладного уровня, таких как например IPSec, OpenVPN, TLS и др. Данные протоколы проанализированы вдоль и поперек, что позволяет сделать суждение об их безопасности.
В тоже время закрытые разработки подобной уверенности не дают.
Можете ли вы опубликовать полную схему использования криптографической защиты?
P.S. Одно из древнейших правил криптографии гласит, что безопасность криптосистемы должна базироваться на конфиденциальности ключей нежели применяемых алгоритмов.
НЛО прилетело и опубликовало эту надпись здесь
Подозреваю, что без открытия схемы шифрования параноики так и не успокоятся — они рассматривают любую, даже очень маленькую вероятность взлома, как уязвимость.
Это не параноя. Это нормальное требование. Почитайте про https://ru.wikipedia.org/wiki/Принцип_Керкгоффса
Это одновременно и нормальное требование, и паранойя в данном конкретном случае — распространенность таких систем слишком мала, чтобы принимать во внимание атаку на них. Тем более, атаку на шифрование.
Ну с таким подходом можно вообще забить на безопасность. Да что вы. С таким подходом можно забить на безопасность, разработку, вакцинацию… А потом люди удивляются что появляются Мираи, Лефпады...
У вас какой-то мир полярный — или покупаем систему с максимальной безопасностью, или не пользуемся системами вообще. На практике же, вероятность соседа даже со сниффером очень мала.
Я вам говорю про нормальную практику публикации схем шифрования, использования проверенных решений, а не про систему с идеальной безопасностью. Фраза "собственные алгоритмические решения" ставит под сомнения заявления о безопасности рекламируемых решений.
Да я не в коем случае не пытаюсь вам возражать или топить за ноолайт. Просто немного удивляюсь паранойе.
Ну да. Зачем огнетушители в офиссах? Мы же не горим каждый день!
Ох. Мы в с вами оперируем разными категориями.
Вы считаете, что уязвимая система непригодна для эксплуатации.
Я считаю, что вероятность взлома УД с современным развитием технологий — очень мала, так как для этого необходим практически физический контакт, надо находиться в радиусе десятков метров. Причем должен находиться человек, который имеет сниффер на определенную частоту/протокол и который понимает, что делает и зачем. Это, плюс отсутствие единого стандарта по частотам/протоколам выливается в то, что в шифровании в УД на данный момент необходимости как таковой просто нет.
Поэтому мне немного смешно смотреть на людей, которым нужна безопасность ради безопасности.
Вы считаете, что уязвимая система непригодна для эксплуатации.
Я считаю, что вероятность взлома УД с современным развитием технологий — очень мала, так как для этого необходим практически физический контакт, надо находиться в радиусе десятков метров. Причем должен находиться человек, который имеет сниффер на определенную частоту/протокол и который понимает, что делает и зачем. Это, плюс отсутствие единого стандарта по частотам/протоколам выливается в то, что в шифровании в УД на данный момент необходимости как таковой просто нет.
Поэтому мне немного смешно смотреть на людей, которым нужна безопасность ради безопасности.
Пока мы не знаем, что внутри, можно предположить худшее: псевдослучайная генерация из константного сида и прочее.
Наличие шифрование в данном решение указано как конкурентное преимущество, то есть то, чего раньше не было.
Поэтому желание узнать обеспечивает ли шифрование безопасность вполне справедливое желание узнать потребительские качества решения.
Поэтому желание узнать обеспечивает ли шифрование безопасность вполне справедливое желание узнать потребительские качества решения.
НЛО прилетело и опубликовало эту надпись здесь
При оценке безопасности вы, на мой взгляд, неправильно оцениваете риски.
Вы можете включать или выключать 220V. Если человек будет работать с электрической сетью и на нее будет несанкционированно подано напряжение это может привести к смерти.
Системы безопасности лучше внедрять и совершенствовать в начале продукта, а не когда он разошелся миллионным тиражом.
Вы можете включать или выключать 220V. Если человек будет работать с электрической сетью и на нее будет несанкционированно подано напряжение это может привести к смерти.
Системы безопасности лучше внедрять и совершенствовать в начале продукта, а не когда он разошелся миллионным тиражом.
Возможно, вы уже утрируете. Если будут проводиться работы с электричеством, то доверять таким устройствам никак нельзя (даже выключателям нельзя), нужно вырубать автоматы, иначе сам виноват в нарушении ТБ.
Всем кто считает меня параноиком, рекомендую посмотреть презентации с Positive Hack Days, где ребята ломали промышленную автоматизацию. Начало у пром. автоматики было такое же — «за цените как круто и удобно».
P.S. Мне просто интересно, как коллеги реализовали шифрование :)
P.S. Мне просто интересно, как коллеги реализовали шифрование :)
НЛО прилетело и опубликовало эту надпись здесь
Лично мне хватило бы абстрактного описания протокола. Реализацию тестить наlj все равно не на исходниках а снифать пакеты по факту.
Чистые симметричные крипто схемы очень неудобны в эксплуатации. Поэтому, судя по вашим ответам я предполагаю, что в ваша система сделана следующим образом.
На узлах сети, есть встроенные «магические» ключи. При начале обмена вы рандомом генерируете случайный сессионный ключ, шифрутете его магическим ключом и транслируете в сеть. Другие узлы видят пакет, расшифровывают его своим магическим ключом и извлекают от туда сеансовый ключ, так начинается сеанс обмена. Во время сеанса пакеты вы шифруте и считаете HMAC. Для защиты от повторов используется нумерование пакетов. Такой своеобразный протокол TCP.
Подобная схема как раз соответствует указанной выше модели угроз.
Чистые симметричные крипто схемы очень неудобны в эксплуатации. Поэтому, судя по вашим ответам я предполагаю, что в ваша система сделана следующим образом.
На узлах сети, есть встроенные «магические» ключи. При начале обмена вы рандомом генерируете случайный сессионный ключ, шифрутете его магическим ключом и транслируете в сеть. Другие узлы видят пакет, расшифровывают его своим магическим ключом и извлекают от туда сеансовый ключ, так начинается сеанс обмена. Во время сеанса пакеты вы шифруте и считаете HMAC. Для защиты от повторов используется нумерование пакетов. Такой своеобразный протокол TCP.
Подобная схема как раз соответствует указанной выше модели угроз.
В подобных системах один сеанс передачи данных — это всего несколько байт, поэтому генерация нового сеансового ключа на каждый чих не имеет никакого смысла, более того, при низкой скорости передачи — сильно увеличивает time-on-air.
Поэтому обычно сеансовый ключ хранится в течение достаточно длительного времени (часы-дни) в ОЗУ устройств и используется совместно с ECB. Данные при ECB с неизменным ключом, конечно, стоит немного посолить.
В системе с центральным шлюзом базовый («магический») ключ может быть задан на шлюзе через банальный веб-интерфейс. При нажатой на этом же шлюзе физической кнопке он может принимать соединения от устройств с неким ключом по умолчанию и выдавать им в ответ ключ, заданный пользователем — таким образом устройства будут инициализированы ключом данной конкретной сети без необходимости физического подключения к ним. Риск слить таким образом ключ сети на сторону крайне невелик.
У Ноолайта, где центральный шлюз необязателен, эта схема не работает, так что возникает вопрос, откуда берётся и как распространяется базовый ключ.
И есть тут, конечно, плохое подозрение про security through obscurity и ключ, тупо зашитый во флэш и одинаковый для всех выпущенных устройств. Тогда или сеансовые ключи генерируются при привязке устройств друг к другу, пишутся во флэш и хранятся там вечно, или можно поуправлять светом у соседа.
Поэтому обычно сеансовый ключ хранится в течение достаточно длительного времени (часы-дни) в ОЗУ устройств и используется совместно с ECB. Данные при ECB с неизменным ключом, конечно, стоит немного посолить.
В системе с центральным шлюзом базовый («магический») ключ может быть задан на шлюзе через банальный веб-интерфейс. При нажатой на этом же шлюзе физической кнопке он может принимать соединения от устройств с неким ключом по умолчанию и выдавать им в ответ ключ, заданный пользователем — таким образом устройства будут инициализированы ключом данной конкретной сети без необходимости физического подключения к ним. Риск слить таким образом ключ сети на сторону крайне невелик.
У Ноолайта, где центральный шлюз необязателен, эта схема не работает, так что возникает вопрос, откуда берётся и как распространяется базовый ключ.
И есть тут, конечно, плохое подозрение про security through obscurity и ключ, тупо зашитый во флэш и одинаковый для всех выпущенных устройств. Тогда или сеансовые ключи генерируются при привязке устройств друг к другу, пишутся во флэш и хранятся там вечно, или можно поуправлять светом у соседа.
Я немного не про это: доверять свою жизнь таким железкам, а не вырубать автоматы при электромонтажных работах — это прямое нарушение ТБ и виноват сам нарушитель. А про алгоритм мне самому было-бы интересно почитать, раз тут такой хороший фидбэк от разработчиков.
Дело не в паранойе, а в том, что зачастую разработчики вообще не парятся с шифрованием, и думают, что достаточно просто использовать функцию AES_enсrypt (условно), и система становится супер защищенной. Причем из-за того, что люди не вникали не то что в тонкости шифрования, но даже не читали рекомендации, как делать правильно. В итоге получается фигня, но с иллюзией безопасности.
Примерно, как в дешевую китайскую входную дверь вставить самый крутой замок (или даже 2-3). Да замок крутой и его не взломают отмычкой, или ещё как-то. Воры просто отогнут дверь ломиком секунд за 20.
Примерно, как в дешевую китайскую входную дверь вставить самый крутой замок (или даже 2-3). Да замок крутой и его не взломают отмычкой, или ещё как-то. Воры просто отогнут дверь ломиком секунд за 20.
Если не можете привести схему, то продемонстрируйте хотя бы модель угроз по которой вы строили систему защиты.
И еще вы упомянули, что генерируете ключи случайным образом, опишите пожалуйста откуда вы берете энтропию и какой алгоритм генерации используете. Сноуден очень интересно рассказывал про «случайные» ключи шифрования.
В природе существует абсолютно стойкий шифр — шифр Вернама (однаразовый блокнот) брут-форс по нему невозможен и это научно доказано.
НО применяя один и тот же ключ более чем к одному открытому тексту, злоумышленник перехватив зашифрованные данные способен к безключевому чтению. Вот такая вот защита от брут-форса…
И еще вы упомянули, что генерируете ключи случайным образом, опишите пожалуйста откуда вы берете энтропию и какой алгоритм генерации используете. Сноуден очень интересно рассказывал про «случайные» ключи шифрования.
Я максимально усложнил работу взломщикам, введя дополнительную защиту от брутфорса. Это всё, что я пока могу сказать.
В природе существует абсолютно стойкий шифр — шифр Вернама (однаразовый блокнот) брут-форс по нему невозможен и это научно доказано.
НО применяя один и тот же ключ более чем к одному открытому тексту, злоумышленник перехватив зашифрованные данные способен к безключевому чтению. Вот такая вот защита от брут-форса…
Хотелось бы полного раскрытия алгоритмов и, возможно, аудита от специалистов в области криптографии. Иначе есть возможность засветиться в https://twitter.com/internetofshit.
К сожалению, сейчас безопасность в IoT оставляет желать лучшего, а т.к. всё реализовано в железе, то баги пофиксить не получится быстро.
К сожалению, сейчас безопасность в IoT оставляет желать лучшего, а т.к. всё реализовано в железе, то баги пофиксить не получится быстро.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за ответы. Вопросы вызваны тем, что после прослушивания курса криптографии на корсере (ни в коем случае не мню себя экспертом после этого), когда лектор множество раз говорил не изобретать велосипед, а воспользоваться готовыми алгоритмами и схемами, т.е. их безопасность доказывается математически, обращаю внимание на это. Также ярким примером является WEP, который вроде бы и изобретён был профессионалами, но в его архитектуру заложены столь глупые ошибки, что не понятно, как это вообще могло произойти.
В IoT устройствах, насколько понимаю, чаще всего или вообще полное отсутствие какой-то защиты или низкое число возможных вариантов ключей, или применение какой-то своей гениальной схемы, в которой профессионал быстро находит слабое место (примеры тоже были в известных продуктах, но уже не вспомню).
В IoT устройствах, насколько понимаю, чаще всего или вообще полное отсутствие какой-то защиты или низкое число возможных вариантов ключей, или применение какой-то своей гениальной схемы, в которой профессионал быстро находит слабое место (примеры тоже были в известных продуктах, но уже не вспомню).
Алгоритм — наверное можно это описать так = ECB+CBC+собственные алгоритмические решения.
Что вы имеет ввиду ECB+CBC+собственные алгоритмические решения? Нельзя совместить ECB и CBC, они два противополжных мода. Один статически шифрует блоки одним и тем же ключем, а второй шифрует цепочным миксом.
В итоге я остался доволен, т. к. ECB/CBC/CTR в чистом классическом виде нормально при постоянной передаче данных не защищают.
Вы говорите о трех разных модах которые используются в разных видах операций. CTR как раз хорошее решение для IoT, который на пример советует Gemalto. https://www.lora-alliance.org/portals/0/documents/whitepapers/LoRaWAN_Security-Whitepaper_V6_Digital.pdf
Ключи создаются случайным образом.
И как происходит обмен ключами?
Можно пожалуйста публично представить схему вашего шифрования?
Прочитал. Даже скачал мануал по ссылке, но так до конца и не понял два момента:
— можно ли запросить состояние силового блока (вроде есть команда get_status, но не документирована)?
— что будет, если я переключу лампу с брелка/выключателя? Узнает ли mtrf об этом?
Ну и да, с шифрованием как-то непонятно… Раскрыть бы немного подробности
— можно ли запросить состояние силового блока (вроде есть команда get_status, но не документирована)?
— что будет, если я переключу лампу с брелка/выключателя? Узнает ли mtrf об этом?
Ну и да, с шифрованием как-то непонятно… Раскрыть бы немного подробности
Когда вы отдаёте команду силовому блоку, то в Serial интерфейс приходят ответы, содержащие актуальную (то есть действительную) информацию о состоянии блока. Если вы измените состояние силового блока с брелка, то модуль MTRF не получит специальное уведомление. Переслал ваш вопрос разработчикам — послушаем официальный ответ на это вопрос.
Когда вы отдаёте команду силовому блоку, то в Serial интерфейс приходят ответы,
Это-то понятно. Но, как по мне, не вполне достаточно. Подождём ответа разработчиков, ибо:
во-первых, радио — довольно непредсказуемая вещь в плане помех, может и ответ не получить (да, читал, есть состояние «нет ответа» или «ошибка исполнения», но она вряд ли скажет текущий статус).
во-вторых, я могу, например, перезагрузить своё устройство с MTRF и/или софтом для контроля/визуализации. И как мне узнать нынешнее состояние?
Перед перезагрузкой сохранить текущее состояние системы, а после загрузки заново отослать все команды, на установку тех значений, что восстановлены из памяти. Соотв-но в случае корректной работы оборудования с каждого датчика вернется ответ, что устройство и так уже выключено/включено.
Не-е-е… Не вариант:
— устройство могло сброситься не по своей воле и чего-то не сохранить
— у меня «есть» ещё брелки/настенные выключатели и т.п.
— команда «Switch» (из примера) переключает нагрузку и, посему я «не знаю», в каком состоянии лампочка, если _успешный_ ответ не был получен.
причём, если я сижу дома и надо мной погас свет — это одно, а если это обогреватель/котёл/насос/да-что-угодно где-то далеко, ну хотя бы на даче? И был переключен по какому-то алгоритму не «мной», а другим блоком ноолайт-а…
Собственно, пока не будет нормальной информации о состоянии исполнительного устройства, буду «облизываться» на ноолайт, но делать свои временные поделки, где точно буду знать, что происходит :)
— устройство могло сброситься не по своей воле и чего-то не сохранить
— у меня «есть» ещё брелки/настенные выключатели и т.п.
— команда «Switch» (из примера) переключает нагрузку и, посему я «не знаю», в каком состоянии лампочка, если _успешный_ ответ не был получен.
причём, если я сижу дома и надо мной погас свет — это одно, а если это обогреватель/котёл/насос/да-что-угодно где-то далеко, ну хотя бы на даче? И был переключен по какому-то алгоритму не «мной», а другим блоком ноолайт-а…
Собственно, пока не будет нормальной информации о состоянии исполнительного устройства, буду «облизываться» на ноолайт, но делать свои временные поделки, где точно буду знать, что происходит :)
НЛО прилетело и опубликовало эту надпись здесь
А разгадка одна — z-wave.
С такими ценами — нет, спасибо. Zigbee/6lowpan.
НЛО прилетело и опубликовало эту надпись здесь
А откуда и какая задержка у вас появляется?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Благодарю!
Собственно, если CMD_Read_State работает, то этого уже вполне достаточно для начальной синхронизации.
С автоматизацией — идея правильная, ибо постоянным опросом на батарейках разоришься :)
Осталось дождаться выключателей с новым протоколом и жизнь вообще наладится!
Собственно, если CMD_Read_State работает, то этого уже вполне достаточно для начальной синхронизации.
С автоматизацией — идея правильная, ибо постоянным опросом на батарейках разоришься :)
Осталось дождаться выключателей с новым протоколом и жизнь вообще наладится!
НЛО прилетело и опубликовало эту надпись здесь
Про параллельно не совсем понял.
Если там разные протоколы, мне придётся постоянно переключать MTRF из старого в новый режим? Или на приём будет работать и так? Раз уж пошла такая пьянка, пример бы…
Пусть будет освещение: 3-4 люстры по 1-2 канала каждая, на каждую люстру по 2 выключателя (типа «проходных»), некий «комп» с MTRF. Одна из люстр с новым (-F) блоком, остальные с обычными.
Я так понимаю, что новым блоком (пока) будет рулить исключительно MTRF, а старыми могут как пульты, так MTRF?
Зато появляется вариант желаемых некоторыми выключателей с фиксацией, правда тогда придётся алгоритм вкл/откл выдумывать…
Если там разные протоколы, мне придётся постоянно переключать MTRF из старого в новый режим? Или на приём будет работать и так? Раз уж пошла такая пьянка, пример бы…
Пусть будет освещение: 3-4 люстры по 1-2 канала каждая, на каждую люстру по 2 выключателя (типа «проходных»), некий «комп» с MTRF. Одна из люстр с новым (-F) блоком, остальные с обычными.
Я так понимаю, что новым блоком (пока) будет рулить исключительно MTRF, а старыми могут как пульты, так MTRF?
Обратная связь в стационарных пультах особо ничего не даёт,
Зато появляется вариант желаемых некоторыми выключателей с фиксацией, правда тогда придётся алгоритм вкл/откл выдумывать…
Друзья, не стесняйтесь, у вас есть редкая возможность задать свои вопросы по nooLite непосредственно разработчику системы.
STI E4 7B573
32F042F6P6
PHL 648 A
Простите, а копировать всю маркировку с чипа — это новый модный тренд вместо того, чтобы написать «STM32F042F6»?
Очень жду новых девайсов с обратной связью, пока в SLF-1-300 не нравится отсутствие возможности (ну точнее это делается костылями с разборкой корпуса) подключить силовой блок за выключатель и сохранить аналоговое управление выключателем как в SB-1-150, так что усиленно ждем SBF-1-150 с поддержкой выключателя и обратной связи :)
Кстати, интересует вопрос как обстоит дело с обратной связью при переключении состояния вручную через выключатель? Получат ли связанные устройства сообщение об изменении состояния?
Кстати, интересует вопрос как обстоит дело с обратной связью при переключении состояния вручную через выключатель? Получат ли связанные устройства сообщение об изменении состояния?
НЛО прилетело и опубликовало эту надпись здесь
to mdn-tech
Пожалуйста, дайте пример посылки 17 байтов запроса состояния силовому блоку SLF-1-300
Не смог методом инженерного тыка понять что написано в документации.
Пожалуйста, дайте пример посылки 17 байтов запроса состояния силовому блоку SLF-1-300
Не смог методом инженерного тыка понять что написано в документации.
Ок, спасибо! Понял, повторил, работает.
Чём вызвано ограничение в 64 устройства на управляющего блоке?
НЛО прилетело и опубликовало эту надпись здесь
Подскажите, если при включении, в эти 12 секунд, на модуль будет высыпано много байт случайной информации на скорости 115200, может это как-то повлиять на его работоспособность или вообще завесить?
НЛО прилетело и опубликовало эту надпись здесь
Не получается, что я не так делаю?
Для включения яркости 50% на 0 канале старому силовому блоку отправляю такую последовательность:
171,0,0,0,0,6,1,95,0,0,0,0,0,0,0,17,172
А именно:
171 (старт),
0 (nooLite TX),
0 (Передать команду),
0,
0 (Ячейка),
6 (Яркость),
1 (Один байт данных),
95 (Половина яркости),
0,
0,
0,
0,
0,
0,
0,
17, (Контрольная сумма)
172
Для включения яркости 50% на 0 канале старому силовому блоку отправляю такую последовательность:
171,0,0,0,0,6,1,95,0,0,0,0,0,0,0,17,172
А именно:
171 (старт),
0 (nooLite TX),
0 (Передать команду),
0,
0 (Ячейка),
6 (Яркость),
1 (Один байт данных),
95 (Половина яркости),
0,
0,
0,
0,
0,
0,
0,
17, (Контрольная сумма)
172
А как привязать пульт к MTRF-64?
силовые блоки привязываются командой 15.
А как с пультами?
силовые блоки привязываются командой 15.
А как с пультами?
НЛО прилетело и опубликовало эту надпись здесь
с разъяснениями от самой организации
Сама организация на своем сайте не имеет неи форума ни нормальной техподдержки.
Вопросы приходится задавать по всяким случайным темам.
Ребята, вы что… Вы из какого века?
Я общался с разработчиком этой железки и в конце концов был послан… со своими вопросами. Вопросами того, для кого эта железка и разрабатывалась.
Посмотрите на документацию, там до сих пор не убраны даже грамматические ошибки — «Управление модульом ».
Купил еще один модуль — похоже(?) не работает. И нет даже желания ни к кому обращаться.
… " с разъяснениями от самой организации". Движетесь вперед семимильными шагами — http://www.noo.com.by/sistema-radioupravleniya-noolite.html — ОГО!!!
Ошибок куча, сильно повышает порог вхождения в разработку с Noolite. Видимо прибыль от самодельщиков минимальная. Видно, что документацию пишут сами разработчики, далекие от навыков технического писателя.
Но тем не менее система очень интересная. Интегрировал ее в свой умный дом, работает стабильно.
Пока не работал с датчиками температуры, а вот цена на датчик температуры и влажности завышены неимоверно…
Хотелось бы видеть датчики движения в классическом корпусе с кронштейном.
Необходимы датчики открытия/закрытия двери/окна, датчики протечки, датчик атмосферного давления.
не помешала бы и возможность подключения датчиков ds18b20, они есть и во всепогодном исполнении.
Но тем не менее система очень интересная. Интегрировал ее в свой умный дом, работает стабильно.
Пока не работал с датчиками температуры, а вот цена на датчик температуры и влажности завышены неимоверно…
Хотелось бы видеть датчики движения в классическом корпусе с кронштейном.
Необходимы датчики открытия/закрытия двери/окна, датчики протечки, датчик атмосферного давления.
не помешала бы и возможность подключения датчиков ds18b20, они есть и во всепогодном исполнении.
А пока взгляд самодельщика на проблему: https://igorkandaurov.com/2017/04/19/noolite-f-mtrf-64-slf-1-300-%d1%87%d0%b0%d1%81%d1%82%d1%8c-1/
Извиняюсь, вот ссылка на мои поделки с этим железом.
См. описание в таблице «Формат и Данные»
А где таблица то?
А где таблица то?
Это был мой первый вопрос разработчику. Воз и ныне там.
тем не менее система очень интересная.
Интересная. Ценой она интересна, в первую очередь. А ассортиментное наполнение — однобокое.
Но вот ребята уже дышат в спину: http://delumo.ru/ Разговаривал с разработчиком — готовят к выпуску такие же модули управления.
НЛО прилетело и опубликовало эту надпись здесь
Эта таблица тоже не помогла…
При нажатии кнопки пультов приходят подобные команды от модуля:
mode=1, req_code=0, togl=46, n_ch=0, n_cmd=0, n_format=0, n_d0=36, n_d1=0, n_d2=0, n_d3=0, n_adr=0
Хотелось понять, что значит n_d0=36
При нажатии кнопки пультов приходят подобные команды от модуля:
mode=1, req_code=0, togl=46, n_ch=0, n_cmd=0, n_format=0, n_d0=36, n_d1=0, n_d2=0, n_d3=0, n_adr=0
Хотелось понять, что значит n_d0=36
Товарищ разработчик!
Ответьте на простые вопросы: Почему мы общаемся с Вами в этой проходной теме? Почему не существует нормального форума, нормального места общения на вашем сайте?
Вам страшно его создать?
НЛО прилетело и опубликовало эту надпись здесь
Работа по документации уже ведётся. Но это не так быстро, т. к. параллельно идёт несколько разработок
Пожалуйста! Выложите инструкцию по прошивке и прошивку для MTRF-64.
(свеже) Купленный модуль после подачи питания через 10-12 секунд мигает светодиодом как и обычный но больше до него достучаться не удается.
Полагаю, его следует перепрошить — как это сделать?
Еще очень интересно, а как узнавать, что батарейка на пульте (иди датчике) разряжена? Почему бы не передавать напряжение или процентное значение заряда в пакете?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новая система nooLite-F с обратной связью и шифрованием