Insta Zigbee Blinds Actuator "Jalousieaktor Mini"

[janikmu]

Device

• Product name: Zigbee Jalousieaktor Mini
• Manufacturer: Insta GmbH
• Model identifier: Generic UP Device
• Device type : Please remove all unrelated device types.
  • Switch
  • Other: Blinds

Insta (under the name Nexentro) has released multiple Zigbee actors, I bought this one for blinds, which also has input lines for conventional switches: https://www.insta.de/produktloesungen/nexentro/produktdetail/zigbee_jalousieaktor_mini

It shows up in deconz after pairing it through the Nexentro Config App (initial config through Bluetooth, then pair with gateway/bridge) and has multiple endpoints, two home automation endpoints and a third I don't recognize. I can execute both lift and tilt value and percentage, ~though tilt seems to be off, but this can be a calibration matter.~

As of now, the REST API has meaningful values for lift and open, but not tilt: {"etag":"968a3eef2800909a974a540715683fb9","hascolor":false,"lastannounced":null,"lastseen":"2021-03-20T18:12Z","manufacturername":"Insta GmbH","modelid":"Generic UP Device","name":"Mittleres Rollo","state":{"bri":63,"lift":25,"on":true,"open":true,"reachable":true},"swversion":"00.47.00","type":"Window covering device","uniqueid":"84:2e:14:ff:fe:a1:cd:5f-06"}}

Also, I can't see anything about the state of switch input state.

The first endpoint is the actual device, the second one a controller. The first one has the Window Covering cluster:

Screenshots

Basic

Identify

Alarms

Device Temperature

Groups

Scenes

On/Off

Level Control

Color Control

Simple Metering

Diagnostics

Other clusters that are not mentioned above

Window Covering

[Smanar]

I can execute both lift and tilt value and percentage, though tilt seems to be off, but this can be a calibration matter.

But on the device I m seing only up and down as wiring, how you can have tilt and lift ?

Also, I can't see anything about the state of switch input state.

It probably possible, but you can just use the covering return state ? if the covering is open, switch is on "up"

[janikmu]

Tilt is possible because after doing calibration (either by doing an up and down and blind tilt cycle while pressing the Prog button in device, or by manually entering the times in the app - see below) the device knows open/closed tilt limit and thus Tilt Percentage (see Window Covering cluster Attributes). This is why I think it can be easily yielded in the REST API.

Regarding the switch inputs: I think it depends on the employed switch (sprung - those that need to be pressed continuously - vs fixed - those that remain in position and usually cannot be pressed simultaneously). I can imagine scenarios where it would be good to know what the switch input to the actor is. But this is definitively not a priority. More of a "could", if even possible?

[SwoopX]

Well, apparently the deconz code seems to be a little inconvenient in this regard. As for the tilt values, it currently goes like this:

When you pair the device, the window covering type is checked for its current value. As default, it creates only lift for the device. When you change that in deconz GUI, the code should detect that and also expose tilt. However, it appears that there's a chicken and egg situation. When you now have changed the value to also expose tilt, the code is not called, as there's a check if a valid HA endpoints exist (which should already be the case) and therefore, a whole passage is skipped. This is especially notable in your case, but should also be a reason for other devices not exposing changed resources (e.g. after a firmware update). I'm not 100% sure if I haven't overlooked anything which compensates this regardless.

As for the switch endpoints you mentioned, there does not seem to be a way to expose them, as they're not there from a zigbee perspective. However, there's always the option for vendors to implement and expose their own attributes and hence expose additional configuration attributes, but those need to be known upfront to be laveraged. There's a way to discover them, but this (currently) involves installing an additional plugin for discovery and then some trial and error to figure out what they do.

Endpoint 7 could be exposed as switch resource, but not sure to what extend that would be meaningful.

OT Rather interesting devices. I would have hoped Blutooth could be disabled and the switches would support power metering. Considerable alternative if you don't wanna go for ubisys.

[janikmu]

When you pair the device, the window covering type is checked for its current value. As default, it creates only lift for the device. When you change that in deconz GUI, the code should detect that and also expose tilt.

I don't quite understand this. I had ~lift~ both lift and tilt attributes exposed without changing anything.

The window covering cluster is also not polled. so this is kinda problematic for the realistic values of the current position.

I have witnessed this in Homebridge, where other states other than "opening" and "closing" are not shown (as opposed to the usual percentages).

[Smanar]

Tilt is possible because after doing calibration (either by doing an up and down and blind tilt cycle while pressing the Prog button in device, or by manually entering the times in the app - see below) the device knows open/closed tilt limit and thus Tilt Percentage (see Window Covering cluster Attributes). This is why I think it can be easily yielded in the REST API.

I can make the field available in the API, but I realy don't know what will happen.

Do you have a linux machine to make test ?

[janikmu]

Yes I do, and would happily test

[Smanar]

You have the procedure here https://github.com/dresden-elektronik/deconz-rest-plugin#install-deconz-development-package-optional-linux-only So for you

sudo apt install deconz-dev
git clone --branch test_tilt https://github.com/Smanar/deconz-rest-plugin.git
cd deconz-rest-plugin
qmake && make
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins

If I m right, it will enable tilt and lift, so you can make test with it. You probably need to re include the devicebut not sure, a restart can be enought.

[janikmu]

Will do, but shouldnt that https://github.com/Smanar/deconz-rest-plugin/blob/17b77c4cf75183f67421e49e14a1aa18a86b4972/light_node.cpp#L533

be switched for a more specific check of the Window Covering Type value (Tilt and Lift)? I could imagine other unknown devices could broadcast "Generic UP Device" as well. I also see that VENDOR_INSTA is already implemented but unused.

[Smanar]

Sure ^^, but it s to test if it work. But it s rare having 2 time the same model ID, it s the way used by manufacture to reconize their stuff, ( a part Tuya where all devices have the same ...)

[SwoopX]

@janikmu

When you pair the device, the window covering type is checked for its current value. As default, it creates only lift for the device. When you change that in deconz GUI, the code should detect that and also expose tilt.

I don't quite understand this. I had lift attributes exposed without changing anything.

Yes, but I'm talking about tilt. That's what you're missing, right?

@Smanar Your proposed change eliminates the symptoms, but not the root case if I'm right ;)

[janikmu]

@SwoopX ugh, sorry, I meant to write tilt. Both Lift and tilt values (absolutes and percentages) were in deconz (GUI) without changing anything. This is what you are talking about, right?

[janikmu]

@Smanar

You have the procedure here https://github.com/dresden-elektronik/deconz-rest-plugin#install-deconz-development-package-optional-linux-only https://github.com/Smanar/deconz-rest-plugin.git

If I m right, it will enable tilt and lift, so you can make test with it. You probably need to re include the devicebut not sure, a restart can be enought.

I've done this. Restarted deconz (is the development version using deconz-gui or deconz headless? I tried both), kicked the device out the network and re-joined the network, but still no lift value in the API.

Update: I think @SwoopX is right about the symptoms vs root cause thing and what he said about polling. In addition to the tilt attribute still not being exposed in the API, I can't seem to get sensible lift values from it as well. E.g. currently my covering is closed (i.e., lift should be 100, but the REST API gives me a lift value of 0.). However, a curl --header "Content-Type: application/json" --request PUT --data '{"lift":0}' http://192.168.178.36:8080/api/KEY/lights/3/state does indeed open it, so it knows which is what, but doesn't correctly reflect that in the API.

[SwoopX]

@SwoopX ugh, sorry, I meant to write tilt. Both Lift and tilt values (absolutes and percentages) were in deconz (GUI) without changing anything. This is what you are talking about, right?

I meant exposure via API, it's clear that the attributes/values are available in deconz GUI if they're supported ;) The feedback you've given so far confirms my theory.

With the modification Smanar proposed, you should only get tilt exposed via API if you delete the device in Phoscon (which basically resets the device) and pair it again.

[janikmu]

With the modification Smanar proposed, you should only get tilt exposed via API if you delete the device in Phoscon (which basically resets the device) and pair it again.

See my comment above. No success :(

OT: Is there any motion to refactor the API resources in future major releases such that e.g. window covering devices (that get more popular, especially with the Ikea solutions now) are not listed as /lights but rather own resources? I could imagine benefits such as faster, dedicated development of related functionalities?

[Smanar]

@Smanar Your proposed change eliminates the symptoms, but not the root case if I'm right ;)

Sure, was a hack to test, but seem not working, 3 solutions

• The model id is unknow at this step
• The attribute WindowCoveringType is not used correctly (as you said before)
• A typo.

Unfortunately I think it s the 2

[janikmu]

Do you see any path to get this solved @Smanar?

[Smanar]

To test you can force the device detection Instead of using if (modelId() == QLatin1String("Generic UP Device"))

use

if (true)

If after that you still not have the field in the json to make test, I think the problem is more on your compilation procedure.

[janikmu]

The adventure of Zigbee controlled blinds continues to unfold...

REST API

Okay, so I looked into it again, and with a hardcoded hasTilt = true in line 504 the tilt attribute is exposed to the API which means it is (most likely) number 2:

The attribute WindowCoveringType is not used correctly (as you said before)

@Smanar said

When you pair the device, the window covering type is checked for its current value. As default, it creates only lift for the device.

But this is weird to me. Shouldn't any device that has the window covering cluster and is not the lumi.light.aqcn02 be checked for the WindowCoveringType? The Nexentro device seemingly correctly reports that cluster attribute as 8 = Tilt Blind Lift & Tilt (see in the Window Covering Cluster Screenshot from deconz GUI above) and ergo should without any change to the code have hasTilt = true...

How can we proceed from here if the window covering type attribute is really not correctly identified?

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/0cd5d0a328a03af7508c5cfd4ec92e25a5ef9c84/light_node.cpp#L495-L504

Polling

The next thing is, that changes are not reflected. @Smanar said (did you delete that part of your post, I cant find it?) that polling does not (really) work for the Window Covering Cluster - is there a way to make this happen?

Execution of Lift and Tilt commands

The final thing I realized is that an API call that changes both the lift and tilt attributes is not executed correctly because of the non-ensured order of packets I guess? https://github.com/dresden-elektronik/deconz-rest-plugin/blob/0cd5d0a328a03af7508c5cfd4ec92e25a5ef9c84/window_covering.cpp#L86 In this call the loop looks at each received package individually, but when talking about lift and tilt, it is important to respect the order 1. lift to position then 2. tilt to desired angle at the reached position, because a lift also at the same time implicitly changes the tilt position for shutters. (upwards lift opens the blinds, downwards lift usually closes the blinds). The current Window Covering API implementation is courtesy of @ebaauw if I am not mistaken, that's why I mention you here fyi.

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[janikmu]

Not stale, still unresolved

[paolanto]

Hello, I would only like to add that I also own this device and would be interested in proper support for it in the REST API. I am not practical at all with C++, but please let me know if there is anything I can do to help.

It is really an interesting device and can see it becoming very popular in scenarios where no physical buttons are present (for example when retrofitting electric blinds), since the Bluetooth interface provides a great emergency control solution.

[Smanar]

Oups, have totally forget this issue.

Okay, so I looked into it again, and with a hardcoded hasTilt = true in line 504 the tilt attribute is exposed to the API which means it is (most likely) number 2:

So it mean the model id is probably not exposed yet in code else my code would have worked , you can check that adding some more debug lines.

if (modelId() == QLatin1String("Generic UP Device"))
{
    hasLift = true;
    hasTilt = true;
}

The next thing is, that changes are not reflected. @Smanar said (did you delete that part of your post, I cant find it?) that polling does not (really) work for the Window Covering Cluster - is there a way to make this happen?

Have totaly forget, but this device need to support reporting so it don't need polling, no ?

In this call the loop looks at each received package individually, but when talking about lift and tilt, it is important to respect the order 1. lift to position then 2. tilt to desired angle at the reached position, because a lift also at the same time implicitly changes the tilt position for shutters. (upwards lift opens the blinds, downwards lift usually closes the blinds).

This is a new problem, but I think it s not deconz problem, on an other device there is no problem, can use the titlt value, even the covering is at 50% For me better to have a command for lift and another for tilt, and code something on your third app.

To resume, I think it will be usefull adding 2 debug line

• to print the modelid()
• to print the attribute 0x0000 value.

DBG_Printf(DBG_INFO, "Debug personnal 1 %s\n", qPrintable(modelId());
DBG_Printf(DBG_INFO, "Debug personnal 2 0x%04X\n", ia->id());

[SwoopX]

I'll rewrite the cluster handling somewhere this week a bit. Would be nice to know if attribute 0x0000 is reportable. @janikmu could you check that?

[janikmu]

Happy to know that this is not forgotten 😉 @SwoopX sure, using the two debug lines provided by @Smanar I guess? These do not seems to output anything sensible, at least when adding them under https://github.com/dresden-elektronik/deconz-rest-plugin/blob/9a98cbee28519168c2b0339f00dd7f10c47c93c9/light_node.cpp#L527

Logging of adding the device below:

15:24:22:146 Debug personnal 1
15:24:22:146 Debug personnal 2 0x0000
15:24:22:147 sql exec SELECT * FROM nodes WHERE mac='84:2e:14:ff:fe:a1:cd:5f-06' COLLATE NOCASE AND state != 'deleted'
15:24:22:148 sql exec SELECT * FROM nodes WHERE mac='0x842e14fffea1cd5f' COLLATE NOCASE AND state != 'deleted'
15:24:22:149 sql exec SELECT * FROM nodes
15:24:22:150 LightNode 4: Window covering device 4 added
15:24:22:151 enqueue event event/added for /lights/4
15:24:22:152 enqueue event config/localtime for /config/
15:24:22:152 add task 433 type 30 to 0x842E14FFFEA1CD5F cluster 0x0004 req.id 25
15:24:22:153 drop request to zombie (rx = 0)
15:24:22:156 Websocket 192.168.178.40:54324 send message: {"e":"added","id":"4","light":{"etag":"d0184dc5319026f5da2a407beaeca2dd","hascolor":false,"lastannounced":null,"lastseen":null,"manufacturername":"Insta","modelid":null,"name":"Window covering device 4","state":{"bri":0,"lift":0,"on":false,"open":false,"reachable":true,"sat":0,"tilt":0},"swversion":null,"type":"Window covering device","uniqueid":"84:2e:14:ff:fe:a1:cd:5f-06"},"r":"lights","t":"event","uniqueid":"84:2e:14:ff:fe:a1:cd:5f-06"} (ret = 443)
15:24:22:483 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x0000
15:24:22:574 poll node 84:2e:14:ff:fe:a1:cd:5f-06
15:24:22:575 Poll light node Window covering device 4
15:24:22:627 read attributes of 0x842E14FFFEA1CD5F cluster: 0x0000: [ 15:24:22:628 0x0005 15:24:22:629 ]
15:24:22:629 add task 435 type 19 to 0x842E14FFFEA1CD5F cluster 0x0000 req.id 29
15:24:22:630 Poll APS request 29 to 0x842E14FFFEA1CD5F cluster: 0x0000
15:24:22:721 Poll APS confirm 29 status: 0xE9
15:24:22:722     drop item attr/swversion
15:24:22:722 0x842E14FFFEA1CD5F error APSDE-DATA.confirm: 0xE9 on task
15:24:22:723 Erase task req-id: 29, type: 19 zcl seqno: 117 send time 0, profileId: 0x0104, clusterId: 0x0000
15:24:23:147 enqueue event config/localtime for /config/
15:24:23:305 poll node 84:2e:14:ff:fe:a1:cd:5f-06
15:24:23:305 Poll light node Window covering device 4
15:24:23:354 read attributes of 0x842E14FFFEA1CD5F cluster: 0x0000: [ 15:24:23:355 0x0005 15:24:23:355 ]
15:24:23:356 add task 439 type 19 to 0x842E14FFFEA1CD5F cluster 0x0000 req.id 33
15:24:23:357 Poll APS request 33 to 0x842E14FFFEA1CD5F cluster: 0x0000
15:24:23:521 Poll APS confirm 33 status: 0xE9
15:24:23:522     drop item attr/swversion
15:24:23:523 0x842E14FFFEA1CD5F error APSDE-DATA.confirm: 0xE9 on task
15:24:23:524 Erase task req-id: 33, type: 19 zcl seqno: 118 send time 0, profileId: 0x0104, clusterId: 0x0000
15:24:24:146 enqueue event config/localtime for /config/
15:24:24:148 poll node 84:2e:14:ff:fe:a1:cd:5f-06
15:24:24:148 Poll light node Window covering device 4
15:24:24:149 Idle timer triggered
15:24:24:199 read attributes of 0x842E14FFFEA1CD5F cluster: 0x0000: [ 15:24:24:200 0x0005 15:24:24:200 ]
15:24:24:201 add task 444 type 19 to 0x842E14FFFEA1CD5F cluster 0x0000 req.id 38
15:24:24:201 Poll APS request 38 to 0x842E14FFFEA1CD5F cluster: 0x0000
15:24:24:322 Poll APS confirm 38 status: 0xE9
15:24:24:324     drop item attr/swversion
15:24:24:326 0x842E14FFFEA1CD5F error APSDE-DATA.confirm: 0xE9 on task
15:24:24:327 Erase task req-id: 38, type: 19 zcl seqno: 119 send time 0, profileId: 0x0104, clusterId: 0x0000
15:24:24:882 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x0000

[SwoopX]

@janikmu I more meant what is described here for attribute 0x0000 of the window covering server cluster https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/How-to...#manually-configure-attribute-reporting

The issue with the current code is that it's in an "act before read" dilemma. The code is correct in that sense, but the read never takes place so the attribute value always remains in its initialization state being 0. Additionally, the passage is only called during initial pairing hence an updated value will never get recognized.

Not too sure yet what the best approach would be to act on a change and what to assume as default.

[janikmu]

Ah I see @SwoopX. Below is a screenshot. It says NOT_FOUND which is "a reportable attribute which has not yet been configured" according to the linked documentation - I guess that is a good sign?

[SwoopX]

I guess... So this code is based on the assumption that the attribute is reportable. It dynamically adds and deletes the required resource items based on the set covering type and also configures all attribute reports for the window covering cluster. Re-pairing the device shouldn't be necessary.

git clone --branch=insta https://github.com/swoopx/deconz-rest-plugin.git

[janikmu]

I'm getting errors building your latest changes @SwoopX

bindings.cpp: In member function ‘bool DeRestPluginPrivate::sendConfigureReportingRequest(BindingTask&)’:
bindings.cpp:2083:13: error: ‘rq2’ was not declared in this scope
             rq2.dataType = deCONZ::Zcl8BitEnum;
             ^~~
bindings.cpp:2083:13: note: suggested alternative: ‘rq’
             rq2.dataType = deCONZ::Zcl8BitEnum;
             ^~~
             rq
bindings.cpp:2088:13: error: ‘rq3’ was not declared in this scope
             rq3.dataType = deCONZ::Zcl8BitUint;
             ^~~
bindings.cpp:2088:13: note: suggested alternative: ‘rq’
             rq3.dataType = deCONZ::Zcl8BitUint;
             ^~~
             rq
bindings.cpp:2094:68: error: no matching function for call to ‘DeRestPluginPrivate::sendConfigureReportingRequest(BindingTask&, <brace-enclosed initializer list>)’
             return sendConfigureReportingRequest(bt, {rq, rq2, rq3});
                                                                    ^
bindings.cpp:679:6: note: candidate: ‘bool DeRestPluginPrivate::sendConfigureReportingRequest(BindingTask&, const std::vector<ConfigureReportingRequest>&)’
 bool DeRestPluginPrivate::sendConfigureReportingRequest(BindingTask &bt, const std::vector<ConfigureReportingRequest> &requests)
      ^~~~~~~~~~~~~~~~~~~
bindings.cpp:679:6: note:   no known conversion for argument 2 from ‘<brace-enclosed initializer list>’ to ‘const std::vector<ConfigureReportingRequest>&’
bindings.cpp:836:6: note: candidate: ‘bool DeRestPluginPrivate::sendConfigureReportingRequest(BindingTask&)’
 bool DeRestPluginPrivate::sendConfigureReportingRequest(BindingTask &bt)
      ^~~~~~~~~~~~~~~~~~~
bindings.cpp:836:6: note:   candidate expects 1 argument, 2 provided

[SwoopX]

@janikmu fixed

[janikmu]

...leading to even more / new errors during make: @SwoopX

de_web_plugin.cpp: In constructor ‘ApiRequest::ApiRequest(const QHttpRequestHeader&, const QStringList&, QTcpSocket*, const QString&)’:
de_web_plugin.cpp:565:45: error: invalid initialization of reference of type ‘const QLatin1String&’ from expression of type ‘const QString’
         version = getAcceptHeaderApiVersion(accept);
                                             ^~~~~~
de_web_plugin.cpp:527:19: note: in passing argument 1 of ‘ApiVersion getAcceptHeaderApiVersion(const QLatin1String&)’
 static ApiVersion getAcceptHeaderApiVersion(const QLatin1String &hdrValue)
                   ^~~~~~~~~~~~~~~~~~~~~~~~~
de_web_plugin.cpp: In member function ‘void DeRestPluginPrivate::addLightNode(const deCONZ::Node*)’:
de_web_plugin.cpp:2103:34: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘unsigned int’} and ‘int’ [-Wsign-compare]
             for (size_t c = 0; c < sd->inClusters().size(); c++)
                                ~~^~~~~~~~~~~~~~~~~~~~~~~~~
de_web_plugin.cpp:2165:30: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘unsigned int’} and ‘int’ [-Wsign-compare]
         for (size_t c = 0; c < i->inClusters().size(); c++)
                            ~~^~~~~~~~~~~~~~~~~~~~~~~~
g++ -c -pipe -Wno-attributes -Wno-psabi -Wall -O2 -std=gnu++1y -Wall -W -D_REENTRANT -fPIC -DDECONZ_DLLSPEC=Q_DECL_IMPORT -DSKIP_EMPTY_PARTS=QString::SkipEmptyParts -DUSE_WEBSOCKETS -DHAS_SQLITE3 -DHAS_OPENSSL -DGW_SW_VERSION=\"2.12.01\" -DGW_SW_DATE=1624400674 -DGW_API_VERSION=\"1.16.0\" -DGIT_COMMMIT=\"37225e95a65298fbb5b26445f9a1b405d9ec8f0e\" -DGW_AUTO_UPDATE_AVR_FW_VERSION=0x260b0500 -DGW_AUTO_UPDATE_R21_FW_VERSION=0x26420700 -DGW_MIN_AVR_FW_VERSION=0x26390500 -DGW_MIN_R21_FW_VERSION=0x26660700 -DGW_MIN_DERFUSB23E0X_FW_VERSION=0x22030300 -DGW_DEFAULT_NAME=\"Phoscon-GW\" -DQT_NO_DEBUG -DQT_PLUGIN -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_SERIALPORT_LIB -DQT_WEBSOCKETS_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I. -I../.. -I../../common -isystem /usr/include/arm-linux-gnueabihf/qt5 -isystem /usr/include/arm-linux-gnueabihf/qt5/QtWidgets -isystem /usr/include/arm-linux-gnueabihf/qt5/QtGui -isystem /usr/include/arm-linux-gnueabihf/qt5/QtSerialPort -isystem /usr/include/arm-linux-gnueabihf/qt5/QtWebSockets -isystem /usr/include/arm-linux-gnueabihf/qt5/QtNetwork -isystem /usr/include/arm-linux-gnueabihf/qt5/QtCore -Irelease -I. -I/usr/lib/arm-linux-gnueabihf/qt5/mkspecs/linux-g++ -o release/de_otau.o de_otau.cpp
de_web_plugin.cpp: In member function ‘virtual bool DeRestPlugin::isHttpTarget(const QHttpRequestHeader&)’:
de_web_plugin.cpp:17561:13: error: ‘const class QHttpRequestHeader’ has no member named ‘pathAt’; did you mean ‘path’?
     if (hdr.pathAt(0) == QLatin1String("api"))
             ^~~~~~
             path
de_web_plugin.cpp:17565:18: error: ‘const class QHttpRequestHeader’ has no member named ‘pathAt’; did you mean ‘path’?
     else if (hdr.pathAt(0) == QLatin1String("description.xml"))
                  ^~~~~~
                  path
In file included from /usr/include/arm-linux-gnueabihf/qt5/QtCore/qcoreapplication.h:43,
                 from /usr/include/arm-linux-gnueabihf/qt5/QtCore/QCoreApplication:1,
                 from de_web_plugin.cpp:11:
de_web_plugin.cpp: In member function ‘virtual int DeRestPlugin::handleHttpRequest(const QHttpRequestHeader&, QTcpSocket*)’:
de_web_plugin.cpp:17592:81: error: no matching function for call to ‘asString(const QUrl&)’
         DBG_Printf(DBG_HTTP, "HTTP API %s %s - %s\n", qPrintable(hdr.method()), qPrintable(hdr.url()), qPrintable(sock->peerAddress().toString()));
                                                                                 ^~~~~~~~~~
In file included from /usr/include/arm-linux-gnueabihf/qt5/QtCore/qcoreapplication.h:44,
                 from /usr/include/arm-linux-gnueabihf/qt5/QtCore/QCoreApplication:1,
                 from de_web_plugin.cpp:11:
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qstring.h:1862:23: note: candidate: ‘const QString& QtPrivate::asString(const QString&)’
 inline const QString &asString(const QString &s)    { return s; }
                       ^~~~~~~~
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qstring.h:1862:23: note:   no known conversion for argument 1 from ‘const QUrl’ to ‘const QString&’
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qstring.h:1863:18: note: candidate: ‘QString&& QtPrivate::asString(QString&&)’
 inline QString &&asString(QString &&s)              { return std::move(s); }
                  ^~~~~~~~
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qstring.h:1863:18: note:   no known conversion for argument 1 from ‘const QUrl’ to ‘QString&&’
de_web_plugin.cpp:17595:13: error: ‘const class QHttpRequestHeader’ has no member named ‘httpMethod’; did you mean ‘method’?
     if (hdr.httpMethod() == HttpPost && hdr.hasKey(QLatin1String("Content-Type")) &&
             ^~~~~~~~~~
             method
de_web_plugin.cpp:17595:29: error: ‘HttpPost’ was not declared in this scope
     if (hdr.httpMethod() == HttpPost && hdr.hasKey(QLatin1String("Content-Type")) &&
                             ^~~~~~~~
de_web_plugin.cpp:17596:26: error: could not convert ‘(& hdr)->QHttpRequestHeader::value(QString(QLatin1String(((const char*)"Content-Type"))))’ from ‘const QString’ to ‘QLatin1String’
        contains(hdr.value(QLatin1String("Content-Type")), QLatin1String("multipart/form-data")))
                 ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
de_web_plugin.cpp:17632:17: error: ‘const class QHttpRequestHeader’ has no member named ‘httpMethod’; did you mean ‘method’?
     if (req.hdr.httpMethod() == HttpOptions)
                 ^~~~~~~~~~
                 method
de_web_plugin.cpp:17632:33: error: ‘HttpOptions’ was not declared in this scope
     if (req.hdr.httpMethod() == HttpOptions)
                                 ^~~~~~~~~~~
de_web_plugin.cpp:17637:55: error: no match for ‘operator=’ (operand types are ‘QLatin1String’ and ‘const QString’)
             origin = hdr.value(QLatin1String("Origin"));
                                                       ^
In file included from /usr/include/arm-linux-gnueabihf/qt5/QtCore/qcoreapplication.h:44,
                 from /usr/include/arm-linux-gnueabihf/qt5/QtCore/QCoreApplication:1,
                 from de_web_plugin.cpp:11:
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qstring.h:91:7: note: candidate: ‘constexpr QLatin1String& QLatin1String::operator=(const QLatin1String&)’
 class QLatin1String
       ^~~~~~~~~~~~~
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qstring.h:91:7: note:   no known conversion for argument 1 from ‘const QString’ to ‘const QLatin1String&’
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qstring.h:91:7: note: candidate: ‘constexpr QLatin1String& QLatin1String::operator=(QLatin1String&&)’
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qstring.h:91:7: note:   no known conversion for argument 1 from ‘const QString’ to ‘QLatin1String&&’
de_web_plugin.cpp:17659:18: error: ‘const class QHttpRequestHeader’ has no member named ‘httpMethod’; did you mean ‘method’?
     else if (hdr.httpMethod() == HttpPost && hdr.pathComponentsCount() == 2 && hdr.pathAt(1) == QLatin1String("fileupload"))
                  ^~~~~~~~~~
                  method
de_web_plugin.cpp:17659:34: error: ‘HttpPost’ was not declared in this scope
     else if (hdr.httpMethod() == HttpPost && hdr.pathComponentsCount() == 2 && hdr.pathAt(1) == QLatin1String("fileupload"))
                                  ^~~~~~~~
de_web_plugin.cpp:17659:50: error: ‘const class QHttpRequestHeader’ has no member named ‘pathComponentsCount’
     else if (hdr.httpMethod() == HttpPost && hdr.pathComponentsCount() == 2 && hdr.pathAt(1) == QLatin1String("fileupload"))
                                                  ^~~~~~~~~~~~~~~~~~~
de_web_plugin.cpp:17659:84: error: ‘const class QHttpRequestHeader’ has no member named ‘pathAt’; did you mean ‘path’?
     else if (hdr.httpMethod() == HttpPost && hdr.pathComponentsCount() == 2 && hdr.pathAt(1) == QLatin1String("fileupload"))
                                                                                    ^~~~~~
                                                                                    path
de_web_plugin.cpp:17719:18: error: ‘const class QHttpRequestHeader’ has no member named ‘pathComponentsCount’
     else if (hdr.pathComponentsCount() == 1 && hdr.pathAt(0) == QLatin1String("description.xml") && hdr.httpMethod() == HttpGet)
                  ^~~~~~~~~~~~~~~~~~~
de_web_plugin.cpp:17719:52: error: ‘const class QHttpRequestHeader’ has no member named ‘pathAt’; did you mean ‘path’?
     else if (hdr.pathComponentsCount() == 1 && hdr.pathAt(0) == QLatin1String("description.xml") && hdr.httpMethod() == HttpGet)
                                                    ^~~~~~
                                                    path
de_web_plugin.cpp:17719:105: error: ‘const class QHttpRequestHeader’ has no member named ‘httpMethod’; did you mean ‘method’?
     else if (hdr.pathComponentsCount() == 1 && hdr.pathAt(0) == QLatin1String("description.xml") && hdr.httpMethod() == HttpGet)
                                                                                                         ^~~~~~~~~~
                                                                                                         method
de_web_plugin.cpp:17719:121: error: ‘HttpGet’ was not declared in this scope
     else if (hdr.pathComponentsCount() == 1 && hdr.pathAt(0) == QLatin1String("description.xml") && hdr.httpMethod() ==
 HttpGet)

 ^~~~~~~
de_web_plugin.cpp:17739:18: error: ‘const class QHttpRequestHeader’ has no member named ‘pathComponentsCount’
     else if (hdr.pathComponentsCount() > 0 && hdr.pathAt(0) == QLatin1String("api"))
                  ^~~~~~~~~~~~~~~~~~~
de_web_plugin.cpp:17739:51: error: ‘const class QHttpRequestHeader’ has no member named ‘pathAt’; did you mean ‘path’?
     else if (hdr.pathComponentsCount() > 0 && hdr.pathAt(0) == QLatin1String("api"))
                                                   ^~~~~~
                                                   path
de_web_plugin.cpp:17743:17: error: ‘const class QHttpRequestHeader’ has no member named ‘pathComponentsCount’
         if (hdr.pathComponentsCount() >= 2 && (req.auth == ApiAuthFull || req.auth == ApiAuthInternal))
                 ^~~~~~~~~~~~~~~~~~~
de_web_plugin.cpp:17746:21: error: ‘const class QHttpRequestHeader’ has no member named ‘pathComponentsCount’
             if (hdr.pathComponentsCount() == 2 && req.hdr.httpMethod() == HttpGet)
                     ^~~~~~~~~~~~~~~~~~~
de_web_plugin.cpp:17746:59: error: ‘const class QHttpRequestHeader’ has no member named ‘httpMethod’; did you mean ‘method’?
             if (hdr.pathComponentsCount() == 2 && req.hdr.httpMethod() == HttpGet)
                                                           ^~~~~~~~~~
                                                           method
de_web_plugin.cpp:17750:26: error: ‘const class QHttpRequestHeader’ has no member named ‘pathComponentsCount’
             else if (hdr.pathComponentsCount() >= 3)
                          ^~~~~~~~~~~~~~~~~~~
de_web_plugin.cpp:17752:53: error: ‘const class QHttpRequestHeader’ has no member named ‘pathAt’; did you mean ‘path’?
                 const QLatin1String apiModule = hdr.pathAt(2);
                                                     ^~~~~~
                                                     path
de_web_plugin.cpp:17836:46: error: ‘const class QHttpRequestHeader’ has no member named ‘httpMethod’; did you mean ‘method’?
                 if (resourceExist && req.hdr.httpMethod() == HttpGet)
                                              ^~~~~~~~~~
                                              method

[SwoopX]

But this time they're not mine 😉

Can you try to remove the package deconz-dev and then reinstall it? Please make sure you use the beta branch for installing it. You can switch back to stable afterwards.

[janikmu]

~Weird, I re-installed deconz-dev (which was indeed outdated) and rebuild your changes, but one error persists~

Scrap that, of course I forgot to switch from stable to beta channel before re-installing deconz-dev. Everything compiled nicely.

Running deconz, I am now getting weird libpng errors. Looks like dependency update chaos rather than a real error, though...

[SwoopX]

Yeah, I guess everybody has those errors... Just ignore them. How's the device doing?

[janikmu]

Can't ignore them, deconz fails at startup...

This could, however, also be due to something else if these errors are only warnings... should I append the whole startup log? It's quite long before finally failing to start.

[SwoopX]

Sure, but please make sure you upload a file 😉

Does it just not get past the device selection or does it actually crash with a core dump?

[janikmu]

Actually, the startup log from /usr/bin/deCONZ --platform minimal --dbg-info=2 is quite short:

libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Segmentation fault

The startup log from systemctl start deconz followed by journalctl -u deconz is longer, but only repeats itself, but the important bit is this:

Jun 25 12:46:09 raspberrypi systemd[1]: Started deCONZ: ZigBee gateway -- REST API.
Jun 25 12:46:09 raspberrypi deCONZ[22827]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-pi'
Jun 25 12:46:09 raspberrypi deCONZ[22827]: libpng warning: iCCP: known incorrect sRGB profile
Jun 25 12:46:10 raspberrypi systemd[1]: deconz.service: Main process exited, code=killed, status=11/SEGV
Jun 25 12:46:10 raspberrypi systemd[1]: deconz.service: Failed with result 'signal'.

After this it only schedules restarts that then fail with the same exact message.

[SwoopX]

Hm, that's not good. Can you please start deconz as follows:

gdb --args /usr/bin/deCONZ --platform minimal --dbg-info=2

1-2 seconds afterwards, you shourld get the gdb promt where you simply type r followed by pressing return. When the application crashes, you should get the promt again, then please type bt and paste the output here, please.

[janikmu]

There you go:

#0  0x76ed0744 in deCONZ::SimpleDescriptor::inClusters() const () from /usr/lib/libdeCONZ.so.1
#1  0x72566b48 in DeRestPluginPrivate::addLightNode(deCONZ::Node const*) ()
   from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#2  0x7258e928 in DeRestPluginPrivate::nodeEvent(deCONZ::NodeEvent const&) ()
   from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#3  0x726ac1e0 in DeRestPluginPrivate::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) ()
   from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#4  0x75ff1244 in QMetaObject::activate(QObject*, int, int, void**) ()
   from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#5  0x76ed96e0 in deCONZ::ApsController::nodeEvent(deCONZ::NodeEvent const&) () from /usr/lib/libdeCONZ.so.1
#6  0x0003a6b8 in ?? ()
#7  0x000491bc in ?? ()
#8  0x000353c0 in ?? ()
#9  0x759ee718 in __libc_start_main (main=0x7e9ce614, argc=1974603776, argv=0x759ee718 <__libc_start_main+268>,
    init=<optimized out>, fini=0xc6a10, rtld_fini=0x76f314c4 <_dl_fini>, stack_end=0x7e9ce614) at libc-start.c:308
#10 0x00035c74 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[janikmu]

@SwoopX maybe it was all just a hick-up.

I re-installed everything (including dependencies), freed up some space (rookie error, SD card of my Pi was at 100%) and I don't get any segmentation fault anymore. However, the tilt attribute is still not there (the only thing I did not do is re-pair the device).

Log is attached below deconz-insta-dbg.txt

[SwoopX]

Hm, the output looks definitively odd. There's indications your network configuration is corrupt/not working.

[...]
16:58:57:150 apsUseExtPanid is 0xDDDDDDDDDDDDDDDD but should be 0, start reconfiguration
16:59:07:149 apsUseExtPanid is 0xDDDDDDDDDDDDDDDD but should be 0, start reconfiguration
16:59:17:148 apsUseExtPanid is 0xDDDDDDDDDDDDDDDD but should be 0, start reconfiguration
16:59:27:148 apsUseExtPanid is 0xDDDDDDDDDDDDDDDD but should be 0, start reconfiguration

There's no binding attempts, not reporting, no nothing in there I'm afraid. Normally, based on the changes, a read of attribute 0x0000 or an attribute report should trigger the changes on the resource item.

[janikmu]

I will reset and repair everything. Is there a best practice for doing so with the Raspbee? It's the only device in my testing instance so I don't need to retain anything.

[SwoopX]

Ah, sorry. Missed it again.

Not really. Under Linux, there's a folder dresden-elektronik under .share in the home directory of the user running deconz, which almost holds everything (except for the network settings kept on the stick). In deconz GUI, you could probably press the pane to leave the network, then open the network settings and set the PAN ID yourself to all 0 instead of D.

[paolanto]

Hi SwoopX, thank you for your effort so far.

Your latest changes are contained in version 12.12.3-beta, correct? I have upgraded to that version, paired the two blind actuators again and the tilt attribute is still not exposed over the API. If you have time to get back to this issue, then please let me know if there is any log or information I can provide to help you. I am very grateful for your support.

[SwoopX]

No worries. No, the changes are not yet release and hence only available in my repo since I do not know if it works or breaks anything. That's why you'd need to compile the custom plugin once more.

I'll quickly update the branch to the latest changes...

[paolanto]

Ok, I see. Unfortunately the steps to compile the plugin locally seem to be for Linux only and I don't have any Linux environment available for this. I normally run deconz using marthoc's docker container a NAS as well as on Windows for trying out stuff. I am afraid I am only able to try it out and provide feedback if anybody builds and shares binaries compatible with either of these two environments (perhaps the binaries within the docker container can be replaced without rebuilding the container image). Of course I remain available for anything it could be useful to check out or trying out with this device.

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[paolanto]

Not stale, issue still unresolved. @janikmu: any chance you could find the time to test SwoopX changes? I would be very grateful. If not, I can try it myself and confirm, however I would need to setup a Linux system just for doing this.

[janikmu]

Sorry both of you, I had zero time to answer. I have tried repairing, re-installing, everything, still no tilt attribute in the API. However, my weird network configuration seemingly is not fixed, at least the lines remain that state:

apsUseExtPanid is 0xDDDDDDDDDDDDDDDD but should be 0, start reconfiguration

Full log: test_debug.txt

For what it is worth, I have switched to zigbee2mqtt and it works flawlessly with that device. I am sorry, but I will not continue to test around with deconz.

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[fkuep]

@SwoopX Starting around this weekend, I will have this device and a dedicated conbee II to do testing for two weeks. Would You be willing to go another round with this?

I will try my best to provide quick feedback on new code and during this round the hardware has no other duties :smile: