Прошил в епром все типы подключенных датчиков, ИУ и все. В зависимости от этого инициируешь переменные.
блин ну не пойму я смысла. Это всё и так лежит в энергонезависимой памяти, которая называется флеш. В ней залит скетч. В скетче есть эта информация. Дак нафига её в еепром то пихать? В том то и дело, если ты ничего подключать дополнительно не собираешься вообще не имеет смысла в еепром пихать. Т.к. туда пихается обычно изменяемая инфа. А постоянная она из флеша (скетча) спокойно также грузится.
Ты же сам предложил епром чтобы заливать в 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
Не совсем об этом речь, я изначально помнишь предлагал тип датчика и адрес датчика (ну или его номер на узле)
Вот смотри лог
01ID DLC Data Period Count Comment0214050401 5 4F 00 09 08 00 62 26 05 температура0314050402 5 50 00 09 01 00 62 26 05 влажность0414050403 5 51 00 09 01 00 63 26 05 давление0514060401 5 4F 00 09 08 00 65 26 06 температура0614060402 5 50 00 09 01 00 65 26 06 влажность0714060403 5 51 00 09 01 00 64 26 06 давление0814070401 5 4C 00 09 08 00 62 25 07 температура0914070402 5 4D 00 09 01 00 64 25 07 влажность1014070403 5 4E 00 09 01 00 64 25 07 давление1114080401 5 4F 00 09 08 00 65 26 08 температура1214080402 5 50 00 09 01 00 65 26 08 влажность1314080403 5 51 00 09 01 00 64 26 08 давление1414090401 5 4F 00 09 08 00 63 26 09 температура1514090402 5 50 00 09 01 00 63 26 09 влажность1614090403 5 51 00 09 01 00 63 26 10 давление17140A0401 5 4C 00 09 08 00 65 25 10 температура18140A0402 5 4D 00 09 01 00 65 25 10 влажность19140A0403 5 4E 00 09 01 00 64 25 10 давление20140B0401 5 46 00 09 08 00 64 23 11 температура21140B0402 5 47 00 09 01 00 62 23 11 влажность22140B0403 5 48 00 09 01 00 63 23 11 давление23140C0401 5 4F 00 09 08 00 64 26 12 температура24140C0402 5 50 00 09 01 00 63 26 12 влажность25140C0403 5 51 00 09 01 00 63 26 12 давление26140D0401 5 4F 00 09 08 00 63 26 13 температура27140D0402 5 50 00 09 01 00 61 26 13 влажность28140D0403 5 51 00 09 01 00 61 26 13 давление29140E0401 5 4F 00 09 08 00 63 26 14 температура30140E0402 5 50 00 09 01 00 62 26 14 влажность31140E0403 5 51 00 09 01 00 62 26 14 давление32140F0401 5 4F 00 09 08 00 63 26 15 температура33140F0402 5 50 00 09 01 00 61 26 15 влажность34140F0403 5 51 00 09 01 00 61 26 15 давление3514120401 5 4F 00 09 08 00 61 26 18 температура3614120402 5 50 00 09 01 00 62 26 18 влажность3714120403 5 51 00 09 01 00 62 26 18 давление3814130401 5 4F 00 09 08 00 63 26 19 температура3914130402 5 50 00 09 01 00 63 26 19 влажность4014130403 5 51 00 09 01 00 62 26 19 давление4114140401 5 4F 00 09 08 00 62 27 20 температура4214140402 5 50 00 09 01 00 62 27 20 влажность4314140403 5 51 00 09 01 00 62 27 20 давление4414150401 5 4C 00 09 08 00 64 26 21 температура4514150402 5 4D 00 09 01 00 63 26 21 влажность4614150403 5 4E 00 09 01 00 62 26 21 давление4716040000 8 5C 14 0E 00 00 00 00 00 1000 1528 04 широковещательный запрос статуса узлов сети4816050400 8 00 00 00 00 00 00 00 00 1000 1528 05 статус ОК4916060400 8 00 00 00 00 00 00 00 00 999 1528 06 статус ОК5016070400 8 00 00 00 00 00 00 00 00 1000 1523 07 статус ОК5116080400 8 00 00 00 00 00 00 00 00 1002 1525 08 статус ОК5216090400 8 00 00 00 00 00 00 00 00 1002 1521 09 статус ОК53160A0400 8 00 00 00 00 00 00 00 00 999 1519 10 статус ОК54160B0400 8 00 00 00 00 00 00 00 00 1001 1519 11 статус ОК55160C0400 8 00 00 00 00 00 00 00 00 1002 1525 12 статус ОК56160D0400 8 00 00 00 00 00 00 00 00 1000 1528 13 статус ОК57160E0400 8 00 00 00 00 00 00 00 00 1000 1526 14 статус ОК58160F0400 8 00 00 00 00 00 00 00 00 1002 1524 15 статус ОК5916120400 8 00 00 00 00 00 00 00 00 1002 1528 18 статус ОК6016130400 8 00 00 00 00 00 00 00 00 1001 1524 19 статус ОК6116140400 8 00 00 00 00 00 00 00 00 1002 1523 20 статус ОК6216150400 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// НИЖЕ АДРЕСА ПАРАМЕТРОВ, ПРИМЕНЯЕМЫХ В УМНОМ ДОМЕ0203typedefenumParameter_addr_enum04{05null_param,//006air_t ,//1 //датчик температуры07air_h ,//2 //датчик влажности08air_p ,//3 //датчик давления09mot_pir ,//4 //10moti_mw ,//5 //датчик движения11vibrat ,//6 //датчик вибрации12noise ,//7 //датчик шума13Illum ,//8 //датчик освещенности14gas_co ,//9 //датчик СО15gas_co2 ,//10 //датчик СО216gas_met ,//11 //датчик метана17smoke ,//12 //датчик курения18fire ,//13 //датчик Огня19body_temp ,//14 //Температура тела20jal_stat ,//15 //Концевик Жалюзи21steam ,//16 //Датчик Пара22microwave ,//17 //Излучение микроволновки23fridge_temp ,//18 //Холодильник24freezer_temp ,//19 //Морозилка25oven_temp ,//20 //Духовка26elec_board ,//21 //Электрощит концевик27door_lock ,//22 //Замок двери28door_close ,//23 //Концевик двери29mot_door1 ,//24 //Датчик прохода 130mot_door2 ,//25 //Датчик прохода 231wind_close ,//26 //Закрыто32water_hot_temp ,//27 //Температура горячей воды33water_cold_temp ,//28 //Температура холодной воды34water_hot_pres ,//29 //Давление горячей воды35water_cold_pres ,//30 //Давление холодной воды36leakage ,//31 //Протечка37aquar_lamp ,//32 //Лампа аквариум38aquar_temp ,//33 //Температура аквариум39aquar_pump ,//34 //Насос аквариум40aquar_clearing ,//35 //Очистка аквариум41cupboard_door ,//36 //Дверь шкафа42safe_door ,//37 //Дверь сейфа43balcony_door ,//38 //Дверь балкона44loggia_door ,//39 //Дверь лоджии45radiator_temp_S ,//40 //Температура батареи46lamp_ceiling ,//41 //Лампа на потолке47lamp_wall ,//42 //Ланпа настенная48lamp_Illum ,//43 //Лампа подсветки49lamp_accident ,//44 //Лампа аварийная50earth_humidity ,//45 //Влажность земли51counter_gas_2 ,//46 //Счетчик газа52counter_gas_2_SB2 ,//47 сервисный байт53counter_water_hot_2 ,//48 //Счетчик горячей воды54counter_water_hot_2_SB2 ,//49 сервисный байт55counter_water_cold_2 ,//50 //Счетчик холодной воды56counter_water_cold_2_SB2 ,//51 сервисный байт57counter_elect_4 ,//52 //Счетчик электричества58counter_elect_4_SB2 ,//53 сервисный байт59counter_elect_4_SB3 ,//54 сервисный байт60counter_elect_4_SB4 ,//55 сервисный байт61ups_voltage_4F ,//56 //напряжение АКБ бесперебойника62ups_voltage_4F_SB2 ,//57 сервисный байт63ups_voltage_4F_SB3 ,//58 сервисный байт64ups_voltage_4F_SB4 ,//59 сервисный байт65air_t _UP ,//60 температура воздуха вверху66air_t _DOWN ,//61 температура воздуха внизу67SIZE_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. А вот все остальное зачем?
Давай все же логику обемена - работы определим. Причем не под железо код а под себя любимых. Как должна себя вести система в зависимости от событий булевых и аналоговых и какие воздействия и на что она должна выдавать.
Т.е перечень событий (не датчиков а событий)
Зима-лето. День-ночь. Есть люди в помещении нет.
Климат. Свет. Охрана. ....
Я тут как то начинал ...
0011. Функции Умного дома0021.1. Управление безопасностью0031.1.1. Защита от незаконного проникновения0041.1.1.1. Входная дверь0051.1.1.2. Окна0061.1.2. Контроль доступа0071.1.2.1. Входная дверь0081.1.2.2. Закрытые для детей помещения0091.1.2.3. Закрытые для гостей помещения0101.1.2.4. Перемещения по квартире0111.1.2.5. Учет людей в помещениях0121.1.2.6. Сейфы0131.1.3. Защита от утечек газа0141.1.3.1. Кухня – контроль, перекрытие газа, оповещение голосовое и СМС0151.1.4. Защита от протечек воды0161.1.4.1. Кухня - контроль, перекрытие воды, оповещение голосовое и СМС0171.1.4.2. Туалет - контроль, перекрытие воды, оповещение голосовое и СМС0181.1.4.3. Ванная - контроль, перекрытие воды, оповещение голосовое и СМС0191.1.5. Защита от затопления соседями0201.1.5.1. Все помещения - контроль, оповещение голосовое и СМС0211.1.6. Защита от пожара0221.1.6.1. Все помещения - контроль, оповещение голосовое и СМС0231.1.7. Контроль качества воздуха –СО, СО2 и пр.0241.1.8. Контроль включения электронагревательных приборов и электричества0251.1.9. Контроль включенности газовой плиты0261.2. Учет коммунальных услуг0271.2.1. Газ - учет, расчет, оповещение о необходимости оплаты голосовое и СМС, хранение0281.2.2. Свет - учет, расчет, оповещение о необходимости оплаты голосовое и СМС, хранение0291.2.3. Вода - учет, расчет, оповещение о необходимости оплаты голосовое и СМС, хранение0301.2.4. Электричество - учет, расчет, оповещение о необходимости оплаты голосовое и СМС, хранение0311.2.5. Отопление ?0321.3. Управление освещением0331.3.1. Основное освещение - Все помещения0341.3.1.1. Включение – выключение электрических ламп0351.3.1.2. Диммирование - электрических ламп0361.3.1.3. Сцены0371.3.1.4. Жалюзи – открытие закрытие0381.3.2. Посветка - Помещения с подсветкой (Коридор, Кухня, Спальня, Гостиная)0391.3.2.1. Включение – выключение светодиодной подсветки0401.3.2.2. Диммирование светодиодной подсветки0411.3.2.3. Сцены0421.3.3. Аварийное освещение0431.3.3.1. Помещения с аварийным освещением - Коридор0441.4. Управление климатом0451.4.1. Нагрев - все помещения с водяными и электронагревательными приборами –(Кухня, Ванная, Кабинет, Спальня, Гостиная)0461.4.1.1. Нагрев радиаторами отопления0471.4.1.2. Нагрев инверторным кондиционером0481.4.1.3. Нагрев Электрическим радиатором0491.4.1.4. Нагрет теплыми полами0501.4.2. Охлаждение0511.4.2.1. Охлаждение кондиционером0521.4.2.2. Охлаждение приточной вентиляцией0531.4.3. Вентиляция0541.4.3.1. Приточная0551.4.3.2. Вытяжная0561.4.3.3. Рекуперация0571.4.4. Влажность0581.4.4.1. Помещения резко изменяемой влажностью – кухня, ванная0591.4.4.2. Помещения требующие комфорта - спальня0601.5. Управление медиа контентом0611.5.1. ТВ0621.5.1.1. IP TV (Multicast)0631.5.1.2. Кабельное TV0641.5.1.3. SAT TV0651.5.1.4. Интернет TV0661.5.2. Радио0671.5.2.1. Интернет Радио0681.5.2.2. Эфирное радио0691.5.2.3. Городская трансляция0701.5.3. Кино0711.5.3.1. Интернет0721.5.3.2. Хранилище0731.5.4. Музыка0741.5.4.1. Интернет0751.5.4.2. Хранилище0761.5.5. Аудиокниги0771.5.5.1. Интернет0781.5.5.2. Хранилище0791.6. Справочная система0801.6.1. На систему0811.6.2. Общая0821.7. Информационная система0831.7.1. Погода0841.7.2. Пробки0851.7.3. Новости0861.7.4. Местонахождение жильцов0871.7.5. Состояние телефонов (заряд)0881.7.6. Коммунальные платежи0891.7.7. Новинки фильмов0901.7.8. Трек почтовых отправлений0911.8. Заказ товаров и услуг0921.8.1. Пицца0931.8.2. Билеты в кино0941.8.3. Такси0951.8.4. Вызов служб аварийных0961.9. Учет и контроль финансов0971.9.1. Приходы0981.9.2. Расходы0992. Уровни управления умным домом1002.1. Ручной – управление исполнительными устройствами штатными органами управления1012.1.1. Безопасность1022.1.2. Учет коммунальных услуг1032.1.3. Управление освещением1042.1.4. Управление климатом1052.1.5. Управление медиа контентом1062.1.6. Справочная система1072.1.7. Информационная система1082.1.8. Заказ товаров и услуг1092.1.9. Учет и контроль финансов1102.2. Дистанционный1112.2.1. Безопасность1122.2.2. Учет коммунальных услуг1132.2.3. Управление освещением1142.2.4. Управление климатом1152.2.5. Управление медиа контентом1162.2.6. Справочная система1172.2.7. Информационная система1182.2.8. Заказ товаров и услуг1192.2.9. Учет и контроль финансов1202.3. Автоматизированный1212.3.1. Безопасность1222.3.2. Учет коммунальных услуг1232.3.3. Управление освещением1242.3.4. Управление климатом1252.3.5. Управление медиа контентом1262.3.6. Справочная система1272.3.7. Информационная система1282.3.8. Заказ товаров и услуг1292.3.9. Учет и контроль финансов1302.4. Автоматический1312.4.1. Безопасность1322.4.2. Учет коммунальных услуг1332.4.3. Управление освещением1342.4.4. Управление климатом1352.4.5. Управление медиа контентом1362.4.6. Справочная система1372.4.7. Информационная система1382.4.8. Заказ товаров и услуг1392.4.9. Учет и контроль финансов1403. Режимы работы умного дома1413.1. Ручное управление исполнительными устройствами1423.1.1. ДУ Выключено1433.1.2. Автоматика Выключена1443.1.3. Умный дом Выключен1453.2. Дистанционное управление исполнительными устройствами1463.2.1. ДУ Включено1473.2.2. Автоматика Выключена1483.2.3. Умный дом Выключен1493.3. Автоматизированное управление исполнительными устройствами1503.3.1. ДУ Включено1513.3.2. Автоматика Включена1523.3.3. Умный дом Выключен1533.4. Автоматическое управление исполнительными устройствами1543.4.1. ДУ Включено1553.4.2. Автоматика Включена1563.4.3. Умный дом Включен1574. Ограничения автоматики1584.1. Клапаны газ ручной взвод1594.2. Клапаны отопления НО1604.3. Вентиляторы Вытяжные и их каналы НО1614.4. Вентиляторы приточные НЗЕще что то
011. Температура, влажность в зал, спальня, кабинет, кухня, коридор, ванна, (туалет?)022. Температура, влажность, давление, освещенность улица - метеостанция033. Управление и концевики штор зал, спальня, кабинет, кухня044. Защита от протечек воды кухня, ванна, туалет055. Защита от утечек газа кухня066. Противопожарная зал, спальня, кабинет, кухня, коридор, кладовка077. Управление светом зал, спальня, кабинет, коридор, кладовка, ванна, туалет, кухня, балкон, лоджия08a. Датчики движения для выключения света более чем 20 минут.09b. Уменьшение и увеличение яркости подсветки в коридоре по датчику движения10c. Если естественное освещение в комнате будет ниже 50%, то система добавит искусственное освещение до 50%. Если естественное освещение будет ниже 40%, то система добавит освещение до 60% и т.д. Это очень удобно во время заката или в пасмурный день.118. Управление подсветкой одноцветной129. Управление подсветкой RGB1310. Охрана (датчики движения) геркон на двери и электронный замок1411. Видеонаблюдение.1512. Домофон в коридоре, кухне, спальне, кабинете1613. Связь GSM и и интернет1714. Учет воды, газа, электричества.1815. Управление кондиционированием1916. Управление отоплением2017. Управление вентиляцией2118. Управление телевизорами, акустикой, проектором.2219. Календарь дат и напоминания2320.2421. Управление полотенцесушителем25261. Во всех помещениях – температура, влажность, освещенность, движение, протечка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 оставить, там всё равно другого кода не добавится
А нельзя как я выше писал