Прошил в епром все типы подключенных датчиков, ИУ и все. В зависимости от этого инициируешь переменные.
блин ну не пойму я смысла. Это всё и так лежит в энергонезависимой памяти, которая называется флеш. В ней залит скетч. В скетче есть эта информация. Дак нафига её в еепром то пихать? В том то и дело, если ты ничего подключать дополнительно не собираешься вообще не имеет смысла в еепром пихать. Т.к. туда пихается обычно изменяемая инфа. А постоянная она из флеша (скетча) спокойно также грузится.
Ты же сам предложил епром чтобы заливать в 15 МК один и тот же скетч. Да в большей степени они одинаковые по ИУ и датчикам но есть и различия.
я чёто тупанул, думал вместо массива с настройками ты хочешь постоянно обращаться в еепром при работе скетча. А ты просто в принципе все мои массивы хочешь оставить, но чтобы они инициализировались только при старте, в соответсвии с еепром .
Т.е. да, скетч получается один на всех. А в процессе настраиваем каждый узел по Serial например или вообще по кану можно (настраивая тем самым еепром, потом ресет и уже пошёл скетч работать). Соответсвенно у всех МК будет два режима
- режим конфигурации,
- рабочий режим.
Блин, это всё как у меня на работе. Допустим новый блок управления идёт один и тот же на все комплектации автомобиля и при установке ты его конфигурируешь, в зависимости от комплектации автомобиля.
Я просто на производстве работаю и постоянно бъемся за унификацию плат, разъемов кода и пр.
MaksVV пишет:
Блин, это всё как у меня на работе. Допустим новый блок управления идёт один и тот же на все комплектации автомобиля и при установке ты его конфигурируешь, в зависимости от комплектации автомобиля.
это всё конечно прикольно, я уже приводил в посте #848 такой пример. смотри файлы screen1... screen16. Но это когда есть возможности для создания программы конфигуратора. Это ещё можно пару месяцев потратить на то чтобы наладить настройку конфигурации например по Serial или по кан, т.к. я вообще не петрю в создании программ для винды, и не осилю такую задачу. А с терминала конфигурировать какими то кодировками - это извините - проще в иде мои массивы заполнить и залить скетч.
это всё конечно прикольно, я уже приводил в посте #848 такой пример. смотри файлы screen1... screen16. Но это когда есть возможности для создания программы конфигуратора. Это ещё можно пару месяцев потратить на то чтобы наладить настройку конфигурации например по Serial или по кан, т.к. я вообще не петрю в создании программ для винды, и не осилю такую задачу. А с терминала конфигурировать какими то кодировками - это извините - проще в иде мои массивы заполнить и залить скетч.
Так я и говорю делаем пока функции эмуляторы работающие с файлом например Config.h
//EEPROM1.write(address, value); //value: значение для записи, от 0 до 255 (byte)
//EEPROM1.update(address, value); //запись если значение отличается от записываемого
//EEPROM1.get(address, data); // Считывает любой тип данных или объект из EEPROM
//EEPROM1.put(address, data); // Записывает любой тип данных или объект из EEPROM.
//EEPROM1[address];// Данный оператор позволяет использовать идентификатор 'EEPROM', как массив.
А потом просто убрав 1 получим работу с епром.
Насчет win программы это с меня на Cbuilder (или как он сейчас называется) набросаю, но он в любом случае должен через serial, can и web общаться.
это всё конечно прикольно, я уже приводил в посте #848 такой пример. смотри файлы screen1... screen16. Но это когда есть возможности для создания программы конфигуратора. Это ещё можно пару месяцев потратить на то чтобы наладить настройку конфигурации например по Serial или по кан, т.к. я вообще не петрю в создании программ для винды, и не осилю такую задачу. А с терминала конфигурировать какими то кодировками - это извините - проще в иде мои массивы заполнить и залить скетч.
MaksVV пишет:
вот вспомнил, есть интересный проект умной теплицы уважаемого коллеги по форуму DIYMan. Много чего можно взять на заметку. Например идея конфигуратора это гуд. Но не в моих силах к сож. Автор гораздо опытнее в программировании, меня точно.
Ну примерно так я себе это и представляю на выходе.
DIYMan пишет:
... управлять микроконтроллером отовсюду, откуда только можно: непосредственно жмакнуть на кнопочку .... По Wi-Fi с домашнего компьютера... По витой паре ..! Со смартфона - ....
Задача ставилась такая:
1. я заранее не знаю, какой функционал мне надо будет дописать, это раз.
2. Не хочу некрасивого кода простынями по нескольку экранов в одной функции - это два.
3. Система модульная .
4. Модули могут быть как в пределах одной коробки, так и разнесены в пространстве .
5. Модули должны поддерживать прозрачное общение друг с другом "из коробки"
6. лёгкая расширяемость поддерживаемых команд
- архитектура устроена так, что посылать команды контроллеру (давайте пока называть главный модуль контроллером, для ясности) можно из любого источника, достаточно только написать поддержку этого источника и зарегистрировать его в программном коде, буквально одной строкой.
- если завтра вам понадобится встроить поддержку датчика температуры, то для его опроса не надо будет писать огромную простыню в функции loop - достаточно написать простенький новый модуль, который и будет выполнять эту чёрную работу. Код в loop при этом не изменится ни на йоту - вместо этого просто добавиться одна строчка в setup, для инициализации модуля.
- Ну допустим, что есть у вас код, который опрашивает датчик и выводит температуру на экран. И захотели вы, помимо вывода на экран - выводить всё это в Serial. Да не просто выводить, а по запросу из Serial же. Короче, уже представляете, сколько зависимостей, да? А вот и нет! Не надо специально корячиться и переписывать модуль для вывода на экран - архитектура, повторюсь, такова, что модуль только отдаёт или устанавливает свое внутреннее состояние, по запросу извне. Откуда пришёл запрос - ему чхать, куда всё это выведется - наплевать. И вот на этом моменте вы подключаете к этому модулю модуль публикации на дисплей (одной строкой кода) - и всё! Просто, правда?
Пришла и мне Mega Pro от robotdyn . Всего 12 дней шла. Я уж и забыл, что из китая так быстро посылки могут приходить. Померил, плата MCP2515 точь в точь входит в развал между пинами меги. поэтому в LAYOUT шилд рисую - не люблю на проводочках всё. На шилже можно также уместить и ESP. кинь схему как ты еспшку подключаешь.
ПС. Я ещё студентом был купил квадратный метр медного текстолита. Всё ещё израсходовать не могу. Платы ЛУТом быстро делать когда всё подготовлено. (поваренная соль, лимонная кислота, перекись водорота, медный текстолит, карандаш, линейка, лобзик с пилкой по металлу, наждачка нулёвка и чуть крупнее, дремель с мелким сверлом , ватные диски, жидкость для снятия лака, журнальные глянцевые тонкие листы, ножницы, лазерный принтер, утюг ).
ПС. Я ещё студентом был купил квадратный метр медного текстолита. Всё ещё израсходовать не могу. Платы ЛУТом быстро делать когда всё подготовлено. (поваренная соль, лимонная кислота, перекись водорота, медный текстолит, карандаш, линейка, лобзик с пилкой по металлу, наждачка нулёвка и чуть крупнее, дремель с мелким сверлом , ватные диски, жидкость для снятия лака, журнальные глянцевые тонкие листы, ножницы, лазерный принтер, утюг ).
Да молодость вспоминается. ;-)
Но я все же думаю что на этом этапе пока нет смысла этим заниматься. Пока не отлажены технические решения заниматься сборкой рано. Вдруг что то еще появится.
А на выходе может и свою плату разведу под ATmega2560 + MCP2515 + TJA1050 + сверху 8266 (ESP07) + еще что нибудь. (пока не знаю, поэтому пока паяный конструктор) затем у китайцеав закажу изготовление.
Вот кстати вопрос на засыпку посоветуй малогабаритный разъем (не жутко дорогой) для подключения этой меги к кабелям из стены. Может для магнитолы или еще что то пинов на 20-40 а лучше 60.
P.S.
Хотя ты знаешь мысль дельная с шилдом, но от него всеравно гибкий паяный жгут нужно делать с разъемом и разъем из стены + разъем к датчикам. До дома доберусь сделаю фото как у меня подрозетники для МК сделаны по квартире.
Еще вопрос, у тебя в byte parameter [6][parameters_quantity перечисленны не все датчики
я хочу добавить СО2 датчик, мне нужно во все 6 {} вставить что то?
Вообще я не понял зачем ты усложнял. Ты сделал возможность произволь назначать тип датчика на произвольный номер строки массива. А зачем? Номер строки в массиве = № датчика. Если делать на eeprom то придется делать фиксированный тип массива с типовыми датчиками и их адресами.
я немного переделаю сейчас массив параметры. Не нужно будет после настройки массива подсчитывать сколько параметров забили в узел, МК сам будет это делать. И понагляднее будет.
Я все же предлагаю обсудить идеологию, а то мы под удобство реализации кода ушли от основной цели.
Нужно определиться
1. Тип датчиков температуры 1 или несколько и по осталным тоже. Вот например у меня есть BME280, SI7021, DS18S20
2. В принципе сколько будет датчиков однотипных на узле. У меня их может быть от 0 до 4.
3. Работаем ли мы с датчиком как с абстракцией или с железными пинами.
Так вот ответ на эти вопросы показывает что к сожалению нужен тип датчика по возможностям (температура, влажность ...), тип датчика по железу, № датчика на узлею То же по ИУ.
Мы рано начали реализовывать функционал не добившись работы протокола в разных режимах.
работаем с параметром. А как он обновляется - неважно. Как раз предлагаемая DIYMan концепция. Т.е., например, параметр температуры воды ты обновляешь далласом , а температуры воздуха - BME. Код работы с параметром по кан, веб и т.д. не поменяется от этого. Ты лишь "подключишь " к параметру определённый модуль в скетче, в данном случае далласа или BME
Как понять это датчик температуры у потолка или у пола?
Я понимаю что ты можешь посспорить на тему зачем мне 2 или 5 датчиков на одном узле. Но! Например вот таких датчиков у меня по 2 в каждом помещении. Как быть?
заведи ещё один параметр - температура вверху, температура внизу. К каждому параметру будет привязан свой датчик.
И слушай я так и не понял зачем ты делаешь DLC не 8? Проще же везхде работать с байт 0-7 чем думать есть у меня в датафрейме например 7 байт или нет.
там есть несколько мест где считывается количсетво байт во фрейме. Наример, когда делаем запрос параметра у какого-нибудь узла, Тело запроса состоит таким образом. Нулевой байт поля данных это глобальный счетчик. А вот дальше идут байты адресов параметров (до 7 шт.). Т.е. с одного запроса мы можем запросить до 7 параметров. Соответсвенно если нужно 3 запросить, то поле данных будет из четырех байт:
счетчик, и три байта адреса параметра. DLC=4
А при ответе параметра , если у нас параметр однобайтовый будет DLC = 5
И слушай я так и не понял зачем ты делаешь DLC не 8? Проще же везхде работать с байт 0-7 чем думать есть у меня в датафрейме например 7 байт или нет.
там есть несколько мест где считывается количсетво байт во фрейме. Наример, когда делаем запрос параметра у какого-нибудь узла, Тело запроса состоит таким образом. Нулевой байт поля данных это глобальный счетчик. А вот дальше идут байты адресов параметров (до 7 шт.). Т.е. с одного запроса мы можем запросить до 7 параметров. Соответсвенно если нужно 3 запросить, то поле данных будет из четырех байт:
счетчик, и три байта адреса параметра. DLC=4
А при ответе параметра , если у нас параметр однобайтовый будет DLC = 5
двухбайтовый DLC = 6
четырехбайтовый DLC = 8
Самый главный вопрос зачем это. Какая цель преследовалась для такого усложнения?
ты мне скажи в чём усложнение то? если будут ноль байты, это вообщето тоже информация (например нулевой адрес). А когда их нет, мы соотвественно и не обращаем на них внимания. Вот предствавь что у нас есть нулевой адрес у параметров.
По моей схеме как запрос параметров сделать ? вот запрос 56 01 05 08 00 00 00 00
56 - счетчик 01 05 08 запрашиваемые параметры, но нулевые параметры в запросе присутсвуют и узел четыре раза ответит и параметром с нулевым адресом.
Я уже не говорю о том, что по моей схеме шина меньше загружается.
ты мне скажи в чём усложнение то? если будут ноль байты, это вообщето тоже информация (например нулевой адрес). А когда их нет, мы соотвественно и не обращаем на них внимания. Вот предствавь что у нас есть нулевой адрес у параметров.
По моей схеме как запрос параметров сделать ? вот запрос 56 01 05 08 00 00 00 00
56 - счетчик 01 05 08 запрашиваемые параметры, но нулевые параметры в запросе присутсвуют и узел четыре раза ответит и параметром с нулевым адресом.
Я уже не говорю о том, что по моей схеме шина меньше загружается.
короче я поменял местами измерения у массива параметр. (это нужно чтобы автоматически определять размер массива - количество присутсвующих параметров. )
Смотри в основном изменения в файле can_struct.h касаемые parameter [][].
Также теперь можно добавлять количество узлов, на которые будет автоматически отсылаться один и тот же параметр (по умолчанию стоит 2)
И слушай я так и не понял зачем ты делаешь DLC не 8? Проще же везхде работать с байт 0-7 чем думать есть у меня в датафрейме например 7 байт или нет.
там есть несколько мест где считывается количсетво байт во фрейме. Наример, когда делаем запрос параметра у какого-нибудь узла, Тело запроса состоит таким образом. Нулевой байт поля данных это глобальный счетчик. А вот дальше идут байты адресов параметров (до 7 шт.). Т.е. с одного запроса мы можем запросить до 7 параметров. Соответсвенно если нужно 3 запросить, то поле данных будет из четырех байт:
счетчик, и три байта адреса параметра. DLC=4
А при ответе параметра , если у нас параметр однобайтовый будет DLC = 5
двухбайтовый DLC = 6
четырехбайтовый DLC = 8
Ууу блин, мы же говорили 1 параметр 1 фрейм, чтобы четко понимать запросил температуру у датчика на потолке и от него и получил
Как понять это датчик температуры у потолка или у пола?
Я понимаю что ты можешь посспорить на тему зачем мне 2 или 5 датчиков на одном узле. Но! Например вот таких датчиков у меня по 2 в каждом помещении. Как быть?
заведи ещё один параметр - температура вверху, температура внизу. К каждому параметру будет привязан свой датчик.
Вот структура
byte parameter [6][parameters_quantity] =
{
// Первое измерение массива:
0 - тип данных переменной параметра,
1 - адрес параметра (по дефайнам выше) ,
2 - сам параметр
3- последнее значение параметра,
4 - адрес 1 узла, которому периодически будет высылаться данный параметр
5 - адрес 2 узла, которому периодически будет высылаться данный параметр
// Второе измерение массива: порядковый номер параметра ЭТО НЕ ЕГО АДРЕС, А ПРОСТО НОМЕР РАСПОЛОЖЕНИЯ В МАССИВЕ
}
Т.е я могу сделать
[BYTE_1_SIGNED, 1, 10, 20, 04,01][0] 1 й датчик температуры
[BYTE_1_SIGNED, 1, 10, 20, 04,01][1] 2 й датчик температуры
[BYTE_1_SIGNED, 1, 10, 20, 04,01][2] 3 й датчик температуры
[BYTE_1, 1, 10, 20, 04,01][3] 1 й датчик влажности
Так?
Где в кан фрейме я это увижу?
14050401 94 00 08 08 01
ID
1 dir
2 ответ параметра
05 от кого
04 кому
01 датчик температуры
Data
94 ?
00 ?
08 ?
08 ?
01 № датчика?
Дальше, если я хочу их запросить то как это сделать с мастера?
Не это совсем не правильно, это уже уникальное имя датчика
Мы же говорили тип датчика адрес датчика. Т.е - тип №1 адрес №1, тип №1 адрес №2, тип №1 адрес №3, (как я выше писал) где тип №1 температурный датчик а 1,2,3 адрес-расположение.
а сейчас "типа" в принципе уже нет есть описание равное номеру т.е
1 датчик называется тип ххх
2 называется ууу
3 zzz
Я то думал будет тип лампа а потом ее номер 1 вот так
1. [лампа][1]
2. [лампа][2]
3. [температура][1]
4. [лампа][3]
а теперь выходит так
1. лампа№1 с значениями
2. лампа№2 с значениями
3 датчик температуры№1 с значениями
4 лампа№3 с значениями
т.е 2 разных ьтипа в общем то однотипного устройства лампа на потолке 1 и лампа на потолке у тебя 2 разных типа устройст, а должен был быть один с адресами.
В итоге в node_11_Kitchen_light.ino у меня 20 реле и больше ничего и будет не 1 тип с 20 адресами а 20 разных типов так?
Мы же говорили тип датчика адрес датчика. Т.е - тип №1 адрес №1, тип №1 адрес №2, тип №1 адрес №3, (как я выше писал) где тип №1 температурный датчик а 1,2,3 адрес-расположение.
а чего тогда в списке параметров у тебя несколько температур? Адреса 1, 27 , 28 , 40, 33
по разъему может несколько лучше делать. 4 pin овые например. У тебя ведь не в общем жгуте все провода приходят?
Я что то такого типа хочу, чтобы все из стены распаяно было на жгут и в руках ардуина с CAN подключалась жгутом. Ну как в авто, открываешь лючок а там блок, отключил проводку блок снял и унес.
В итоге в node_11_Kitchen_light.ino у меня 20 реле и больше ничего и будет не 1 тип с 20 адресами а 20 разных типов так?
да, а че такого? неужели прям через 254 перевалят все параметры? сомневаюсь
Дело в логике построения. Если у каждого датчика имя собственное зачем тогда типы придумывать. Тогда на каждый контроллер уникальный код.
Одно дело поросить все датчики температуры, другое опросить все датчики температуры там, потом там, а про тип датчика температуры за унитазом а и забыл, а а эти типы я потом ввел и писец.
А если тип один и есть адреса и пожно получить длинну занятых адресов, то можно for прокрутить и все опросить, а так я должен четко знать какие типы темп. датчиков у меня существуют и какие есть на данном узле.
Посмотри код и принцип построения Умной теплицы, особенно на форуме когда он начинал. Я выжимки выше делал, но лучше форум.
Должно быть четкое бинарно матричное деление а не одномерный массив.
ну если ты так хочешь тип всё таки у нас есть в поле данных параметра один свободный байт))
Это не я хочу это логика требует.
И кстати мы мух с котлетами путать начинаем. Я это уже говорил.
Сначала протокол. Хранение и настройка. В итоге ты в связи с тем что так проще хранить усложняешь протокол.
Мастер (да и любой узел) должен иметь возможность запросить у узла параметр датчика типа ххх №yyy а так же какие датчики типы датчиков есть и их кол-во
на узле есть 4 датчика типа x, 2 типа y, 1 типа z.
ну и как хранить информацию с датчиков прикажете? Есть двумерный массив.
Судя по твоим высказываниям вижу только один выход - задавать фиксированное количество адресов у всех типов. Я с тобой то согласен, только как это ,блин , всё запрограммировать. эти массивы они же вредные. если пихать в то же измерение адрес, то например у одно типа сделал 20 адресов и все типы стали с 20 адресами. Переменную величину то не сделать.
ну и как хранить информацию с датчиков прикажете? Есть двумерный массив.
Судя по твоим высказываниям вижу только один выход - задавать фиксированное количество адресов у всех типов. Я с тобой то согласен, только как это ,блин , всё запрограммировать. эти массивы они же вредные. если пихать в то же измерение адрес, то например у одно типа сделал 20 адресов и все типы стали с 20 адресами. Переменную величину то не сделать.
А зачем их все хранить?
Нужно определить что нужно хранить а что можно перезапросить.
Все климатические параметры хранить нет смысла. Состояние ламп вкл/выкл спорно можно и опросить,
Бузусловно нужно хранить например количество людей в помещении да и то нужно определить где хранить на light или main. А вот все остальное зачем?
Давай все же логику обемена - работы определим. Причем не под железо код а под себя любимых. Как должна себя вести система в зависимости от событий булевых и аналоговых и какие воздействия и на что она должна выдавать.
a. Датчики движения для выключения света более чем 20 минут.
09
b. Уменьшение и увеличение яркости подсветки в коридоре по датчику движения
10
c. Если естественное освещение в комнате будет ниже 50%, то система добавит искусственное освещение до 50%. Если естественное освещение будет ниже 40%, то система добавит освещение до 60% и т.д. Это очень удобно во время заката или в пасмурный день.
11
8. Управление подсветкой одноцветной
12
9. Управление подсветкой RGB
13
10. Охрана (датчики движения) геркон на двери и электронный замок
14
11. Видеонаблюдение.
15
12. Домофон в коридоре, кухне, спальне, кабинете
16
13. Связь GSM и и интернет
17
14. Учет воды, газа, электричества.
18
15. Управление кондиционированием
19
16. Управление отоплением
20
17. Управление вентиляцией
21
18. Управление телевизорами, акустикой, проектором.
22
19. Календарь дат и напоминания
23
20.
24
21. Управление полотенцесушителем
25
26
1. Во всех помещениях – температура, влажность, освещенность, движение, протечка
Ууу блин, мы же говорили 1 параметр 1 фрейм, чтобы четко понимать запросил температуру у датчика на потолке и от него и получил
Так вы все-таки запрашиваете данные от датчиков? Мастер-слэйв, а ля Модбас? А зачем тогда CAN?
Где то была уже выше описана концепция. Поэтому коротко.
Все узлы могут передавать в любое время, и по заданному алгоритму инициативно рассылают информацию. Тем не менее есть мастер (слейв как дублирующая система, пока мастер работоспособен слейв не выполняет никаких функций кроме контроля мастера, в случае же аварии мастера берет на себя его функции) который является как контролирующим для всей сети так и шлюзом с внешними управляющими системами.
На выходе любой узел передает данные как инициативно так и по запросу. Узел с НАЗВАНИЕМ Мастер сидит выше в модели ОСИ и несет не коммуникационные а шлюзовые и контролирующие функции.
Все запросы к узлам нужны для работу более сложных сценариев если это потребуется далее, причем выполняемых на сервере, где они будут храниться вместе с анными, не хочется убирать эту возможность и тем более хранить эту информацию в пямяти контроллеров.
Да и еще, запросить параметр или дать команду на исполнение может не только узел с НАЗВАНИЕМ мастер, но и любой узел у любого узла.
с трехмерным массивом стрёмненько получается. Загрузка ОЗУ МЕГИ 43%. При том что массив на 10% только используется, даже меньше (смотри тип данных где 0 - значит № такого датчика отсутсвует на узле).
Можно количество датчиков максимум 5 сделать а не 20.
с трехмерным массивом стрёмненько получается. Загрузка ОЗУ МЕГИ 43%. При том что массив на 10% только используется, даже меньше (смотри тип данных где 0 - значит № такого датчика отсутсвует на узле).
Можно количество датчиков максимум 5 сделать а не 20.
блин, всё вкурил как ты хочешь сделать
блин ну не пойму я смысла. Это всё и так лежит в энергонезависимой памяти, которая называется флеш. В ней залит скетч. В скетче есть эта информация. Дак нафига её в еепром то пихать? В том то и дело, если ты ничего подключать дополнительно не собираешься вообще не имеет смысла в еепром пихать. Т.к. туда пихается обычно изменяемая инфа. А постоянная она из флеша (скетча) спокойно также грузится.
Ты же сам предложил епром чтобы заливать в 15 МК один и тот же скетч. Да в большей степени они одинаковые по ИУ и датчикам но есть и различия.
блин, всё вкурил как ты хочешь сделать
Один отлаженный скетч на все МК это песня будет.
P.S.
Я просто на производстве работаю и постоянно бъемся за унификацию плат, разъемов кода и пр.
я чёто тупанул, думал вместо массива с настройками ты хочешь постоянно обращаться в еепром при работе скетча. А ты просто в принципе все мои массивы хочешь оставить, но чтобы они инициализировались только при старте, в соответсвии с еепром .
Т.е. да, скетч получается один на всех. А в процессе настраиваем каждый узел по Serial например или вообще по кану можно (настраивая тем самым еепром, потом ресет и уже пошёл скетч работать). Соответсвенно у всех МК будет два режима
- режим конфигурации,
- рабочий режим.
Блин, это всё как у меня на работе. Допустим новый блок управления идёт один и тот же на все комплектации автомобиля и при установке ты его конфигурируешь, в зависимости от комплектации автомобиля.
Адектаватная концепция.
Я просто на производстве работаю и постоянно бъемся за унификацию плат, разъемов кода и пр.
Блин, это всё как у меня на работе. Допустим новый блок управления идёт один и тот же на все комплектации автомобиля и при установке ты его конфигурируешь, в зависимости от комплектации автомобиля.
)))
это всё конечно прикольно, я уже приводил в посте #848 такой пример. смотри файлы screen1... screen16. Но это когда есть возможности для создания программы конфигуратора. Это ещё можно пару месяцев потратить на то чтобы наладить настройку конфигурации например по Serial или по кан, т.к. я вообще не петрю в создании программ для винды, и не осилю такую задачу. А с терминала конфигурировать какими то кодировками - это извините - проще в иде мои массивы заполнить и залить скетч.
это всё конечно прикольно, я уже приводил в посте #848 такой пример. смотри файлы screen1... screen16. Но это когда есть возможности для создания программы конфигуратора. Это ещё можно пару месяцев потратить на то чтобы наладить настройку конфигурации например по Serial или по кан, т.к. я вообще не петрю в создании программ для винды, и не осилю такую задачу. А с терминала конфигурировать какими то кодировками - это извините - проще в иде мои массивы заполнить и залить скетч.
Так я и говорю делаем пока функции эмуляторы работающие с файлом например Config.h
это всё конечно прикольно, я уже приводил в посте #848 такой пример. смотри файлы screen1... screen16. Но это когда есть возможности для создания программы конфигуратора. Это ещё можно пару месяцев потратить на то чтобы наладить настройку конфигурации например по Serial или по кан, т.к. я вообще не петрю в создании программ для винды, и не осилю такую задачу. А с терминала конфигурировать какими то кодировками - это извините - проще в иде мои массивы заполнить и залить скетч.
вот вспомнил, есть интересный проект умной теплицы уважаемого коллеги по форуму DIYMan. Много чего можно взять на заметку. Например идея конфигуратора это гуд. Но не в моих силах к сож. Автор гораздо опытнее в программировании, меня точно.
Ну примерно так я себе это и представляю на выходе.
... управлять микроконтроллером отовсюду, откуда только можно: непосредственно жмакнуть на кнопочку .... По Wi-Fi с домашнего компьютера... По витой паре ..! Со смартфона - ....
Задача ставилась такая:
1. я заранее не знаю, какой функционал мне надо будет дописать, это раз.
2. Не хочу некрасивого кода простынями по нескольку экранов в одной функции - это два.
3. Система модульная .
4. Модули могут быть как в пределах одной коробки, так и разнесены в пространстве .
5. Модули должны поддерживать прозрачное общение друг с другом "из коробки"
6. лёгкая расширяемость поддерживаемых команд
- архитектура устроена так, что посылать команды контроллеру (давайте пока называть главный модуль контроллером, для ясности) можно из любого источника, достаточно только написать поддержку этого источника и зарегистрировать его в программном коде, буквально одной строкой.
- если завтра вам понадобится встроить поддержку датчика температуры, то для его опроса не надо будет писать огромную простыню в функции loop - достаточно написать простенький новый модуль, который и будет выполнять эту чёрную работу. Код в loop при этом не изменится ни на йоту - вместо этого просто добавиться одна строчка в setup, для инициализации модуля.
- Ну допустим, что есть у вас код, который опрашивает датчик и выводит температуру на экран. И захотели вы, помимо вывода на экран - выводить всё это в Serial. Да не просто выводить, а по запросу из Serial же. Короче, уже представляете, сколько зависимостей, да? А вот и нет! Не надо специально корячиться и переписывать модуль для вывода на экран - архитектура, повторюсь, такова, что модуль только отдаёт или устанавливает свое внутреннее состояние, по запросу извне. Откуда пришёл запрос - ему чхать, куда всё это выведется - наплевать. И вот на этом моменте вы подключаете к этому модулю модуль публикации на дисплей (одной строкой кода) - и всё! Просто, правда?
https://www.forumhouse.ru/threads/341712/
Пришла и мне Mega Pro от robotdyn . Всего 12 дней шла. Я уж и забыл, что из китая так быстро посылки могут приходить. Померил, плата MCP2515 точь в точь входит в развал между пинами меги. поэтому в LAYOUT шилд рисую - не люблю на проводочках всё. На шилже можно также уместить и ESP. кинь схему как ты еспшку подключаешь.
ПС. Я ещё студентом был купил квадратный метр медного текстолита. Всё ещё израсходовать не могу. Платы ЛУТом быстро делать когда всё подготовлено. (поваренная соль, лимонная кислота, перекись водорота, медный текстолит, карандаш, линейка, лобзик с пилкой по металлу, наждачка нулёвка и чуть крупнее, дремель с мелким сверлом , ватные диски, жидкость для снятия лака, журнальные глянцевые тонкие листы, ножницы, лазерный принтер, утюг ).
ПС. Я ещё студентом был купил квадратный метр медного текстолита. Всё ещё израсходовать не могу. Платы ЛУТом быстро делать когда всё подготовлено. (поваренная соль, лимонная кислота, перекись водорота, медный текстолит, карандаш, линейка, лобзик с пилкой по металлу, наждачка нулёвка и чуть крупнее, дремель с мелким сверлом , ватные диски, жидкость для снятия лака, журнальные глянцевые тонкие листы, ножницы, лазерный принтер, утюг ).
Да молодость вспоминается. ;-)
Но я все же думаю что на этом этапе пока нет смысла этим заниматься. Пока не отлажены технические решения заниматься сборкой рано. Вдруг что то еще появится.
А на выходе может и свою плату разведу под ATmega2560 + MCP2515 + TJA1050 + сверху 8266 (ESP07) + еще что нибудь. (пока не знаю, поэтому пока паяный конструктор) затем у китайцеав закажу изготовление.
Вот кстати вопрос на засыпку посоветуй малогабаритный разъем (не жутко дорогой) для подключения этой меги к кабелям из стены. Может для магнитолы или еще что то пинов на 20-40 а лучше 60.
P.S.
Хотя ты знаешь мысль дельная с шилдом, но от него всеравно гибкий паяный жгут нужно делать с разъемом и разъем из стены + разъем к датчикам. До дома доберусь сделаю фото как у меня подрозетники для МК сделаны по квартире.
Еще вопрос, у тебя в byte parameter [6][parameters_quantity перечисленны не все датчики
я хочу добавить СО2 датчик, мне нужно во все 6 {} вставить что то?
Вообще я не понял зачем ты усложнял. Ты сделал возможность произволь назначать тип датчика на произвольный номер строки массива. А зачем? Номер строки в массиве = № датчика. Если делать на eeprom то придется делать фиксированный тип массива с типовыми датчиками и их адресами.
Конечно не все перечислены. Я просто от балды несколько вставил и всё.
я чуть усложнил, чтобы не забивать память МК, когда реально на узле параметр отсутсвует.
Да, конечно нужно во все 6 вставить информацию, по сути в одном только адрес параметра, а в оставльных настройки этого параметра.
я немного переделаю сейчас массив параметры. Не нужно будет после настройки массива подсчитывать сколько параметров забили в узел, МК сам будет это делать. И понагляднее будет.
Я все же предлагаю обсудить идеологию, а то мы под удобство реализации кода ушли от основной цели.
Нужно определиться
1. Тип датчиков температуры 1 или несколько и по осталным тоже. Вот например у меня есть BME280, SI7021, DS18S20
2. В принципе сколько будет датчиков однотипных на узле. У меня их может быть от 0 до 4.
3. Работаем ли мы с датчиком как с абстракцией или с железными пинами.
Так вот ответ на эти вопросы показывает что к сожалению нужен тип датчика по возможностям (температура, влажность ...), тип датчика по железу, № датчика на узлею То же по ИУ.
Мы рано начали реализовывать функционал не добившись работы протокола в разных режимах.
Нужно добить протокол.
работаем с параметром. А как он обновляется - неважно. Как раз предлагаемая DIYMan концепция. Т.е., например, параметр температуры воды ты обновляешь далласом , а температуры воздуха - BME. Код работы с параметром по кан, веб и т.д. не поменяется от этого. Ты лишь "подключишь " к параметру определённый модуль в скетче, в данном случае далласа или BME
Не совсем об этом речь, я изначально помнишь предлагал тип датчика и адрес датчика (ну или его номер на узле)
Вот смотри лог
01
ID DLC Data Period Count Comment
02
14050401 5 4F 00 09 08 00 62 26 05 температура
03
14050402 5 50 00 09 01 00 62 26 05 влажность
04
14050403 5 51 00 09 01 00 63 26 05 давление
05
14060401 5 4F 00 09 08 00 65 26 06 температура
06
14060402 5 50 00 09 01 00 65 26 06 влажность
07
14060403 5 51 00 09 01 00 64 26 06 давление
08
14070401 5 4C 00 09 08 00 62 25 07 температура
09
14070402 5 4D 00 09 01 00 64 25 07 влажность
10
14070403 5 4E 00 09 01 00 64 25 07 давление
11
14080401 5 4F 00 09 08 00 65 26 08 температура
12
14080402 5 50 00 09 01 00 65 26 08 влажность
13
14080403 5 51 00 09 01 00 64 26 08 давление
14
14090401 5 4F 00 09 08 00 63 26 09 температура
15
14090402 5 50 00 09 01 00 63 26 09 влажность
16
14090403 5 51 00 09 01 00 63 26 10 давление
17
140A0401 5 4C 00 09 08 00 65 25 10 температура
18
140A0402 5 4D 00 09 01 00 65 25 10 влажность
19
140A0403 5 4E 00 09 01 00 64 25 10 давление
20
140B0401 5 46 00 09 08 00 64 23 11 температура
21
140B0402 5 47 00 09 01 00 62 23 11 влажность
22
140B0403 5 48 00 09 01 00 63 23 11 давление
23
140C0401 5 4F 00 09 08 00 64 26 12 температура
24
140C0402 5 50 00 09 01 00 63 26 12 влажность
25
140C0403 5 51 00 09 01 00 63 26 12 давление
26
140D0401 5 4F 00 09 08 00 63 26 13 температура
27
140D0402 5 50 00 09 01 00 61 26 13 влажность
28
140D0403 5 51 00 09 01 00 61 26 13 давление
29
140E0401 5 4F 00 09 08 00 63 26 14 температура
30
140E0402 5 50 00 09 01 00 62 26 14 влажность
31
140E0403 5 51 00 09 01 00 62 26 14 давление
32
140F0401 5 4F 00 09 08 00 63 26 15 температура
33
140F0402 5 50 00 09 01 00 61 26 15 влажность
34
140F0403 5 51 00 09 01 00 61 26 15 давление
35
14120401 5 4F 00 09 08 00 61 26 18 температура
36
14120402 5 50 00 09 01 00 62 26 18 влажность
37
14120403 5 51 00 09 01 00 62 26 18 давление
38
14130401 5 4F 00 09 08 00 63 26 19 температура
39
14130402 5 50 00 09 01 00 63 26 19 влажность
40
14130403 5 51 00 09 01 00 62 26 19 давление
41
14140401 5 4F 00 09 08 00 62 27 20 температура
42
14140402 5 50 00 09 01 00 62 27 20 влажность
43
14140403 5 51 00 09 01 00 62 27 20 давление
44
14150401 5 4C 00 09 08 00 64 26 21 температура
45
14150402 5 4D 00 09 01 00 63 26 21 влажность
46
14150403 5 4E 00 09 01 00 62 26 21 давление
47
16040000 8 5C 14 0E 00 00 00 00 00 1000 1528 04 широковещательный запрос статуса узлов сети
48
16050400 8 00 00 00 00 00 00 00 00 1000 1528 05 статус ОК
49
16060400 8 00 00 00 00 00 00 00 00 999 1528 06 статус ОК
50
16070400 8 00 00 00 00 00 00 00 00 1000 1523 07 статус ОК
51
16080400 8 00 00 00 00 00 00 00 00 1002 1525 08 статус ОК
52
16090400 8 00 00 00 00 00 00 00 00 1002 1521 09 статус ОК
53
160A0400 8 00 00 00 00 00 00 00 00 999 1519 10 статус ОК
54
160B0400 8 00 00 00 00 00 00 00 00 1001 1519 11 статус ОК
55
160C0400 8 00 00 00 00 00 00 00 00 1002 1525 12 статус ОК
56
160D0400 8 00 00 00 00 00 00 00 00 1000 1528 13 статус ОК
57
160E0400 8 00 00 00 00 00 00 00 00 1000 1526 14 статус ОК
58
160F0400 8 00 00 00 00 00 00 00 00 1002 1524 15 статус ОК
59
16120400 8 00 00 00 00 00 00 00 00 1002 1528 18 статус ОК
60
16130400 8 00 00 00 00 00 00 00 00 1001 1524 19 статус ОК
61
16140400 8 00 00 00 00 00 00 00 00 1002 1523 20 статус ОК
62
16150400 8 00 00 00 00 00 00 00 00 1000 1527 21 статус ОК
Как понять это датчик температуры у потолка или у пола?
Приходит просто тип датчика, а нужно знать еще его номер в на узле и его HW тип (насчет HW не уверен)
Я понимаю что ты можешь посспорить на тему зачем мне 2 или 5 датчиков на одном узле. Но! Например вот таких датчиков https://ru.aliexpress.com/item/High-quality-E18-D80NK-infrared-obstacle-avoidance-sensor-3-50cm-adjustable-free-shipping/1999477248.html?spm=a2g0s.9042311.0.0.274233edw70RXk у меня по 2 в каждом помещении. Как быть?
Либо отправлять на мастер количество людей в помещении либо передавать событие сработки датчика 1->2 или 2->1 (направление прохода)
И слушай я так и не понял зачем ты делаешь DLC не 8? Проще же везхде работать с байт 0-7 чем думать есть у меня в датафрейме например 7 байт или нет.
Как понять это датчик температуры у потолка или у пола?
Я понимаю что ты можешь посспорить на тему зачем мне 2 или 5 датчиков на одном узле. Но! Например вот таких датчиков у меня по 2 в каждом помещении. Как быть?
заведи ещё один параметр - температура вверху, температура внизу. К каждому параметру будет привязан свой датчик.
И слушай я так и не понял зачем ты делаешь DLC не 8? Проще же везхде работать с байт 0-7 чем думать есть у меня в датафрейме например 7 байт или нет.
там есть несколько мест где считывается количсетво байт во фрейме. Наример, когда делаем запрос параметра у какого-нибудь узла, Тело запроса состоит таким образом. Нулевой байт поля данных это глобальный счетчик. А вот дальше идут байты адресов параметров (до 7 шт.). Т.е. с одного запроса мы можем запросить до 7 параметров. Соответсвенно если нужно 3 запросить, то поле данных будет из четырех байт:
счетчик, и три байта адреса параметра. DLC=4
А при ответе параметра , если у нас параметр однобайтовый будет DLC = 5
двухбайтовый DLC = 6
четырехбайтовый DLC = 8
И слушай я так и не понял зачем ты делаешь DLC не 8? Проще же везхде работать с байт 0-7 чем думать есть у меня в датафрейме например 7 байт или нет.
там есть несколько мест где считывается количсетво байт во фрейме. Наример, когда делаем запрос параметра у какого-нибудь узла, Тело запроса состоит таким образом. Нулевой байт поля данных это глобальный счетчик. А вот дальше идут байты адресов параметров (до 7 шт.). Т.е. с одного запроса мы можем запросить до 7 параметров. Соответсвенно если нужно 3 запросить, то поле данных будет из четырех байт:
счетчик, и три байта адреса параметра. DLC=4
А при ответе параметра , если у нас параметр однобайтовый будет DLC = 5
двухбайтовый DLC = 6
четырехбайтовый DLC = 8
Самый главный вопрос зачем это. Какая цель преследовалась для такого усложнения?
ты мне скажи в чём усложнение то? если будут ноль байты, это вообщето тоже информация (например нулевой адрес). А когда их нет, мы соотвественно и не обращаем на них внимания. Вот предствавь что у нас есть нулевой адрес у параметров.
По моей схеме как запрос параметров сделать ? вот запрос 56 01 05 08 00 00 00 00
56 - счетчик 01 05 08 запрашиваемые параметры, но нулевые параметры в запросе присутсвуют и узел четыре раза ответит и параметром с нулевым адресом.
Я уже не говорю о том, что по моей схеме шина меньше загружается.
ты мне скажи в чём усложнение то? если будут ноль байты, это вообщето тоже информация (например нулевой адрес). А когда их нет, мы соотвественно и не обращаем на них внимания. Вот предствавь что у нас есть нулевой адрес у параметров.
По моей схеме как запрос параметров сделать ? вот запрос 56 01 05 08 00 00 00 00
56 - счетчик 01 05 08 запрашиваемые параметры, но нулевые параметры в запросе присутсвуют и узел четыре раза ответит и параметром с нулевым адресом.
Я уже не говорю о том, что по моей схеме шина меньше загружается.
Ок понял.
короче я поменял местами измерения у массива параметр. (это нужно чтобы автоматически определять размер массива - количество присутсвующих параметров. )
Смотри в основном изменения в файле can_struct.h касаемые parameter [][].
Также теперь можно добавлять количество узлов, на которые будет автоматически отсылаться один и тот же параметр (по умолчанию стоит 2)
версия 17
И слушай я так и не понял зачем ты делаешь DLC не 8? Проще же везхде работать с байт 0-7 чем думать есть у меня в датафрейме например 7 байт или нет.
там есть несколько мест где считывается количсетво байт во фрейме. Наример, когда делаем запрос параметра у какого-нибудь узла, Тело запроса состоит таким образом. Нулевой байт поля данных это глобальный счетчик. А вот дальше идут байты адресов параметров (до 7 шт.). Т.е. с одного запроса мы можем запросить до 7 параметров. Соответсвенно если нужно 3 запросить, то поле данных будет из четырех байт:
счетчик, и три байта адреса параметра. DLC=4
А при ответе параметра , если у нас параметр однобайтовый будет DLC = 5
двухбайтовый DLC = 6
четырехбайтовый DLC = 8
Ууу блин, мы же говорили 1 параметр 1 фрейм, чтобы четко понимать запросил температуру у датчика на потолке и от него и получил
так и есть. Это когда тип сообщения ответ парамтера. А в запросе сразу можно несколько запросить. Ну если хочешь всегда один запрашивай - кто мешает.
Как понять это датчик температуры у потолка или у пола?
Я понимаю что ты можешь посспорить на тему зачем мне 2 или 5 датчиков на одном узле. Но! Например вот таких датчиков у меня по 2 в каждом помещении. Как быть?
заведи ещё один параметр - температура вверху, температура внизу. К каждому параметру будет привязан свой датчик.
Вот структура
И по разъему посоветуешь чтонибудь? Автомобильный или для магнитолы или еще какой?
нет ты не понял. вот так надо
01
// НИЖЕ АДРЕСА ПАРАМЕТРОВ, ПРИМЕНЯЕМЫХ В УМНОМ ДОМЕ
02
03
typedef
enum
Parameter_addr_enum
04
{
05
null_param,
//0
06
air_t ,
//1 //датчик температуры
07
air_h ,
//2 //датчик влажности
08
air_p ,
//3 //датчик давления
09
mot_pir ,
//4 //
10
moti_mw ,
//5 //датчик движения
11
vibrat ,
//6 //датчик вибрации
12
noise ,
//7 //датчик шума
13
Illum ,
//8 //датчик освещенности
14
gas_co ,
//9 //датчик СО
15
gas_co2 ,
//10 //датчик СО2
16
gas_met ,
//11 //датчик метана
17
smoke ,
//12 //датчик курения
18
fire ,
//13 //датчик Огня
19
body_temp ,
//14 //Температура тела
20
jal_stat ,
//15 //Концевик Жалюзи
21
steam ,
//16 //Датчик Пара
22
microwave ,
//17 //Излучение микроволновки
23
fridge_temp ,
//18 //Холодильник
24
freezer_temp ,
//19 //Морозилка
25
oven_temp ,
//20 //Духовка
26
elec_board ,
//21 //Электрощит концевик
27
door_lock ,
//22 //Замок двери
28
door_close ,
//23 //Концевик двери
29
mot_door1 ,
//24 //Датчик прохода 1
30
mot_door2 ,
//25 //Датчик прохода 2
31
wind_close ,
//26 //Закрыто
32
water_hot_temp ,
//27 //Температура горячей воды
33
water_cold_temp ,
//28 //Температура холодной воды
34
water_hot_pres ,
//29 //Давление горячей воды
35
water_cold_pres ,
//30 //Давление холодной воды
36
leakage ,
//31 //Протечка
37
aquar_lamp ,
//32 //Лампа аквариум
38
aquar_temp ,
//33 //Температура аквариум
39
aquar_pump ,
//34 //Насос аквариум
40
aquar_clearing ,
//35 //Очистка аквариум
41
cupboard_door ,
//36 //Дверь шкафа
42
safe_door ,
//37 //Дверь сейфа
43
balcony_door ,
//38 //Дверь балкона
44
loggia_door ,
//39 //Дверь лоджии
45
radiator_temp_S ,
//40 //Температура батареи
46
lamp_ceiling ,
//41 //Лампа на потолке
47
lamp_wall ,
//42 //Ланпа настенная
48
lamp_Illum ,
//43 //Лампа подсветки
49
lamp_accident ,
//44 //Лампа аварийная
50
earth_humidity ,
//45 //Влажность земли
51
counter_gas_2 ,
//46 //Счетчик газа
52
counter_gas_2_SB2 ,
//47 сервисный байт
53
counter_water_hot_2 ,
//48 //Счетчик горячей воды
54
counter_water_hot_2_SB2 ,
//49 сервисный байт
55
counter_water_cold_2 ,
//50 //Счетчик холодной воды
56
counter_water_cold_2_SB2 ,
//51 сервисный байт
57
counter_elect_4 ,
//52 //Счетчик электричества
58
counter_elect_4_SB2 ,
//53 сервисный байт
59
counter_elect_4_SB3 ,
//54 сервисный байт
60
counter_elect_4_SB4 ,
//55 сервисный байт
61
ups_voltage_4F ,
//56 //напряжение АКБ бесперебойника
62
ups_voltage_4F_SB2 ,
//57 сервисный байт
63
ups_voltage_4F_SB3 ,
//58 сервисный байт
64
ups_voltage_4F_SB4 ,
//59 сервисный байт
65
air_t _UP ,
//60 температура воздуха вверху
66
air_t _DOWN ,
//61 температура воздуха внизу
67
SIZE_PARAM_ARRAY
//62 size // общее количество параметров, применяемых в умном доме
68
}Parameter_addr_ENUM;
смотри параметр 60 и 61
и будут у тебя разные канфреймы 1405043С 94 00 08 08 01
1405043D 94 00 08 08 01
по разъему может несколько лучше делать. 4 pin овые например. У тебя ведь не в общем жгуте все провода приходят?
смотри внимательно версию 17 я там вместо дефайнов , енум сделал у параметров
Не это совсем не правильно, это уже уникальное имя датчика
Мы же говорили тип датчика адрес датчика. Т.е - тип №1 адрес №1, тип №1 адрес №2, тип №1 адрес №3, (как я выше писал) где тип №1 температурный датчик а 1,2,3 адрес-расположение.
а сейчас "типа" в принципе уже нет есть описание равное номеру т.е
1 датчик называется тип ххх
2 называется ууу
3 zzz
Я то думал будет тип лампа а потом ее номер 1 вот так
1. [лампа][1]
2. [лампа][2]
3. [температура][1]
4. [лампа][3]
а теперь выходит так
1. лампа№1 с значениями
2. лампа№2 с значениями
3 датчик температуры№1 с значениями
4 лампа№3 с значениями
т.е 2 разных ьтипа в общем то однотипного устройства лампа на потолке 1 и лампа на потолке у тебя 2 разных типа устройст, а должен был быть один с адресами.
В итоге в node_11_Kitchen_light.ino у меня 20 реле и больше ничего и будет не 1 тип с 20 адресами а 20 разных типов так?
реле будут в исп механизмах
Мы же говорили тип датчика адрес датчика. Т.е - тип №1 адрес №1, тип №1 адрес №2, тип №1 адрес №3, (как я выше писал) где тип №1 температурный датчик а 1,2,3 адрес-расположение.
а чего тогда в списке параметров у тебя несколько температур? Адреса 1, 27 , 28 , 40, 33
В итоге в node_11_Kitchen_light.ino у меня 20 реле и больше ничего и будет не 1 тип с 20 адресами а 20 разных типов так?
да, а че такого? неужели прям через 254 перевалят все параметры? сомневаюсь
по разъему может несколько лучше делать. 4 pin овые например. У тебя ведь не в общем жгуте все провода приходят?
Я что то такого типа хочу, чтобы все из стены распаяно было на жгут и в руках ардуина с CAN подключалась жгутом. Ну как в авто, открываешь лючок а там блок, отключил проводку блок снял и унес.
можно компьютерный взять который com25.
ну если ты так хочешь тип всё таки у нас есть в поле данных параметра один свободный байт))
В итоге в node_11_Kitchen_light.ino у меня 20 реле и больше ничего и будет не 1 тип с 20 адресами а 20 разных типов так?
да, а че такого? неужели прям через 254 перевалят все параметры? сомневаюсь
Дело в логике построения. Если у каждого датчика имя собственное зачем тогда типы придумывать. Тогда на каждый контроллер уникальный код.
Одно дело поросить все датчики температуры, другое опросить все датчики температуры там, потом там, а про тип датчика температуры за унитазом а и забыл, а а эти типы я потом ввел и писец.
А если тип один и есть адреса и пожно получить длинну занятых адресов, то можно for прокрутить и все опросить, а так я должен четко знать какие типы темп. датчиков у меня существуют и какие есть на данном узле.
Посмотри код и принцип построения Умной теплицы, особенно на форуме когда он начинал. Я выжимки выше делал, но лучше форум.
Должно быть четкое бинарно матричное деление а не одномерный массив.
ну если ты так хочешь тип всё таки у нас есть в поле данных параметра один свободный байт))
Это не я хочу это логика требует.
И кстати мы мух с котлетами путать начинаем. Я это уже говорил.
Сначала протокол. Хранение и настройка. В итоге ты в связи с тем что так проще хранить усложняешь протокол.
Мастер (да и любой узел) должен иметь возможность запросить у узла параметр датчика типа ххх №yyy а так же какие датчики типы датчиков есть и их кол-во
на узле есть 4 датчика типа x, 2 типа y, 1 типа z.
ну и как хранить информацию с датчиков прикажете? Есть двумерный массив.
Судя по твоим высказываниям вижу только один выход - задавать фиксированное количество адресов у всех типов. Я с тобой то согласен, только как это ,блин , всё запрограммировать. эти массивы они же вредные. если пихать в то же измерение адрес, то например у одно типа сделал 20 адресов и все типы стали с 20 адресами. Переменную величину то не сделать.
короче весь скетч переписывать.
У каждой переменной получается дикий адрес - сначала адрес узла, потом тип девайса и в конце номер датчика. Тройной адрес получается.
короче весь скетч переписывать.
У каждой переменной получается дикий адрес - сначала адрес узла, потом тип девайса и в конце номер датчика. Тройной адрес получается.
Ну с самого начала так было, потом поняли что в ID не хватает для адресов и ушли в 1 байт data. А сейчас все подругому.
Давай может пойдем как у меня на работе сформируем ТТ ну или хотя бы ОТТ, разобъем на этапы.
А насчет переписывать, у нас сейчас идет выработка технических решений. (Как в ОКР Эскизный, Технический и только поторм РКД).
малой кровью можно обойтись, если добавить третье измерение к массиву parameter, котороое и будет указывать на номер датчика
ну и как хранить информацию с датчиков прикажете? Есть двумерный массив.
Судя по твоим высказываниям вижу только один выход - задавать фиксированное количество адресов у всех типов. Я с тобой то согласен, только как это ,блин , всё запрограммировать. эти массивы они же вредные. если пихать в то же измерение адрес, то например у одно типа сделал 20 адресов и все типы стали с 20 адресами. Переменную величину то не сделать.
А зачем их все хранить?
Нужно определить что нужно хранить а что можно перезапросить.
Все климатические параметры хранить нет смысла. Состояние ламп вкл/выкл спорно можно и опросить,
Бузусловно нужно хранить например количество людей в помещении да и то нужно определить где хранить на light или main. А вот все остальное зачем?
Давай все же логику обемена - работы определим. Причем не под железо код а под себя любимых. Как должна себя вести система в зависимости от событий булевых и аналоговых и какие воздействия и на что она должна выдавать.
Т.е перечень событий (не датчиков а событий)
Зима-лето. День-ночь. Есть люди в помещении нет.
Климат. Свет. Охрана. ....
Я тут как то начинал ...
001
1. Функции Умного дома
002
1.1. Управление безопасностью
003
1.1.1. Защита от незаконного проникновения
004
1.1.1.1. Входная дверь
005
1.1.1.2. Окна
006
1.1.2. Контроль доступа
007
1.1.2.1. Входная дверь
008
1.1.2.2. Закрытые для детей помещения
009
1.1.2.3. Закрытые для гостей помещения
010
1.1.2.4. Перемещения по квартире
011
1.1.2.5. Учет людей в помещениях
012
1.1.2.6. Сейфы
013
1.1.3. Защита от утечек газа
014
1.1.3.1. Кухня – контроль, перекрытие газа, оповещение голосовое и СМС
015
1.1.4. Защита от протечек воды
016
1.1.4.1. Кухня - контроль, перекрытие воды, оповещение голосовое и СМС
017
1.1.4.2. Туалет - контроль, перекрытие воды, оповещение голосовое и СМС
018
1.1.4.3. Ванная - контроль, перекрытие воды, оповещение голосовое и СМС
019
1.1.5. Защита от затопления соседями
020
1.1.5.1. Все помещения - контроль, оповещение голосовое и СМС
021
1.1.6. Защита от пожара
022
1.1.6.1. Все помещения - контроль, оповещение голосовое и СМС
023
1.1.7. Контроль качества воздуха –СО, СО2 и пр.
024
1.1.8. Контроль включения электронагревательных приборов и электричества
025
1.1.9. Контроль включенности газовой плиты
026
1.2. Учет коммунальных услуг
027
1.2.1. Газ - учет, расчет, оповещение о необходимости оплаты голосовое и СМС, хранение
028
1.2.2. Свет - учет, расчет, оповещение о необходимости оплаты голосовое и СМС, хранение
029
1.2.3. Вода - учет, расчет, оповещение о необходимости оплаты голосовое и СМС, хранение
030
1.2.4. Электричество - учет, расчет, оповещение о необходимости оплаты голосовое и СМС, хранение
031
1.2.5. Отопление ?
032
1.3. Управление освещением
033
1.3.1. Основное освещение - Все помещения
034
1.3.1.1. Включение – выключение электрических ламп
035
1.3.1.2. Диммирование - электрических ламп
036
1.3.1.3. Сцены
037
1.3.1.4. Жалюзи – открытие закрытие
038
1.3.2. Посветка - Помещения с подсветкой (Коридор, Кухня, Спальня, Гостиная)
039
1.3.2.1. Включение – выключение светодиодной подсветки
040
1.3.2.2. Диммирование светодиодной подсветки
041
1.3.2.3. Сцены
042
1.3.3. Аварийное освещение
043
1.3.3.1. Помещения с аварийным освещением - Коридор
044
1.4. Управление климатом
045
1.4.1. Нагрев - все помещения с водяными и электронагревательными приборами –(Кухня, Ванная, Кабинет, Спальня, Гостиная)
046
1.4.1.1. Нагрев радиаторами отопления
047
1.4.1.2. Нагрев инверторным кондиционером
048
1.4.1.3. Нагрев Электрическим радиатором
049
1.4.1.4. Нагрет теплыми полами
050
1.4.2. Охлаждение
051
1.4.2.1. Охлаждение кондиционером
052
1.4.2.2. Охлаждение приточной вентиляцией
053
1.4.3. Вентиляция
054
1.4.3.1. Приточная
055
1.4.3.2. Вытяжная
056
1.4.3.3. Рекуперация
057
1.4.4. Влажность
058
1.4.4.1. Помещения резко изменяемой влажностью – кухня, ванная
059
1.4.4.2. Помещения требующие комфорта - спальня
060
1.5. Управление медиа контентом
061
1.5.1. ТВ
062
1.5.1.1. IP TV (Multicast)
063
1.5.1.2. Кабельное TV
064
1.5.1.3. SAT TV
065
1.5.1.4. Интернет TV
066
1.5.2. Радио
067
1.5.2.1. Интернет Радио
068
1.5.2.2. Эфирное радио
069
1.5.2.3. Городская трансляция
070
1.5.3. Кино
071
1.5.3.1. Интернет
072
1.5.3.2. Хранилище
073
1.5.4. Музыка
074
1.5.4.1. Интернет
075
1.5.4.2. Хранилище
076
1.5.5. Аудиокниги
077
1.5.5.1. Интернет
078
1.5.5.2. Хранилище
079
1.6. Справочная система
080
1.6.1. На систему
081
1.6.2. Общая
082
1.7. Информационная система
083
1.7.1. Погода
084
1.7.2. Пробки
085
1.7.3. Новости
086
1.7.4. Местонахождение жильцов
087
1.7.5. Состояние телефонов (заряд)
088
1.7.6. Коммунальные платежи
089
1.7.7. Новинки фильмов
090
1.7.8. Трек почтовых отправлений
091
1.8. Заказ товаров и услуг
092
1.8.1. Пицца
093
1.8.2. Билеты в кино
094
1.8.3. Такси
095
1.8.4. Вызов служб аварийных
096
1.9. Учет и контроль финансов
097
1.9.1. Приходы
098
1.9.2. Расходы
099
2. Уровни управления умным домом
100
2.1. Ручной – управление исполнительными устройствами штатными органами управления
101
2.1.1. Безопасность
102
2.1.2. Учет коммунальных услуг
103
2.1.3. Управление освещением
104
2.1.4. Управление климатом
105
2.1.5. Управление медиа контентом
106
2.1.6. Справочная система
107
2.1.7. Информационная система
108
2.1.8. Заказ товаров и услуг
109
2.1.9. Учет и контроль финансов
110
2.2. Дистанционный
111
2.2.1. Безопасность
112
2.2.2. Учет коммунальных услуг
113
2.2.3. Управление освещением
114
2.2.4. Управление климатом
115
2.2.5. Управление медиа контентом
116
2.2.6. Справочная система
117
2.2.7. Информационная система
118
2.2.8. Заказ товаров и услуг
119
2.2.9. Учет и контроль финансов
120
2.3. Автоматизированный
121
2.3.1. Безопасность
122
2.3.2. Учет коммунальных услуг
123
2.3.3. Управление освещением
124
2.3.4. Управление климатом
125
2.3.5. Управление медиа контентом
126
2.3.6. Справочная система
127
2.3.7. Информационная система
128
2.3.8. Заказ товаров и услуг
129
2.3.9. Учет и контроль финансов
130
2.4. Автоматический
131
2.4.1. Безопасность
132
2.4.2. Учет коммунальных услуг
133
2.4.3. Управление освещением
134
2.4.4. Управление климатом
135
2.4.5. Управление медиа контентом
136
2.4.6. Справочная система
137
2.4.7. Информационная система
138
2.4.8. Заказ товаров и услуг
139
2.4.9. Учет и контроль финансов
140
3. Режимы работы умного дома
141
3.1. Ручное управление исполнительными устройствами
142
3.1.1. ДУ Выключено
143
3.1.2. Автоматика Выключена
144
3.1.3. Умный дом Выключен
145
3.2. Дистанционное управление исполнительными устройствами
146
3.2.1. ДУ Включено
147
3.2.2. Автоматика Выключена
148
3.2.3. Умный дом Выключен
149
3.3. Автоматизированное управление исполнительными устройствами
150
3.3.1. ДУ Включено
151
3.3.2. Автоматика Включена
152
3.3.3. Умный дом Выключен
153
3.4. Автоматическое управление исполнительными устройствами
154
3.4.1. ДУ Включено
155
3.4.2. Автоматика Включена
156
3.4.3. Умный дом Включен
157
4. Ограничения автоматики
158
4.1. Клапаны газ ручной взвод
159
4.2. Клапаны отопления НО
160
4.3. Вентиляторы Вытяжные и их каналы НО
161
4.4. Вентиляторы приточные НЗ
Еще что то
01
1. Температура, влажность в зал, спальня, кабинет, кухня, коридор, ванна, (туалет?)
02
2. Температура, влажность, давление, освещенность улица - метеостанция
03
3. Управление и концевики штор зал, спальня, кабинет, кухня
04
4. Защита от протечек воды кухня, ванна, туалет
05
5. Защита от утечек газа кухня
06
6. Противопожарная зал, спальня, кабинет, кухня, коридор, кладовка
07
7. Управление светом зал, спальня, кабинет, коридор, кладовка, ванна, туалет, кухня, балкон, лоджия
08
a. Датчики движения для выключения света более чем 20 минут.
09
b. Уменьшение и увеличение яркости подсветки в коридоре по датчику движения
10
c. Если естественное освещение в комнате будет ниже 50%, то система добавит искусственное освещение до 50%. Если естественное освещение будет ниже 40%, то система добавит освещение до 60% и т.д. Это очень удобно во время заката или в пасмурный день.
11
8. Управление подсветкой одноцветной
12
9. Управление подсветкой RGB
13
10. Охрана (датчики движения) геркон на двери и электронный замок
14
11. Видеонаблюдение.
15
12. Домофон в коридоре, кухне, спальне, кабинете
16
13. Связь GSM и и интернет
17
14. Учет воды, газа, электричества.
18
15. Управление кондиционированием
19
16. Управление отоплением
20
17. Управление вентиляцией
21
18. Управление телевизорами, акустикой, проектором.
22
19. Календарь дат и напоминания
23
20.
24
21. Управление полотенцесушителем
25
26
1. Во всех помещениях – температура, влажность, освещенность, движение, протечка
27
Протечки
28
Авария
29
Проворот
30
Ремонт
31
Ручное выключение и включение с конролем протечки
32
Вентиляция от влажности
33
Влажность выше скорость больше
34
СО2
малой кровью можно обойтись, если добавить третье измерение к массиву parameter, котороое и будет указывать на номер датчика
Ок.
Решение пока не важно, важно сохранение концепции первоначальной. Хотя ее нужно еще обдумывать. См. выше.
Ууу блин, мы же говорили 1 параметр 1 фрейм, чтобы четко понимать запросил температуру у датчика на потолке и от него и получил
Так вы все-таки запрашиваете данные от датчиков? Мастер-слэйв, а ля Модбас? А зачем тогда CAN?
Ууу блин, мы же говорили 1 параметр 1 фрейм, чтобы четко понимать запросил температуру у датчика на потолке и от него и получил
Так вы все-таки запрашиваете данные от датчиков? Мастер-слэйв, а ля Модбас? А зачем тогда CAN?
Где то была уже выше описана концепция. Поэтому коротко.
Все узлы могут передавать в любое время, и по заданному алгоритму инициативно рассылают информацию. Тем не менее есть мастер (слейв как дублирующая система, пока мастер работоспособен слейв не выполняет никаких функций кроме контроля мастера, в случае же аварии мастера берет на себя его функции) который является как контролирующим для всей сети так и шлюзом с внешними управляющими системами.
На выходе любой узел передает данные как инициативно так и по запросу. Узел с НАЗВАНИЕМ Мастер сидит выше в модели ОСИ и несет не коммуникационные а шлюзовые и контролирующие функции.
Все запросы к узлам нужны для работу более сложных сценариев если это потребуется далее, причем выполняемых на сервере, где они будут храниться вместе с анными, не хочется убирать эту возможность и тем более хранить эту информацию в пямяти контроллеров.
Да и еще, запросить параметр или дать команду на исполнение может не только узел с НАЗВАНИЕМ мастер, но и любой узел у любого узла.
с трехмерным массивом стрёмненько получается. Загрузка ОЗУ МЕГИ 43%. При том что массив на 10% только используется, даже меньше (смотри тип данных где 0 - значит № такого датчика отсутсвует на узле).
Можно количество датчиков максимум 5 сделать а не 20.
Ну и простыня получилась ппц, в отдельную вкладку это нужно.
с 5-ю датчиками загрузка ОЗУ 21% - ещё куда ни шло. Я почему за ОЗУ беспокоюсь, ведь кода работы с датчиками ещё нет. Это только каркас узла.
На узле со светом можно 20 оставить, там всё равно другого кода не добавится
А зачем их все хранить?
Нужно определить что нужно хранить а что можно перезапросить.
Все климатические параметры хранить нет смысла. Состояние ламп вкл/выкл спорно можно и опросить,
Бузусловно нужно хранить например количество людей в помещении да и то нужно определить где хранить на light или main. А вот все остальное зачем?
а если CAN лёг , мы в автономный режим переходим. откуда брать эти не хранящиеся параметры? замерять каждый раз когда они требуются?
с трехмерным массивом стрёмненько получается. Загрузка ОЗУ МЕГИ 43%. При том что массив на 10% только используется, даже меньше (смотри тип данных где 0 - значит № такого датчика отсутсвует на узле).
Можно количество датчиков максимум 5 сделать а не 20.
Ну и простыня получилась ппц, в отдельную вкладку это нужно.
с 5-ю датчиками загрузка ОЗУ 21% - ещё куда ни шло. Я почему за ОЗУ беспокоюсь, ведь кода работы с датчиками ещё нет. Это только каркас узла.
На узле со светом можно 20 оставить, там всё равно другого кода не добавится
А нельзя как я выше писал