Ещё есть проблема когда риэлторы приглашают кучу людей на одно и тоже время. И иногда доходит до скандалов.

Во всей этой теме вижу огромную проблему в расставленных акцентах — самый важный тут это арендодатель, а самый безправный арендатор, хоть он и предлагает живые деньги. Должно быть наоборот. Есть рынок жилья, где владельцы конкурируют между собой за клиента. Клиент онеспеша выбирает себе наилучший вариант. Так вижу.

тогда немного подскажу как сделать самому:
— Кран шаровый с электроприводом с возможностью ручного управления. Линк где взять кидал выше.
— Датчик влаги типа этого: rozetka.com.ua/neptun_sw003/p296094
— I/O модуль типа этого: www.commbox.com.br/htm/produtos_mio.php. С помощью него ты сможешь управлять кранами и получать сигналы о сработке датчиков через Ethernet порт. Тот что я скинул имеет достаточно низкоуровневый API и доку на португальском. Лучше поищи такой же, но с веб сервером на борту, чтобы не парсить байт эррей:-(
— Raspberry Pi 2 Model B (raspberry.com.ua/...y-pi-2-model-b-armv7-1gb) — если предполагается некая логика автоматизации.

ЗЫ: у меня у самого ремонт в разгаре так что спрашивай если че;-)

По поводу антипротечек:
— почти все российского производства (для меня критично)
— система состоит из трех частей: краны перектрытия, датчики влаги и централи.
— я так и не нашел системы с открытым SDK чтобы интегрировать в общую систему дома.
— краны стоят по 70евро, а надо их не только на хол/гор воду, но и на все батареи. (например: armakip.kiev.ua/...vyj-elektroprivodom.html
— датчик влаги очень похож на комп.мышку и их нужно разбросать по местам возможных протечек. это мерзость.
— время сработки одного крана до 30 секунд.
— куча дополнительной проводки, которую еще нужно объяснить строителям. есть варианты беспроводной системы, но это постоянно менять батарейки.

В качестве альтернативы я бы посоветовал в сан узле сделать трапики в полу. На счет комнат с батареями — возможно гидроизоляция.

ЗЫ: поставь камеру за входной дверью, и если уж совсем круто — там где паркуешь машину. я себе такую купил: rozetka.com.ua/...n_ds_2cd2432f_iw/p699374 и NVR к ней rozetka.com.ua/...n_ds_7104ni_sn_p/p701184. Для NVR-а есть SDK правда на C++.

ЗЗЫ: я решил пропагандировать измельчители пищевых отходов. Вот мой: bt.rozetka.com.ua/...or-evolution-100/p149291. Правда стоил дофигища.

Тема реально интересная. Хочу поделиться фишками со своего проекта.

Юзаем log4net, но там нет Trace левела и поэтому в новых проектах стараюсь использовать NLog.

Вот дефиниция лог-левелов:
*Trace — very detailed logs, which may include high-volume information such as protocol payloads. This log level is typically only enabled during development.
*Debug — debugging information, less detailed than trace, typically not enabled in production environment.
*Info — information messages, which are normally enabled in production environment.
*Warn — anything that can potentially cause an application limitation, such as license expiring, switching from a primary to backup server, retrying an operation etc. Usually an automatic recovery is defined for such situations.
*Error — any error fatal to the operation but not to the application itself such as, cannot open file, missing data, input data format incorrect, etc.
*Fatal — any error that forces application to shut down and may result in data corruption or loss.

А вот формат лог-сообщения:

<date> <time> [<process_id>] [<thread_id>] <log_level> <logger_name> — Message (<message_token>) <direction> <source target="">. Details — <message_details>

Where:
 <process_id> — is the id of the process in which the message was processed. Useful in multiprocess applications.
 <thread_id> — is the id of the thread in which the message was processed. Useful for multithreading applications.
 <log_level> — is one of the possible NLog log levels.
 <message_token> — is a random six digit number which identifies the message chain. Application may receive some event, do calculations and send it further in different thread. To be able to trace this chain, all messages in a single chain will have the same token.
 <direction> — is the direction of the message. Could be: FROM, TO.
 <source target=""> - usually a component name. Depending on <direction> this parameter shows the source or target component for this message.
 <message_details> — specific message information.

Для анализа логов использую Hoo Win Tail (www.hootech.com/WinTail ). Там есть подсвтка по ключевым словам, а главное фильтрация. И я могу отфильтровать любую цепочку сообщений или все сообщения на входе компонента, или все что компонент отправил и т.д.

В завершение скажу — так как мой проект занимается системами безопасности, то о ремоут дебагинге просто не может быть речи. Единственная возможность анализа неисправности — логи!