Шаблон интерфейса - включение по температуре

[stD]

снять показания и отправить данные "куда следует".

Это как вариант, например писать в БД и забирать уже оттуда.

А почему в задачу контроллера не может входить "ответ на запрос", при условии, что это ни на что не влияет?

[vitfil]

Потому что вы никак не можете гарантировать, что этот запрос никак не повлияет на состояние контроллера. Больше скажу: вы не можете гарантировать, что этот запрос вообще дойдет до него.

[stD]

вы не можете гарантировать, что этот запрос вообще дойдет до него.

Я не только не могу гарантировать (например контроллер стоит на даче, инет плохой и часть инфы погибает) что запрос дошёл, но и предполагаю, что какие-то пакеты не долетят до ардуины.

Но это и не принципиально, ведь в интерфейсе у меня отображается только то, что выполнила ардуина.

Если писать в БД, то будет то же самое, при запросе из БД пакет может так же потерятся.
...

Мне непонятно, как запрос может повлиять на состояние контроллера. Иными словами, по Вашему получается, что нельзя у контроллера что-либо запрашивать и функция Serial.available() губительна.

[vitfil]

Я объяснил свою мысль. Возможно, мое объяснение кажется вам слишком коротким, но, к сожалению, у меня не слишком много свободного времени, чтобы сделать даже небольшой курс по распределенным системам. Предложенная мной архитектура подкреплена и теоретическими знаниями, и практическим опытом. Ваш путь тоже имеет право на существование. Как известно, в ИТ существует множество верных решений одной задачи, особенно когда оптимальность решений уходит на второй план.

[stD]

Я объяснил свою мысль

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

Я повторюсь, мне не понятно, почему нельзя запрашивать у контроллера данные? Какая разница, отдаёт он их сам или по запросу?

ПС
Если Вы обладаете знаниями и нашли время читать форум, то поделитесь.

[vitfil]

Сообщение от mebitek

Я повторюсь, мне не понятно, почему нельзя запрашивать у контроллера данные? Какая разница, отдаёт он их сам или по запросу?

Да кто ж вам сказал, что нельзя? Просто это не совсем кошерно. Подумайте, что будет, если вам потребуется добавить еще две ардуинки? А если двадцать? А если ардуинки управляют неким устройством крайне редко меняющим статус, для чего их постоянно опрашивать? Пускай она сама сообщает об изменении статуса.
Еще раз повторю, что идея, когда сервер опрашивает все периферийные устройства (активные, умеющие сами "думать") не совсем кошерна. Это приводит нас к тому, что на сервере должна быть куча заданий с кучей расписаний. Управлять этим хозяйством будет становиться все сложней, логика будет все разухабистей.
Можно ли так делать? Можно, конечно, но стоит ли?..

[melsem]

Сообщение от vitfil

Подумайте, что будет, если вам потребуется добавить еще две ардуинки? А если двадцать?

А что получит сервер если одновременно будут отправлять, если совпадет? И чем их больше то выше вероятность? Или на ардуйны время цеплять?

Не проще ли по разным идентификаторам, как по типу ds1820? Опросил одну, ответила обработал и все.
В скетче к ардуйнам править, только один-два символа идентификатора.
Да и сервер не будет загружен постоянным слушанием порта.

[stD]

Спасибо.
Я Вас понял, Вы мыслите более масштабно.

Когда я это придумывал, мне было необходимо делать постоянный опрос с маленьким интервалом. В частности, началось всё с загородной теплицы.

Если позволите, ещё вопрос?
В приведённом Вами примере:

unsigned long current_time = millis();
int time_elapsed = (current_time > time) ? (current_time - time) : (MAX_MILLIS - time + current_time)
if (time_elapsed >= 120000) {
time = current_time;
...
}

Переменная time_elapsed объявлена как int, то есть, не больше 32767, но ведь тут...

time_elapsed >= 120000

Это опечатка или я что-то не доглядел?

[vitfil]

Действительно, опечатка закралась...

[stD]

Спасибо.