Tuya Update.

[Smanar]

Ok so with lot of help from @vegetate7 some improvements, but not all are used yet.

• Add a TRV devices MOES Zigbee Radiator Actuator HY368 #3110
• Adding some option for TRV device, for exemple
  curl -H 'Content-Type: application/json' -X PUT -d '{"windowopen_set":[true,20,20]}' http://IP:PORT/api/KEY/sensors/21/config
  To set windows open mode (Valve/temperature/timer).
  Or low battery, but I don't find how to have 'false" as defaut value, I always have "null"
• Switch are finally working, but deconz will create always 3 entries even it s a double gang New device request - TS0601 / TZE200_nkjintbl #2879
• Starting to add covering, need to test set level, but a remote is needed so for the moment this part is disabled.

[Smanar]

Tuya device need manufacture name to be reconized, and it s not possible with API actual code so I m using 2 tips

• Try to retreive information from deconz (if the user have used the read attribute.
• Try to find information on the database, so the inclusion can faild the first time (I m not freezing the code), but succed on the second one.

Tuya covering are now working open/close/stop/lift and reverse as setting.

[Smanar]

And all is working, adding 2 tuya covering, a router and an end device.

[Abbadon89]

Any reason why is not included? Atm only way to use it is moving to z2mqtt ;/

[artkrz]

Am I correct that other PRs created after this one got merged? WTF? This is not cool at all :(

deCONZ is having a beta release at the 15th day of the month in which the beta of last month becomes stable. Pull requests done before the 10th of the month, are getting included in the next beta (if there are no issues ofcourse!). Stable release would be around the 1st - 5th of the month after latest beta.

Does this mean that this PR (created 15 days ago, way before 10th) will not get in to stable till November? Can someone explain?

[Smanar]

Yep, sorry, Dresden have no problem with the code but the version 81 is a stable version with lot of improvements, the tuya code is not a "light code" so it was too dangerous to put it in a stable version.
So you will have it at the latest, at the next public version (the 15 th october, a Beta) or earlier in an alpha version, but I don't think the alpha can be used on HA (only Pure Unix machine) if it s the third application you are using ?

[artkrz]

I'm using official Docker image with Conbee2, on HA side I'm using https://www.home-assistant.io/integrations/deconz. BTW, I think this info should be here as soon as it was clear that this PR will not be merged into next beta.

[andysaab]

Sad news :(
We`ve been waiting so long!

Smanar, why you talking about v81?

Now I`ve v82

[Smanar]

Because the 82 was out almost in same time than the 81 (less than 2 days)
I m a little lost in all those versions ^^.
The 81 is the last stable, idk yet for the 82, probably a beta, but still without tuya code.

I think the PR will be validated in same time, an alpha will be available to test it (or a beta).

[andysaab]

We have no way, will wait.

[gmitch64]

I pulled down your updated tuya branch, recompiled, and moved over the new lib.
This time I was able to log into Phoscon.

I deleted the old device, ran a rescan, and I'm seeing the motor come in on the VNC client, but nothing is showing in Postman. The model is a ZM25TQ according to the label on it.

G

[Smanar]

Ok so I have checked the code again, I have missed something, but you need to have a bulb device for it ATM.

It s a long story, but to make short tuya device need 2 inclusions, 1 to write on database usefull information, but the device can be bad reconized, and a second one where deconz read the previous data to make the correct inclusion.

If it still don't work with the actual code, can you make this test :

• set phosocn in permit join
• read again the device basic attribute, cluster 0x0000, button "read"

If it s still not working I need the manufacture number to force the detection, on the node info panel.

[gmitch64]

I've just updated my local code from your branch, and I'm compiling it again. Here's the info from the info panel, just in case.

G

[gmitch64]

Also noticed this error in the compilation - not sure if it's relevant/important, but just in case.

specs/linux-g++ -o release/green_power.o green_power.cpp
green_power.cpp: In function ‘GpKey_t GP_DecryptSecurityKey(quint32, const GpKey_t&)’:
green_power.cpp:20:39: warning: unused parameter ‘sourceID’ [-Wunused-parameter]
GpKey_t GP_DecryptSecurityKey(quint32 sourceID, const GpKey_t &securityKey)
^~~~~~~~
green_power.cpp:20:64: warning: unused parameter ‘securityKey’ [-Wunused-parameter]
GpKey_t GP_DecryptSecurityKey(quint32 sourceID, const GpKey_t &securityKey)
^~~~~~~~~~~

[gmitch64]

Also noticed this one..

tuya.cpp: In member function ‘bool DeRestPluginPrivate::SendTuyaRequestThermostatSetWeeklySchedule(TaskItem&, quint8, QString)’:
tuya.cpp:702:96: warning: unused parameter ‘weekdays’ [-Wunused-parameter]
eRestPluginPrivate::SendTuyaRequestThermostatSetWeeklySchedule(TaskItem &taskRef, quint8 weekdays , QString transitions )

G

[gmitch64]

OK, tried several times, and it's still not including properly.

Looking at #3161 @andysaab has the same motor as me, but it looks like his is/was being included as a light, where my one seems to be including as a smart plug.

He also seems to have a different manufacturer name and model Identifier

from my one

And mine is a ZM25TQ, as is his.
Is there any other info/testing I can do?

G

[Smanar]

There is a difference beetween your both device, his have the cluster 0x0006 and the tuya cluster is hidden, yours haven't the cluster 0x0006 but have the cluster tuya visible.

To create the "device" the code search for cluster 0x0006 (this is the native working mode) or tuya cluster (I think the problem is from here ^^).

The warning are not dangerous.

I have modified the code to force the device creation, even if the code don't see the tuya cluster (I think it s the problem).

Don't delete the node beetwen 2 inclusions.

If it s still not working I need the debug log during the inclusion ( 30s before up to 2 mn after)

deCONZ --dbg-error=2 --dbg-info=2

Edit:

where my one seems to be including as a smart plug.

You are seing the plug ? If yes it s a good new, it mean the code is working.

[gmitch64]

OK. It's still showing as a Smart Plug rather than a light. I'll do the inclusion again after breakfast with the debugging and update here. Just as a sanity check, here's the motor I'm using. So it looks the same as the one @andysaab has - at least from the outside.

[Smanar]

Yeah ! Exactly the same model ...

BTW, if the "plug" device is visible, do you have the device json ?

[gmitch64]

The plug is visible in the GUI via VNC, but Postman doesn't show anything sadly.

G

[gmitch64]

Now, I do have 3 of these motors (the other 2 are mounted and a pain to get to the pairing button). I paired the first one I got with either .84 or .85, and it DID pair - doesn't work via deConz though.

This is the JSON for the one that paired previously.

"17": {
"etag": "72a695e26aa120e91db786fe58f58d08",
"hascolor": false,
"lastannounced": null,
"lastseen": "2020-10-23T17:25Z",
"manufacturername": "_TYST11_wmcdj3aq",
"modelid": "mcdj3aq",
"name": "Green Screen",
"state": {
"alert": "none",
"bri": 0,
"lift": 0,
"on": false,
"open": false,
"reachable": false
},
"swversion": "20180727",
"type": "Window covering device",
"uniqueid": "bc:33:ac:ff:fe:68:0e:8d-01"
},

G

[gmitch64]

OK. Just did a git pull, and I see the code has been updated.

From https://github.com/Smanar/deconz-rest-plugin
   7db39a2..d90041f  tuya       -> origin/tuya
Updating 7db39a2..d90041f
Fast-forward
 database.cpp      |  8 +++++---
 de_web_plugin.cpp |  8 +++++---
 rest_sensors.cpp  | 23 ++++++++++++++++-------
 tuya.cpp          | 40 +++++++++++++++++++++++++++++++++++++++-
 4 files changed, 65 insertions(+), 14 deletions(-)

Copied the updated the lib file and rebooted.
Set the motor into inclusion mode (pressed the button 3 times)
Set Phoscon into inclusion mode for lights
It shows in the GUI as a Smart Plug, but nothing in Phoscon, and nothing from Postman either.
Put Phoscon back into inclusion mode for lights.
Sat at did a read on the Basic Cluster every few seconds for the 3 minute inclusion.

Still nothing showing in Phoscon or Postman.

Going to try and run the debug version now.

G

[gmitch64]

OK, I'm missing something....

/usr/bin/deCONZ --dbg-error=2 --dbg-info=2 --http-port=80

QCoreApplication::arguments: Please instantiate the QApplication object first
QXcbConnection: Could not connect to display
Aborted

[Smanar]

Try with
deCONZ -platform minimal --dbg-error=2 --dbg-info=2 --http-port=80

but it have worked with version 84 and 85, but not the last one ?

Edit:
Was not the same model
The working is "_TYST11_wmcdj3aq"
Thenot working is "_TZE200_wmcdj3aq"

[gmitch64]

I've just done that, and also added

StandardOutput=file:/home/pi/logs/deCONZ-output.log
StandardError=file:/home/pi/logs/deCONZ-error.log

into the service startup, but it didn't generate the log files. There's a whole load of data in syslog if that's of any use?
If so, is there a place I should upload it to? Or just zip it up and attach here?

G

[Smanar]

Both are working, It will depend of size I think

BTW, I have just edited my previous post

The working is "_TYST11_wmcdj3aq"
The not working is "_TZE200_wmcdj3aq"

[gmitch64]

That's correct on the working vs non working. However, both are ZM25TQ motors. I'm guessing there was some change in the logic of the inclusion, and it's not being detected incorrectly?

G

[Smanar]

Ok have find the problem, give me 10 mn

[Smanar]

Ok, no bad idea, I will check your log, because I realy don't see what is missing.

I think the working device have the cluster 0x0006, I know where the problem is from, but I don't understand why.

[gmitch64]

Here's the syslog.

I'll have another run one this posts.

G

[Smanar]

Ok, this time I have found.

It s an old code that I have removed, and was back because of a mistake in PR, to resume it blacklist the mac adress of this device

Smanar@7684d81

[gmitch64]

OK. Did the pull

From https://github.com/Smanar/deconz-rest-plugin
d90041f..116a6fb tuya -> origin/tuya
Updating d90041f..116a6fb
Fast-forward
database.cpp | 8 +++++-
de_web_plugin.cpp | 17 ++++++------
light_node.cpp | 2 ++
rest_sensors.cpp | 41 +++++++++++++++++++++++++--
tuya.cpp | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------
5 files changed, 140 insertions(+), 42 deletions(-)

And we get a compilation error.

rest_sensors.cpp: In member function ‘int DeRestPluginPrivate::changeSensorConfig(const ApiRequest&, ApiResponse&)’:
rest_sensors.cpp:1205:33: error: expected initializer before ‘modeSet’
QString modeSet = map[pi.key()].toString();
^~~~~~~
rest_sensors.cpp:1206:29: error: ‘modeSet’ was not declared in this scope
if (modeSet == "heat") { data = QByteArray("\x00", 1); }
^~~~~~~
Makefile.Release:1066: recipe for target 'release/rest_sensors.o' failed
make[1]: *** [release/rest_sensors.o] Error 1

[gmitch64]

OK. Removed rest_sensors.cpp from my local copy and did a git pull again. Clean compilation this time, not sure why I was getting an error last time.

The GUI still shows it as a Smart_Plug

Phoscon seems to think it's a thermostat

But the JSON looks respectable

"21": {
"etag": "3fa9464299e663f05e6eba5abc9b38e3",
"hascolor": false,
"lastannounced": null,
"lastseen": "2020-10-31T19:03Z",
"manufacturername": "_TZE200_wmcdj3aq",
"modelid": "TS0601",
"name": "Smart plug 21",
"state": {
"alert": "none",
"bri": 0,
"lift": 0,
"on": false,
"open": true,
"reachable": true
},
"swversion": null,
"type": "Window covering device",
"uniqueid": "bc:33:ac:ff:fe:45:7a:36-01"
},

[gmitch64]

I'm guessing the errors are because it still thinks it's a plug, rather than a light, even though the JSON looks correct?

curl -H 'Content-Type: application/json' -X PUT -d '{"lift": 50}' http://192.168.42.130:80/api/XXXXXXXXXX/lights/2/state
[{"error":{"address":"/lights/2/state","description":"parameter, lift, not available","type":6}},{"error":{"address":"/lights/2/state","description":"missing parameter to set light state","type":5}}]

curl -H 'Content-Type: application/json' -X PUT -d '{"bri": 50}' http://192.168.42.130:80/api/XXXXXXXXXX/lights/2/state
[{"error":{"address":"/lights/2/state","description":"parameter, bri, not available","type":6}},{"error":{"address":"/lights/2/state","description":"missing parameter to set light state","type":5}}]p

Now, the "on" command is accepted, but doesn't do anything on the motor.

curl -H 'Content-Type: application/json' -X PUT -d '{"on": true}' http://192.168.42.130:80/api/XXXXXXXXXX/lights/2/state
[{"success":{"/lights/2/state/on":true}}]

G

[Smanar]

Clean compilation this time, not sure why I was getting an error last time.

It s because I m on several device in same time, and use the github to transfert the code from a machine to another, the code have moved 10/15 time just today ^^, you have made a "git pull" just beetween a corrective.

For the plug type, it s something normal, look at the node title in deconz "Smart Plug" it s the real value, send by the device itself, I m using a hack for the type was "Window covering device" but for zigbee standard, this device is a plug.

But why a thermostat in phoscon ? Here, I realy don't have idea ...

And you have made a mistake with your commands, you are using the id = 2, and on the json the id = 21.

[gmitch64]

Dang, yup... 2 does not equal 21. SO, changing that to 21...

Open true turns the motor one way.
Open false turns the motor the other way.

Close, either true or false does nothing.

I can't find a way to stop the motor from turning - I presume once I set the limits it will stop, but there should be a command to stop it? The remote control does stop it, which is what I'm using at the moment.

Lift and Bri generate a success error message, but don't do anything with the motor. Is that expected?

G

[gmitch64]

As for Phoscon, I just use that for doing the inclusion, and making sure that the lights work.

In the DeConz GUI, it's still showing as a Smart Plug - is that how it should be? And not a light?

G

[Smanar]

In the DeConz GUI, it's still showing as a Smart Plug - is that how it should be? And not a light?

Yep, hack not possible in deconz ^^, deconz is a "zigbee management software" not a domotic app, so the zigbee rules need to be respected at maximum for me, that you see in deconz need to be the reality.

To stop the covering
curl -H 'Content-Type: application/json' -X PUT -d '{"stop": true}' http://IP:PORT/api/KEY/lights/ID/state
Not working ?

And yes, it depend of device, but generally they need a calibration step, to stop itself and to enable the "bri"/"lift" command.

But if you still have problem for calibration pls use a similar issue or create a new one, we have realy abused with PR usage ^^.

[gmitch64]

Yes, "stop": true does stop the motor. I should have tired that - I was expecting to see something in the state area for that; my bad.

Once I get my screen hung, I'll get the limits set, and see if the bri/lift start working at that point. If not, then I'll open a new issue, as you are correct, we (I), have probably abused this PR.

One last question, will these updates hit 5.87 at the start of November, or will they need to wait till the beta of 5.88 in the middle of the month?

G

[Smanar]

Lol, not possible to be sure

Next Beta: 2.05.88 expected at the 15th of November.
Next Stable: 2.05.87 expected at 8th November.

if the code is to much sensible for a stable, they can decide to validate then only for the beta.