Построение Скд: Прямые Запросы К Mysql

[nxs]

Добрый день, друзья!

Помогите советом в выборе оборудования и в шагах реализации.

Пытаюсь своими силами реализовать простейшую СКД: дверь, замок, считыватель карточек.

Но есть один нюанс: хочу, чтобы после считывания карточки контроллер обращался не к своей базе памяти ключей, а каждый раз отправлял запрос на доступ к серверу БД (MySQL).

Такое возможно? Может это уже реализовано?

Если нет, на каком оборудовании это пытаться реализовать?

Если нужно уточнить какие-то детали - буду рад ответить на ваши вопросы.

Спасибо за помощь!

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[o_l_e_g]

Программу для контроллера пишешь сам?

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[NebsteR]

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

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[o_l_e_g]

распберри пи на каждую точку

Может запрос будет через ПК...ждем автора.

[NebsteR]

К каждому замку ставить ПК?

Хотя распберри и будет тем самым пк, только небольшим и относительно дешевым...

А сама база, очевидно, где то в сети этих "замков", вероятно на пк или еще где...

[nxs]

Программу для контроллера пишешь сам?

Пока ещё ничего не пишу. Рассматриваю все варианты, ищу готовые решения.

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

К каждому замку ставить ПК?

Хотя распберри и будет тем самым пк, только небольшим и относительно дешевым...

А сама база, очевидно, где то в сети этих "замков", вероятно на пк или еще где...

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

Управлять всеми замками с распберри? Есть какие-то готовые решения (желательно под линукс)?

База - не то, что за пределами замков, но даже за пределами города, где эти замки будут расположены.

Изменено 10 июня, 2013 пользователем nxs

[ferrum]

Пытаюсь своими силами реализовать простейшую СКД: дверь, замок, считыватель карточек.

Но есть один нюанс: хочу, чтобы после считывания карточки контроллер обращался не к своей базе памяти ключей, а каждый раз отправлял запрос на доступ к серверу БД (MySQL).

Такое возможно? Может это уже реализовано?

Если нет, на каком оборудовании это пытаться реализовать?

Разжуйте слово "Реализовать": Разработать , Выбрать готовое?

Сколько точек доступа? Степень территориальной распределенности?

К чему такая категоричная централизванность? При перебоях связи двери будут заблокированы что ли? (Кстати не забывайте про ответственные моменты по пожарной безопасности, СКУД должен работать как часы и открыться по сигналу "пожар").

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

И почему именно Мускуль если не секрет? Мало чтоли СУБД нормальных под Линукс(PostgreSQL, Firebird и др.)

Почитайте например как работают СКУДы Kantech, Бастион, Perco...

Вот например на Perco можно все сделать, нормальный Питерский СКУД, неплохие контроллеры с Ethernet интерфейсом

пс Ставить комп на каждую дверь это как минимум "из пушки по воробьям"

[NebsteR]

Управлять всеми замками с распберри? Есть какие-то готовые решения (желательно под линукс)?

На каждую дверь свой распберри, да. Это реально первое, что идет в голову, если надо реализовать "свою" подобную систему, достаточно специфическая задача для любых контроллеров и точно потребует разработки. Или готовые СКД, которые уже разработаны и которых, мягко говоря, дофига... Готовые решения для распберри? Прямой запрос к серверу MySQL или любому другому, из под линукса - не проблема вообще, вопрос 5 минут гугления. Дергать одним-двумя i/o портами на распберри - тоже дело пары минут...

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

Можно, на любом мк с езернет модулем на борту, или отдельным недорогим езернет контроллером на плате, плюс разъем с трансформаторами внутри... Просто и недорого, в железе... А вот программная часть - "слегка" наоборот. Я, например, если и возьмусь реализовать такое, запрошу минимум несколько десятков тысяч за один экземпляр, гербер этого экземпляра и хекс для прошивки (не исходники, за них значительно больше)... Изменено 10 июня, 2013 пользователем NebsteR

[ferrum]

Можно, на любом мк с езернет модулем на борту...

Забавно будет понаблюдать за переписыванием libmySQL.so под какую нибудь Мегу или Пик (см. название топика)

[NebsteR]

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

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

[ferrum]

Но arm ни есть любой мк, это достаточно мощная железяка.

Можно и на "любом" 8 битном МК сделать, если отказаться от гнилой концепции СУБД-Контроллер в пользу трехзвенки. Сервер приложений общается с контроллерами на своем "примитивном" протоколе, сервер приложений с СУБД стандартными средствами и без костылей.

пс Поднимать весь стек TCP\IP полностью и не нужно вовсе, он слишком жирен

Изменено 10 июня, 2013 пользователем ferrum

[NebsteR]

Сервер приложений общается с контроллерами на своем "примитивном" протоколе, сервер приложений с СУБД стандартными средствами и без костылей.

Такой вариант тоже есть...

Но arm ни есть любой мк, это достаточно мощная железяка.

Я и не говорил, что это любой мк

пс Поднимать весь стек TCP\IP полностью и не нужно вовсе, он слишком жирен

Ясен пень...

[ferrum]

Такой вариант тоже есть...

Прикольно, приведите пример любого серьезного СКУДа где используется не такой вариант...

Во всяком случае контроллеров СКД разговаривающих с СУБД не встречал, но я ведь не волшебник, а только...

[NebsteR]

Прикольно, приведите пример любого серьезного СКУДа где используется не такой вариант...

Понятия не имею, ТС спрашивал о прямых запросах от контроллера - я ответил

[ferrum]

ТС очередной человек, зарегистрировавшийся чтоб задать единственный провакационный вопрос "А что если сделать квадратные колеса" и смыться

Нужен этот огород? Я подозреваю что человек нуждается в интеграции с какой то системой( не иначе как с апачем), дак это совсем другой разговор

[nxs]

Разжуйте слово "Реализовать": Разработать , Выбрать готовое?

Разработать, если нет готового решения (или хотя-бы частичного решения)

Сколько точек доступа? Степень территориальной распределенности?

На данный момент одна дверь. Всё.

К чему такая категоричная централизванность? При перебоях связи двери будут заблокированы что ли? (Кстати не забывайте про ответственные моменты по пожарной безопасности, СКУД должен работать как часы и открыться по сигналу "пожар").

Идеально было бы всегда обращаться к центральной БД, если связи нет - открывать/закрывать "по памяти".

Что касается пожарной безопасности - решение это "для себя", по-этому вопросы открытия по сигналу "пожар" пока не рассматриваю.

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

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

И почему именно Мускуль если не секрет? Мало чтоли СУБД нормальных под Линукс(PostgreSQL, Firebird и др.)

Наша система учета рабочего времени работает на MySQL.

пс Ставить комп на каждую дверь это как минимум "из пушки по воробьям"

Даже это решение на данном этапе устроит. Если не сложно - опишите пути реализации, пожалуйста.

Но arm ни есть любой мк, это достаточно мощная железяка.

Можно и на "любом" 8 битном МК сделать, если отказаться от гнилой концепции СУБД-Контроллер в пользу трехзвенки. Сервер приложений общается с контроллерами на своем "примитивном" протоколе, сервер приложений с СУБД стандартными средствами и без костылей.

Но как? Где об этом почитать?

ТС очередной человек, зарегистрировавшийся чтоб задать единственный провакационный вопрос "А что если сделать квадратные колеса" и смыться

Нужен этот огород? Я подозреваю что человек нуждается в интеграции с какой то системой( не иначе как с апачем), дак это совсем другой разговор

Да, позвольте описать немного подробнее:

1. есть система учета рабочего времени, написана на основе liferay (java)

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

3. нужно в эту систему добавлять время прихода/ухода сотрудника.

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

[ferrum]

А у вас как с программированием под ПК?

Контроллер Z5R NET и SDK к нему для ваших задач я думаю за глаза и никаких малин.

Извиняйте но библиотекак Виндовая только, хотя стоит уточнить

Изменено 12 июня, 2013 пользователем ferrum

[nxs]

Вот уже больше 10ти лет работаю системным администратором.

Пописываю на пхп в качестве подработки, скрипты на шелле - само собой.

Системным программированием не увлекался, но руки прямо стоят - думаю, справлюсь.

[ferrum]

Конвертер Z397 для Линуксов нормально подойдет, так как аппаратный в отличии от СДК выше упомянутый, протокол конвертер-ПК открыт.

На PHP я думаю "не совсем удобно" будет, удобней написать будет демон мониторящий компорт, выбирающий события из контроллера и закидывающий их в БД

[nxs]

Спасибо, сейчас посмотрю, что я смогу с ним сделать.

Ещё нашел такой вариант, но вам не по душе будет: http://nesit.org/rfp...-access-system/

Но очень просто в реализации.

Изменено 12 июня, 2013 пользователем nxs

[ferrum]

Почему же не по душе, эффектная игрушка.

Главное чтоб вам нравилось.

[nxs]

Мне нравится. Я имел ввиду, что в ваших глазах это решение "с пушки по воробьям"

У меня ещё один вопрос. Реализую по вот этой схеме: https://github.com/xillwillx/RFPiD

Там есть картинка, где все красиво нарисовано. Вот она:

\

Не могли бы вы ответить, что это там? Нигде не нашел описания.

[NebsteR]

A breadboard, wires, and 12v power adapter...

[nxs]

Семен-семеныч ... спасибо!

Кстати, (простите за дилетантский вопрос) а на сколько безопасна такая схема?

Может дополнительно добавить какие-то развязки?

Изменено 16 июня, 2013 пользователем nxs

[nxs]

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

Вопрос новый появился: что мне нужно в схеме заменить, если место замка (12 вольт на клемы) надо подавать питание 220В на другое устройство (звонок) с большим током (около 10 ампер)?

С блоком питания понятно, а с транзистором как?