eralde

Как вы верно заметили, данные кэшируются. Список компонентов веб-интерфейс запрашивает через команду components list. Команда отправляет запрос от Кинетика на сервер, где с прошивками. Последний ответ на запрос к серверу кэшируется на стороне Кинетика. Попробуйте увеличить время жизни кэша, используя команду components validity-period. Список компонентов запрашивается и на других страницах интерфейса (например, на дашборде), т.е. у большинства людей в кэше ответ для этой команды будет лежать практически сразу. Безусловно, есть сценарий "заблокировал доступ к серверу обновлений отключил Кинетику Интернет -> открыл браузер -> зашел на страницу Приложения", в котором приходится ждать, пока запрос к серверу отвалится по таймауту, но он, на мой взгляд, является достаточно редким. Улучшить можно, подумаем. Пока предлагаю поиграть с настройкой validity-period.

Похоже, что возникла какая-то несостыковка между тем, что ожидает код веб-интерфейса и что возвращает API прошивки. Ожидайте исправления, пожалуйста.

Из этого, правда, никак не следует, что новый должен оставаться неудобным

Будет очень здорово, если вы добавите пару скриншотов для сравнения "было"/"стало"

@yvazik я удалил self-test из вашего сообщения. Ваш селф-тест загружен отдельным сообщением, скрыт и доступен теперь только модерaторам. Публикация селф-теста в открытом доступе может быть небезопасна, поэтому обязательно скрывайте такие сообщения (три точки в верхнем правом углу -> скрыть).

@vasiliy777 поскольку вы написали о проблеме, вас упомянут в ченджлоге, когда появится исправление.

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

Спасибо, интересно, я про такую функцию даже не знал Нужно изучить вопрос.

@keenet07 @FLK я не спорю с тем, что обсуждаемая тема может быть интересно большему числу людей. Предлагаемое решение (как и любая другая фича), если договориться, что она реализуется, требует: - разработки - поддержки после внедрения И по результатам программистам, конечно, очень хочется, чтобы вышло то, чем кто-то реально будет пользоваться. У меня есть опыт разработки браузерного расширения, которое что-то меняло в интерфейсе (так, как это казалось разумным мне и группе самых активных пользователей). Потраченные усилия (суммарно) -- это несколько человеко-месяцев (не 1-2, а больше). Максимальный размер аудитории (судя по скачиванию расширения из Chrome Web Store): ~ 100 человек. Поэтому, @keenet07 упрекать меня в том, что я не бросаюсь сразу делать конструктор стилей в интерфейсе можно, конечно. Но, кажется, более продуктивно будет поискать людей, которым такой конструктор поможет, и предложить им обсудить, как они себе такой конструктор представляют.

На моих Android-устройствах и с вашей версией Yandex Lite проблему воспроизвести не удается. Можно попробовать обновить Yandex Lite до последней версии или подождать, пока будет исправлена та проблема, которая возникла у @vasiliy777.

Если бы стояла задача сделать конструктор для пользователя, то такое решение выглядело бы вполне разумным. В текущих реалиях (и с учетом того, что в этой теме активны только три человека) я пока не вижу, чем расширение для браузера существенно хуже.

Спасибо, теперь понятно, как воспроизвести проблему. Проблема воспроизводится. Как поправить мне тоже понятно. @Winterfury исправление для Brave должно помочь и вашей версии Хрома тоже. @valery.vn нет гарантий, что в браузере на базе Chrome 86 все заработает. @KeyYerS и на эмуляторе Android-устройства, и на физическом телефоне прокрутка в Yandex Lite нормально работает. В стабильной 4.2 так же, как в 4.3.

Именно так

Все правильно. Насколько я помню, так же было сделано и в предыдущей версии веб-интерфейса.

Если Wi-Fi-система состоит из одного устройства, то показывать, через какой узел подключен клиент -- это точно лишнее (через текущий ). В моей домашней системе текст "через ... " отображается на 4.3 Beta 2:

Сейчас тема (светлая/темная) -- это примерно три сотни CSS-переменных. Плюс, некоторые переменные используются сразу в нескольких местах, т.е. можно напороться на то, что меняешь что-то на свой вкус в одном месте и автоматически получаешь конфликт в другом. Я с трудом представляю, как эту конструкцию сделать проще для широкого круга пользователей. Начать стоит, конечно, с того, чтобы сделать её проще саму по себе. Можете сами в консоли разработчика поиграться и посмотреть, что будет: Screen Recording 2025-02-27 at 21.15.06.mov

Спасибо за репорт! Проверка сложности пароля будет со временем улучшена

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

@vasiliy777 чтобы понять, что не работает в вашем браузере, нужно для начала научиться устанавливать именно эту версию браузера. Как это сделать? Если вам известны другие браузеры, подверженные такой же проблеме -- напишите их названия/версии, пожалуйста.

Возьмите тот запрос, которым создавали маршрут, и допишите "no": true внутрь объекта с IP/маской/интерфейсом: { "ip": { "route": { "no": true, "network": "199.199.199.199", "mask": "255.255.255.255", "interface": "Wireguard0" } } }

Веб-интерфейс работает с тем набором данных, которые ему отдает прошивка конкретного устройства (контроллера, ретранслятора). В текущих версиях прошивки информации о клиентах, подключенных к ретранслятору по проводу, нет ни на ретрансляторе, ни на контроллере. Когда ретрансляторы научатся отдавать список своих проводных клиентов контроллеру, веб-интерфейс будет отображать верные данные. Работа в этом направлении идет.

Новость заключается в том, что команду system debug и вкладку в веб-интерфейсе удалили совсем, потому что команда "запустить отладку всего" не нужна практически никогда, но создает черезмерную нагрузку на систему.

Веб-интерфейс показывает MAC-адрес из выдачи show ip hotspot. @Le ecureuil

Приложите скриншот всей таблицы целиком, пожалуйста.

Система команд для работы с правилами МСЭ в прошивке устроена довольно своеобразно. Она проектировалась в тот момент, когда никакого JSON API для веб-интерфейса ещё даже не планировалось. Веб-интерфейс использует JSON API везде более-менее стандартным образом (позволяющим, в частности, объединять несколько команд в один HTTP-запрос). В случае с правилами МСЭ есть выбор: использовать тот же самый стандартный способ или добавлять "костыли", позволяющие обойти особенности системы команд. Мы выбрали первый вариант, поэтому, как вы верно заметили, результат получается тот, который хочет пользователь, но система вдобавок генерирует сообщения об ошибках. Ошибки no input можно смело игнорировать, если правила сохраняются корректно. Ошибки system failed имеет смысл починить, конечно. Есть вероятность, что со временем удасться побороть ошибки полностью. Спасибо за репорт!