Если бегуны стартуют по очереди, каждому можно присвоить свое имя. Эти данные затем отображаются на графиках, что делает анализ результатов более наглядным.
2. Разделять забеги по группам:
Вы можете разбивать забеги на категории, например, 100, 200 или 500 метров. При экспорте данных на сайт каждая группа будет отображаться в виде отдельных графиков.
3. Замерять забеги с несколькими участниками:
Система поддерживает забеги, где сразу участвуют несколько спортсменов. Например, если на финиш одновременно прибегают 5 человек, таймер фиксирует время каждого участника индивидуально.
4. Сейчас в разработке NFC-метками:
Каждая метка будет содержать имя спортсмена. Метку можно будет наклеить, например, на велосипед. В будущем тренеру будет достаточно поднести телефон к метке, чтобы автоматически записать данные спортсмена в систему.
Если следовать инструкции - включить IoT-устройство и сразу зайти на сервер для настройки - никаких проблем возникнуть не должно.
Что касается вашей идеи с трёхходовкой, она кажется излишне сложной. Проще дать возможность каждому устройству задавать уникальное имя. Когда клиент заходит на сервер, и если сервер обнаруживает несколько устройств с одинаковым IP-адресом, система может запросить имя устройства, а затем сопоставить его с данными.
Мы применяли подобный подход в прошлом году, устанавливая около 15 сенсоров на одном из заводов. Эти сенсоры мониторят оборудование и передают свои локальные IP-адреса на сервер предприятия. На сервере мы настроили удобную панель, где отображается весь список устройств и графики с данными, которые сервер подтягивает по локальным IP адресам. Такой подход отлично зарекомендовал себя. Нужен новый сенсор? Просто включил, подключил к роутеру сети - и он сразу появляется на сервере, готовый к работе. Забегая вперёд и отвечая хейтерам: сохранять историю данных в техническом задании не было. Нужно отображать только актуальные, свежие данные в режиме реального времени.
К сожалению среди наших клиентов mDNS в среднем работает только у 60% пользователей. Конечно эти цифры могут варьироваться в других случаях, но у нас статистика именно такая. Объяснять оставшимся 40% клиентов, почему технология не работает, особенно когда их количество исчисляется тысячами, превращается в крайне трудоемкую задачу.
Вы, вероятно, не совсем внимательно прочитали статью. Проблемы с тем, что устройство находится за NAT, на самом деле нет. IoT-устройство, подключённое к вашей WiFi-сети, может определить свой локальный IP-адрес (например, 192.168.3.2) и отправить его на сервер (onclick.lv) через GET-запрос.
Сервер при этом сохраняет два параметра: локальный IP, который отправило устройство, и глобальный IP, с которого пришёл запрос.
Когда потом вы заходите на сайт (с той же сети), сервер видит ваш глобальный IP-адрес, сравнивает его с сохранёнными данными и проверяет, были ли запросы от IoT-устройства с этим же глобальным IP. Если совпадение есть, сервер может показать вам локальный IP-адрес устройства, который был передан ранее.
На самом деле существует несколько подходов к реализации Captive Portal. :) Ваш подход тоже вполне рабочий, но мы остановились на использовании локального IP 192.168.4.1 и библиотеки DNSServer.
На устройствах Android и iOS, Captive Portal срабатывает благодаря особенностям операционных систем, которые проверяют доступ к интернету, отправляя запросы, например, на connectivitycheck.gstatic.com. DNSServer перехватывает такие запросы и перенаправляет их на локальный сервер 192.168.4.1, обеспечивая корректную работу Captive Portal. Кстати, по аналогичному принципу работает WiFiManager, который является отличным конкурентом вашему продукту. :)
Что касается POST обновлений, я с вами полностью согласен. Однако речь здесь идет о новых пользователях, а не об обновлении существующего кода.
Да, это неплохое решение, но среди наших клиентов mDNS в среднем работает только у 60% пользователей. Эти цифры могут варьироваться в других случаях, но у нас статистика именно такая.
Так же хочется поговорить о кнопках Translate, Paste, Clear. Как правильно заметил vadimbelyaev они не переводятся в зависимости от выбранного языка интерфейса в программе. Они были написаны на английском т.к. на русском кнопки Перевести Вставить Удалить, достаточно длинные что на мой взгляд не совсем рационально. — Другими словами, некрасиво смотреться такие длинные кнопки. Заменять их рисунками тоже не хотеться. Как вы считаете, что мне с ними делать?
Может все такие стоит их перевести на русским как и не заморачиваться больше по этому поводу?
Что касается 5-ого пункта. Я о этом не задумывался. Действительно, хотеться услышать ответ на этот вопрос от жителей Хабра. Могу ли я использовать название для программы Google Translate by privet.lv?
Ответил выше вам. Спасибо за интерес к проекту.
На текущем этапе система позволяет:
1. Фиксировать имена спортсменов:
Если бегуны стартуют по очереди, каждому можно присвоить свое имя. Эти данные затем отображаются на графиках, что делает анализ результатов более наглядным.
2. Разделять забеги по группам:
Вы можете разбивать забеги на категории, например, 100, 200 или 500 метров. При экспорте данных на сайт каждая группа будет отображаться в виде отдельных графиков.
3. Замерять забеги с несколькими участниками:
Система поддерживает забеги, где сразу участвуют несколько спортсменов. Например, если на финиш одновременно прибегают 5 человек, таймер фиксирует время каждого участника индивидуально.
4. Сейчас в разработке NFC-метками:
Каждая метка будет содержать имя спортсмена. Метку можно будет наклеить, например, на велосипед. В будущем тренеру будет достаточно поднести телефон к метке, чтобы автоматически записать данные спортсмена в систему.
Если следовать инструкции - включить IoT-устройство и сразу зайти на сервер для настройки - никаких проблем возникнуть не должно.
Что касается вашей идеи с трёхходовкой, она кажется излишне сложной. Проще дать возможность каждому устройству задавать уникальное имя. Когда клиент заходит на сервер, и если сервер обнаруживает несколько устройств с одинаковым IP-адресом, система может запросить имя устройства, а затем сопоставить его с данными.
Мы применяли подобный подход в прошлом году, устанавливая около 15 сенсоров на одном из заводов. Эти сенсоры мониторят оборудование и передают свои локальные IP-адреса на сервер предприятия. На сервере мы настроили удобную панель, где отображается весь список устройств и графики с данными, которые сервер подтягивает по локальным IP адресам. Такой подход отлично зарекомендовал себя. Нужен новый сенсор? Просто включил, подключил к роутеру сети - и он сразу появляется на сервере, готовый к работе.
Забегая вперёд и отвечая хейтерам: сохранять историю данных в техническом задании не было. Нужно отображать только актуальные, свежие данные в режиме реального времени.
К сожалению среди наших клиентов mDNS в среднем работает только у 60% пользователей. Конечно эти цифры могут варьироваться в других случаях, но у нас статистика именно такая. Объяснять оставшимся 40% клиентов, почему технология не работает, особенно когда их количество исчисляется тысячами, превращается в крайне трудоемкую задачу.
Вы, вероятно, не совсем внимательно прочитали статью. Проблемы с тем, что устройство находится за NAT, на самом деле нет. IoT-устройство, подключённое к вашей WiFi-сети, может определить свой локальный IP-адрес (например, 192.168.3.2) и отправить его на сервер (onclick.lv) через GET-запрос.
Сервер при этом сохраняет два параметра: локальный IP, который отправило устройство, и глобальный IP, с которого пришёл запрос.
Когда потом вы заходите на сайт (с той же сети), сервер видит ваш глобальный IP-адрес, сравнивает его с сохранёнными данными и проверяет, были ли запросы от IoT-устройства с этим же глобальным IP. Если совпадение есть, сервер может показать вам локальный IP-адрес устройства, который был передан ранее.
Откроет последний запущенный.
На самом деле существует несколько подходов к реализации Captive Portal. :) Ваш подход тоже вполне рабочий, но мы остановились на использовании локального IP 192.168.4.1 и библиотеки DNSServer.
На устройствах Android и iOS, Captive Portal срабатывает благодаря особенностям операционных систем, которые проверяют доступ к интернету, отправляя запросы, например, на connectivitycheck.gstatic.com. DNSServer перехватывает такие запросы и перенаправляет их на локальный сервер 192.168.4.1, обеспечивая корректную работу Captive Portal. Кстати, по аналогичному принципу работает WiFiManager, который является отличным конкурентом вашему продукту. :)
Что касается POST обновлений, я с вами полностью согласен. Однако речь здесь идет о новых пользователях, а не об обновлении существующего кода.
Да, это неплохое решение, но среди наших клиентов mDNS в среднем работает только у 60% пользователей. Эти цифры могут варьироваться в других случаях, но у нас статистика именно такая.
Хм. Они залиты компаундом?
Да, наверное, стоит об этом задуматься. Однако за эти несколько месяцев у нас не было таких казусов.
Sonoff запоминает текущий баланс кошелька (в памяти). Если он увеличивается на стоимость кофе, реле включается, и баланс обновляется.
webdesignerwall.com/tutorials/5-useful-css-tricks-for-responsive-design
Может все такие стоит их перевести на русским как и не заморачиваться больше по этому поводу?
Что касается 5-ого пункта. Я о этом не задумывался. Действительно, хотеться услышать ответ на этот вопрос от жителей Хабра. Могу ли я использовать название для программы Google Translate by privet.lv?