Протокол для Умного Дома

[ARV]

CAN будет явно невыгодным вариантом для самопального умного дома.
я бы все-таки больше склонялся к тому, о чем в начале и писал - к USART, а для больших расстояний - классический RS232 с соответствующим драйвером. проблема сна решается костылем: если USART не будит МК сам по себе, можно настроить прерывание по уровню/фронту INT0/INT1, соединить пин RX с пином запроса этого прерывания, а в протоколе предусмотреть, что перед передачей рабочего пакета мастер посылает 1 байт для пробуждения. ну, или как-то так.

вопросы быстродействия явно надуманные: если у нас выключатель, то он сразу по нажатию кнопки должен свет включить, а потом, когда мастер спросит, уведомить его об этом. т.е. лампочка включится мгновенно не зависимо от того, как часто и как быстро мастер проводит "опрос" исполнительных устройств. а передача нескольких байт даже на скорости 600 бод на глаз будет давать незаметную задержку включения света по инициативе мастера...

[parovoZZ]

я бы все-таки больше склонялся к тому, о чем в начале и писал - к USART, а для больших расстояний - классический RS232 с соответствующим драйвером.

Хоть с драйвером, хоть без - это всё не дифф. пары. Соответственно, все помехи с линии прямиком в МК.

фронту INT0/INT1

фронт МК не будит, если остановлен осциллятор. А он остановлен в deepsleep: AVR это не MSP430. Тут всё по простому.

вопросы быстродействия явно надуманные

не надуманные. Очень сильно раздражет запоздалая реакция на воздействие.

[ARV]

Соответственно, все помехи с линии прямиком в МК.

и что? при наличии хоть какого-то протокола пакетной передачи данных это приведет лишь к ложному пробуждению МК в момент включения холодильника или там болгарки в той же сети. я не говорю, что защита входов МК не нужна, я говорю только о данных

фронт МК не будит

я писал по уровню/фронту - не читали? не будит фронт, ну и не надо, по уровню можно проснуться

Очень сильно раздражет запоздалая реакция на воздействие

откуда она возьмется? до 10 секунд задержки при управлении через облако никого не смущает, а до 0,1 секунды при управлении по проводу вдруг стало проблемой?!

[roman.com]

у тебя 8 жил... сделай усарт и линию побудки

Можно и так...
-Есть такая кнопочка в схеме )) Называется "sleep" - для принудительного перевода AVR в режим спячки...
-Есть и вторая кнопочка - для принудительного вывода AVR из режима спячки...
Но проблема не в этом. А в том, что надо выделять отдельные выводы AVR под эти кнопочки. А выводов у AVR ограниченное количество... А нам ещё 20 штук AVR подключать куда то надо))

Будет шина RS-485? А для неё буферный усилитель без вариантов. А жрёт он наравне с МК. Его тоже в сон? А как тогда пробуждаться?

Не будет у нас ни RS-485 ни CAN. Будет или USART или самодельный протокол.
Пока ещё не определились))

В ADSL модеме вовсе не частотное кодирование.

При чём тут вообще ADSL ? Я говорил о модеме с частотным кодированием.
Первый модем с частотный кодированием появился в далёком 1979 году...

первый модем.jpg

(189.25 КБ) 93 скачивания

Тогда ещё даже само слово "ADSL" не слышали))
Спецификация ADSL появилась только в 1987 году...

Добавлено after 1 hour 3 minutes 14 seconds:
Что лучше... USART vs САМОПАЛ )) Давайте разбираться)) Пока что USART vs САМОПАЛ - счёт 0:0 ))

А пока продолжаем "пилить" самодельный протокол))

1- AVR выходит из спячки по первому фронту импульса пакета.

пробуждение по приёму пакета.jpg

(147.76 КБ) 133 скачивания

Чтобы разбудить AVR никакие дополнительные провода тянуть не нужно. Что явный плюс в пользу САМОПАЛ))
USART vs САМОПАЛ - счёт 0:1 ))

2- После пробуждения AVR включает таймер и начинает отсчитывать время между прерываниями INT0 (Mode: Any change).
3- Синхронизация автомата приёмника RX осуществляется по синхропаузе (или межпакетный интервал, как в Ethernet).
4- Обработка пакета. По окончании передачи пакета срабатывает автомата приёмника RX. Далее AVR переходит в режим обработки пакета.
4.1- Первым делом проверяется целостность пакета (по количеству прерываний). В нашем случае должно быть 32 байт х 8 бит x 2 импульса = 512 прерываний. Если за время приёма пакета прерываний было больше 512 или меньше 512, значит при передачи пакета на линии была помеха, что привело к "лишним" прерываниям. В этом случае AVR выдаст ошибку "error_change" и пакет будет отброшен.
4.2- После проверки целостности пакета переходим к проверки контрольной суммы пакета CRC16. В случае ошибки CRC16 AVR выдаст ошибку "error_CRC" и пакет будет отброшен.

обработка пакета.jpg

(156.94 КБ) 143 скачивания

Кроме того автомат приёмника RX непрерывно следи за всем процессом приёма пакетов.
5- Если во время приёма пакета на линии возникает помеха и в результате помехи пауза между импульсами или частота импульсов не соответствует заданной (~16 кГц...40 кГц), то срабатывает автомат приёмника RX и AVR выдаст ошибку "error_RX".

ошибка передачи.jpg

(154.13 КБ) 131 скачивание

Частота импульсов может не соответствовать заданной в случае изменения частоты калиброванного RC генератора передатчика или приёмника (при изменении температуры и/или при изменении питающего напряжения). Т.к. кварца у нас нет. ))
Однако, т.к. таймер у нас перезапускается при каждом прерывании INT0 (Mode: Any change), то соответственно и требования к стабильности калиброванного RC генератора передатчика и приёмника у нас значительно ниже по сравнению с USART. Что явный плюс в пользу САМОПАЛ))
USART vs САМОПАЛ - счёт 0:2 ))


Добавлено after 5 minutes 55 seconds:
А в целом наш самодельный протокол очень похож на USART ))

автомат USART.jpg

(46.01 КБ) 96 скачиваний

таймер USART.jpg

(85.33 КБ) 95 скачиваний

Только скорость передачи у нас получилась в два раза меньше. Что явный плюс в пользу USART))
USART vs САМОПАЛ - счёт 1:2 ))

Но это скорее из-за несовершенства программы автомата RX на Си.
А писать программу автомата RX на Ассемблере (с точностью до машинного такта процессора) мне лениво))


Добавлено after 27 minutes 19 seconds:
Хотя в прошлой теме мы разгоняли AVR на Ассемблере до скорости 10 МБит/с и более... Когда делали самодельный Ethernet на AVR ))

Ethernet-Atmega8-тр.jpg

(200.93 КБ) 99 скачиваний

Что доказывает, что по скорости самодельный протокол может значительно превосходить любой USART))
Но это уже совсем другая тема))

[parovoZZ]

Я говорил о модеме

модем - это модулятор/демодулятор. Кодирование/декодирование - это кодек.

Будет или USART или самодельный протокол.

Опять спуталось тёплое с мягким. USART - это интерфейс. Т.е. физическая среда для передачи данных. Протокол - это способ передачи данных по какому-либо инерфейсу.

[roman.com]

Как скажешь))

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

0_мастер_1_слейв_гальваническая развязка_1.jpg

(52.73 КБ) 96 скачиваний

Ну или добавить в разрыв оптопару...
А можно даже и трансформатор (как в Ethernet). Будет симметричная согласованная линия. ))
Протокол частотного кодирования всё это позволяет. А вот с USART будет сложнее... Что явный плюс в пользу САМОПАЛ))
USART vs САМОПАЛ - счёт 1:3 ))

Хотя нет... ставить 20 штук трансформаторов (как в Ethernet) это уже перебор)) Обойдёмся однопроводной линией.
[uquote="ARV",url="/forum/viewtopic.php?p=4041863#p4041863"]а передача нескольких байт даже на скорости 600 бод на глаз будет давать незаметную задержку включения света по инициативе мастера...[/uquote]
Всё считается... передача пакетов по 32 байт. На скорости 600 бод (или 4800 бит/c) на глаз не будет давать заметную задержку... если слейв один и мастер один)) А если их 20 штук ?
4800 бит/c/32 байт=18 пак/c или 0,05 c. Что на первый взгляд не плохо.
А если так: 0,05 c x 20 штук = 1 c.
))
Вообще не так всё считается.)) Нет у нас бод. Нет у нас текстовых данных. Нет у нас знаков)) Нет у нас ничего)) Есть пакеты с флагами... вкл/выкл и т.д. (как в Ethernet).

[uquote="ARV",url="/forum/viewtopic.php?p=4041892#p4041892"]до 10 секунд задержки при управлении через облако никого не смущает[/uquote]

[uquote="ARV",url="/forum/viewtopic.php?p=4041892#p4041892"]до 0,1 секунды при управлении по проводу вдруг стало проблемой?![/uquote]
до 0,1 секунды - терпимо. ))

[ARV]

Всё считается... передача пакетов по 32 байт. На скорости 600 бод (или 4800 бит/c) на глаз не будет давать заметную задержку... если слейв один и мастер один)) А если их 20 штук ?
4800 бит/c/32 байт=18 пак/c или 0,05 c. Что на первый взгляд не плохо.
А если так: 0,05 c x 20 штук = 1 c.

32 байта - это вы "Войну и мир" передавать ежедневно собрались каждому МК? 1 байт адрес, 1 байт команда, 2 байта параметры команды, 1 байт контрольной суммы, пара байт начала-конца пакета - итого 7 байт - с головой и запасом на 255 ведомых МК!
ведомые исполнители типа выключателя - им не надо ничего посылать каждую секунду. для одновременного включения-выключения группы выключателей достаточно одного широковещательного пакета сразу всем. датчики, кроме охранных, чаще 1 раза в секунду опрашивать тоже не нужно. таким образом, реально в сети будет пару раз в несколько секунд проскакивать 2-3 пакета по 7 байт.

как вы считали, что на 20 исполнительных устройств у вас задержка в 20 раз увеличивается?!

Добавлено after 4 minutes 17 seconds:
при желании можно предусмотреть мультимастерный режим, но тогда аппаратная реализация общей шины будет иная, потребуются транзисторные ключи... ну и придется протокольно реализовывать процедуру захвата канала и т.п. - не сложно, но по сравнению с тупым одномастерным способом в разы сложнее

[roman.com]

1 байт адрес, 1 байт команда, 2 байта параметры команды, 1 байт контрольной суммы, пара байт начала-конца пакета - итого 7 байт - с головой и запасом на 255 ведомых МК!

Не пойдёт. Все пакеты должны быть одинаковой длины...

для одновременного включения-выключения группы выключателей достаточно одного широковещательного пакета сразу всем

Можно и бродкаст. Не проблема))

датчики, кроме охранных, чаще 1 раза в секунду опрашивать тоже не нужно.

Датчики вообще опрашивать не нужно)) Они сами должны сообщить если что...

как вы считали, что на 20 исполнительных устройств у вас задержка в 20 раз увеличивается?!

Максимально возможная задержка пропорционально количеству опрашиваемых слейвов. если в сети слейвов 20 штук, то и опрашивать надо все 20 штук. Поэтому и максимально возможная (теоретически) задержка будет в 20 раз больше...

при желании можно предусмотреть мультимастерный режим, но тогда аппаратная реализация общей шины будет иная, потребуются транзисторные ключи... ну и придется протокольно реализовывать процедуру захвата канала и т.п. - не сложно, но по сравнению с тупым одномастерным способом в разы сложнее

Есть другой вариант. Тупо подключить все слейвы к одному мастеру.

Допустим берём любую AVR типа ATmega48PA/88PA/168PA/328P.
У них можно переназначать прерывания (PCINT0...PCINT23) на любой свободный пин.

Screenshot_4.jpg

(40.67 КБ) 91 скачивание

Самодельный протокол позволяет использовать любые свободные пины AVR, а не только специально выделенные для USART. Что явный плюс в пользу САМОПАЛ))
USART vs САМОПАЛ - счёт 1:4 ))

Значит всего к одной AVR типа ATmega48PA/88PA/168PA/328P можно подключить 12 других AVR по двум провода TX и RX (т.е. 12 штук TX и 12 штук RX).
Соответственно для связи 20 штук AVR нам потребуется две AVR. Тогда схема будет такая:

0_мастер_20_слейв.jpg

(77.33 КБ) 92 скачивания

И никакие мультиплексоры не нужны))

[ARV]

как не с вами разговаривал...

Все пакеты должны быть одинаковой длины

7 байт - достаточно? ладно, 10.

Они сами должны сообщить если что

в сети, где ведущий только один, никакой датчик ничего сам по себе не сообщает, он ждет опроса

Максимально возможная задержка пропорционально количеству опрашиваемых слейвов. если в сети слейвов 20 штук, то и опрашивать надо все 20 штук.

логично. только разве все 20 слейвов надо опрашивать каждую секунду? например, датчики температуры нет нужды опрашивать чаще 1 раза в минуту. датчик освещенности - вообще 1 раз в 5 минут. датчик влажности - раз в 10 минут достаточно. какие там еще у вас датчики могут быть? исполнительные устройства вроде выключателей/диммеров вообще не нужно опрашивать, им отправляются пакеты в момент изменения состояния

откуда такая сетевая нагрузка у вас получается?!

Тупо подключить все слейвы к одному мастеру

я только об этом варианте и говорю

Самодельный протокол позволяет использовать любые свободные пины AVR, а не только специально выделенные для USART. Что явный плюс в пользу САМОПАЛ))

весьма сомнительный плюс...

Значит всего к одной AVR типа ATmega48PA/88PA/168PA/328P можно подключить 12 других AVR по двум провода TX и RX

если добавить пару буферных элементов, то можно подключить сотни 4 слейвов. без буферов в пределах 5 метров - сотню, пожалуй, тоже получится... почему 12?!

Добавлено after 4 minutes 46 seconds:
давайте считать.
20 слейвов * (10 байт запроса + 10 байт ответа) = 400 байт = 4000 бит
при скорости 9600 бит/сек опрос всех датчиков с ответами займет менее 0,5 сек

Добавлено after 4 minutes 40 seconds:
когда-то очень-очень давно я продумывал умный дом... но так и не допродумал можете почитать мои измышления, может, что-то почерпнете полезное...
http://arv.radioliga.com/downloads.any/smart_home.pdf

[roman.com]

7 байт - достаточно? ладно, 10.

Потому что проще программа... проще коммутировать... проще обрабатывать пакеты когда они все одинаковой длины.
В пакете меняется только адрес назначения Destination и адрес отправителя Source.
Всё))
1- Прилетел пакет по Ethernet 32 байта.
2- Мастер посмотрел адрес слейва (Destination) в пакете и сразу отправил пакет 32 байта нужному слейву, не разбирая сам пакет.
Мастер не тратит время на обработку пакетов. Мастер разбирает пакет только если пакет адресован самому мастеру (Destination).
И т.д. и т.п.
Весь вопрос в простоте программы коммутаторов и скорости коммутации пакетов по локалке и Ethernet.
А ещё там есть шифрование. При шифровании вообще нельзя менять длину пакетов. Иначе там вообще будет пипец))
И т.д. и т.п.
Короче это большая и долгая тема... почему все пакты должны быть все одинаковой длины.


Добавлено after 2 minutes 23 seconds:
[uquote="ARV",url="/forum/viewtopic.php?p=4042057#p4042057"]

Самодельный протокол позволяет использовать любые свободные пины AVR, а не только специально выделенные для USART. Что явный плюс в пользу САМОПАЛ))

весьма сомнительный плюс...[/uquote]
А по мне нормальный такой плюс)) Когда можно спокойно переназначать любые выводы под TX и RX для меня хороший плюс))

[NStorm]

Мелком глянул тему. ТС, если вы решили изобретать велосипед - изобретайте сами. Че вы людям голову морочите? Умный дом как будто только сейчас придумали, чтобы протоколы да интерфейс изобретать, еще и споря с теми, кто предлагает проверенные временем решения...

Самодельный протокол позволяет использовать любые свободные пины AVR, а не только специально выделенные для USART. Что явный плюс в пользу САМОПАЛ))

А ногами ходить от ус-ва к ус-ву, то еще и от проводов и AVR можно отказаться. Тоже плюс видимо по такой логике.

[roman.com]

Че вы людям голову

Никому я ничего не морочу)) У нас свободный форум))

А ногами ходить от ус-ва к ус-ву

Это делается программно как два пальца об асфальт)) Это намного проще чем даже поставить мультиплексор))

споря с теми, кто предлагает проверенные временем решения...

Кто предлагает ? Пока не видел тут проверенных решений в железе...


Всё таки я склоняюсь больше к принципу работы маршрутизатора (или роутера, как вам будет угодно).
Маршрутизатор (или роутер) не опрашивает компьютеры по локальной сети)) Он (маршрутизатор) просто принимает и отправляет пакеты по указанному адресу. Вот и вся его работа)) Думаю у меня мастер будет заниматься в основном тем же)).

Осталась последняя проблема - мастер (он же коммутатор) на максимальной скорости не может одновременно принимать и отправлять пакеты разным слейвам. Он даже не может просто одновременно отправлять и принимать пакеты. Никакого дуплекса. Мастер может работать только в симплексе. Скорости процессора AVR не хватает... И во время приёма пакетов на максимальной скорости все прерывания должны быть отключены (кроме разумеется прерываний самого автомата приёмника RX).

0_мастер_20_слейв_2.jpg

(58.82 КБ) 97 скачиваний

Тут я вижу два решения:
1- добавить линии управления потоком (типа как в RS-232 всякие там RTS, CTS и т.д.)
2- или просто добавить в схему типа буфер FIFO RX (как в любом нормальном коммутаторе).

Что лучше... фиг его знает))


Добавлено after 18 minutes 48 seconds:
Если добавить линии управления потоком (типа как в RS-232 всякие там RTS, CTS и т.д.) то просто потребуется много выводом МК и всё)) Будет типа простого RS-232. Никаких опросов слейвов. Передача - полный дуплекс по запросу мастера или слейва.

А может просто добавить к каждому МК ещё по одному МК в качестве буфера FIFO. Будет как в обычном коммутаторе. И опять же никаких опросов слейвов. Передача - полный дуплекс без запросов. Только надо будет не 20 штук AVR а 60 штук AVR )) Всего то))


Добавлено after 1 hour 56 minutes 13 seconds:

еще и от проводов и AVR можно отказаться

Уже пытались в прошлой теме)) делали все по радио...

дом.jpg

(166.29 КБ) 100 скачиваний

Радио больше не хочу. Провода и AVR хочу.))

можете почитать мои измышления, может, что-то почерпнете полезное...
http://arv.radioliga.com/downloads.any/smart_home.pdf

Управление по силовой проводке... по моему перебор))

Добавлено after 7 minutes 41 second:
Вот самая лучшая схема которую мы тестировали в прошлой теме)) Прекрасно работает)) В ней нет ни мастера ни слейвов. И никто никого постоянно не опрашивает))

схема_1.jpg

(196.87 КБ) 100 скачиваний

Есть только проблема - схема просто дохрена жрёт электричества. Грубо до 15 Ватт. И если у вас нет дома аккумулятора от "КАМАЗА" и дизель-генератора, то про автономность вашего дома можно забыть.))

Поэтому хочу всё переделать на простых дешёвых и главное энергоэффективных AVR.
Чтоб весь дом у меня уходил в спячку с током потребления 10 микроампер )) Вот и вся задача.

[ARV]

Управление по силовой проводке... по моему перебор))

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

Чтоб весь дом у меня уходил в спячку с током потребления 10 микроампер

и как это вы собираетесь совместить с непрерывным обменом по сети?! у вас взаимоисключающие требования.

Добавлено after 1 minute 43 seconds:
вопрос чисто на засыпку: когда пропало сетевое питание, какие функции умного дома вы планируете сохранять? управление освещением? тёплым полом? медиасистемой? это все тоже от аккумулятора будет питаться?

[roman.com]

мне представляется неразумным не использовать уже готовую инфраструктуру...

Сигналы управления по электропроводке - тема интересная. В энергетике используется уже давно.
Но.
Тогда придётся ставить в каждую розетку блок питания 220V/5V.
Или всё таки лучше питать всё по витухе от одного аккумулятора 12V ?
Что лучше (надёжней и пожаробезопасней) ? 20 штук блоков питания (в каждую розетку) или один аккумулятор с системой защиты ?

вдруг жене не понравится, в какое место торшер включен...

В доме куча розеток.

розетка.jpg

(87.54 КБ) 111 скачиваний

Ну переключи свой торшер в любую другую свободную розетку...
Затем в приложении выбери номер розетки куда включён торшер. Всё розетки есть в приложении))

как это вы собираетесь совместить с непрерывным обменом по сети?! у вас взаимоисключающие требования.

Не будет у меня непрерывного обмена по сети. Все будут спать. И просыпаться только по событию (приёму пакета, нажатию кнопки, сработке датчика и т.д.).

вопрос чисто на засыпку: когда пропало сетевое питание, какие функции умного дома вы планируете сохранять? управление освещением? тёплым полом? медиасистемой? это все тоже от аккумулятора будет питаться?

Когда пропало сетевое питание, в доме есть ещё вода и газ.

Все датчики продолжают работать (в спящем режиме) от аккумулятора:
-охранный датчик
-пожарный датчик
-датчик протечки воды
-датчик газа
-датчик температуры для газовой плиты
...
Все шаровые краны продолжают работать (в спящем режиме) от аккумулятора:
-кран воды
-кран газа
...

датчики_краны_задвижки.jpg

(35.76 КБ) 98 скачиваний

Можно ещё добавить отопление на газовом котле.

Короче... Когда пропало сетевое питание, дом продолжает жить)).

Уходя из дома я забыл выключить чайник на газовой плите. А в это время в доме пропало сетевое питание. Да без проблем ! -кран газа работает от аккумулятора 12 V.

И т.д. и п.т.

Единственное что будет непрерывно жрать электричество - модуль Ethernet, который подключён напрямую к провайдеру. Он спать не будет)) А что делать... Связь с домом нужна постоянная.
))

[ARV]

Что лучше (надёжней и пожаробезопасней) ? 20 штук блоков питания (в каждую розетку) или один аккумулятор с системой защиты ?

мировые производители давно сделали свой выбор: сейчас блоки питания встраиваются в каждую лампочку! кстати, если на то пошло, то полно готовых модулей, умещающихся прямо в подрозетник, с WiFi - там стоит ESP32 (если не ошибаюсь), которую можно перепрошить под свой протокол. и тогда изобретать придется только своё ПО нижнего и верхнего уровня, вопросы быстродействия, надежности, коллизий и т.п. отпадут естественным путём.

[roman.com]

полно готовых модулей, умещающихся прямо в подрозетник, с WiFi - там стоит ESP32

А выключатели как питать будем ?
Видали много раз уже такие устройства...

https://www.youtube.com/watch?v=5vH-gEZQxkQ

Выключатель на конденсаторах - это жесть))
Нормальный выключатель требует нулевого провода. Которого в настенном выключателе нет. Значит надо штробить стену и тащить нулевой провод бля питания беспроводного выключателя)) Пипец... И ради чего это ? Чтобы поставить WiFi выключатель...))

Да возьми ты болгарку да сделай штробу полтора метра от выключателя до пола.

штроба.jpeg

(165.19 КБ) 92 скачивания

Проложи витуху и спрячь под пол.

витуха.jpg

(235.3 КБ) 100 скачиваний

Пипец...
Делается это один раз в жизни !)) Тебе этой витухи хватит до конца жизни))
И сразу решён вопрос с питанием, управлением, надёжностью, автономностью, энергоэффективностью... и т.д.

[ARV]

Нормальный выключатель требует нулевого провода. Которого в настенном выключателе нет.

зато он есть в распредкоробке недалеко от выключателя. там и можно разместить "дистанционный" выключатель

Делается это один раз в жизни

моё скромное наблюдений убеждает меня в том, что как ни планируй расположение розеток, после ремонта всегда выясняется, что половина из них расположена неудобно...

[roman.com]

До распредкоробки штроба те же полтора метра... только вверх а не вниз ))

Да проложи ты нормальную витуху по дому. Будет ещё и Интернет в подарок))
В нормальных домах сразу закладывают все провода и ставят нормальные розетки 220V с Интернетом и кабельным TV. Всё в одной розетки. А все провода выводят в электрощит. Всё это делается ещё на стадии строительства дома.

розетка в нормально доме.jpg

(42.26 КБ) 101 скачивание

Но это только в нормальных домах))

как ни планируй расположение розеток, после ремонта всегда выясняется, что половина из них расположена неудобно...

Ну да... У нас же всё не как у людей))

[ARV]

До распредкоробки штроба те же полтора метра

до распредкоробки уже лежит провод от штатного выключателя, дополнительно ничего штробить не надо

В нормальных домах сразу закладывают все провода

еще и в гофротрубе для удобной замены проводов. и чо?

У нас же всё не как у людей

у нас запросы по 3 раза в день меняются

[parovoZZ]

У меня в доме вообще нет никакой витухи. И антенны тоже нет. Нах оно не нужно. Всё на радио.