Это понятно, ну все-равно не посмотрю красивый график и т. д. Возможно, пользователь хотел бы под себя сделать интерфейс на локальном компе, смотреть именно то, что ему надо и обрабатывать/реагировать на данные именно как ему надо.
И все-таки не до конца понял, если в работе зонт возникнут проблемы или необходимо будет его временно отключить, то потребуется установить перемычку?
тут надо понимать, что компания-разработчик всё же не одним зонтом и частными заказами занимается - у них сервера обрабатывают тысячи корп клиентов по разным продуктам. поэтому хочется верить, что серверные мощности защищены он подобных проблем. по крайней мере за всё время использования зонта я не наблюдал ни одной проблемы на серверной части. Достаточно будет соединить провода, которые от котла идут к зонту.
Подскажите пожалуйста, в 113.50 работают 10е доли градуса в режимах: "эконом", "антизаморозка", "рассписание"?
У нас предлагается решение с резервным управлением на SMS и голосовым меню. Решение со сторонними серверами не предусматривается. Пример, многие используют облачную почту, email. Да, бывают сбои, но короткие и очень редкие. Используют потому, что дешево, даже бесплатно.
Я и не говорю о готовом решении для локальной рабочей станции. Просто достаточно понимать как расшифровывать данные, посылаемые на сервер, а конечный пользователь пусть с ними дальше разбирается и пишет ПО под свои нужды, тем более, что возможность для смены ip адреса и порта в зонт заложены и никаких дополнительных затрат от разработчика не требуется. Только вот вряд ли разработчик выложит как именно расшифровывать данные от зонт к серверу. Т. е. если устанавливать зонт у людей, далеких от котлов и схем (грубо у бабушки), то есть смысл сделать переключатель: В первом положении провода от котла подключены к зонт и котел работает от зонт. Во втором положении, провода от котла будут замкнуты между собой (как перемычка на плате котла) и котел работает в своем штатном режиме. Верно?
Сложный вопрос. С одной стороны вы не яндекс или мейл. ру. С другой стороны могу подтвердить, что сбоев было не много и термостат в это время работает в автономном режиме. Согласен, что облачные решения позволяют упростить многие вопросы. И 6 тыр не самые большие деньги. Но вот если зонт использовать в доме еще и в качестве поэтажных термостатов - то решение будет не самое бюджетное. А вот, что реально было бы интересно, но из серии "кино не для всех" - это ввести понятие "виртуальных устройств" и чтобы можно было данные по температуре выкидывать на сервер. Может даже платный сервис. Например, я хочу подключить датчики на z-wave и вполне логично хочется эти данные условно раз в 5 минут куда-то скидывать. Чтобы потом посмотреть, что и когда происходило. Дернуть сервер по http вообще проблем не составляет. А рисовалка графиков вроде как есть уже готовая. И по этому скажите что-то
Спасибо, идея интересная. Подключать все, что можно и рисовать. Т. е. Ваше предложение - иметь публичный API для сторонних сервисов. Почему бы и нет? Кстати, кажется, есть публичные сервисы, которые берут все что им дают и рисуют. Где то на habrahabr. ru видел, если не ошибаюсь. Скоро, они выходят из производства на днях, в апреле. Допиливается веб-интерфейс. Есть программисткие технические трудности. Можно 5 проводных + 5 радио.
Верно, но такого подключения я ни разу не встречал, равно как и сообщений о поломках Зонта. Проще, да и логичнее - параллельно с Зонтом к котлу подключить механический термостат, который замыкает контакты при падении температуры. Когда всё нормально - термостат установлен на темп ниже, чем рабочая Зонта. Если вдруг Зонт сломается и темп начнёт падать - механический подхватит котёл и не даст всему промёрзнуть. Ну и заодно если бабушка замерзнет - она сможет сама крутануть механический термостат на "потеплее". Следует понимать, что при этом возможность регулировки Зонтом пропадёт - ведущий термостат тот, на котором выше температура.
@kam711, Согласитесь, описанных Вами потребностей, достаточно было бы выложить протокол передачи данных от девайса к серверу. Тогда каждый мог сделать бы под себя (или запрсить у программистов) любую хотелку и реагировать на нее так, как ему хочется, а не как хочет стандартный сервер.
Насколько я понимаю трудности больше к вебу. Может тогда сделать вторую группу на 5 датчиков и на сайте задавать к какой группе датчики относятся?
А кто говорил, что обязательно должен быть открытый протокол? Это коммерческий продукт - люди тратятся на разработку - должны как-то отбивать деньги. Конечно хотелось бы иметь что-то подобное opensource, но согласитесь - это уже о другом.
@kam711, на данный момент производитель бесплатно предоставляет веб мониторинг, каким способом с этой стороны (со стороны передачи данных на сервер) отбиваются деньги? Деньги отбиваются только на продаже устройства - как я понимаю. На мой взгляд, наоборот, было бы гораздо интереснее купить такое устройство с открытым протоколом и пользователю затачивать под свои нужды + например, оставить свой сервер кому не охота заморачиваться. Если только производитель не планирует в будущем сделать платным веб мониторинг, тогда да, есть смысл скрывать протокол.