search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.89k stars 496 forks source link

Saswell SEA801-Zigbee TRV #3109

Closed rotragit closed 4 years ago

rotragit commented 4 years ago

SASWELL-SEA801-zigbee-wifi-Regolatore-di-Temperatura-del-Termostato-riscaldamento-programmabile-lavoro-con-tuya-gateway

Device

This is a TRV valve from Saswell. Joined deconz using Phoscon -> Sensors. Attached is the screenshot, no useful information seem to be present in other clusters.

Attached SEA801.zip with sniffing the operations when connected to a Tuya Zigbee Gateway. Room temperature was 28°C. Temperature in the filenames are without the comma (200 = 20.0°C, 165 = 16.5°C).

At the moment I have a Tuya Zigbee Gateway, but it's not mine. I was unable to find the Netwok key while sniffing. Could it be it's not encrypted?

SEA801-basic-cluster

SEA801.zip

rotragit commented 4 years ago

Low battery.

When the device has battery changed it start with a "test" and "reset". When it's ok to operate, among the others, there is this message:

04:29:13:500 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00046905000100 04:29:13:500 Tuya debug 5 : Status: 0 Transid: 4 Dp: 1385 Fn: 0 Data 0

If the device goes low battery, the device sends this message once:

04:30:45:472 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00046905000101 04:30:45:472 Tuya debug 5 : Status: 0 Transid: 4 Dp: 1385 Fn: 0 Data 1

and stop working (display off and low battery icon shown).

To reproduce: insert near to empty batteries in the device :-)

@vegetate7 have you the same message while the device is "bootstrapping"?

vegetate7 commented 4 years ago

@vegetate7 have you the same message while the device is "bootstrapping"?

Your idea with dead batteries is cool. Tested both my devices, and have same behavior, but with different DP:

Battery low:

14:54:27:263 Tuya debug 4 : Address 0xBC33ACFFFE6EBA40 Payload 00246e01000101
14:54:27:263 Tuya debug 5 : Status: 0 Transid: 36 Dp: 366 Fn: 0 Data 1
...
15:03:15:942 Tuya debug 4 : Address 0xEC1BBDFFFE94645A Payload 002d6e01000101
15:03:15:942 Tuya debug 5 : Status: 0 Transid: 45 Dp: 366 Fn: 0 Data 1

Battery ok:

15:11:49:141 Tuya debug 4 : Address 0xBC33ACFFFE6EBA40 Payload 00116e01000100
15:11:49:141 Tuya debug 5 : Status: 0 Transid: 17 Dp: 366 Fn: 0 Data 0
...
15:12:31:830 Tuya debug 4 : Address 0xEC1BBDFFFE94645A Payload 00156e01000100
15:12:31:830 Tuya debug 5 : Status: 0 Transid: 21 Dp: 366 Fn: 0 Data 0

Address 0xBC33ACFFFE6EBA40 is _TZE200_ckud7u2l / TS0601. Address 0xEC1BBDFFFE94645A is _TYST11_ckud7u2l / kud7u2l.

Smanar commented 4 years ago

Ha yes we miss the battery level. There is no info about that ?

Else we can use this dp with the field "state/lowbattery" (can be true or false) ?

On the site he is using dp = 533 : battery satus, and it s perhaps a battery level ?

rotragit commented 4 years ago

For me is a battery status (boolean). I've checked also with the Tuya Gateway app and there is no level indicator.

vegetate7 commented 4 years ago

Same for me. I've never seen DP 533 in logs. Actually I checked all logs i collected, and only DPs with unknown purposes were 366 and 1293. 1293 is one byte, always seen 0, still unknown. 366 as we can see now - is the battery status boolean.

Smanar commented 4 years ago

Ok so I have updated the code for battery, for both devices. You will have a new filed "state/lowbattery" that can be true or false.

And done some change on the json, for exemple the "preset" field will be removed on the GbxAXL2. So take care, you can have problem.

vegetate7 commented 4 years ago

not compiling, may be 'sensor' must be instead of 'sensorNode':

database.cpp: In function ‘int sqliteLoadAllSensorsCallback(void*, int, char**, char**)’:
database.cpp:3233:21: error: ‘sensorNode’ was not declared in this scope
                 if (sensorNode.modelId() == QLatin1String("kud7u2l") || // tuya 
                     ^~~~~~~~~~
database.cpp:3241:21: error: ‘sensorNode’ was not declared in this scope
                 if (sensorNode.modelId() == QLatin1String("kud7u2l") || // tuya 
                     ^~~~~~~~~~
Smanar commented 4 years ago

Right, corrected.

vegetate7 commented 4 years ago

Works for 'kud7u2l' and 'TS0601':

  "state": {
        "lastupdated": "none",
        "lowbattery": true,
        "on": true,
        "temperature": 2850,
        "valve": 70
    },
rotragit commented 4 years ago

Works for me also. But I don't understand why the status is "null" even if I reset the device (change batteries). The message is sent by the device. And the device is already in deconz, no need to pair again.

When the batteries are dead the status changes to "true". And if batteries are again "good" switch to "false".

And I don't see the status in HA, but that could be because the device was already in. I'll try to clean from HA and let it discover again the valve.

Smanar commented 4 years ago

The status is null, until the device send an information about it.

rotragit commented 4 years ago

The status is null, until the device send an information about it.

yes, but is missing the first message, when the device bootstrap. And the message is in the log.

I'll try to debug. But it's ok at the moment ^^

Smanar commented 4 years ago

Manup is validating PR, so I think it s the last days before the next version. Not sure I can make a modification for this version.

rotragit commented 4 years ago

no problem, this low battery status (true or false) will always be tricky because is sent only once ^^

Smanar commented 4 years ago

@rotragit I have made some change, but like you "lowbattery" not working, and seem "battery" not working too (an another tuya valve)

https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3110

rotragit commented 4 years ago

@Smanar yes, on one of my valves sometimes the bootstrapping message about lowbattery is caught, on the other never. If the battery is ok the lowbattery=false message is sent only once when you insert new batteries. If batteries are ok, no message will be sent until the batteries go empty. However, when the batteries go empty/dead, the lowbattery status start flapping. So, it would be great if the default value for the lowbattery status could be "false" instead of "null" at beginning for this kind of devices. But I'm not sure is possible nor it's correct.

Smanar commented 4 years ago

Right, I will do that.

vegetate7 commented 4 years ago

I do not think I write this in wrong issue, as all done in one code piece :) Can we ever have 'state' values persists on deConz restart? Those TRVs only reporting when value changes, so this can be long time:

        "state": {
            "lastupdated": "none",
            "lowbattery": null,
            "on": null,
            "temperature": null,
            "valve": null
        },

Yep, 'lowbattery' too. Is there way to save "state" value into DB once it changes?

Smanar commented 4 years ago

No, I don't think it s possible, on rejoin for exemple a Xiaomi device can be "unrecheable for 1 hour.

For lowbattery it's ok, I have already the change (idk on wich one version), it will be false at reboot.

vegetate7 commented 4 years ago

I am talking not about rejoining. Every time deConz restarted - ZHAthermostat nodes resets their 'state' values. I think somewhere need 'save to DB'? Other sensors saved:

sqlite> select sid,name,type,state,config from sensors where deletedState='normal' order by cast(sid as integer);
....
27|MotionSensor1|ZHAPresence|{"lastupdated":"2020-08-20T16:18:24.077","presence":true}|{"battery":100,"duration":90,"on":true,"reachable":true,"temperature":0}
28|lumi.relay.c2acn01|ZHAPower|{"current":0,"lastupdated":"2020-08-13T12:14:21.838","power":0,"voltage":227}|{"on":true,"reachable":true,"temperature":4100}
29|kud7u2l|ZHAThermostat|{"lastupdated":null,"lowbattery":null,"on":null,"temperature":null,"valve":null}|{"battery":null,"heatsetpoint":1550,"locked":null,"mode":"auto","offset":-100,"on":true,"preset":"manual","reachable":true,"schedule":null,"schedule_on":null,"windowopen_set":null}
30|TS0601|ZHAThermostat|{"lastupdated":null,"lowbattery":null,"on":null,"temperature":null,"valve":null}|{"heatsetpoint":1550,"locked":null,"mode":"auto","offset":-100,"on":true,"preset":"manual","reachable":true,"schedule":null,"schedule_on":null}

btw 'config' values saved in DB.

Smanar commented 4 years ago

For config it s normal, it s setting. But for state ...., for exemple it s useless to save a temperature or a presence detection, they can have changed at restart

And to have the real value, we need the device send it, so we are forced to wait.

rotragit commented 4 years ago

But for state ...., for exemple it s useless to save a temperature or a presence detection, they can have changed at restart

And to have the real value, we need the device send it, so we are forced to wait.

yes, but sometime is better to have the old value than nothing. For example for the batterylow status, but in general if the value is expected to change, it will change in a short time anyway. Viceversa if the value doesn't change for a long period of time, it could be better to have the old value.

But I'm not sure if this state consistency should be keep by the deconz plugin or by the end application (HA, domotiz, .....). With z2m I think it could be possible to publish the data to the mqtt server with the retain flag set to true, so this problem does not exist.

vegetate7 commented 4 years ago

Also there the 'lastupdated' value (which is actually not updated):

        "manufacturername": "_TYST11_ckud7u2l",
        "modelid": "kud7u2l",
        "name": "kud7u2l",
        "state": {
            "lastupdated": "none",
            "lowbattery": null,
            "on": null,
            "temperature": 2450,
            "valve": null
        },

It can help on decision how to interprete values, stalled or not. No doubt both choices are bad. But until we have a way to somehow 'poll' the device for the fill state, my vote for keeping old values.

But I'm not sure if this state consistency should be keep by the deconz plugin or by the end application (HA, domotiz, .....).

DeConz sending discovery info on start. So if some value 'null' in DB, it will be 'null' in HA regardless of HA saving old value.

Smanar commented 4 years ago

For battery low, it s already done, and it s strange you still have "lowbattery": null, on yours ...

Now imagine a presence detector, it detect a presence, and go out of order, if you restart deconz, it will trigger at start, even without detection.

Better to have "null" than a bad value, "null" don't trigger users script, bad values yes.

DeConz sending discovery info on start. So if some value 'null' in DB, it will be 'null' in HA regardless of HA saving old value.

I don't think, on domoticz I m changing values ONLY if deconz say me value is changing, and you haven't websocket notifications for "null" so I m sure it s same for HA.

oberschwabe commented 3 years ago

I was looking for a working HVAC and according to https://zigbee.blakadder.com the SasWell SEA801-DF1 is supported by DeCONZ. In GitHub the device is mentioned at https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3109 but it is not shown in the official Dresden-Electronic Supported devices at : https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Supported-Devices. When i went through all the forums and reading threads it seems several people managed to pair it with DeCONZ. Anyone able to give me a hint on what i am doing wrong? In Phoscon i start searching for new "Sensors", on the HVAC it shows the temperatur and the wifi symbol is blinking. I press "AUTO/MANU" and "+" for a few seconds until "----" is shown. After some time it jumps back and shows the temperature again but nothing is shown in Phoscon. I repeated several times but the device is not shown, searching for Lights or Switches is also not successfull. The distance from USB stick to device was less than 2m while testing. Found also youtube video which describes exactly what happens https://www.youtube.com/watch?v=sijmNDrUeV0 - the video shows the Tuya gateway but same result as with DeCONZ.

Smanar commented 3 years ago

I don't think the device is visible on phoscon. You need to use third app or take a look direclty in the api to see it.

You haven't the GUI to be sure (with checking in deconz) ?

rotragit commented 3 years ago

As far as I know, SEA801-DF1 is not a zigee TRV. It's 868Mhz Tuya protocol and works only with it's gateway (that is connected to the wifi). The zigbee version is the one on the title: SEA801-ZIGBEE written on the back of the TRV.

AndreaAPMS commented 3 years ago

Guys hi all, regarding this issue I've tried all your suggestion but always with same failure results. I can see the device in the Deconz GUI but no success with using api for example in nodered. In nodered I can only have all system linked with phoscon app. is there a way I can link the item with nodered or OpenHab binding?

vegetate7 commented 3 years ago

I'm sure I saw NodeRed module for interaction to Deconz REST API directly.

Smanar commented 3 years ago

@AndreaAPMS you can take a look direclty in the API to be sure. But if you haven't the device in the API but visible in deconz

If it s still not working can you show the basic attribute panel, filled with value.

AndreaAPMS commented 3 years ago

Ok very good I’ll try now...I’ll be more clear on it. I’ve found some differences between my and yours deconz.

Andrea Pesci Apms Mob +393356629469 www.apms.it

Sent from mobile

On 8 Nov 2020, at 11:50, Smanar notifications@github.com wrote:

 @AndreaAPMS you can take a look direclty in the API to be sure. But if you haven't the device in the API but visible in deconz

set phosocn in permit join (add new sensor) in deconz read again the basic attribute, cluster 0x0000 "basic", press the read button (need probably to awake the sensor). If it s still not working can you show the basic attribute panel, filled with value.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

AndreaAPMS commented 3 years ago

I even tested directly with rest api via curl

Andrea Pesci Apms Mob +393356629469 www.apms.it

Sent from mobile

On 8 Nov 2020, at 11:43, vegetate7 notifications@github.com wrote:

 I'm sure I saw NodeRed module for interaction to Deconz REST API directly.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

AndreaAPMS commented 3 years ago

I can’t have any value from basic. I’ll revert with pictures

Andrea Pesci Apms Mob +393356629469 www.apms.it

Sent from mobile

On 8 Nov 2020, at 11:50, Smanar notifications@github.com wrote:

 @AndreaAPMS you can take a look direclty in the API to be sure. But if you haven't the device in the API but visible in deconz

set phosocn in permit join (add new sensor) in deconz read again the basic attribute, cluster 0x0000 "basic", press the read button (need probably to awake the sensor). If it s still not working can you show the basic attribute panel, filled with value.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

AndreaAPMS commented 3 years ago

Here are my results after what you asked me:

firstzigbee

it seems that device is not recognised. I've deCONZ installed on raspberry 3 with latest Raspbian. working off course with guy even if I'd prefer the headless version. this is the answer from rest api.

{"1":{"config":{"configured":true,"on":true,"sunriseoffset":30,"sunsetoffset":-30},"etag":"811fb7e5e3f26223cf3b53212ae4cd60","manufacturername":"Philips","modelid":"PHDL00","name":"Daylight","state":{"dark":false,"daylight":true,"lastupdated":"2020-11-08T13:43:20.531","status":170,"sunrise":"2020-11-08T06:14:04","sunset":"2020-11-08T16:08:02"},"swversion":"1.0","type":"Daylight","uniqueid":"00:21:2e:ff:ff:06:15:9f-01"},"2":{"config":{"on":true,"reachable":true},"ep":1,"etag":"ae4274f477b545a5274e8292d5e7efc2","lastseen":"2020-11-08T13:49Z","manufacturername":"Tuya","modelid":"TS0121","name":"Consumption 2","state":{"consumption":0,"lastupdated":"2020-11-08T13:49:48.262"},"type":"ZHAConsumption","uniqueid":"ec:1b:bd:ff:fe:ac:54:85-01-0702"},"3":{"config":{"on":true,"reachable":true},"ep":1,"etag":"811fb7e5e3f26223cf3b53212ae4cd60","lastseen":"2020-11-08T13:49Z","manufacturername":"Tuya","modelid":"TS0121","name":"Power 3","state":{"current":0,"lastupdated":"2020-11-08T13:37:12.806","power":0,"voltage":0},"type":"ZHAPower","uniqueid":"ec:1b:bd:ff:fe:ac:54:85-01-0b04"}}

You can see that only sensors I can see are connected to the smart plug.

AndreaAPMS commented 3 years ago

when I press read Botton I can see "Zigbee icon" flashing on the device so it seems that connection is done correctly.

I've downloaded your Tuya branch compiled with QMAKE && make -j2 than copied to /usr/share/deCONZ/config/ the result of make file. It seems nothing different from previous version, I even tried downloading latest beta release with same results

AndreaAPMS commented 3 years ago

image this is correct

Smanar commented 3 years ago

Ok so it s normal, new model = 88teujp I still need 2 thing to add your device.

rotragit commented 3 years ago

@Smanar , from the z2m group we have:

119 - valve position

and 88teujp is SEA802-Zigbee.

zigbeeModel: ['88teujp', '88teujp\u0000'], fingerprint: [{ modelID: '88teujp\u0000', manufacturerName: '_TYST11_c88teujp' }], model: 'SEA802', vendor: 'Saswell'

(https://github.com/Koenkk/zigbee2mqtt/issues/2781#issuecomment-706557648)

AndreaAPMS commented 3 years ago

Good, now my problem is crash of po due to GUI use. Do you think is possible to use it headless. Off course when everything is fine and set up?

Sent from mobile

On 8 Nov 2020, at 16:44, Smanar notifications@github.com wrote:

 Ok so it s normal, new model = 88teujp I still need 2 thing to add your device.

The manufacture number on node info panel The manufacture name, it s just above the "model identifier", you can use deconz just to ask for this value (you probably need to wake up the device in same time). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Smanar commented 3 years ago

I m adding it in the deconz code, so yes you will be able to use it headless, but it s too late to have the manufacture code ?

BTW you have your phone number on issue.

Smanar commented 3 years ago

@AndreaAPMS I have take 0x0000 ATM the code is online.

AndreaAPMS commented 3 years ago

image

Thank you for the phone number !!!! I just answered the mail. It is Very very slow the process of reading this device, after startup it takes hours to get it on.

Smanar commented 3 years ago

Nope the Manufacture number is on Node info panel, and you have it for sure (without needing to wait), else the device would't be in deconz.

It's 0x0000 or 0x1002, 1/2 chance to have the good one.

AndreaAPMS commented 3 years ago

69 www.apms.it

Sent from mobile

On 8 Nov 2020, at 17:44, Smanar notifications@github.com wrote:

 Nope the Manufacture number is on Node info panel

It's 0x0000 or 0x1002, 1/2 chance to have the good one.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Smanar commented 3 years ago

69 ? here ?

image

rotragit commented 3 years ago

in z2m is set as 0x0000 (https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3109#issuecomment-723608443)

AndreaAPMS commented 3 years ago

I've tried to recompile plugin with bad result, system is crashing

Smanar commented 3 years ago

With one branch have you tried ? You can try the "tuya_pr", this one use the last deconz code, with some segmentation fault solved.

oberschwabe commented 3 years ago

seems i have no luck with any of the HVAC Devices - first the Eurotronic Spirit ZigBee #1098 where i received a new firmware and device support topic has been reopened and now the Tuya.

@rotragit : you are correct the SEA801-DF1 is not a Zigbee - Device - it was wrongly delivered. now i got the ZigBee version SEA801-Z01 and i managed to pair with deCONZ adapter. I was a little surprised it was detected as a light but it seems it is not detected correctly. an API query gives this: { "etag": "5038192ee1007d38dc8854c7222f01b0", "hascolor": false, "lastannounced": "2020-11-17T19:45:38Z", "lastseen": "2020-11-17T19:44Z", "manufacturername": "_TYST11_c88teujp", "modelid": "88teujp", "name": "On/Off light 24", "state": { "alert": "none", "on": false, "reachable": true }, "swversion": "20180727", "type": "On/Off light", "uniqueid": "60:a4:23:ff:fe:b2:76:9f-01" } saswell1 saswell2

i think the conbee / deconz firmware is up to date: Version : 2.05.88 / 15.10.2020 Firmware: 26660700

Any idea / suggestions?

Smanar commented 3 years ago

This is in deconz ATM, but not the version 88 ^^ But https://github.com/dresden-elektronik/deconz-rest-plugin/releases/tag/v2.6.0-beta And there is already a 2.6.1