Тогда есть еще более олдовый способ. Берем дешевый калькулятор, припаиваем провода счетчика параллельно кнопке «равно», набираем изначальное значение счетчика, затем «плюс» и 0,01, наслаждаемся цифровым индикатором. К сожалению, как и велокомп, калькулятор будет засыпать в перерывах. Но самый существенный недостаток не в этом, а в том, что это фактически просто второй индикатор, он не дает особых преимуществ, ну, разве что его можно вынести в более удобное место. Тогда как описанный в статье способ позволяет делать с данными что угодно. Можно смотреть их на мобилке, можно строить графики потребления по времени, можно даже попробовать отправлять данные водоканалу автоматически.
То есть он на каждом обороте немного смещается и получается, что срабатывание происходит, условно говоря, на 0,9 оборота? Просто не могу представить как оно так может чисто механически. Я себе представляю, что там на колесике закреплен магнит, а рядом с колесиком стоит геркон. Как в такой системе может быть дрейф — ума не приложу. Надо на своих счетчиках попробовать последить.
А чем это мешает? Ну небольшой дрейф, но на один оборот мнадшего разряда срабатывание все равно один раз. А вот дребезг контактов, мне кажется, может создавать проблему, особенно при медленном вращении счетчика, когда геркон относительно долгое время находится в состоянии на грани.
Учитывая, что электричество пропадает довольно редко и ненадолго, то в качестве аварийного питания на долгое время хватит и обычных батареек, включенных через диод. А если озаботится сном контроллера и побудкой по прерыванию, то о них, наверное, можно забыть на годы.
Мне кажется, лучше число срабатываний геркона хранить в самой ардуине и передавать каждый раз на сервер не сам факт увеличения показаний на единицу, а значение счетчика целиком. Это позволит избежать расхождения показаний, когда сервер по какой-то причине не может принять данные: завис, обслуживался, отключился свитч и т.д.
По-моему, это ужасная аналогия. Понять суть состояний электропитания не сложно и так, а эта аналогия запутывает, не понятно, что конкретно (в процессоре, а не в придуманном офисе) отключено в том или ином случае. Ничего интуитивного я тут не вижу. И тем более аналогия не позволяет легко запомнить какое из состояний какое. Что такое C6? Я уже забыл.
Да, прошли те времена, когда Макдоналдс ценился как сеть бесплатных туалетов. Теперь это бесплатный вайфай.
Вообще не понимаю этой гонки за вайфаем, мне обычно хватает мобильного интернета, а публичный вайфай слишком легко компрометируется.
Суд решит, что такая точка является публичной, всего и делов. И даже не потому, что суд плохой, а потому что задача суда решать спорные вопросы. Вот описанный случай с точкой в универе гораздо сложнее. Но и он может быть разрешен. Например, сначала суд предупреждает, что точка должна быть лучше защищена, либо отключена, а в случае рецидивов ответственность по полной.
Но ведь эта игра, несмотря на то что не вышла, является объектом защиты авторских прав. Собственно именно потому она у него и оказалась. Так какого черта он собирается с ней делать?
Обрезать можно, это меньшая из проблем. Можно в конец пароля добавить еще и комбинацию из цифр и букв, которая покрыла бы и другие ограничения. Но все равно найдется какой-нибудь сайт, который потребует, чтобы пароль не начинался с цифры, например. Или чтобы буквы не повторялись.
Ну и когда пароль нельзя задать все это вообще не поможет. Потом, аккаунт это не только пароль, обычно еще и идентификатор юзера, который тоже нужно помнить. И тут ограничений бывает еще больше чем на пароли.
А бывает, что надо хранить гораздо больше данных. Например, реквизиты банковской карты: номер карты, владелец, срок действия, CVV, PIN и все эти данные нельзя сгенерировать, они предопределены.
А бывает, нужно хранить несколько связанных аккаунтов. Допустим есть у меня хостинг. Это аккаунт у хостера и всякие аккаунты от БД, FTP, SSH.
В общем, у меня сотни разных паролей и как жить без хранителя паролей, я не представляю.
Серьезный минус по сравнению с хранителями паролей — невозможность применения в системах, где нельзя задать произвольный пароль (допустим он генерируется и сообщается вам), а также в системах, которые предъявляют определенные требования к паролю. Последнее сплошь и рядом: требуют определенную длину, наличие букв разного регистра, цифр, символов. Ваш алгоритм всегда дает на выходе строку из 32 букв и цифр и такой пароль много где не прокатит.
Мой хранитель паролей делает резервную копию базы при каждом запуске и хранит какое-то количество последних копий. А сама база лежит в дропбоксе, в котором есть версионность файлов. Заодно разруливаются и конфликтные перезаписи открытой базы.
Вообще не понимаю этой гонки за вайфаем, мне обычно хватает мобильного интернета, а публичный вайфай слишком легко компрометируется.
Ну и когда пароль нельзя задать все это вообще не поможет. Потом, аккаунт это не только пароль, обычно еще и идентификатор юзера, который тоже нужно помнить. И тут ограничений бывает еще больше чем на пароли.
А бывает, что надо хранить гораздо больше данных. Например, реквизиты банковской карты: номер карты, владелец, срок действия, CVV, PIN и все эти данные нельзя сгенерировать, они предопределены.
А бывает, нужно хранить несколько связанных аккаунтов. Допустим есть у меня хостинг. Это аккаунт у хостера и всякие аккаунты от БД, FTP, SSH.
В общем, у меня сотни разных паролей и как жить без хранителя паролей, я не представляю.