QT&ZigBee Опции

[Stoptyssin]

Здравствуйте! Заранее извиниясь за ламерство. Пишу диплом. Надо написать программу которая получает данные от нескольких ZigBee устройст и заносит их в базу данных (MySql). В принципе все устройства соеденены с ПК через ZigBee коллектор который работает как виртуальный COM-порт. Ни с мускулем ни QT особо дел не имел. Подскажите в каком направлении двигаться, если можно то с примерами (можно и на WiFi и на Bluetouth там я сам разберусь). И последний вопрос (самый ламерский), как лучше - принимать данные : буфер -> файл ->бд, или же буфер ->бд (временная таблица)-> файл. Заранее спасибо за ответы.

[Abesh]

Библиотека по работе с Com -портом:
QSerialDevice

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

[zloiia]

Ну насчет последовательного порта я бы все-таки порекомендовал qextserialport. Ну если будет использоваться MinGW и Винда, то ТУТ у меня есть все библиотеки которые в данном случае понадобятся уже собранные.

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

[kuzulis]

Ну насчет последовательного порта я бы все-таки порекомендовал qextserialport.

Чем аргументируешь? Чем оно лучше?

[Stoptyssin]

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

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

[zloiia]

Чем аргументируешь? Чем оно лучше?

Все равно все от него пляшут

данные полученные с устройства должны сохранятся в архиве, а БД уже обработанные.

А можно сразу нескромный вопрос - "А чем БД плоха в качестве архива?" Вы же, если я не ошибаюсь, MySQL использовать собрались, а там есть такой замечательный тип как Archive. И вообще часть обработки (если не всю) можно положить непосредственно на базу данных. Почитайте про триггеры

При этом всем может одновременно идти инфармация от нескольких устройств

Вы что-то там упоминали про ZigBee коллектор, что-то не могу понять как он работает. Он принимает данные с устройств и какает в порт сообщениями типа "Такой-то девайс послал то-то" ? Или он на одно устройство рассчитан?

[Stoptyssin]

Чем аргументируешь? Чем оно лучше?

Он принимает данные с устройств и какает в порт сообщениями типа "Такой-то девайс послал то-то" - именно так

[kuzulis]

Все равно все от него пляшут

LOL Кто эти все?

Сейчас идет процесс интеграции QSerialDevice 2.0 в Qt (как аддон).
Nokia дала добро и в скором времени начнется интеграция репозитория и т.п.

Так что про QextSerialPort можно забыть, тем более, он по многим параметрам уступает
как в кривом архитектурном плане, возможностях, также оно уже "мертво" и не развивается вообще.

Так что вывод делайте сами.

Он принимает данные с устройств и какает в порт сообщениями типа "Такой-то девайс послал то-то" - именно так

Я не распарсил, что имеется ввиду?

Сообщение отредактировал kuzulis - 21.1.2012, 18:00

[Stoptyssin]

Будет строиться сеть (звезда) на интерфейсе ZigBee, вся игфа со всех устройств сливается в один ПК. В Пк вставляется следующая херотень http://www.telegesis.com/products/etrx2_usb.htm

[zloiia]

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

<CommandValue>

Где Command и Value были целыми числами. Данные капали где-то 5 раз в секунду и лень было заморачиваться с оптимизацией, поэтому сделал так. (писал с использованием QextSerialPort но разницы никакой). Унаследовался от QextSerialPort , завел слот, который связал с сигналом readyRead() (то есть в этом слоте читал данные, которые пришли с порта). В нем все что приходило забивал в свойство этого класса типа QByteArray (то есть создавал буфер на случай если у меня не вся команда придет сразу) и затем в этом буфере искал целую команду. Когда находил команду, высылал сигнал, который сообщал что за команда пришла и ее параметр

void Device::newData()
{
    if(bytesAvailable()<=0) return;

    _buffer.append(readAll()); //дописываю в буфер данные что прочитаны

    if(_buffer.size()>=3)
    {
        QRegExp rx("<([0-7])(\\d{0,})>"); 

        int pos =0;
        while(rx.indexIn(_buffer,pos)!= -1) //накладываю маску
        {
            char command = rx.cap(1).toAscii().at(0); //смотрю что за команда пришла
            int value=0; //какой параметр команды
            int led=0; //какой светодио
            switch(command)
            {
                case (int)LED_NUM:
                    led=rx.cap(2).toInt();
                break;

                case (int)BLINK_PERIOD:
                    value=rx.cap(2).toInt();
                break;

                case (int)LED_BRIGHT:
                    led=rx.cap(2).mid(0,1).toInt();
                    value=rx.cap(2).mid(1,BRIGHT_SIZE).toInt();
                break;

                case (int)ECHO: emit echoFounded(1); break;
            }
            emit innedData((char)command,value,led); //высылаю сигнал о том что принята команда
            _buffer.remove(pos,rx.matchedLength());
            pos+=rx.matchedLength();
        }

        rx.setPattern("error");
        if( (pos=rx.indexIn(_buffer,0)) != -1 )
        {
            _buffer.remove(pos,rx.matchedLength());
            emit errorFounded(0);
        }
    }

}

Затем создал обычный класс, унаследованный от QObject, к котором принимал этот сигнал и просто забивал очередь QQueue. В этом-же классе переопределил свойство void timerEvent(QTimerEvent *); и в нем смотрел, если очередь не пустая, то писал в базу одно первое сообщение очереди и успокаивался. Пришлось извратиться с таймером так, потому что в качестве базы выступала xml таблица на удаленной машине, подключенная через ODBC