MajorDoMo

1) Добавил поле в табличку. Возможно из-за этого система подвисала, то что логи ошибками наполнялись...проверьте
2) Вроде поправил работу LAN с многоканальными устройствами. Но не точно...девайсов таких нет - проверить не могу.

2) подтверждаю - все отлично теперь, в смысле 2 канальные выключатели заработали, как надо.

а (1) кто нить подтвердит?)) Потому что у меня всё стабильно работало несколько дней ещё до того как лан режим выкатил...но у меня все поля вручную созданы были, т.к. модуль прямо на системе разрабатывал. Так что есть вероятность, что именно из-за этого были подвисания, подтормаживания и т.п.

yii писал(а): Вс май 12, 2019 9:01 am А вот можно ли попробовать научить модуль рулить автоматическим режимом девайсов th 10/16?
Сейчас объясню на пальцах

Эти девайсы могут работать в 3х режимах: обычный выключатель, авто режим по температуре, авто режим по влажности.
Текущий режим работы в свойствах отображается, это свойство deviceType, которое при изменении в eWeLink нормально прилетает в модуль, и имеет значения соответственно: normal, temperature и humidity в зависимости от того в каком режиме девайс.

А вот текущих границ включающих и выключающих девайс в авто режиме среди свойств нету...

Попробовал менять deviceType - режимы меняются, а значения температуры или влажности берутся те что были последний раз...

Соответственно вопрос в том что бы научиться читать и писать текущие границы температуры и влажности...

Еще, посмотрев внимательно на данные в модуле, нужные данные в не распарсеном виде увидел в свойстве targets...
[{"reaction":{"switch":"on"},"targetHigh":"45"},{"reaction":{"switch":"off"},"targetLow":"20"}], строка для работы по температуре и влажности одинакова, что это (температура или влажность определяется по режиму работы, в режиме обычного выключателя ни на что не влияет (остается последней).

Еще есть свойство mainSwitch которое в ручном режиме дублирует switch, а в автоматическом всегда on. Скорее всего используется eWelink'ом для проверки авто режима, так как если девайс в авторежиме то он не дает его переключить в ручную (пишет что в авторежиме это не доступно), однако из модуля девайс спокойно включается и выключает игнорируя это.

Можно ли ожидать парсинг targets в ближайших обновлениях, или быстрее свой скрипт набросать?

targets я выведу (да, наконец добрался =D)...неплохо бы ещё знать - как включается данный режим? В смысле программно...можете глянуть что улетает в сокет при включении автоматического режима?

nick7zmail писал(а): Чт янв 30, 2020 7:49 am targets я выведу (да, наконец добрался =D)...неплохо бы ещё знать - как включается данный режим? В смысле программно...можете глянуть что улетает в сокет при включении автоматического режима?

Приветствую. Хорошо что это сообщение всплыло, а то у меня завал на работе, даже не знал что модуль обновился а так форум маякнул

Я сейчас уже не гляну. У меня единственный TH на тасмоту давно перешит, ибо родной функционал никакой. Но я делал управление им через меню, все работало, так что по идее все как описано. В targets json с параметрами порогов температуры и влажности. В deviceType режим работы. В нормальном режиме targets не затирается, просто игнорируется, т.е. там всегда последнее установленное значение для обоих автоматических режимов. т.е. менять по сути ничего не надо, просто распарсить json из targets для удобной привязки его параметров к свойствам объекта, ну и собрать обратно при изменении любого из свойств. Я из меню менял параметры, собирал из них json, и модуль прекрасно отправлял его в облако. все изменения видны были в ewelinke. В примере выше json реальный, взятый в свое время из привязанного к модулю TH.

Включаются авторежимы через свойство deviceType normal, temperature и humidity соответственно. Тут вобще ничего трогать не надо. Пишем в свойство привязанного объекта нужный режим и все.

Ну и добавлю про логику, так как с ней у многих проблема даже в родном приложении на примере:

Обычный режим
deviceType normal
targets игнорируется, что в нем не важно, в реале там значения с последнего авторежима

Контроль температуры
при 27 градусах наш девайс должен отключаться, при 22 включаться, это будет выглядеть так:
deviceType temperature
targets [{"reaction":{"switch":"off"},"targetHigh":"27"},{"reaction":{"switch":"on"},"targetLow":"22"}]

Контролироль влажность, при 60% включать девайс, при 45 выключать:
deviceType humidity
targets [{"reaction":{"switch":"on"},"targetHigh":"60"},{"reaction":{"switch":"off"},"targetLow":"45"}]

т.е. targets один для обоих режимов, значение targetHigh обязательно должно быть больше targetLow, и это значение либо температуры, либо влажности в зависимости от режима ну и switch что делается при достижении верхнего, либо нижнего порога. Все это надо учитывать в своих скриптах при управлении в ручную.

yii писал(а): Чт янв 30, 2020 10:11 am Обычный режим
deviceType normal
targets игнорируется, что в нем не важно, в реале там значения с последнего авторежима

Вот про это я и спрашивал...хотел узнать как включить/выключить авто режим)))

А почему на тасмоту? Что там интересного? Понятное дело, что мкутт и т.п. Но тут теперь тоже всё по локалке работает, инет не нужен...какие фишки там есть?

nick7zmail писал(а): Чт янв 30, 2020 10:42 am
Вот про это я и спрашивал...хотел узнать как включить/выключить авто режим)))

А почему на тасмоту? Что там интересного? Понятное дело, что мкутт и т.п. Но тут теперь тоже всё по локалке работает, инет не нужен...какие фишки там есть?

ну рад что ответил как раз то что надо, кому то пригодится это точно.

Про тасмоту, в родном приложении логика однобокая, либо авто режим, либо таймеры и тд. Нет сети, а девайс перезагрузился по питанию, значит нет таймеров итд...

У меня задача была рулить вытяжкой в погребе, это влажное помещение, так как оптимальная влажность для хранения некоторых овощей вобще 95%, ну и rssi там почти на грани -68 - -72... на тасмоте я двумя правилами сделал нужную мне логику, не зависящую от сети и электричества (в смысле что после включения питания все продолжает работать так как все хранится в устройстве). На родной так как я хотел не вышло бы.

С текущими версиями и LAN mode может и выйдет что то, но я прошился на тасмоту как раз когда прилетело первое неудачное обновление на версую 3хх в котором датчик считывался ровно один раз - при включении девайса и у меня все встало... ждать обновлений не очень хотелось, сейчас это вроде давно поправили... ну и обратно ходу нет, так как сейчас подключен bme280 который нормально работает с большими влажностями в отличии от dht подобных, ну и в планах второй канал туда завестит под другие нужды, но это как тепло станет

У меня Sonoff T12C двухканальный. В модуле у него в данных аж 4 свитча(выключателя). Switch0 и Switch1 управляют включением 1-го и 2-го каналов света. А вот для чего и что делают switch2 и switch3?

doc_bravn писал(а): Чт янв 30, 2020 11:13 am У меня Sonoff T12C двухканальный. В модуле у него в данных аж 4 свитча(выключателя). Switch0 и Switch1 управляют включением 1-го и 2-го каналов света. А вот для чего и что делают switch2 и switch3?

Ничего, такая структура у всех девайсов где более одного канала... т.е. просто сделали один массив на все... ну и как следствие врятли стоит ждать сонофф более чем на 4 канала

nick7zmail писал(а): Вс янв 12, 2020 5:22 pm Ну судя по скринам - как минимум есть метрики rfTrigX - в них приходят данные, когда поступил сигнал с какого либо обученного датчика/пульта. И есть метрики RfList, где храняться сохранённые команды для отправки, и rfSend, через которую, скорее всего, можно отправить обученную команду...Что туда надо отправить - это надо отснифить. У кого то единоразово так делал - и оно работало. Отправлять надо номер ячейки, куда сохранён код, из rfList. Сейчас не вспомню, как это делается. Говорю - надо снифить трафик, и смотреть как сам сонофф это инициирует.

Сори, только сейчас смог вернуться к данному вопросу.
1. Чем и как можно отснифить на Raspberry, tcpdump'ом? Просто RfList и rfTrigX еще как-то можно отснифить, а вот в rfSend (если я правильно понял) только посылаются команды, т.е. что там должно быть и в каком формате не понятно.
Я могу по пульту через eWelink приложение что-то включить, увижу, что что-то поменялось в каком-то из rfTrigX. Пойму какой это номер в rfList, но что мне закидывать в rfsend? просто номер соответствия rfTrigX'а того, что в rfList?
2. Какого рода доступ нужен, чтобы смог зайти и покопаться? teamviewer подет?
3. Могу попытаться выслать один bridge, у меня 2 их, второй покупал, когда были ограничения по кол-ву пультов, которые он может запомнить - раньше было 4 пульта в памяти и все. Сейчас это ограничение больше (сколько не знаю, но у меня влезло 6 пультов). Второй уже стал не нужен. Но я не уверен, что между ua-ru посылки нормально ходят.