Closed JocWal closed 1 year ago
May try this DDF. Not 100% sure about the tuya DP ...
{
"schema": "devcap1.schema.json",
"manufacturername": "_TZE200_myd45weu",
"modelid": "TS0601",
"vendor": "TS0601",
"product": "Tuya Soil Sensor",
"sleeper": true,
"status": "Silver",
"subdevices": [{
"type": "$TYPE_TEMPERATURE_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0402"
],
"items": [{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion",
"parse": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0x0001",
"script": "tuya_swversion.js"
},
"read": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0x0001"
}
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/battery",
"read": {
"fn": "none"
},
"parse": {
"dpid": 5,
"eval": "Item.val = Attr.val;",
"fn": "tuya"
},
"default": 0
},
{
"name": "config/offset"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/lastupdated"
},
{
"name": "state/temperature",
"read": {
"fn": "none"
},
"parse": {
"dpid": 1,
"eval": "Item.val = Attr.val;",
"fn": "tuya"
},
"default": 0,
"awake": true
}
]
},
{
"type": "$TYPE_HUMIDITY_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0405"
],
"items": [{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion",
"parse": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0x0001",
"script": "tuya_swversion.js"
},
"read": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0x0001"
}
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/battery",
"read": {
"fn": "none"
},
"parse": {
"dpid": 5,
"eval": "Item.val = Attr.val;",
"fn": "tuya"
},
"default": 0
},
{
"name": "config/offset"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/humidity",
"read": {
"fn": "none"
},
"parse": {
"dpid": 4,
"eval": "Item.val = Attr.val;",
"fn": "tuya"
},
"default": 0,
"awake": true
},
{
"name": "state/lastupdated"
}
]
}
]
}
If that doesn,t work will try with other dpid, or from this DDF
Hi there, Thanks for your help! in general I got it to work. I had to change the dpid's though. I tried the id's from the post you pointed to and the moisture and temp id's seem to be the correct ones: [dpid: 3, 'soil_moisture'] - had to scale the raw value since putting it into tap water showed 70% moisture -> "eval": "Item.val = Attr.val * 142.857;" [dpid: 5, 'soil temperature'] - also scaled by 100 to get the value in °C.
However I was not able the get battery level readout so far. I tried dpid 15 from the same post (see below), but it didn't work.
[9, 'temperature_unit', tuya.valueConverter.temperatureUnit], [14, 'battery_state', tuya.valueConverter.batteryState], [15, 'battery', tuya.valueConverter.raw],
Well, then you have : Battery - dpid 5 or 15 -» not working Humidity - dpid 3 -» Working after 142.857 ?! Usually this number has to be adjusted by multiples of 10, not with a so strange value Temperature - dpid 5 --» Working after 100
That's it ?
Have you tried dpid 4 for battery ? But still surprised because it really seems that it's dpip 15 https://github.com/Koenkk/zigbee-herdsman-converters/blob/bcdb6b3c593cac61741cbe9f5254606de73f67f7/devices/tuya.js#L1268
[15, 'battery', tuya.valueConverter.raw],
Harf, I have see it recently, it seem deconz can't handle raw value, but need to make c++ code edition to correct that. It can explain why I have ths issue on TRV too.
I think you can see log for other dpid but nothing for this one ? (visible with "info")
21:44:58:635 TY_DATA_REPORT: seq 66, dpid: 0x69, type: 0x02, length: 4, val: 5003
But if it's that soil mùosture will not work too, perhaps it's just a Z2M convertion.
[3, 'soil_moisture', tuya.valueConverter.raw],
Can you get logs when the device make this report ?
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.
Well, then you have : Battery - dpid 5 or 15 -» not working Humidity - dpid 3 -» Working after 142.857 ?! Usually this number has to be adjusted by multiples of 10, not with a so strange value Temperature - dpid 5 --» Working after 100
That's it ?
Have you tried dpid 4 for battery ? But still surprised because it really seems that it's dpip 15 https://github.com/Koenkk/zigbee-herdsman-converters/blob/bcdb6b3c593cac61741cbe9f5254606de73f67f7/devices/tuya.js#L1268
I tried both 4 and 15 for the battery - neither worked unfortunately.
There's another issue I found with humidity. The raw value seems to change resolution blow 1% resulting in an jump in the value reported by phoscon.
He ? You mean you have 50% then sudently 1% more ? I don't see unity on your graph but it seem more important ?
And this problem can be from the device itself, we don't make convertion for humidity.
Edit:
BTW it's not humidity, this device don't have it, but soil moisture, and from Z2M it's with the dp 3, not 4, it can explain the strange * 142.857
BTW it's not humidity, this device don't have it, but soil moisture, and from Z2M it's with the dp 3, not 4, it can explain the strange
But we don,t have a State/soil_moisture attribute then that's why we use state/humidity (that's only a semantic difference BTW ;-))
And you're right, it seesm that I made a mistake when proposing the DDF. The dp is 3, not 4. and seems that @JocWal already changed it earlier. He could perhaps confirm.
And we can't use the "state/moisture" ? I can see this one in the official code ATM.
Good news, as I didn't see it in the generic item list, nor in any DDF, I thought that it didn't exist
It's something recent. And effectively the json is still missing, something like
{
"schema": "resourceitem1.schema.json",
"id": "state/moisture",
"datatype": "UInt16",
"access": "R",
"public": true,
"description": "The current relative moisture in percent.",
"parse": {
"at": "0x0000",
"cl": "0x0408",
"ep": 0,
"eval": "Item.val = Attr.val",
"fn": "zcl"
},
"default": 0
}
Thanks for the DDF. I have a soil sensor which optically is exactly the same, just the model name is different - mine is called GXM-01. I have tried out the DDF with dpid 3 for moisture 5 for temperature 15 for battery and I can confirm it works.
My only question is: Can anyone explain the strange moisture * 142.857 multiplication? Why is it exactly that value?
My only question is: Can anyone explain the strange moisture * 142.857 multiplication? Why is it exactly that value?
Lol, Yes, I think there is a problem here too. And other project I can't see this convertion.
What is your manufacture name ? (To add it in the PR, or if you want to make it ? )
And if you can share the final DDF with all changes.
See my DDF enlosed as txt file. The manufacturer name is GIEX-Smart (as per packaging)/ GI-EXperience as per AliExpress
After my first tests, I get a 100% in tab water and 55-60% in well watered soil and 0% in the air - so doesn't look too bad; just the multiplication factor doesn't seem to be as usual and I was wondering what was the thinking process to get to this value.
Thx, fine, your model is the same, "_TZE200_myd45weu" But on your DDF you are not using state/moisture too ? Do you want I make a PR with your DDF and all files needed for the moisture one (you will need 2/3 more json file) ?
I think it's better to create a new sensor, a ZHAMoisture
Thanks for the DDF. I have a soil sensor which optically is exactly the same, just the model name is different - mine is called GXM-01. I have tried out the DDF with dpid 3 for moisture 5 for temperature 15 for battery and I can confirm it works.
My only question is: Can anyone explain the strange moisture * 142.857 multiplication? Why is it exactly that value?
I think that this value was just calculated assuming that tap water is 100% relative humidity in the air compared to mesured value by device. Then 2 choices, mesured value is not humidity, or water is not 100% relative humidity in the air … I guess that it’s the second option because relative humidity is a combination of pressure/temp in the air.
anyway @smanar is right, better to use moisture and adjust this one.
From Z2M the value is a percent, we can just check if the value never go under 100. But IDK if you can see it without new json file ?
I think it's better to create a new sensor, a ZHAMoisture
Like the idea ;-)
For me it's a good thing because this sensor already exist in code, so better to use it. Just need to know if @psfpwsfngolwle want to make the PR or not ?
Need to add the ZHAMoisture in the DDF, and a state/moisture json in the "generic" folder.
Thanks for your responses. Sorry, I am quite new to this - what does PR stand for?
Some further insights on comparing the values from DPID 3 on this soil sensor with the ones from a another old model I have (not using Zigbee). I have placed both of them outside next to each other. While the old one shows continiously in-/decresing values - and it outlines that is has rained during the period with values going to 70+, the Zigbee model jumps quite back and forth and in fact it stays at 60 since Mar 25 1:30 am. You can see that by opening both attached screenshots next to each other.
So I am wondering if this soil sensor is really a reliable option respectivel,y are we using the right DPID for reading the moisture?
Do you have similar observations? Are your values (100, 61.43, 60, ...) the same?
As suggested by @Smanar, I think it,s better to have DDF with correct attributes. Then we could discuss about values or reliability later ;-)
Could you try with this DDF ?
{
"schema": "devcap1.schema.json",
"manufacturername": "_TZE200_myd45weu",
"modelid": "TS0601",
"product": "Tuya Soil Sensor",
"sleeper": true,
"status": "Gold",
"subdevices": [{
"type": "$TYPE_TEMPERATURE_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0402"
],
"items": [{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion",
"parse": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0x0001",
"script": "tuya_swversion.js"
},
"read": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0x0001"
}
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/battery",
"read": {
"fn": "none"
},
"parse": {
"dpid": 15,
"eval": "Item.val = Attr.val;",
"fn": "tuya"
},
"default": 0
},
{
"name": "config/offset"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/lastupdated"
},
{
"name": "state/temperature",
"read": {
"fn": "none"
},
"parse": {
"dpid": 5,
"eval": "Item.val = Attr.val * 100;",
"fn": "tuya"
},
"default": 0,
"awake": true
}
]
},
{
"type": "ZHAMoisture",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0408"
],
"items": [{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion",
"parse": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0x0001",
"script": "tuya_swversion.js"
},
"read": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0x0001"
}
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/battery",
"read": {
"fn": "none"
},
"parse": {
"dpid": 15,
"eval": "Item.val = Attr.val;",
"fn": "tuya"
},
"default": 0
},
{
"name": "config/offset"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/moisture",
"read": {
"fn": "none"
},
"parse": {
"dpid": 3,
"eval": "Item.val = Attr.val * 100;",
"fn": "tuya"
},
"default": 0,
"awake": true
},
{
"name": "state/lastupdated"
}
]
}
]
}
As I changed sensor UUID for ZHAMoisture, better to to delete the device and add it again.
Need to add the ZHAMoisture in the DDF, and a state/moisture json in the "generic" folder.
And a new constant in constants.json and a subdevice like generic/subdevices/moisture_sensor.json ? ;-)
Have you tried dpid 4 for battery ? But still surprised because it really seems that it's dpip 15 https://github.com/Koenkk/zigbee-herdsman-converters/blob/bcdb6b3c593cac61741cbe9f5254606de73f67f7/devices/tuya.js#L1268
@Smanar, I saw that they also send the TuyaMagicPacket on this device, could this have an impact to the way the device reports datas ? You have more experience than me on this behavior ;-)
could this have an impact to the way the device reports datas ?
Yes, it's exacty the problem, without the unlock sequence device simply don't send report. Or you can have working mode issue, like a device with 3 outputs that can't work independantely. But I don't understand his result, with the moving value. I will check on other project.
And a new constant in constants.json and a subdevice like generic/subdevices/moisture_sensor.json ? ;-)
Need to add a file called "state_moisture_item.json" in "devices\generic\items" with
{
"schema": "resourceitem1.schema.json",
"id": "state/moisture",
"datatype": "UInt16",
"access": "R",
"public": true,
"description": "The current relative moisture in percent.",
"parse": {
"at": "0x0000",
"cl": "0x0408",
"ep": 0,
"eval": "Item.val = Attr.val",
"fn": "zcl"
},
"default": 0
}
Edit: Ha yes, I thought the tuya unlock sequence was already in the DDF, can make a try with it, yes.
{
"schema": "devcap1.schema.json",
"manufacturername": "_TZE200_myd45weu",
"modelid": "TS0601",
"product": "Tuya Soil Sensor",
"sleeper": true,
"status": "Gold",
"subdevices": [
{
"type": "$TYPE_TEMPERATURE_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0402"
],
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "config/configured",
"refresh.interval": 86400,
"read": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": [
"0x0004",
"0x0000",
"0x0001",
"0x0005",
"0x0007",
"0xfffe"
]
},
"parse": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0xfffe",
"eval": "Item.val = (Attr.val != 0)"
},
"public": false,
"default": false
},
{
"name": "attr/swversion",
"parse": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0x0001",
"script": "tuya_swversion.js"
},
"read": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0x0001"
}
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/battery",
"read": {
"fn": "none"
},
"parse": {
"dpid": 15,
"eval": "Item.val = Attr.val;",
"fn": "tuya"
},
"default": 0
},
{
"name": "config/offset"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/lastupdated"
},
{
"name": "state/temperature",
"read": {
"fn": "none"
},
"parse": {
"dpid": 5,
"eval": "Item.val = Attr.val * 100;",
"fn": "tuya"
},
"default": 0,
"awake": true
}
]
},
{
"type": "ZHAMoisture",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0408"
],
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion",
"parse": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0x0001",
"script": "tuya_swversion.js"
},
"read": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0x0001"
}
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/battery",
"read": {
"fn": "none"
},
"parse": {
"dpid": 15,
"eval": "Item.val = Attr.val;",
"fn": "tuya"
},
"default": 0
},
{
"name": "config/offset"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/moisture",
"read": {
"fn": "none"
},
"parse": {
"dpid": 3,
"eval": "Item.val = Attr.val * 100;",
"fn": "tuya"
},
"default": 0,
"awake": true
},
{
"name": "state/lastupdated"
}
]
}
]
}
I have used the definitions from the previous post, 1) put the files into the respective folders 2) restarted deconz 3) deleted the pair sensors (humidity/ temperature) 4) Paired the soil sensor again.
The result is that I get a temperature and a moisture sensor and the temperature sensor seems to provide the right values. On the moisture sensor, I also get the values for battery, reachable, ... but the most important - the value for "moisture" is completely missing now. Any thoughts?
Do you have some error in log (with INFO, DDF and APS checked) for that device ?
May be also suppress the * 100
in the eval
part ofstate/moisture
Yep if you can take a look in logs ? But its like a problem with the "state_moisture_item.json" file, but I don't see what I m doing wrong, what is your deconz version ?
Hello, if I can be of any help. I tried also the latest 2 files and I get the below results, the moisture is not working. Deconz version: 2.21.0 For Temperature sensor: { "config": { "battery": 100, "offset": 0, "on": true, "reachable": true }, "etag": "ea11fdc3a6f1b917aca09b0950ca45be", "lastannounced": null, "lastseen": "2023-03-29T14:21Z", "manufacturername": "_TZE200_myd45weu", "modelid": "TS0601", "name": "Temperature 20", "state": { "lastupdated": "2023-03-29T13:53:15.938", "temperature": 2500 }, "type": "ZHATemperature", "uniqueid": "a4:c1:38:af:22:d1:cc:76-01-0402" } For Moisture sensor: { "config": { "battery": 100, "offset": 0, "on": true, "reachable": true }, "etag": "86a1a5f226eb6b2ec46344de73b3afde", "lastannounced": null, "lastseen": "2023-03-29T14:30Z", "manufacturername": "_TZE200_myd45weu", "modelid": "TS0601", "name": "Moisture 21", "state": { "lastupdated": "2023-03-29T13:53:16.128", "moisture": 0 }, "type": "ZHAMoisture", "uniqueid": "a4:c1:38:af:22:d1:cc:76-01-0408" }
These json reprots seems well formed, compliant with the DDF.
I assume that you you put the state_moisture_item.json
as described by @Smanar (https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6731#issuecomment-1487117055) in the right folder and that have you deleted * 100
in the eval
part of state/moisture
in the DDF.
Then can you get some log (debug view) ?
Need to add a file called "state_moisture_item.json" in "devices\generic\items" with
BTW, what is your OS ? it the system "devices" folder not the "user" one (/usr/share/deCONZ/devices/generic/items on normal OS), so not possible on docker OS (or relay hard)
Hope that the debug log is usable. Raspberry Pi 4, Deconz 2.21.0, the 2 files are installed in /home/pi/.local/share/dresden-elektronik/deCONZ/devices: under ./tuya for TS0601_Tuya_Soil_Sensor.json (the * 100 was deleted) under ./generic/items for state_moisture_item.json
Actually on Deconz-GUI I do not see the moisture
and now without the *100 we have (real value must be around 6%):
For Moisture sensor: { "config": { "battery": 100, "offset": 0, "on": true, "reachable": true }, "etag": "774dbe12d5cba15f8182b00792730072", "lastannounced": null, "lastseen": "2023-03-29T18:41Z", "manufacturername": "_TZE200_myd45weu", "modelid": "TS0601", "name": "Moisture 21", "state": { "lastupdated": "2023-03-29T18:40:10.061", "moisture": 1 }, "type": "ZHAMoisture", "uniqueid": "a4:c1:38:af:22:d1:cc:76-01-0408" }
Actually on Deconz-GUI I do not see the moisture
You won't see in it DecONZ-GUI (it's "masked" under Tuya Cluster) , only thru REST-API in Phoscon or third-party software.
Hope that the debug log is usable.
We can see reporting about battery in the log for both sensors :
19:24:21:017 a4:c1:38:af:22:d1:cc:76-01-0402/config/battery expression: Item.val = Attr.val; --> 100
19:24:21:018 TY_DATA_REPORT: seq 230, dpid: 0x0F, type: 0x02, length: 4, val: 100
19:24:21:018 TY_DATA_REPORT: seq 230, dpid: 0x0F, type: 0x02, length: 4, val: 100
19:24:21:019 a4:c1:38:af:22:d1:cc:76-01-0408/config/battery expression: Item.val = Attr.val; --> 100
19:24:21:020 TY_DATA_REPORT: seq 230, dpid: 0x0F, type: 0x02, length: 4, val: 100
19:24:21:021 TY_DATA_REPORT: seq 230, dpid: 0x0F, type: 0x02, length: 4, val: 100
But I couldn't locate values for temp or moisture in the log. But now that you have a value that's great ! Do you know what is the theoric precision for the moisture mesure of this device ? We just have to fnd the "good" value and multiplier
We can also see report of dpid 14 that we don't use at this time. Seems a kind of battery state.
19:24:21:185 APS-DATA.indication srcAddr: 0x1e87, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0xEF00, lqi: 255, rssi: -64
19:24:21:186 TY_DATA_REPORT: seq 231, dpid: 0x0E, type: 0x04, length: 1, val: 2
19:24:21:187 TY_DATA_REPORT: seq 231, dpid: 0x0E, type: 0x04, length: 1, val: 2
19:24:21:187 TY_DATA_REPORT: seq 231, dpid: 0x0E, type: 0x04, length: 1, val: 2
19:24:21:187 TY_DATA_REPORT: seq 231, dpid: 0x0E, type: 0x04, length: 1, val: 2
After some search, it seems that humidity accuracy for this device is fluctuant : 0~50%(±3%),50%~100%(±5%).
Then without calibration it's difficult to say what 1
you got for moisture means, Is it 10% or 1% ? If your reference is around 6% like you wrote, then, with the expected precision I suggest it's 10% ... but we need other measure ...
This can be of any help:
https://smarthomescene.com/reviews/tuya-zigbee-plant-soil-sensor-gxm-01-review/
Not really … I already got the information I need about this device and already looking at other projects to complete those that are not in reviews or seller ads. Because there is no calibration for moisture it’s difficult to be sure that the returned value is accurate or not … that’s why we just need some empiric tests just to see if the value is in a « correct » range or if we need to multiply it. Can you just add some water in you test soil just to catch the variation ?
Hope that the debug log is usable. Raspberry Pi 4, Deconz 2.21.0, the 2 files are installed in /home/pi/.local/share/dresden-elektronik/deCONZ/devices: under ./tuya for TS0601_Tuya_Soil_Sensor.json (the * 100 was deleted) under ./generic/items for state_moisture_item.json
So strange it finaly work, perhaps this json is useless if the item is already in the c++ code .... It's the good place for user DDF, but can't work for the "state_moistureitem.json", this one need to be in the deconz folder, you need to see other ones "state........json" insode.
We can also see report of dpid 14 that we don't use at this time. Seems a kind of battery state.
Yes, exactly.
Hi! I have the same sensor. Can you wrap up quickly what I should do to enable it properly? So war I have just "humidity" enabled, but want to go the moisture path... Thanks, Thomas
Hi! I have the same sensor. Can you wrap up quickly what I should do to enable it properly? So war I have just "humidity" enabled, but want to go the moisture path... Thanks, Thomas
May just take a reading from that point ;-) https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6731#issuecomment-1487117055
So strange it finaly work, perhaps this json is useless if the item is already in the c++ code .... It's the good place for user DDF, but can't work for the "state_moistureitem.json", this one need to be in the deconz folder, > you need to see other ones "state........json" insode.
@Smanar when I put the 2 files in the deconz folder, they are deleted at each reboot, so useless for me. If you have a way to keep the state_moisture_item.json your help would be appreciated.
that’s why we just need some empiric tests just to see if the value is in a « correct » range or if we need to multiply it. Can > you just add some water in you test soil just to catch the variation ?
@BabaIsYou, let me few days and I will send you some samples. First look, it seems that we might not need any correction.
@smanar, I assume state/moisture
is normalised to report the percentage of water in the soil in units of 0.01%, as per the ZCL definition of Measured Value in cluster 0x0408, and consistent with state/humidity
for 0x0405? So values would be between 0 and 10000?
As @ebaauw says maybe we have to multiply the value with 10000 instead of taking out the 100, since 3 hours I am testing the moisture and I have quit similar results between 2 devices. As of now my reference shows 26% and as you see the ZHAMoisture shows 28 it might be 280000. @BabaIsYou & @Smanar what do you think?
{ "config": { "battery": 100, "offset": 0, "on": true, "reachable": true }, "etag": "50ddafa324c1ce6fd274f8d7bf2e6c25", "lastannounced": null, "lastseen": "2023-03-30T21:09Z", "manufacturername": "_TZE200_myd45weu", "modelid": "TS0601", "name": "Moisture 21", "state": { "lastupdated": "2023-03-30T21:01:21.331", "moisture": 28 }, "type": "ZHAMoisture", "uniqueid": "a4:c1:38:af:22:d1:cc:76-01-0408" }
By 100, so 28% is reported as 2800.
@ebaauw , actually as you see the REST API reports 28, but I have no idea if this value must be 2800 or 280000 as you say. Because in the DDF actually we have: { "name": "state/moisture", "read": { "fn": "none" }, "parse": { "dpid": 3, "eval": "Item.val = Attr.val ;", "fn": "tuya" }, "default": 0, "awake": true }
I have tried several approaches now all with the same result. The moisture sensor gets created but without a value for moisture - as mentioned before. I figure out that the "humidity" sensor which was initially created after pairing it with the first DDF where I used humidity gets recreated after I reboot deconz even though I had deleted it via the API before. That might be a reason for the weird behaviour on my side but I am also not clear what I else I can do. If you have any experience with that, please let me know.
As @BEskandari seems to have right value I think that DDF is correct. May be we can multiply it by 100 get compliant with other devices.
For situation of @psfpwsfngolwle, it looks like symptoms of a fantom -FF endpoint. Please @psfpwsfngolwle could you get once more json of your sensors about this device ? Just to be sure about your situation ?
Hi everyone,
I think if you put the generic/items/state_moisture_item.json
in the persistent /mnt/data/supervisor/addons/data/core_deconz/.local/share/dresden-elektronik/deCONZ/devices
folder it actually loads. It seems to do for me anyway.
I get the following from the REST-API:
lastannounced | "2023-03-30T15:21:08Z"
lastseen | "2023-03-31T06:55Z"
manufacturername | "_TZE200_myd45weu"
modelid | "TS0601"
name | "Moisture 60"
state |
lastupdated | "2023-03-31T06:37:05.169"
moisture | 3800
type | "ZHAMoisture"
so that seems to be in working order, right?
EDIT: So it becomes /mnt/data/supervisor/addons/data/core_deconz/.local/share/dresden-elektr onik/deCONZ/devices/generic/items/state_moisture_item.json
Yes it seems good 👍
So if values go from 0 to 10000, it's fine for me too. Someone want to make a PR with the DDF and the item json ?
So if values go from 0 to 10000, it's fine for me too. Someone want to make a PR with the DDF and the item json ?
And adding new constant in constants.json and a subdevice like generic/subdevices/moisture_sensor.json to be complete ? ;-)
An update from my side: I finally got it to work and the API requests do show me proper values now. In order to have it in my home automation solution I also had to adapt/ enhance the logic to create Zigbee devices as "moisture" is not known there at this point. I would definitely recommend to keep the * 100 multiplication as this would give more consistency overall - to my knowledge, e.g. temperature and humidity are also having a 0-10000 range in the API and therefore it would make sense to do it the same way for moisture.
HI! I followed the seps above and was able to get it running. Many thanks! I deleted the *100, as I like to have it at a percentage scale between 0-100. Works good for me. Thomas
Device
Screenshots
Node Info Panel
Basic
Groups
Scenes
OTAU
Tuya specific