Open basti0001 opened 6 years ago
manup
commented
6 years ago Hi, thanks for looking into this. This plugin hasn't been updated in while I'll have a look to fix the build and readme.md when I'm back from travel end of January.
Meanwhile if you wanna try the plugin should build similar as the REST API plugin .pro file, maybe you can compare these two for linker differences.
basti0001
commented
6 years ago Hi Manuel, enjoy traveling ;-)
I had a look and checked out the git repro for the deconz-rest-plugin. The Version of qt is in both cases the same (5.7.1 from the debian stretch repro). Compiling of this repro fails however: In member function ‘bool DeRestPluginPrivate::allowedToCreateApikey(const ApiRequest&, ApiResponse&, QVariantMap&)’: 'ParamSecurityMaterial0’ is not a member of ‘deCONZ’ QByteArray sec0 = apsCtrl->getParameter(deCONZ::ParamSecurityMaterial0);
I had a look into types.h and truly this struct element does not exist. So compiler is complaining for a reason. This means I can't investigate further from the "trunk". I will have a look, maybe I can switch from tunk to the labled version.
Cheers
Sebastian
basti0001
commented
6 years ago Hi again, switching to the release with
git checkout tags/V2_04_99
leads to same compiling error: 'ParamSecurityMaterial0’ is not a member of ‘deCONZ’ QByteArray sec0 = apsCtrl->getParameter(deCONZ::ParamSecurityMaterial0);
Conclusion: master and tag/V2_04_99 (REST plugin) seem to have compiling issues with the default .pro files shipped. But this is a issue for the other repro. Shall I create another issue for the rest-plugin repro?
Cheers
Sebastian
Hi Dresden dev, 1rst of all: thx for the nice tool & job on the resbee! I started with debian stretch and the deCONZ application this xmas. working so far with a OSRAM lightify for debugging and 1rst approaches.
background:
q_Widget.pro: QT += core gui
LIBS+= -L../.. -ldeCONZ -lcrypt
unix:!macx: LIBS += -ldeCONZ -lcrypt greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = q_Widget DEFINES += DECONZ_DLLSPEC=Q_DECL_IMPORT TEMPLATE = app DEFINES += QT_DEPRECATED_WARNINGS
SOURCES += main.cpp\ mainwindow.cpp \ MyNode.cpp
HEADERS += mainwindow.h \ MyNode.h
FORMS += mainwindow.ui
QMAKE_CXXFLAGS += -Wno-attributes
INCLUDEPATH += /usr/include/deconz /usr/include
.pro file finished
here the src code for the main.cpp: int main(int argc, char *argv[]) { QApplication a(argc, argv); printf("HelloWorld\n"); BasicApsPlugin MyApsPlugin; return 0; }
issue: output shows: ./q_Widget libEGL warning: DRI3: Screen seems not DRI3 capable libEGL warning: DRI2: failed to authenticate HelloWorld QObject::connect: Cannot connect (null)::apsdeDataConfirm(const deCONZ::ApsDataConfirm&) to BasicApsPlugin::apsdeDataConfirm(const deCONZ::ApsDataConfirm&) QObject::connect: Cannot connect (null)::apsdeDataIndication(const deCONZ::ApsDataIndication&) to BasicApsPlugin::apsdeDataIndication(const deCONZ::ApsDataIndication&)
Means: program compiles and runs, but during run time there is an issue where we can't connect to the lib --> exit. What am I missing? Default location of ldeCONZ is at /usr/libs and linked dynamically as system lib. Do I need to link statically? Do I need to run deCONZ as gui application in order to gain access to functionality? Maybe I got it all wrong. According to the doc I expected the API to gain access to the already running deCONZ application. Is this correct? Means there are already instances e.g. m_apsCtrl = deCONZ::ApsController::instance();
If not correct, this would mean one has to program parts of the deCONZ application on it's own. I expected the API only to gain access to (ideal case) the found objects in the MeshGrid --> I can take care of application where I focus on the intelligence of the automated home, not on the deeper detail of the ZigBee standard.
Thx for your time and answer
Sebastian