Andrew V.

Приветствую. имею две ультра2, размещенные в разных частях города, у разных провайдеров и тд. Так вот последние пару недель стал очень часто ловить, что оба роутера недоступны для удаленного управления. Висят серым в приложении. То есть проблема 100% на стороне облачного сервера приложения. Через облачный keendns при этом веб открывается прекрасно. Ну и еще одна вытекающая из этого прлблема. Если в приложении под ios зайти на роутер, потом свернуть приложение и через какое-то время развернуть (а роутер при этом успел стать недоступным для дистанционного управления изза проблем на серверах), то всплывашка с недоступностью удаленного управления не позволяет даже выйти в главное меню приложения (к списку устройст). На всплывашке нажимаешь ок - а она возникает снова через долю секунды, блокируя любое управление. И так раз 20 подряд, потом приходит в себя и позволяет выйти в меню. Надо приручить сумасшедшую всплывашку.

Тут задача не проинформировать в первую очередь, а создать триггер для дальнейшего действия. Например, выключить уведомления по движению с определенных камер ivideon, поставить термостат nest на более высокую температуру, переключить sonoff на другой режим и тд. Короче, масса домашних гаджетов, да и сервисов подвязана на ifttt. А если по информированию по приходу - то тоже, сейчас это решается исключительно сторонними скриптами на флешке, а через ifttt - нажатием на две кнопки на смартфоне.

В певую очередь для всяческой автоматизации и скуда очень бы хотелось уйти от геофенсинга к триггерам по регистрации абонента в сети.

Приветствую. Планируется ли поддержка сервиса ifttt на уровне прошивки? Было бы очень удобно привязывать различные действия к появлению/пропаданию абонента в сети и т.д. Насколько я помню, такой функционал есть теперь у Асуса, например: https://ifttt.com/asusrouter и у tp-link: https://ifttt.com/tplink_router Было бы неплохо иметь такую интеграцию и в Кинетиках.

Так он уже к вам ходит с этим вопросом 2 месяца. Хотите, можем напрямую общаться, если это будет оперативнее.

Ну что же вы так. Уже даже дамп траффика для всех возможных 9 комбинаций давно на почте у сотрудника ТП, который занимается этим вопросом два месяца. Уточню, перестал работать доступ не к модему в другой подсети (доступа никогда и не было), а к обычным устройствам в той же подсети. К которым доступ был многие месяцы на 2.11

Разработчики пытались реализовать эту функцию, но, как я понимаю, запал у них быстро кончился - и ничего в итоге не сделали. И, кстати, в новом драфте поломали кеенднс доступ и к устройствам в одной подсети - у меня из двух настроенных устройств одно продолжает открываться, а второе перестало, с редиректом на его ip адрес в локалке даже при дистанционном доступе. Если б знал, что сломают даже то, что работало - даже не думал бы просить о доступе к модему извне.

То есть если в пинг-чеке 3 адреса, то ответ хотя бы от одного из них будет означать, что интернет есть??

Новостей пока нет? )

Что именно проверить? У провайдера днс падают раз-два в месяц и чаще всего по ночам. Это видно по отваливающейся части умного дома, которая хостится в usa и на амазоне. Мне от разбирающихся людей мнение по решению нужно, а не сидеть месяц ловить ошибку и ждать, сработает или нет. Про задержку - тоже хотелось бы компетентное мнение, почему так было и поможет ли. Поскольку если не поможет - то смысл менять то, что работает в 99% времени. Про ранжирование днс - вообще в идеале статью в фак как по остальным актуальным функциям кинетика.

Приветствую. У меня следующая ситуация. У основного провайдера по выделенке - иногда тупят dns - в результате чего бывает недоступен забугорный сегмент интернета. При этом пинг-чек такие пропадания иностранного интернета не фиксирует, потому что стоит дефолтный вариант проверки, а там сайты, которые зеркалятся через Россию, я так понимаю. Соответственно, на резервный канал ничего не переключается - просто не открывается часть ресурсов. Если я добавлю к двум провайдерским днс'ам ещё и гугловский - это меня никак не спасёт? Днс'ы в списке ранжируются автоматически, но только по времени их отклика, как я понимаю. То есть запрос пойдёт через гугл только если в какой-то момент два провайдерских днс тупо упадут или будут пинговаться дольше, чем гугловский. Что маловероятно. Ну и второй вопрос. Когда я на 2.10 давным-давно добавил гугловский днс третьим - тут же заметил появившуюся задержку перед открытием каждой страницы - примерно секунда-две. Убрал третий днс, оставив только два провайдерских - задержка пропала. На 2.12 такой задержки не должно быть? И с чем она могла быть связана. Ну и напоследок, ставите ли вы вообще доп днс помимо тех, что выдал провайдер и зачем? Спасибо!

Все, что я хотел про индикацию написать - я написал. По работе с модемами мной создана отдельная тема. Здесь я отметил, что, может, индикацию частично и поправили, а работу с модемами испортили. Полагаю, это связанные моменты.

Мне кажется, наоборот сломали. У меня теперь 4G модем в резерве скатывается на 2G. Так иногда было и раньше. Но раньше при переключении на него он тут же переходил на 4G, а теперь висит на 2G до тех пор, пока его пинг чек не передёрнет по питанию, потому что через 2G не тянет вообще ничего. Ничего кроме прошивки ультры не менялось за это время. Делаю вывод, что сломали.

Я просто даже не ожидал, что приложение может по-разному выводить индикацию при переходе на резерв по разным условиям. К сожалению, уже проверить в ближайшее время не получится. Но 100% что приложение показывает НЕПРАВИЛЬНО - желтым основное соединение в главном меню при том, что активно резервное (переключенное пинг чеком) - при дистанционном подключении. Должно показывать зеленым резервное. И вчера я 100% словил правильную индикацию резервного зеленым при выдергивании кабеля - а вот локальное соединение было или дистанционное - не уверен. Скорее локальное. И я почти уверен, что при дистанционном подключении и выдернутый кабель показывает основное соединение желтым - что неправильно, а должно показывать резервное зеленым.

Неправильная индикация основного или резервного канала в приложении. Если с основного на резерв переключает пинг чек по пропаданию пинга - то в приложении отображается основное соединение якобы как активное, но жёлтым цветом. Если с основного на резерв переключение произошло при выдёргивании провайдерского кабеля - то в приложении правильно отображается активный резервный канал зелёным.

У меня две ультра2. Одна загородом, вторая в квартире. Загородом система посложнее, в сети несколько роутеров, думал проблема в этом. Но сейчас наблюдаю такую же проблему в квартире, где ультра - единственный роутер. И с совершенно другими подключенными клиентами. Итак, иногда начинается такая фигня и длится по несколько часов. Идентичных записей в логе много сотен, они повторяются раз в пару секунд. С чем это может быть связано? Сигнал на этом клиенте нормальный, он никуда не отваливается. Это вообще wifi камера, висящая на стене. С другими клиентами всё нормально, им хватает парной записи раз в сутки. А вот по некоторым клиентам (раньше я думал, что только по айфонам и айпадам, но сегодняшняя ночь показывает, что такое происходит с любым клиентом) - вот так: Dec 20 02:49:48wmond WifiMaster0/AccessPoint0: (MT76x2) STA(20:59:a0:b8:e4:ee) set key done in WPA2/WPA2PSK. Dec 20 02:49:50wmond WifiMaster0/AccessPoint0: (MT76x2) STA(20:59:a0:b8:e4:ee) had associated successfully. Dec 20 02:49:50wmond WifiMaster0/AccessPoint0: (MT76x2) STA(20:59:a0:b8:e4:ee) set key done in WPA2/WPA2PSK. Dec 20 02:49:52wmond WifiMaster0/AccessPoint0: (MT76x2) STA(20:59:a0:b8:e4:ee) had associated successfully. Dec 20 02:49:52wmond WifiMaster0/AccessPoint0: (MT76x2) STA(20:59:a0:b8:e4:ee) set key done in WPA2/WPA2PSK. Dec 20 02:49:54wmond WifiMaster0/AccessPoint0: (MT76x2) STA(20:59:a0:b8:e4:ee) had associated successfully. Dec 20 02:49:54wmond WifiMaster0/AccessPoint0: (MT76x2) STA(20:59:a0:b8:e4:ee) set key done in WPA2/WPA2PSK. Dec 20 02:49:56wmond WifiMaster0/AccessPoint0: (MT76x2) STA(20:59:a0:b8:e4:ee) had associated successfully. Dec 20 02:49:56wmond WifiMaster0/AccessPoint0: (MT76x2) STA(20:59:a0:b8:e4:ee) set key done in WPA2/WPA2PSK. Dec 20 02:49:59wmond WifiMaster0/AccessPoint0: (MT76x2) STA(20:59:a0:b8:e4:ee) had associated successfully. Dec 20 02:49:59wmond WifiMaster0/AccessPoint0: (MT76x2) STA(20:59:a0:b8:e4:ee) set key done in WPA2/WPA2PSK. Dec 20 02:50:03wmond WifiMaster0/AccessPoint0: (MT76x2) STA(20:59:a0:b8:e4:ee) had associated successfully.

А можно параллельно потыкать кого-нибудь, кто за веб отвечает? Ещё раз спасибо!

В идеале хотелось бы иметь возможность добавлять имена устройствам в keendns не только в одной подсети, но и в других - стандартными методами через меню, а не через CLI как сейчас. Очень актуально для резервных каналов интернета (в том числе для операторских роутеров, а так же модемов в режиме хайлинк). И нужна возможность добавлять авторизацию с логином-паролем от основного роутера - для тех устройств в сети, которые авторизации вообще не имеют (пока сделал через CLI, но было бы круто делать это галкой около имени устройства через веб интерфейс keendns что-то типа "добавить принудительную авторизацию"). Ну и вопрос с редиректом некоторых роутеров типа моего - тоже открыт. Спасибо большое за содействие! Если будет необходимо - могу дать доступ через teamviewer.

Приветствую. Домашняя сеть, ультра2 на 192.168.1.1. Основной канал - выделенка. МТС роутер Huawei CPE B315 по проводу как второй ipoe - в режиме резерва на 192.168.2.1. В локальной сети прекрасно открывается мтс роутер Huawei по его ip 192.168.2.1 что когда он в резерве, что в активе. Чтобы получить доступ к нему через keendns сделал, как советовали: ip http proxy mts upstream http 192.168.2.1 80 domain ndns allow public При этом при переходе по mts.bla-bla.mykeenetic.ru извне - браузер редиректится на http://192.168.2.1/html/index.html?url=mts.bla-bla.mykeenetic.ru - и, соответственно, ничего не открывается. Написал в саппорт, там после долгих изучений ответили: То есть CPE B315 форвардит на 192.168.2.1 в любом случае, даже при обращении извне через keendns. Есть ли какой вариант обойти это или исправить в будущих прошивках? В настройках самого CPE B315 я такого не нашёл. Возможно, подскажете, куда копать. В CLI разбираюсь слабо, но готовые команды вбить могу без проблем. Спасибо!

У меня на iphone 7 и прошивке 11.2 свайп по синему меню вообще не активен. При свайпе справа налево и наоборот - резко подпрыгивает вверх это синее меню - и ничего не происходит. Upd. При идеально ровном и аккуратном свайпе четко в границах меню удалось таки убрать это меню. Но получается это один раз из 10. Было бы лучше убирать его по нажатию на фоновую страницу, все равно там торчит ее огрызок с переключателями с полностью обрезанными подписями, которые можно случайно понажимать и даже не заметить.

Добрый день. Есть в приложении под ios две неточности, которые немного раздражают. 1. Порядок пунктов меню на синем фоне (при нажатии трех полосочек в левом верхнем меню) не совпадает с порядком иконок на сером фоне в разделе главная. В первом случае это wi-fi - инстернет - система - приложения. Во втором: система - wi-fi - интернет - приложения. При этом в одном случае система это гаечный ключ, а во втором - шестеренка. Немного путает и выглядит небрежно, хотелось бы единообразия. 2. Если вызвать меню с синим фоном по нажатию на три полоски в левой верхней части экрана - то выйти из этого меню можно только нажатием на какой-то из его пунктов. При этом само меню не закрывает весь экран, а оставляет справа поле, на котором видно часть страницы, с которой вышел на это меню. При нажалии на это поле переключаются какие-то почти полностью перекрытые синим меню пункты в нем, а по логике архитектуры меню apple при нажатии на это поле сначала должно скрываться синее меню. То есть не должны быть одновременно активны для пользователя два слоя - меню и старой страницы. При нажатии на часть старой страницы - должно скрываться синее меню, а не нажиматься на 90% перекрытые кнопки на старой странице. Спасибо!

Это не автозамена. Это наконец-то завезли правильные русские кавычки в русскую раскладку на айфоне.

Полностью выгрузите приложение на айфоне двойным нажатием на home и свайпом приложения вверх. После этого должно нормально сконнектится. Если да - то это мой баг, и решать его нужно пока только выгрузкой, ромашку ждать бесполезно. Нужно просто приложению принудительно инициировать новый коннект при каждом разворачивании приложения, а не только при первой загрузке. Если нет - то что-то новое.

Это ваш кастом или через автообновление приходит та же прошивка? Спасибо!

А можно слегка о планах развития приложения? Безотносительно полного перехода в облако. Чтобы понимать, чего интересного ждать в ближайшие пару месяцев ) Ну и чтобы новую тему не создавать - мне кажется совершенно неправильным, что на главном экране в самой верхней части экрана - при переходе роутера на резерв указывается основное (неработающее сейчас) соединение жёлтым цветом - вместо указания активного резервного соединения зелёным. Да и очень хотелось бы видеть текущее соединение в списке роутеров. Вот тут хотя бы цветом: зелёный кружок - основное, желтый - резервное. Спасибо!