Ocelot

1. Избавиться от зашитых в коде адресов. Не всегда это возможно, но здесь скорее да, чем нет. DS18B20 умеет сообщать свой адрес (команды SearchRom / ReadRom). Пусть контроллер считывает после загрузки адреса всех датчиков. Код получится универсальный.

2. Вынести константы в EEPROM, зашить один раз, при изменении кода EEPROM не перезаписывать. У AVR за это отвечает фьюз EESAVE.

MAX431x

У слейва перепутаны местами TXD и RXD.

Мастер посылает пакеты. Слейв слушает линию, и когда видит пакет, обрабатывает его и отвечает. slave.poll() как раз отвечает за приём, обработку пакета и отправку ответного. Этот метод нужно периодически дёргать в основном цикле, по таймеру или просто так. Если мастер ничего не прислал, slave.poll() просто завершается. Все модбасные регистры отображаются в память слейва (массив au16data[]), можно их читать/писать в любой момент. Точнее, не совсем в любой, а когда не вызывается slave.poll().

Блок

if (master.getState() == COM_IDLE) {
      u8state = 0;
      u32wait = millis() + 100;       
    }

даёт задержку 100мс перед следующим опросом модбаса. В коде мастера реализован простейший конечный автомат с тремя состояниями.
1) u8state == 1 Отправка запроса
2) u8state == 2 Приём ответа
3) u8state == 0 Задержка

Кастомные символы загружаются в собственную память контроллера LCD, а там есть место только для 8 штук. Может, бывают совместимые дисплеи, допускающие больше 8 символов, не знаю.
Но никто не мешает задать сколько угодно кастомных символов и загружать их в индикатор в нужные моменты. Просто одновременно отображать получится не более 8 разных.

1. Датчику освещенности нужно сделать матовое окно или, лучше, полусферу. Посмотрите, как устроены люксметры:

В показания датчика придется вносить поправку.

2. Для датчиков температуры/влажности одной дырочки недостаточно, нужно чтобы воздух свободно циркулировал вокруг датчика. Придется сделать сетку или перфорацию, типа такой:

Поправки вносить, скорее всего, не придется. Возможно, немного ухудшится время реакции на изменение температуры/влажности.

Распишу основные плюсы и минусы архитектур, а финальный выбор - за вами.

Arduino / AVR
+ Очень низкий порог вхождения
+ Тонны документации и примеров, в т.ч. на русском
– Дорого
– Мощности хватает не на всё. Опрос десятка датчиков - нормально, а вот графический LCD, например, USB или камера - уже проблематично.
– Arduino IDE упрощает программирование ценой раздувания и замедления кода. Наверное, лучше сразу писать на чистом C/C++.

AVR32
+ Мощные
+ Легкий переход с архитектуры AVR (по крайней мере, так утверждает Atmel)
– Дорого
– Мало документации

STM32
+ На порядок мощнее AVR
+ Стоят столько же или даже меньше
+ Есть прекрасные отладочные платы (я про серию Discovery)
+ Вполне неплохо с документацией. Есть готовые руководства по "быстрому старту".
– Поддержка все-таки не такая широкая, как у AVR
– Архитектура сложна для начинающих. Это обратная сторона мощности, и тут нет ардуиноподобной обёртки, которая спасает от "выстрела себе в ногу".

Другие ARM Cortex M (например, LPC11xx)
+ На порядок мощнее AVR
+ Стоят столько же или даже меньше
– С документацией похуже, чем у STM32
– Как всякий ARM, сложны для начинающих

Raspberry Pi
+ Полноценный компьютер
+ Дешево за систему с такой производительностью
+ Можно поставить Linux и фигачить код на Питоне
– Чтобы использовать на все 100% и писать что-то низкоуровневое, нужно быть профи
– Доступен только как плата в сборе. Взять одно ядро и использовать в своей разработке? Забудьте.

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

Подойдет. Общаться с ним через UART.
Datasheet на железо: docs.mirifica.eu/Neoway.com/archive/M590/Neoway%20...
Описание команд: 2150692.ru/files/neoway_m590_at_command_sets_v3.0.pdf

Внимание! Модуль трехвольтовый, подавать на пины 5В напрямую нельзя, нужен согласователь уровней.