Arduino.ru

Не совсем мое дело) Но если вы любознательный и есть время вот есть очень грамотная статья по поводу этих интерфейсов https://2662255.ru/can-rs485/

Я к чему просто я когда свои модули разрабатывал я тоже смотрел в сторону CAN и в итоге отказался и там очень много аргументов) Поэтому и заострил на этом внимание. CAN классная вещь но как по мне не для домашней автоматики и скорость у него меньше даже чем у RS но не намного. Это просто модификация как юы протокола и там много мусора для задачи домашней автоматики. А так в целом кто че хочет делает))) любой уровень будет работать что нисший самый хоть самый высокий. Но в целом я остановился на таких аргументах как скорость, помехазащищеность так как в моей квартире линии идут рядом с силовыми все + много потребителей мощных и главное это простота и дешивезна. Если поможет в целом то был рад стараться.

CAN более скоростной я имел ввиду, потому что арбитраж аппаратный и не нужно дожидаться пока мастер опросит. А так скорость шины да, наверное  одинаковая примерно, при прочих равных. CAN разгоняется до 1 Мбит при определённых условиях, а про RS485 таких скоростей не слышал. 

из той статьи которую вы привели складывается ощущение, что автор ещё бОльший дилетант чем я. Например: "С другой стороны, есть еще один параметр – максимальное количество тревог, которое может обработать система в секунду. Этот параметр у CAN хуже – ведь каждая тревога должна быть не только передана, но и должна сначала поучаствовать в процессе арбитража."

Давайте представим can систему из 10 датчиков , которые сработали почти одновременно и 11-й типа следящий МК, да что представлять, я на столе такое собирал. Дак вот следящий МК получает сообщения от всех CAN датчиков за 100мс, при этом разница во времени между соседними сообщениями соответсвенно 10мс. скорость шины 100кбит/с. По моим примерным подсчетам на такой скорости максимально это 800 сообщений в секунду (1,5 байта заголовок+8 байт инфы). 

Интересно посмотреть на реализацию данной простой задачи на базе RS485.

Можно и другие части статьи легко опровергнуть. Я не защищаю CAN. У самого уже были куплены 20 модулей RS485, но программировать оказалось легче на CAN при использовании библиотеки. Поэтому выбрал его. и не жалею. Негатива пока не встретил не одного, чего не скажешь о RIV, у него, да, есть какие то косяки с протоколом. Но у меня вся система проще гораздо, пока 3 МК насчитывает. 

Что мог сказал))) В остальном я бессилен. Как говорится все интерфейсы хороши, но каждый в своей сфере как говорится. У меня у самого используется не только RS))) просто я КИПовец) и есть опыт работы с интерфейсами. Моя задача была как я сказал Вас не отговорить а просто осветить со всех сторон этото вопрос.

такие были сопли, мега-волосянка. нет ничего более постоянного, чем...

это моя самая большая в жизни плата 200 на 200. 

травить пришлось в тазике, другой посудины найти не смог: 

готово

Купил стопицот пинхидеров, просверлил стопицот отверстий, запаял стопицот перемычек, даже отходов не было от резисторов и кондёров, всё в дело пошло)

получилась такая почти материнская плата аля микро атх socket ARD2018:

LCD, счётчик PZEM, кан модуль MCP закрепил на винты с гайками, хорошо получилось. 

и слава тебе Господи, всё заработало, сразу!!! Бывает же такое.

Я доволен. Осталось всё в ящик сложить и провода подключить. 

Я не пробовал, но видел скан патента, где  CAN как раз звездой разведен. Ну и, в любом случае, в две стороны можно лучи пустить не выходя за рамки стандарта. Другое дело что на шину не надо адское количество устройств навешивать. В DeviceNet, например, существует ограничение условного MAC - 6 бит.

Если использовать 485-й, то транспортный уровень нужно самому на МК пилить, а в CAN уже все готово - МК за ногу дернули, он из буфера читанул пакет и голова у программиста не болит насчет проверки целостности, перезапроса данных и т.д.

+100. людям, которые действительно попользовали кан, уже будет лень применять rs485. 

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

Вот тут человек продумал как решить вопрос звезды на CAN

https://demid.net/product/разветвитель-шины-can-8-портов/

Думаю надо попробовать.

В общем накропал тут библиотеку как обещал. https://github.com/graynet-dev/aHomeBus2

Она в свою очередь основана на https://github.com/adlerweb/asysbus

А та на iSysBus Patrick Amrhein, www.isysbus.org.

Riv , и что с этой твоей библиотекой модули уже не глючат по CAN, не отваливаются? Значит программный косяк был? 

Глючили не модули, проблема в звезде на Can. Вот и буду ее решать концентратором CAN.

Причем у меня на работе с той же проблемой столкнулись. Т.е. переполнение буферов ошибок и контроллер перестает отвечать на софт ресет. Только полный сброс.

А библиотека полностью скрывает от программиста работу с CAN  и пр. шинами. 

Всем привет.

Я автор этого безобразия, на которое дали ссылку чуть выше. Рисовал долго :) Работает прикольно. Делался для себя.

Как-то тут резко обсуждение прервалось... мне кажется нужно продолжить, ибо тема хорошая, интересная. Да и у меня по ней есть наработки.

Коротко о себе: Александр, без двух недель 40 лет, 3 детей, 2 диплома программиста, с МК начал знакомство года 4 назад и не с Arduino а с PIC16-18. Потом STM32. В основном пишу все в Mikroc. Умею и C#. Кое-как автоматизировал дачу. Могу что угодно включить/выключить удаленно, выставить нужную температуру по этажам. 12 датчиков раскиданы повсюду. От улицы до земли (ввод воды). Отопление самодельными канальными нагреваттелями в вентиляции. Температура в доме поддерживается +/-0.25 градуса. Но душа хочет именно умного дома а не пульта от него.

На сегодня у меня наколбашено 13 блоков с разным назначением. Около 30 готовых к работе железок. Проект в виде хобби, вялотекущий, но уже работающий. Блоки естественно с CAN-шиной. Протокол польностью свой - это ложка дегтя.

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

а ктонибудь пробовал CAN на 10...50кБит/c запускать? вроде нужны особые трансиверы. Думаю, что с такой скоростью пофиг на звёздность шины. 

Пробовал. Ничего интересного. Просто маленькая скорость. Что-то тут явно не так. CAN у меня заводится практически в любых условиях.

Я сегодня прочел все 23 страницы в этой ветке и кажется мне что проблемы не в звездности.

1) MCP2515 на китайской платке тактируется от 8МГц (Мегабит с этой штукой не получить априори, ну да фиг с ним), а SPI вы к ней инициализируете на 10МГц - в чем тайный смысл и как это по-вашему должно работать - не понятно. Тем более 10Мгц по проводкам а не разводкой на плате.

2) Не увидел ни одного скриншота с программой Canculator. Сдается мне что выставления только скорости CAN для MCP2515 не достаточно. Нужно проверять что там в библиотеке с SJW, BRP и прочими PHSEG.

3) Не увидел ни одного скриншота с осциллографа.

4) Есть вопрос по резистору у MCP2551 от RS на GND. Какой там номинал чтоб выставлять хотя бы 125кбит/с

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

PS. у меня тоже проблем с CAN сетью не было, но я узлов ещё много не навешивал, всего 3 пока. Работает как всем известный автомат.

А у меня 20 узлов, сеть древовидная. И узлы накопив ошибки выпадают.

Специально написал код который позволяют через esp8266 дать команду на ресет CAN и ничего не работает. Только аппаратный сброс.

Вот примерно так

Концентратор появился после постройки гаража... 6*8м с лабораторией на втором этаже. Чисто (психо)логичкски это другая сеть, которую надо подключить к основной. Сначала был собран повторитель 50x32мм односторонний без перемычек... CAN+CANSPI

и в принципе на этом можно было закрыть вопрос. Но и после добавления блоков сложно придерживаться шинной топологии.

Тот же MCP2551.

А в плане скорости я ставил 10кбит/с чисто для проверки. Меньше не позволяет USBtinViewer софтина usb-can переходника. Я использую перерисованный под себя usbtin. Не люблю перемычки :)

Для себя я принял, что снижать скорость буду только при невозможности обработать поток пакетов. И скорее всего от 250кбит, которые есть сейчас, рано или поздно провалюсь в 125 а может и ниже. Просто тут обратная зависимость. Лучше чтобы код умел переваривать такой поток, иначе это халтура а не программа.

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

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

Мое имхо, если перепаять на китайских модулях все дерьмовые tja1050 на MCP2551 , и за одно и кварцы на 16Мгц, поставить скорость 100 кбит/с  то проблема возможно ликвидируется. Ну или ставить предложенный концентратор.

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

С точки зрения CAN - это нормальная идея, а с точки зрения подачи питания - зло. Именно CAN кабель стоит каких-то неимоверных денег. Типа 400р/м - это перебор, имхо.

Питание у меня по жилам витухи не идёт. Везде кидаю вместе с витухой лапшу. по лапше 220В от Компьютерного UPS. На каждом МК свой БП AC-DC. Не знаю насколько такой подход правильный, но не парюсь по падению напряжения и толщине питающих проводов. 

Опасное это дело, с сигнальными цепями 220В кидать. Так до беды не далеко. + Решишь картину прибить а про кабель забыл. Питающие все по СНИП кладутся. Вертикально  и пр. А слаботочка обычно как придется.

Мне обычного ноутбучного блока питания типа такого http://ntb74.ru/?product=b-p-dlya-noutbuka-3q-ch120-meu08n-120w хватает на всю сеть без потерь. Не забывай про вилку напряжений на регуляторах.

Но это только мое имхо.

В наших проектах мы используем библиотеку https://github.com/coryjfowler/MCP_CAN_lib

Там есть MCP2515Calc.xlsx

По поводу звезды. Вот что пишут производители железа использующие CAN.

Ответвления от основной “линии” длиной до 3 м — допустимы. Общая длина проводов не должна превышать 500 м.

Если “звезды” не избежать, то можно использовать следующую схему.

Так как обычно используется кабель с 4-мя витыми парами, можно использовать одну из них для прохода сигнала “туда”, а вторую для прохода сигнала “обратно”.

Таким образом, можно сохранить линейную топологию даже при физически проложенном кабеле “звездой”.

Видимо проблемы как у Ethernet со 100 метрами на 100 Мб. 

Так что попробую CAN HUB от demid.net  и если не пойдет буду вытягивать звезду в шину как написано выше.

P.S.

У меня от центрального щита звезда во все помещения это по 10-15 м. не меньше по кабелю, а в некоторых помещениях ответвления еще по 5-7 метров.

Я включал логи и как раз наблюдал большое количество ошибок.

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

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

мда, почитал, и вооооообще ничего не понял, хотя я, оказывается, соавтор О_О.    Видимо библиотека для очень узкого круга людей. Слишком сложно всё. Те кто способен это всё понять, чужим трудом вряд ли будут пользоваться, им проще своё наваять. 

На самом деле все просто

Это адреса в сети CAN

uint8_t can_addr_net[] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,77,78};

Это Modbus

uint8_t modbus_rtu_addr_net[] = {100,101,102,103};

Объявляем тип узла

AHB ahb0(5,Master);

Объявляем
AHB_CAN ahbCan0(52, CAN_500KBPS, MCP_16MHZ , 2,can_addr_net, size_can_addr_net);
AHB_MODBUS_RTU ahbModBusRtu0(0,1,10,modbus_rtu_addr_net, size_modbus_rtu_addr_net);

Ну там еще мелочи в сетапе

И все

Так отправляешь сообщение
ahb0.ahbSend(AHB_PKGTYPE_UNICAST, 167, 100, 0, ahb0._nodeId,  sizeof(data1), data1);

Так принимаешь

ahbPacket pkg = ahb0.loop();

  Serial.print(msg_num3);
    Serial.print(F(" - Type: 0x"));
    Serial.print(pkg.meta.type);
    Serial.print(F(" - CMD: 0x"));
    Serial.print(pkg.meta.cmd);    
    Serial.print(F("  Target: 0x"));
    Serial.print(pkg.meta.target);
    Serial.print(F("  Port: 0x"));
    Serial.print(pkg.meta.port);
    Serial.print(F("  Source: 0x"));
    Serial.print(pkg.meta.source);
    Serial.print(F("  Length: 0x"));
    Serial.print(pkg.len);
    for(byte i=0; i<pkg.len; i++) {
      Serial.print(F(" 0x"));
      Serial.print(pkg.data[i]);
    }

Все остальное от пользователя спрятано, поддержка сети, Web интерфейс, маршрутизация

Честно говоря выкладывать пока не планировал, пока еще в начале пути. Воспринимай как мой черновик. Я просто github использую как хранилище своего кода. Пока только для отладки.

На выходе должно быть как обещались раньше. Как в библиотеке CAN, которая от тебя скрывает контроллер. Наша либа скрывает протокол. Все те фишки которые мы городили спрячутся в библиотеку. А дальше пиши логику работы модуля и говори что на какой адрес кидать. Как работает сеть от тебя скрыто.

Так же реализовал маршрутизацию между сетями.

У меня есть например контроллер фанкойла у него Modbus, который я использую как экран, термостат и реле для управления радиатора, включением кондея и вентиляцией. Так вот его можно опросить с соседнего контроллера просто по адресу 100. https://ru.aliexpress.com/item/4000189402896.html?spm=a2g0v.12010612.8148356.4.40f3265aYyv0iM

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

Это следующий этап. Но хочу сделать ее независимой от кода. Настройкой из вне. Прошивка единая. Настройка как маршрутов, датчиков и пр. Снаружи через Can или Web консоль esp-link или MQTT. Механизм записи чтения EPROM реализован. C Due сложнее там нет отдельной памяти там все в ПЗУ вместе с основной программой.

см. ahb.cpp здесь пока только NodeID но все в наших руках.

Смотри еще node_setup.ino я ей устанавливаю NodeID перед прошивкой. Криво конечно, потом по правильному сделаю.

а сами переменные датчиков и состояния исполнительных механизмов где будут храниться? тоже в еепром? или изначально отводим на узле место в ОЗУ  по максимуму  (сколько это возможно) для переменных, и не важно будет ли этот объём использоваться или нет, переменные все равно будут присутствовать. А необходимость использования той или иной переменной уже будет настраиваться через еепром. 

я тоже в соседнем проекте про вебасто хотел сделать цивильное устройство, как заводское. Типа чтобы всё настраивалось не через правку скетча и перезаливку, а по смс, либо MQTT. В итоге трахотни с программированием добавилось, что ппц. код вырос до нельзя. Вместо того чтобы тратить время на оттачивание работы основных функций девайса, приходится программировать как настраивается та или иная функция, при этом лишней памяти отъедается  много. Допустим настроили котёл одного типа, а код, связанный с котлом другого типа (который не используется) просто болтается в ПЗУ и ОЗУ за зря.   А если делать правкой и перезаливкой скетча через директивы условной компиляции, тогда неиспользуемая часть кода просто не заливается в проц. 

И в итоге все новые функции которые я добавляю один фиг через правку скетча и перезаливку приходиться настраивать. 

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

Возможность обновления ПО же всегда должна присутствовать, без неё никуда. И по сути получается процедура конфигурирования устройства делается просто через обновление ПО. 

Тут ты прав, сначала основной код а потом настройка. Главное настройки сделай в виде переменных, пока из файла. А потом заменишь на считанные из памяти EEPROM. 

а ответь на #1135?  Проще будет понять твою библиотеку на конкретных примерах. Представим что нам нужна сеть из 3 МК. Один мастер -  собирает инфу и отправляет на MQTT. Остальные это  два узла, шлют мастеру инфу один, например, температуру (int8_t), другой - напряжение (float). Мастер также сообщает в MQTT, если узлы отпали из сети.  Вот конкретная задача.

Можешь три скетча показать? 

У нас в последнем скетче какая была концепция? Вспоминаем. Типа такая. Создаем лист:

- Список (enum) названий (читай адресов) узлов в умном доме; Этот список в скетчах всех узлов сети одинаковый. 

- Список (enum) в принципе возможных переменных, участвующих в умном доме (типы устройств) + конкретные экземпляры устройств (ты их обозвал № датчика), т.е. например тип устройства это датчик открытия окна, а номер датчика - это какого именно окна .В типе устройств сразу содержится информация какого типа данных эта переменная (int, float, unsigned long и т.д.) Я эти оба элемента (тип устройств и номер датчика ) в целом обозвал параметры. Этот список в скетчах всех узлов сети одинаковый. Кстати говоря самые важные параметры например пожарные датчики пишем первыми, т.к. они будут иметь наименьший адрес и будут выигрывать арбитраж в CAN, если сеть загружена. 

- по аналогии и список (enum) возможных исполнительных механизмов много дома; Этот список в скетчах всех узлов сети одинаковый. 

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

Примерно было как то так. 

Вообще я пока думаю о библиотеке как о коммуникационной. С небольшой функциональностью в части обработки данных и выдаче исполнительных решений.

Хранить значения датчиков и состояния ИУ в памяти и тем более в EEPROM вообще смысла не вижу. Проще опросить.  Утяжелять контроллер не хочется. Думаю мозги основные все же наверх.

В общем пока точно не знаю. Задача отладить протокол обмена между узлами.

Я  до этого не  дошел даже. Сейчас есть три возможных типа канальных интерфейса (дальше будет больше) подключаемых к МК и адреса за этим интерфейсом. Причем если за CAN интерфейсом прячется где то в сети удаленный Modbus или Uart то их тогда тоже вписываем

Например это узел 1
uint8_t can_addr_net[] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,77,78,104,105,106,107};

uint8_t uart_addr_net[] = {0,55,56};

uint8_t modbus_rtu_addr_net[] = {100,101,102,103};

А это узел 2

uint8_t can_addr_net[] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,55,56, 100,101,102,103};

uint8_t uart_addr_net[] = {0,77,78};

uint8_t modbus_rtu_addr_net[] = {104,105,106,107};

Если я захочу направить инф. с узла №1 на 103 адрес то он сразу уйдет в 485 интерфейс как телеграмма а если на 107 например, то он уйдет в CAN и все узлы его получат. Но узел 2 увидит что у него на его Modbus есть этот адрес и он переправит пакет. Получит ответ и переправит его на узел 1. Вот это работает.

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

Попробовал связку NodeMCU-32S + TJA1050 c https://github.com/miwagner/ESP32-Arduino-CAN

Работает лучше чем Mega 2560 + esp8266 + mcp2515 и компактнее 

А в чем лучшесть? А физику лучше , имхо, MCP2551

The ESP32’s peripherals contains a CAN Controller that supports Standard Frame Format (11-bit ID) and Extended Frame Format (29-bit ID) of the CAN2.0B specification.

По ходу дела экспрессиф решил все, что есть на свете, в свой чип сунуть.

MCP2515 к МК подключается по SPI, в моей схеме 2560 + MCP2515 по SPI 10 МГц  + esp8266 2.4 ГГц, видимо влияют др. на друга. И как я уже понял при накоплении ошибок CAN уходит в bus-off.

ESP32 все в одном и вопрос ЭМС решен разработчиком. 240 МГц + память дает возможность работать с freeRTOS, причем  https://github.com/miwagner/ESP32-Arduino-CAN сразу с использованием FreeRTOS написан.

Все что мне нужно вынести на шилд это TJA1050 + max485 + разъем.

Цена в Китае 2500 шт 10 NodeMCU-32S на 30 ног и 2800 за 10 шт ESP32-DevKitC на 36 ног. Пока прикупил на месте NodeMCU-32S пару. Позже возьму ESP32-DevKitC посмотрю что лучше.

TJA1050 аж 30 рублей.

Сравни с 2560 pro - 450 + MCP2560 - 100 + esp8266 - 100 итого 650 + проблемы с ЭМС.

У тебя этих проблем видимо не нарисовалось так как ты шилд сделал для сопряжения MCP2515 c 2560 pro и у тебя 8266 не шумит под боком.

Я вообще на STM32 думал уйти, типа такой https://aliexpress.ru/item/4000375025917.html?spm=a2g0o.cart.0.0.f5e83c00g94RyY&mp=1 да народ насоветовал ESP32. Она под IOT заточена в полный рост.

Опять же мое ИМХО. 

А вообще не плохо бы было вот такое сваять только еще и с MAX485 на борту

https://cnx-software.ru/2018/02/15/%D0%BF%D0%BB%D0%B0%D1%82%D0%B0-%D0%B4%D0%BB%D1%8F-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8-can32-%D1%81-%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%BC-esp32-%D0%BF%D1%80%D0%B5%D0%B4/

все равно эту плату куда то втыкать надо. Не будешь же напрямую на ноги МК периферию  вешать, опторазвязки надо и т.д.  Вот в этом куда-то и сделать rs485 , да и CAN трансивер тогда уж. В этом случае можно тогда брать обычный nodemcu32.  

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

Такими темпами можно и не успеть пожить в умном доме. состаришься быстрее, без конца выбирая МК, тем более планы по системе наполеоновские.  

esp32 мощнее stm32 в разы + куча перефирии на борту.  

По поводу скорости разработки, просто времени не хватает. Сыну еще 2х лет нет вот время и утекает сквозь пальцы.

Кстати в части исполнительных устройств и автоматики я двигаюсь нормально. Вентиляцию с рекуператорами поставил и пр. Жалюзи всякие с электроприводами и пр.  Пульты разные на 433 и 2.4RF все есть, все работает. В терминологии Demid.net глупый дом с ДУ у меня есть. А вот к именно полностью автоматическому, сценарному управлению домом я осторожно подхожу. Здесь надежность наше все.

Шилд буду делать но маленький в размер. Чтобы все в подрозетник влезало.

Пока вот так все реализовано.