Очередной "Умный дом", на этот раз модульная система...

MaksVV
Offline
Зарегистрирован: 06.08.2015

блин, всё вкурил как ты хочешь сделать

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:
Прошил в епром все типы подключенных датчиков, ИУ и все. В зависимости от этого инициируешь переменные. 

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

Ты же сам предложил епром чтобы заливать в 15 МК один и тот же скетч. Да в большей степени они одинаковые по ИУ и датчикам но есть и различия.

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

блин, всё вкурил как ты хочешь сделать

Один отлаженный скетч на все МК это песня будет.

P.S. 

Я просто на производстве работаю и постоянно бъемся за унификацию плат, разъемов кода и пр.

MaksVV
Offline
Зарегистрирован: 06.08.2015

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

Т.е. да, скетч получается один на всех. А в процессе настраиваем каждый узел по Serial например или вообще по кану можно (настраивая тем самым еепром, потом ресет и уже пошёл скетч работать). Соответсвенно у всех МК будет два режима

- режим конфигурации,

- рабочий режим.

Блин, это всё как у меня на работе. Допустим новый блок управления идёт один и тот же на все комплектации автомобиля и при установке ты его конфигурируешь, в зависимости от комплектации автомобиля. 

Адектаватная концепция. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:

Я просто на производстве работаю и постоянно бъемся за унификацию плат, разъемов кода и пр.

MaksVV пишет:

Блин, это всё как у меня на работе. Допустим новый блок управления идёт один и тот же на все комплектации автомобиля и при установке ты его конфигурируешь, в зависимости от комплектации автомобиля. 

 

)))

MaksVV
Offline
Зарегистрирован: 06.08.2015

это всё конечно прикольно, я уже приводил в посте #848 такой пример. смотри файлы screen1... screen16. Но это когда есть возможности для создания программы конфигуратора. Это ещё можно пару месяцев потратить на то чтобы наладить настройку конфигурации например по Serial или по кан, т.к. я вообще не петрю в создании программ для винды, и не осилю такую задачу.  А с терминала конфигурировать какими то кодировками - это извините - проще в иде мои массивы заполнить  и залить скетч. 

 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

это всё конечно прикольно, я уже приводил в посте #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 общаться.
 
riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

это всё конечно прикольно, я уже приводил в посте #848 такой пример. смотри файлы screen1... screen16. Но это когда есть возможности для создания программы конфигуратора. Это ещё можно пару месяцев потратить на то чтобы наладить настройку конфигурации например по Serial или по кан, т.к. я вообще не петрю в создании программ для винды, и не осилю такую задачу.  А с терминала конфигурировать какими то кодировками - это извините - проще в иде мои массивы заполнить  и залить скетч. 

MaksVV пишет:

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

Ну примерно так я себе это и представляю на выходе.

DIYMan пишет:

...  управлять микроконтроллером отовсюду, откуда только можно: непосредственно жмакнуть на кнопочку .... По Wi-Fi с домашнего компьютера... По витой паре ..! Со смартфона - .... 



Задача ставилась такая:

1. я заранее не знаю, какой функционал мне надо будет дописать, это раз.

2. Не хочу некрасивого кода простынями по нескольку экранов в одной функции - это два.

3. Система модульная .

4. Модули могут быть как в пределах одной коробки, так и разнесены в пространстве .

5. Модули должны поддерживать прозрачное общение друг с другом "из коробки"  

6. лёгкая расширяемость поддерживаемых команд

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

если завтра вам понадобится встроить поддержку датчика температуры, то для его опроса не надо будет писать огромную простыню в функции loop - достаточно написать простенький новый модуль, который и будет выполнять эту чёрную работу. Код в loop при этом не изменится ни на йоту - вместо этого просто добавиться одна строчка в setup, для инициализации модуля.

Ну допустим, что есть у вас код, который опрашивает датчик и выводит температуру на экран. И захотели вы, помимо вывода на экран - выводить всё это в Serial. Да не просто выводить, а по запросу из Serial же. Короче, уже представляете, сколько зависимостей, да? А вот и нет! Не надо специально корячиться и переписывать модуль для вывода на экран - архитектура, повторюсь, такова, что модуль только отдаёт или устанавливает свое внутреннее состояние, по запросу извне. Откуда пришёл запрос - ему чхать, куда всё это выведется - наплевать. И вот на этом моменте вы подключаете к этому модулю модуль публикации на дисплей (одной строкой кода) - и всё! Просто, правда?

https://www.forumhouse.ru/threads/341712/

MaksVV
Offline
Зарегистрирован: 06.08.2015

Пришла и мне Mega Pro от robotdyn . Всего 12 дней шла. Я уж и забыл, что из китая так быстро посылки могут приходить. Померил, плата MCP2515 точь в точь входит в развал между пинами меги. поэтому в LAYOUT шилд рисую - не люблю на проводочках всё. На шилже можно также уместить и ESP. кинь схему как ты еспшку подключаешь. 

ПС. Я ещё студентом был купил квадратный метр медного текстолита. Всё ещё израсходовать не могу. Платы ЛУТом быстро делать когда всё подготовлено. (поваренная соль, лимонная кислота, перекись водорота, медный текстолит, карандаш, линейка, лобзик с пилкой по металлу,  наждачка нулёвка и чуть крупнее, дремель с мелким сверлом , ватные  диски, жидкость для снятия лака, журнальные глянцевые тонкие листы, ножницы, лазерный принтер,  утюг ).

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

ПС. Я ещё студентом был купил квадратный метр медного текстолита. Всё ещё израсходовать не могу. Платы ЛУТом быстро делать когда всё подготовлено. (поваренная соль, лимонная кислота, перекись водорота, медный текстолит, карандаш, линейка, лобзик с пилкой по металлу,  наждачка нулёвка и чуть крупнее, дремель с мелким сверлом , ватные  диски, жидкость для снятия лака, журнальные глянцевые тонкие листы, ножницы, лазерный принтер,  утюг ).

Да молодость вспоминается. ;-)

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

А на выходе может и свою плату разведу под ATmega2560 + MCP2515 + TJA1050 + сверху 8266 (ESP07) + еще что нибудь. (пока не знаю, поэтому пока паяный конструктор) затем у китайцеав закажу изготовление.

Вот кстати вопрос на засыпку посоветуй малогабаритный разъем (не жутко дорогой) для подключения этой меги к кабелям из стены. Может для магнитолы или еще что то пинов на 20-40 а лучше 60. 

P.S.

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

riv
Offline
Зарегистрирован: 20.07.2017

Еще вопрос, у тебя в byte parameter [6][parameters_quantity перечисленны не все датчики

я хочу добавить СО2 датчик, мне нужно во все 6 {} вставить что то?

Вообще я не понял зачем ты усложнял. Ты сделал возможность произволь назначать тип датчика на произвольный номер строки массива. А зачем? Номер строки в массиве = № датчика. Если делать на eeprom то придется делать фиксированный тип массива с типовыми датчиками и их адресами.

MaksVV
Offline
Зарегистрирован: 06.08.2015

Конечно не все перечислены. Я просто от балды несколько вставил и всё. 

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

Да, конечно нужно во все 6 вставить информацию, по сути в одном только адрес параметра, а в оставльных настройки этого параметра.  

 

MaksVV
Offline
Зарегистрирован: 06.08.2015
первое измерение массива parameter[][]  выглядит так:
 
тип данных переменной параметра                   #define TYPE_VAR                 0 
адрес параметра (тот что в списке дефайнов)   #define PARAMETER_ADDR     1
сама переменная параметра                             #define PARAMETER               2
старое значение переменной параметра           #define PARAMETER_LAST      3
адрес узла периодической отправки                 #define PERIODIC_CANADDR  4
адрес второго узла периодической отправки
 
ПС. читай коменты в скетче, там всё описано по идее
MaksVV
Offline
Зарегистрирован: 06.08.2015

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

riv
Offline
Зарегистрирован: 20.07.2017

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

Нужно определиться

1. Тип датчиков температуры 1 или несколько и по осталным тоже. Вот например у меня есть BME280, SI7021, DS18S20

2. В принципе сколько будет датчиков однотипных на узле. У меня их может быть от 0 до 4.

3. Работаем ли мы с датчиком как с абстракцией или с железными пинами.

Так вот ответ на эти вопросы показывает что к сожалению нужен тип датчика по возможностям (температура, влажность ...), тип датчика по железу, № датчика на узлею То же по ИУ.

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

Нужно добить протокол.

MaksVV
Offline
Зарегистрирован: 06.08.2015

работаем с параметром. А как он обновляется - неважно. Как раз предлагаемая DIYMan концепция. Т.е., например,  параметр температуры воды ты обновляешь далласом , а температуры воздуха - BME. Код работы с параметром по кан, веб и т.д. не поменяется от этого. Ты лишь "подключишь " к параметру определённый модуль в скетче, в данном случае далласа или BME

riv
Offline
Зарегистрирован: 20.07.2017

Не совсем об этом речь, я изначально помнишь предлагал тип датчика и адрес датчика (ну или его номер на узле)

Вот смотри лог 

Как понять это датчик температуры у потолка или у пола?

Приходит просто тип датчика, а нужно знать еще его номер в на узле и его 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 байт или нет.

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:

Как понять это датчик температуры у потолка или у пола?

Я понимаю что ты можешь посспорить на тему зачем мне 2 или 5 датчиков на одном узле. Но! Например вот таких датчиков у меня по 2 в каждом помещении. Как быть?

заведи ещё один параметр - температура вверху, температура внизу. К каждому параметру будет привязан свой датчик. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:

И слушай я так и не понял зачем ты делаешь DLC не 8? Проще же везхде работать с байт 0-7 чем думать есть у меня в датафрейме например 7 байт или нет.

там есть несколько мест где считывается количсетво байт во фрейме. Наример, когда делаем запрос параметра у какого-нибудь узла, Тело запроса состоит таким образом. Нулевой байт поля данных это глобальный счетчик. А вот дальше идут байты адресов параметров (до 7 шт.). Т.е. с одного запроса мы можем запросить до 7 параметров. Соответсвенно если нужно 3 запросить, то поле данных будет из четырех байт: 

счетчик, и три байта адреса параметра. DLC=4

А при ответе параметра , если у нас параметр однобайтовый будет DLC = 5

двухбайтовый DLC = 6 

четырехбайтовый DLC = 8

 

 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:

И слушай я так и не понял зачем ты делаешь DLC не 8? Проще же везхде работать с байт 0-7 чем думать есть у меня в датафрейме например 7 байт или нет.

там есть несколько мест где считывается количсетво байт во фрейме. Наример, когда делаем запрос параметра у какого-нибудь узла, Тело запроса состоит таким образом. Нулевой байт поля данных это глобальный счетчик. А вот дальше идут байты адресов параметров (до 7 шт.). Т.е. с одного запроса мы можем запросить до 7 параметров. Соответсвенно если нужно 3 запросить, то поле данных будет из четырех байт: 

счетчик, и три байта адреса параметра. DLC=4

А при ответе параметра , если у нас параметр однобайтовый будет DLC = 5

двухбайтовый DLC = 6 

четырехбайтовый DLC = 8

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

MaksVV
Offline
Зарегистрирован: 06.08.2015

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

По моей схеме как запрос параметров сделать ? вот запрос 56  01  05  08  00  00  00  00

56  - счетчик  01  05  08 запрашиваемые параметры, но нулевые параметры в запросе присутсвуют и узел четыре раза ответит и параметром с нулевым адресом. 

Я уже не говорю о том, что по моей схеме шина меньше загружается. 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

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

По моей схеме как запрос параметров сделать ? вот запрос 56  01  05  08  00  00  00  00

56  - счетчик  01  05  08 запрашиваемые параметры, но нулевые параметры в запросе присутсвуют и узел четыре раза ответит и параметром с нулевым адресом. 

Я уже не говорю о том, что по моей схеме шина меньше загружается. 

Ок понял.

MaksVV
Offline
Зарегистрирован: 06.08.2015

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

Смотри в основном изменения в файле can_struct.h касаемые  parameter [][]. 

Также теперь можно добавлять количество узлов, на которые будет автоматически отсылаться один и тот же параметр (по умолчанию стоит 2)

версия 17 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:

И слушай я так и не понял зачем ты делаешь DLC не 8? Проще же везхде работать с байт 0-7 чем думать есть у меня в датафрейме например 7 байт или нет.

там есть несколько мест где считывается количсетво байт во фрейме. Наример, когда делаем запрос параметра у какого-нибудь узла, Тело запроса состоит таким образом. Нулевой байт поля данных это глобальный счетчик. А вот дальше идут байты адресов параметров (до 7 шт.). Т.е. с одного запроса мы можем запросить до 7 параметров. Соответсвенно если нужно 3 запросить, то поле данных будет из четырех байт: 

счетчик, и три байта адреса параметра. DLC=4

А при ответе параметра , если у нас параметр однобайтовый будет DLC = 5

двухбайтовый DLC = 6 

четырехбайтовый DLC = 8

Ууу блин, мы же говорили 1 параметр 1 фрейм, чтобы четко понимать запросил температуру у датчика на потолке и от него и получил

MaksVV
Offline
Зарегистрирован: 06.08.2015

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

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:

Как понять это датчик температуры у потолка или у пола?

Я понимаю что ты можешь посспорить на тему зачем мне 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 № датчика?
 
Дальше, если я хочу их запросить то как это сделать с мастера?
riv
Offline
Зарегистрирован: 20.07.2017

И по разъему посоветуешь чтонибудь? Автомобильный или для магнитолы или еще какой?

MaksVV
Offline
Зарегистрирован: 06.08.2015

нет ты не понял. вот так надо 

01// НИЖЕ АДРЕСА ПАРАМЕТРОВ, ПРИМЕНЯЕМЫХ В УМНОМ ДОМЕ
02 
03typedef 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

MaksVV
Offline
Зарегистрирован: 06.08.2015

по разъему может несколько лучше делать. 4 pin овые например. У тебя ведь не в общем жгуте все провода приходят?

MaksVV
Offline
Зарегистрирован: 06.08.2015

смотри внимательно версию 17 я там вместо дефайнов , енум сделал у параметров

riv
Offline
Зарегистрирован: 20.07.2017

Не это совсем не правильно, это уже уникальное имя датчика 

Мы же говорили тип датчика адрес датчика. Т.е - тип №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 разных типов так?

 

MaksVV
Offline
Зарегистрирован: 06.08.2015

реле будут в исп механизмах

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:

Мы же говорили тип датчика адрес датчика. Т.е - тип №1 адрес №1, тип №1 адрес №2,  тип №1 адрес №3, (как я выше писал) где тип №1 температурный датчик  а 1,2,3 адрес-расположение.

а чего тогда в списке параметров у тебя несколько температур?  Адреса 1, 27 , 28 , 40,  33

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:

В итоге в node_11_Kitchen_light.ino у меня 20 реле и больше ничего и будет не 1 тип с 20 адресами а 20 разных типов так?

да, а че такого? неужели прям через 254 перевалят все параметры? сомневаюсь

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

по разъему может несколько лучше делать. 4 pin овые например. У тебя ведь не в общем жгуте все провода приходят?

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

 

MaksVV
Offline
Зарегистрирован: 06.08.2015

можно компьютерный взять который com25. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

ну если ты так хочешь тип всё таки у нас есть в поле данных параметра один свободный байт))

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:

В итоге в node_11_Kitchen_light.ino у меня 20 реле и больше ничего и будет не 1 тип с 20 адресами а 20 разных типов так?

да, а че такого? неужели прям через 254 перевалят все параметры? сомневаюсь

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

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

А если тип один и есть адреса и пожно получить длинну занятых адресов, то можно for прокрутить и все опросить, а так я должен четко знать какие типы темп. датчиков у меня существуют и какие есть на данном узле.

Посмотри код и принцип построения Умной теплицы, особенно на форуме когда он начинал. Я выжимки выше делал, но лучше форум.

Должно быть четкое бинарно матричное деление а не одномерный массив.

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

ну если ты так хочешь тип всё таки у нас есть в поле данных параметра один свободный байт))

Это не я хочу это логика требует. 

И кстати мы мух с котлетами путать начинаем. Я это уже говорил.

Сначала протокол. Хранение и настройка. В итоге ты в связи с тем что так проще хранить усложняешь протокол.

Мастер (да и любой узел) должен иметь возможность запросить у узла параметр датчика типа ххх №yyy а так же какие датчики типы датчиков есть и их кол-во

на узле есть 4 датчика типа x, 2 типа y, 1 типа z.

MaksVV
Offline
Зарегистрирован: 06.08.2015

ну и как хранить информацию с датчиков прикажете? Есть двумерный массив. 

Судя по твоим высказываниям вижу только один выход - задавать фиксированное количество адресов у всех типов. Я с тобой то согласен, только как это ,блин , всё запрограммировать. эти массивы они же вредные. если пихать в то же измерение адрес, то например у одно типа сделал 20 адресов и все типы стали с 20 адресами. Переменную величину то не сделать. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

короче весь скетч переписывать.

У каждой переменной получается дикий адрес - сначала адрес узла, потом тип девайса и в конце номер датчика. Тройной адрес получается. 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

короче весь скетч переписывать.

У каждой переменной получается дикий адрес - сначала адрес узла, потом тип девайса и в конце номер датчика. Тройной адрес получается. 

Ну с самого начала так было, потом поняли что в ID не хватает для адресов и ушли в 1 байт data. А сейчас все подругому.

Давай может пойдем как у меня на работе сформируем ТТ ну или хотя бы ОТТ,  разобъем на этапы.

А насчет переписывать, у нас сейчас идет выработка технических решений.  (Как в ОКР Эскизный, Технический и только поторм РКД).

MaksVV
Offline
Зарегистрирован: 06.08.2015

малой кровью можно обойтись, если добавить третье измерение к массиву parameter, котороое и будет указывать на номер датчика

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

ну и как хранить информацию с датчиков прикажете? Есть двумерный массив. 

Судя по твоим высказываниям вижу только один выход - задавать фиксированное количество адресов у всех типов. Я с тобой то согласен, только как это ,блин , всё запрограммировать. эти массивы они же вредные. если пихать в то же измерение адрес, то например у одно типа сделал 20 адресов и все типы стали с 20 адресами. Переменную величину то не сделать. 

А зачем их все хранить?

Нужно определить что нужно хранить а что можно перезапросить.

Все климатические параметры хранить нет смысла. Состояние ламп вкл/выкл спорно можно и опросить,

Бузусловно нужно хранить например количество людей в помещении да и то нужно определить где хранить на light или main. А вот все остальное зачем?

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

Т.е перечень событий (не датчиков а событий)

Зима-лето. День-ночь. Есть люди в помещении нет. 

Климат. Свет. Охрана. ....

Я тут как то начинал ...

Еще что то

 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

малой кровью можно обойтись, если добавить третье измерение к массиву parameter, котороое и будет указывать на номер датчика

Ок.

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

triac
triac аватар
Offline
Зарегистрирован: 03.05.2018

riv пишет:

Ууу блин, мы же говорили 1 параметр 1 фрейм, чтобы четко понимать запросил температуру у датчика на потолке и от него и получил

Так вы все-таки запрашиваете данные от датчиков? Мастер-слэйв, а ля Модбас? А зачем тогда CAN?

riv
Offline
Зарегистрирован: 20.07.2017

triac пишет:

riv пишет:

Ууу блин, мы же говорили 1 параметр 1 фрейм, чтобы четко понимать запросил температуру у датчика на потолке и от него и получил

Так вы все-таки запрашиваете данные от датчиков? Мастер-слэйв, а ля Модбас? А зачем тогда CAN?

Где то была уже выше описана концепция. Поэтому коротко.

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

На выходе любой узел передает данные как инициативно так и по запросу. Узел с НАЗВАНИЕМ Мастер сидит выше в модели ОСИ и несет не коммуникационные а шлюзовые и контролирующие функции. 

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

Да и еще, запросить параметр или дать команду на исполнение может не только узел с НАЗВАНИЕМ мастер, но и любой узел у любого узла.

MaksVV
Offline
Зарегистрирован: 06.08.2015

с трехмерным массивом стрёмненько получается. Загрузка ОЗУ МЕГИ 43%.  При том что массив на 10% только используется, даже меньше (смотри тип данных где 0 - значит № такого датчика отсутсвует на узле). 

Можно количество датчиков максимум 5 сделать а не 20. 

Ну и простыня получилась ппц, в отдельную вкладку это нужно. 

с 5-ю датчиками загрузка ОЗУ 21%  - ещё куда ни шло. Я почему за ОЗУ беспокоюсь, ведь кода работы с датчиками ещё нет. Это только каркас узла. 

На узле со светом можно 20 оставить, там всё равно другого кода не добавится

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:

А зачем их все хранить?

Нужно определить что нужно хранить а что можно перезапросить.

Все климатические параметры хранить нет смысла. Состояние ламп вкл/выкл спорно можно и опросить,

Бузусловно нужно хранить например количество людей в помещении да и то нужно определить где хранить на light или main. А вот все остальное зачем?

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

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

с трехмерным массивом стрёмненько получается. Загрузка ОЗУ МЕГИ 43%.  При том что массив на 10% только используется, даже меньше (смотри тип данных где 0 - значит № такого датчика отсутсвует на узле). 

Можно количество датчиков максимум 5 сделать а не 20. 

Ну и простыня получилась ппц, в отдельную вкладку это нужно. 

с 5-ю датчиками загрузка ОЗУ 21%  - ещё куда ни шло. Я почему за ОЗУ беспокоюсь, ведь кода работы с датчиками ещё нет. Это только каркас узла. 

На узле со светом можно 20 оставить, там всё равно другого кода не добавится

А нельзя как я выше писал

[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,03][3] 1 й датчик влажности