Для этого надо чуть более вменяемое описание зависимостей (Requires/Whants/BindsTo/PartOf), чем то, что лежит на freedesktop.org. Потому как я до конца не понимаю, как это вообще должно работать — как-то после «BindsTo несколько более строгое, чем Requires» и почти то же самое про PartOf, образуется равномерная каша в голове, не разбавляемая даже экспериментами.
Повожусь ещё несколько вечеров и либо буду сочинять баго-реквест, либо плюну и откачусь на симлинки…
Огорчает, что нет готового механизма «пнуть зависимых при изменении статуса» на случай _запуска_ .mount/.automount, только на случай его остановки :(
Что-то не хочет у меня это всё нормально работать с bind-ами.
Есть /mnt/sda, с automount. Монтируется при обращении.
Есть /opt/oh2 == bind to /mnt/sda/oh2 тоже с automount, BindsTo/After/PartOf на mnt-sda.mount.
При запуске opt-oh2.automount всё первый раз срабатывает. Но! Если отмонтируется /mnt/sda, то opt-oh2.automount переходит в 'inactive(dead)' и, соответственно, перестаёт работать. А OnFailure у automount нет…
Несколько дней гугления и вопрос на «Тостере» пока результат не дали :(
А я трижды уже пытался "переехать", но пока остаюсь на 1.8, хотя и обновленный гуй в 2.0 ощутимо приятнее...
Особенную "боль" доставляют скрипты из 1.8, которые в 80% случаев надо переписывать. Также сильно иначе стал работать JSONPATH (в частности, не удалось вытянуть данные вида "transform("JSONPATH",$.data[?(@.name=='abc')][0].value)" и пришлось писать JS функцию, генерящую готовый объект по имени поля)
Сейчас неспешно перевожу всю логику на NodeRed, а openhab занимается только отображением. В планах таки переползти под 2.0 на raspberry pi с read-only root.
Согласен с предыдущим оратором )) Идея хороша, но инструмент, ИМХО, сильно избыточен.
Если ставится задача на посмотреть что-то через модбас, то проще и «дешевле» сделать микро- веб страничку в ЕСП-шке. Ибо чаще раза в секунду всё равно опрашивать без толку, да mqtt внесёт ещё и дополнительные задержки.
Если уж очень хочется «живого» обновления, то не рефрешем всей страницы, а используя ajax/websocket (не помню, допилили ли их).
На своих домашних датчиках делаю шаблонообразную веб морду для конфига и просмотра живых значений с рефрешем страницы целиком. Даже раз в секунду полсотни значений нормально успевает отдать
Про параллельно не совсем понял.
Если там разные протоколы, мне придётся постоянно переключать MTRF из старого в новый режим? Или на приём будет работать и так? Раз уж пошла такая пьянка, пример бы…
Пусть будет освещение: 3-4 люстры по 1-2 канала каждая, на каждую люстру по 2 выключателя (типа «проходных»), некий «комп» с MTRF. Одна из люстр с новым (-F) блоком, остальные с обычными.
Я так понимаю, что новым блоком (пока) будет рулить исключительно MTRF, а старыми могут как пульты, так MTRF?
Обратная связь в стационарных пультах особо ничего не даёт,
Зато появляется вариант желаемых некоторыми выключателей с фиксацией, правда тогда придётся алгоритм вкл/откл выдумывать…
Собственно, если CMD_Read_State работает, то этого уже вполне достаточно для начальной синхронизации.
С автоматизацией — идея правильная, ибо постоянным опросом на батарейках разоришься :)
Осталось дождаться выключателей с новым протоколом и жизнь вообще наладится!
— устройство могло сброситься не по своей воле и чего-то не сохранить
— у меня «есть» ещё брелки/настенные выключатели и т.п.
— команда «Switch» (из примера) переключает нагрузку и, посему я «не знаю», в каком состоянии лампочка, если _успешный_ ответ не был получен.
причём, если я сижу дома и надо мной погас свет — это одно, а если это обогреватель/котёл/насос/да-что-угодно где-то далеко, ну хотя бы на даче? И был переключен по какому-то алгоритму не «мной», а другим блоком ноолайт-а…
Собственно, пока не будет нормальной информации о состоянии исполнительного устройства, буду «облизываться» на ноолайт, но делать свои временные поделки, где точно буду знать, что происходит :)
Когда вы отдаёте команду силовому блоку, то в Serial интерфейс приходят ответы,
Это-то понятно. Но, как по мне, не вполне достаточно. Подождём ответа разработчиков, ибо:
во-первых, радио — довольно непредсказуемая вещь в плане помех, может и ответ не получить (да, читал, есть состояние «нет ответа» или «ошибка исполнения», но она вряд ли скажет текущий статус).
во-вторых, я могу, например, перезагрузить своё устройство с MTRF и/или софтом для контроля/визуализации. И как мне узнать нынешнее состояние?
Прочитал. Даже скачал мануал по ссылке, но так до конца и не понял два момента:
— можно ли запросить состояние силового блока (вроде есть команда get_status, но не документирована)?
— что будет, если я переключу лампу с брелка/выключателя? Узнает ли mtrf об этом?
Ну и да, с шифрованием как-то непонятно… Раскрыть бы немного подробности
их еще есть у других, но немного. Ищутся по mini 5v 3a dcdc или чему-то подобному. Появились новые — Уже и длиннее. На каком чипе — не знаю, но дроссель сильно крупнее
Стандарт лишь оговаривает, что _должен_ «говорить» про себя зарядник, а пользоваться ли этими данными — выбор смарта. возможно, 4s ещё наплевательски относился к зарядному кабелю, возможно — переходник USB-Apple достаточно «туп», чтобы игнорировать сигналы с D+/D-.
Я как-то не пользуюсь продукцией Apple, а с остальными не раз бывало, что «железка» не хочет брать больше 0.5А потому как не понимает, что это «зарядник». Дополнительный квест — китайские USB шнурки — либо непропай/обрыв по одной из жил, либо D+/D- не распаяны вообще, либо жилы настолько тонкие, что на 0.5м шнурка падает до 1В на 0.7А нагрузки…
Я в последее время «подсел» на вот такие модули. Купил оптом десяток и ставлю во всякие поделки
При заявленных 3А, пробовал примерно 2А нагрузку — без проблем справляется с «разумным» (точно не мерил, субъективно до 50С) нагревом.
С точки зрения данных для зарядки — у него, как хотят многие смартфоны, «закорочены» D+ и D-, что обычно детектится смартфонами как «зарядное устройство», а не «компьютерный порт USB». Для «яблочных» придётся переделывать
По дому раскидано несколько bmP280, bmE280, DS18B20 и одинокий DHT22 (AM2302).
По году-полутора наблюдений могу сказать, что разброс bmp/bme в пределах 0.5..1С и 0.5..1.6 мм.рт.ст. при том, что высота установки примерно одинакова (±0.5м). С влажностью сложнее, но BME280 по ощущениям гораздо адекватнее DHT22, особенно при высокой влажности, где DHT «промокает» и держит 99.9% довольно долго. Разность по влажности DHT BME была порядка 5-7.
Есть три рядом стоящих датчика — BMP на плате с «мозгами» на ESP8266, BME+DS18B20 на выносном датчике в паре метров рядом. Давление различается на 0.5мм, стабильно за всё время наблюдений. А вот температура 18B20+BME гораздо непредсказуемей. во-первых, BME _гораздо_ лучше ловит отраженное тепло (коррекция -2.2С по сравнению с 18B20), во-вторых у них сильно разная инерционность и расхождение гуляет до пары-тройки градусов (особенно, когда сосед снизу окно открывает ;) ) Что, в общем-то, логично, т.к. BMx250 позиционируются в том числе для навигации в помещениях.
ЗЫ: где-то мелькал совет по вымачиванию DHT22 полчаса в спирте с последующей сушкой несколько часов — вроде как перестаёт откровенно левые показания давать и выравнивается между датчиками. Не пробовал…
Ну, там ещё куча светодиодиков и пафосные релюшки на 6А… %)
Если брать «фирменные» малогабаритные реле от того же weidmuller-а (а только что-то подобное и влезет в такой корпус ИМХО), то можно и дороже сделать… Но что-то мало верится…
На ESP8266 датчик BME280 живет на примерно 4÷5 метрах UTP кабеля под крышей уже пару лет. Грозы и «убитые» стартёры от древних ламп ЛБ-40 выдержал успешно. Тестовый китайский 1.8" OLED жил на метрах восьми от «ардуины», но подглючивал (возможно сам по себе)
… «1» — +3.3-5В, «2», «3» — шина данных, «4» — GND. TVS стоит на минимальные для этой модели 5В (срабатывание при 5.2 примерно). Если напряжение питания больше, выбрать другой на «сколько-в-питании или чуть выше»
иногда вместо диодных сборок ставлю TVS везде.
Вместо сборок пойдут и «простые» диоды. 1N4148 или 1N5819 (SS14), но у вторых обратный ток сравнительно большой
Отдельный плюс за controllio — забавная игрушка. Если б ещё не цена…
А вот I2C без защиты это плохо. На полутора метрах вполне реально пожечь входа от включения соседнего холодильника или даже лампочки. TVS и/или диодная развязка плюс резистор, ом на 10-30 крайне желательны.
Повожусь ещё несколько вечеров и либо буду сочинять баго-реквест, либо плюну и откачусь на симлинки…
Огорчает, что нет готового механизма «пнуть зависимых при изменении статуса» на случай _запуска_ .mount/.automount, только на случай его остановки :(
Есть /mnt/sda, с automount. Монтируется при обращении.
Есть /opt/oh2 == bind to /mnt/sda/oh2 тоже с automount, BindsTo/After/PartOf на mnt-sda.mount.
При запуске opt-oh2.automount всё первый раз срабатывает. Но! Если отмонтируется /mnt/sda, то opt-oh2.automount переходит в 'inactive(dead)' и, соответственно, перестаёт работать. А OnFailure у automount нет…
Несколько дней гугления и вопрос на «Тостере» пока результат не дали :(
Я свой брал банально через и-бей с доставкой за $16 (тут). Нормально пришло за четыре недели обычной почтой
Резкость наводится и, в отличие от обзора, кольцо резкости болтается
А я трижды уже пытался "переехать", но пока остаюсь на 1.8, хотя и обновленный гуй в 2.0 ощутимо приятнее...
Особенную "боль" доставляют скрипты из 1.8, которые в 80% случаев надо переписывать. Также сильно иначе стал работать JSONPATH (в частности, не удалось вытянуть данные вида "
transform("JSONPATH",$.data[?(@.name=='abc')][0].value)" и пришлось писать JS функцию, генерящую готовый объект по имени поля)Сейчас неспешно перевожу всю логику на NodeRed, а openhab занимается только отображением. В планах таки переползти под 2.0 на raspberry pi с read-only root.
Если ставится задача на посмотреть что-то через модбас, то проще и «дешевле» сделать микро- веб страничку в ЕСП-шке. Ибо чаще раза в секунду всё равно опрашивать без толку, да mqtt внесёт ещё и дополнительные задержки.
Если уж очень хочется «живого» обновления, то не рефрешем всей страницы, а используя ajax/websocket (не помню, допилили ли их).
На своих домашних датчиках делаю шаблонообразную веб морду для конфига и просмотра живых значений с рефрешем страницы целиком. Даже раз в секунду полсотни значений нормально успевает отдать
Если там разные протоколы, мне придётся постоянно переключать MTRF из старого в новый режим? Или на приём будет работать и так? Раз уж пошла такая пьянка, пример бы…
Пусть будет освещение: 3-4 люстры по 1-2 канала каждая, на каждую люстру по 2 выключателя (типа «проходных»), некий «комп» с MTRF. Одна из люстр с новым (-F) блоком, остальные с обычными.
Я так понимаю, что новым блоком (пока) будет рулить исключительно MTRF, а старыми могут как пульты, так MTRF?
Зато появляется вариант желаемых некоторыми выключателей с фиксацией, правда тогда придётся алгоритм вкл/откл выдумывать…
Собственно, если CMD_Read_State работает, то этого уже вполне достаточно для начальной синхронизации.
С автоматизацией — идея правильная, ибо постоянным опросом на батарейках разоришься :)
Осталось дождаться выключателей с новым протоколом и жизнь вообще наладится!
— устройство могло сброситься не по своей воле и чего-то не сохранить
— у меня «есть» ещё брелки/настенные выключатели и т.п.
— команда «Switch» (из примера) переключает нагрузку и, посему я «не знаю», в каком состоянии лампочка, если _успешный_ ответ не был получен.
причём, если я сижу дома и надо мной погас свет — это одно, а если это обогреватель/котёл/насос/да-что-угодно где-то далеко, ну хотя бы на даче? И был переключен по какому-то алгоритму не «мной», а другим блоком ноолайт-а…
Собственно, пока не будет нормальной информации о состоянии исполнительного устройства, буду «облизываться» на ноолайт, но делать свои временные поделки, где точно буду знать, что происходит :)
Это-то понятно. Но, как по мне, не вполне достаточно. Подождём ответа разработчиков, ибо:
во-первых, радио — довольно непредсказуемая вещь в плане помех, может и ответ не получить (да, читал, есть состояние «нет ответа» или «ошибка исполнения», но она вряд ли скажет текущий статус).
во-вторых, я могу, например, перезагрузить своё устройство с MTRF и/или софтом для контроля/визуализации. И как мне узнать нынешнее состояние?
— можно ли запросить состояние силового блока (вроде есть команда get_status, но не документирована)?
— что будет, если я переключу лампу с брелка/выключателя? Узнает ли mtrf об этом?
Ну и да, с шифрованием как-то непонятно… Раскрыть бы немного подробности
Стандарт лишь оговаривает, что _должен_ «говорить» про себя зарядник, а пользоваться ли этими данными — выбор смарта. возможно, 4s ещё наплевательски относился к зарядному кабелю, возможно — переходник USB-Apple достаточно «туп», чтобы игнорировать сигналы с D+/D-.
Я как-то не пользуюсь продукцией Apple, а с остальными не раз бывало, что «железка» не хочет брать больше 0.5А потому как не понимает, что это «зарядник». Дополнительный квест — китайские USB шнурки — либо непропай/обрыв по одной из жил, либо D+/D- не распаяны вообще, либо жилы настолько тонкие, что на 0.5м шнурка падает до 1В на 0.7А нагрузки…
При заявленных 3А, пробовал примерно 2А нагрузку — без проблем справляется с «разумным» (точно не мерил, субъективно до 50С) нагревом.
С точки зрения данных для зарядки — у него, как хотят многие смартфоны, «закорочены» D+ и D-, что обычно детектится смартфонами как «зарядное устройство», а не «компьютерный порт USB». Для «яблочных» придётся переделывать
По году-полутора наблюдений могу сказать, что разброс bmp/bme в пределах 0.5..1С и 0.5..1.6 мм.рт.ст. при том, что высота установки примерно одинакова (±0.5м). С влажностью сложнее, но BME280 по ощущениям гораздо адекватнее DHT22, особенно при высокой влажности, где DHT «промокает» и держит 99.9% довольно долго. Разность по влажности DHT BME была порядка 5-7.
Есть три рядом стоящих датчика — BMP на плате с «мозгами» на ESP8266, BME+DS18B20 на выносном датчике в паре метров рядом. Давление различается на 0.5мм, стабильно за всё время наблюдений. А вот температура 18B20+BME гораздо непредсказуемей. во-первых, BME _гораздо_ лучше ловит отраженное тепло (коррекция -2.2С по сравнению с 18B20), во-вторых у них сильно разная инерционность и расхождение гуляет до пары-тройки градусов (особенно, когда сосед снизу окно открывает ;) ) Что, в общем-то, логично, т.к. BMx250 позиционируются в том числе для навигации в помещениях.
ЗЫ: где-то мелькал совет по вымачиванию DHT22 полчаса в спирте с последующей сушкой несколько часов — вроде как перестаёт откровенно левые показания давать и выравнивается между датчиками. Не пробовал…
Проще уж, как делают в пром. контроллерах — клемма под винт или нажимная
Если брать «фирменные» малогабаритные реле от того же weidmuller-а (а только что-то подобное и влезет в такой корпус ИМХО), то можно и дороже сделать… Но что-то мало верится…
ЗЫ: но корпуса-то забавные
… «1» — +3.3-5В, «2», «3» — шина данных, «4» — GND. TVS стоит на минимальные для этой модели 5В (срабатывание при 5.2 примерно). Если напряжение питания больше, выбрать другой на «сколько-в-питании или чуть выше»
иногда вместо диодных сборок ставлю TVS везде.
Вместо сборок пойдут и «простые» диоды. 1N4148 или 1N5819 (SS14), но у вторых обратный ток сравнительно большой
А вот I2C без защиты это плохо. На полутора метрах вполне реально пожечь входа от включения соседнего холодильника или даже лампочки. TVS и/или диодная развязка плюс резистор, ом на 10-30 крайне желательны.