eralde

@Axl Проблема понятна, можно вашу текущую конфигурацию поправить так, чтобы веб-интерфейс её дальше нормально обрабатывал: - откройте, пожалуйста, WebCLI в веб-интерфейсе роутера (my.keenetic.net/a) - введите все команды из списка ниже по очереди на вкладке Parse, после ввода каждой нажимайте кнопку "Отправить запрос" no schedule rebootrouter no schedule scheduleNaN schedule schedule0 description "Reboot router" action start 58 4 * action stop 59 4 * exit schedule schedule1 description "Интернет (Ночь)" action stop 0 1 * action start 0 8 * exit system reboot schedule schedule0 system configuration save - дальше можно попробовать посоздавать через веб-интерфейс расписания и убедиться, что это нормально работает

Стало намного понятнее, спасибо! Ваши файлы скрытым сообщением я тоже вижу. Подождите, пожалуйста, пока сбрасывать роутер. Веб-интерфейс, похоже, некорректно обрабатывает вашу конфигурацию, не думаю, что сброс поможет. Прямо сейчас можно попробовать вот что: - удалить через CLI расписание, которое вы там создали (или вообще все уж созданные: no schedule {name}) + сохранить конфигурацию (system configuration save) - создать несколько расписаний через веб-интерфейс (это должно нормально сработать) - создать через CLI доп. расписание заново (думаю, что оно и в этом случае пока будет отображаться в веб-интерфейсе без названия)

Выложите self-test или startup-config скрытым сообщением, пожалуйста.

Расписаний можно создать много (точно больше двух). Создание расписаний через веб-интерфейс не должно стирать расписания, созданные через CLI. Опишите, пожалуйста, пошагово, что вы делаете в веб-интерфейсе, что ожидаете получить и что происходит на самом деле. И приложите, пожалуйста, self-test или startup-config отдельно скрытым сообщением (лучше всего тот, где ещё ничего не затерто).

Продолжать запрашивать список статей БЗ, если пользователь решил их не смотреть, конечно, большого смысла не имеет. Это хорошее замечание, спасибо Но вот, чтобы устройству прям "поплохело" от такого... С текущим API, на самом деле, вообще не очень понятно, что будет возвращаться в ответ на запросы из первой попытки, если запросить список статей из базы знаний ещё раз (создав, вторую попытку). Со стороны пользователя API (веб-интерфейса) понять для какой попытки будут приходить данные нельзя, потому что все запросы -- это GET rci/webhelp/v2/ui-notes без дополнительных параметров. Я бы сказал, что каждое открытие всплывающей подсказки приводит к тому, что: - фоновый процесс "опроси базу знаний" в прошивке перезапускается - его статус опрашивается чаще (в веб-интерфейсе остаются опрашивающие "хвосты" от предыдущих попыток) Думаю, что браузер в лимит допустимых запросов в единицу времени упрется быстрее, чем устройству действительно поплохеет, даже в случае 7628

Спасибо за репорт! Меню с настройками в мобильной версии нужно, конечно, скрывать

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

Выглядит как лишняя граница, которая не нужна. Спасибо за репорт! Уберем

Есть подозрение, что это "само исправилось" при переделке диалогов

Как вы верно заметили, данные кэшируются. Список компонентов веб-интерфейс запрашивает через команду 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