Tuya QT-07s (myd45qeu) soil humidity en temp sensor always reports 0% humidity

Advice
1

Hi all,

A week ago I bought myself the (as seen known by now) QT-07S soil temperature and moisture sensor and tried to connect it to my deconz insance, and there it started.
I had to upgrade deconz and at the moment I’m running Version 2.21.02 with firmware 26780700 on my ConbeeII stick.
I have been using this stick for 2+ years now, always running smooth with sonoff/Ikea and some other tuya temp/hum (air) devices without any issues.

After upgrading Deconz I also found a DDF file, which I managed to upload to my headless rapberry instance, and it uses that custom DDF now. This gives me the temp and hum sensor in Domoticz (via Deconz), though there the issue starts:

The temperature is updating, though the humidity (which is quite low at 0) also says at zero and when I look into the lastupdated date, it stays at the moment I added the sensor to deconz, that date just doesn’t change, although the temps date changes (as the value does).

I also made myself a debug.txt log, but (with my knowledge) I don’t see something that might explain the behaviour. Actually, it just looks like the sensor itself just doesn’t send (valid?) numbers, hence the 0.

I hope you might be able to shine some light on this matter.

Thanks!

2

Hello can you give the device model manufacture name ?
Where are you seing the moisture value ? Can try with phoscon / help / API Information / sensor

3

Hi Smanar,

I’m using alle sensors within Domoticz (via de deconz plugin voor domoticz) and I assumed it must have been the myd45weu type, as as soon as I added the DDF Json it started working (getting recognised) after a restart.

When I a get sensors as a REST call I get these two results back for the temp en soil:

“13”: {
“config”: {
“battery”: 100,
“offset”: 0,
“on”: true,
“reachable”: true
},
“etag”: “3b3f8396b2becaecfe9b242f969935d8”,
“lastannounced”: “2023-06-25T10:17:43Z”,
“lastseen”: “2023-06-26T06:03Z”,
“manufacturername”: “_TZE200_myd45weu”,
“modelid”: “TS0601”,
“name”: “Bodemtemp”,
“state”: {
“lastupdated”: “2023-06-26T06:03:32.067”,
“temperature”: 2000
},
“type”: “ZHATemperature”,
“uniqueid”: “a4:c1:38:58:c4:64:32:ad-01-0402”
},
“14”: {
“config”: {
“battery”: 100,
“offset”: 0,
“on”: true,
“reachable”: true
},
“etag”: “3b3f8396b2becaecfe9b242f969935d8”,
“lastannounced”: “2023-06-25T10:17:43Z”,
“lastseen”: “2023-06-26T06:03Z”,
“manufacturername”: “_TZE200_myd45weu”,
“modelid”: “TS0601”,
“name”: “Bodemhum”,
“state”: {
“humidity”: 0,
“lastupdated”: “2023-06-22T12:56:57.718”
},
“type”: “ZHAHumidity”,
“uniqueid”: “a4:c1:38:58:c4:64:32:ad-01-0405”
}

As I’m running deconz in headless mode on a raspbian os without graphical support, I can run deconz GUI, so I have to do it with API calls, or log dumps.

As you can see, although the temp is updated, the lastupdated value of the soil(humidity) stays at the 22nd of june.

4

You are probabling using an old DDF, you have a ZHATemperature + ZHAHumidity and on the last DDF (the native one, no need to make a DDF yourself) you need to have a ZHATemperature + ZHAMoisture

So better to delete first the entry in the database using phoscon (delete the device), check your DDF (to be sure you have the last version), you don’t need custom one, just the official one, them re-include it.

Edit:
I have forget this device in the domoticz plugin, I m adding it ATM, you will have it in beta branch maximum tommorow.

Edit2:
There is a Soil moisture widget on domoticz, so have used this one, the code modification is on the beta branch, not tested, but it run.

        # Val is a value 0 to 100, need to be converted in 0 to 200
        #00 - 09 = saturated
        #10 - 19 = adequately wet
        #20 - 59 = irrigation advice
        #60 - 99 = irrigation
        #100-200 = Dangerously dry

I m using a basic convertion ( 100 - V) *2 , tell me if value need adjustement.

5

Hi Smanar,

Thanks so far, I will have a look into this.
The only thing is, I cannot delete the device from the phoscon interface, as it doesn’t show up in the Phoscon interface as a sensor after adding it. Deleting it using domoticz (and I assume via REST as well then) just brings it back after a restart, so that doesn’t delete it from the DB as well.
As soon as I’m able to, I’ll see what this does for me.

Peter

6

Update: Just updated Domoticz-Deconz to beta (using 1.0.29 at the moment).
Removed the custom DDF and using deconz own version now (the correct one), though haven’t been able to remove the device via Phoscon WebUI yet, so (also after restarts) it still is using the “old” ZHAHumidity sensor type (hence not working).
So, until Phoscon knows how to display the sensor I assume I’m stuck for now.

7

as it doesn’t show up in the Phoscon interface as a sensor after adding it

Not normal, the temperature sensor is supported, so you need to see at least this one ? Or there is a white list for temperature sensor on Phoscon ?

Deleting it using domoticz (and I assume via REST as well then) just brings it back after a restart

So the device is deleted, you are not seing it in domoticz/custom/deconz/sensor, but he is come back at restart ? You are deleting it on the custom page ? not on the devices one ?

I presume you haven’t access to the GUI ?

If you don’t restart, the device is deleted ? I haven’t asked, you don’t use virtual OS ?

8

Smanar,

To give some extra details:
I’m using Raspbian on a raspberry Pi, and as said, Domoticz with your Domoticz-Deconz plugin.
Normally I always add new devices to the zigbee network using the “pwa” phoscon WebGUI, as I’m running a lite (nog graphical) version of Raspbian on this Pi (this is my dedicated Domoticz/P1/Zigbee pi)

When I started with this device (the soilsensor) I tried to add it as a sensor using phoscon, though it just wasn’t recognized at all. Then I found some info about this sensor being quite new, so I tried adding the DDF file as used. After using that DDF, i ran the search again and it found the device (new device ready), though it didn’t appear in the phoscon webpage, so after doing it a few times and getting desperate I was pretty surprised to see that in domoticz the sensor DID show up (one temp and one hum). After reading the other post about this sensor a bit more I saw other were having similar problems and addressed it to the Phoscon UI that needed to include it (orso).

This behaviour never changed so I can do a resync using Phoscon, but it will never show up, so I can delete it using Phoscon as well.

What I did try was:

Delete it using the “bin” icon in the deconz plugin in domoticz, it doesn’t matter which of the two sensors I delete, they both disappear immediately then, and also cannot be found when doing a /sensors API call.

Though after restarting the deconz process, they are both back again.

I also tried deleting them by doing a DELETE on the sensor ID sending “reset”:true (and ?reset=true) in the request, but again, it disappears until i restart the deconz proces on the pi.
Yes I also deleted them from devices in Domoticz as well, but as soon as I restart deconz and they apear back as devices in deconz, the devices are also being recreated in domoticz again (but it remains the non-working ZHAHumidity sensor)…

I hope this makes it a little clearer :wink:

9

Lol, so from that I m reading the deletion is working, but why the device is back on the API … Perhaps you restart too fast, before deconz write the change on the database ?

But something you can do is deleting the sensor using domoticz for exemple and re-include the device (without restarting). It will be re-included using the DDF (as deconz have loaded it at start) and I hope the new entry will overwrite the old one.

And yes, deleting them from the devices tab in domoticz is not a lot of usefull, because if domoticz see the device it will re add it automaticaly, and when you restart all is resynchronised. But you can delete it in the device part after you delete it in the custom page, and wait for the new inclusion, will be better, if I m right you will not have the ZHAHumidity.

Else I will explain you how to restart deconz in debug mode with usefull flags (no write on disk)

10

Smanar,

Just did another retry.
I deleted the sensors using domoticz again(for some reason I had to delete them both this time, maybe because I started with ID14 first and then 13?) ah well, after deleting I waited somewhere between 45 minutes and an hour

they still were non-existent, then (without restarting deconz) I tried re-adding, but nothing found (multiple times), then after restarting deconz I did manage to get them (re)added again, but as they were (already)there, same problem, using the settings from the first time (they just don’t want to start using the correct/new DDF).

11

I just queried the sensors and devices tables of the zll.db file and to my surprise (I read a case of earlier this year where there was a mismatch between sensors and devices which looks a bit like this case) both tables are just the same before and after the API call to delete the sensors… so it seems the devices are removed from memory, but remain intact in the DB and thus return on restart of deconz.

Can I just delete the Mac from the devices table and the two linked sensors in the sensors table and restart?

12

It’s worrying, you have perhaps a problem with the database, no error about “locked database” ?

Sure, and there is no danger if you make a backup before. The device will be already in the network, so can be visible in deconz, but not present in the database, so the name will be something like 0xXXXX, but it’s not a problem.

But if later you are still not able to add new device (deconz not able to add them to the database), will be a good idea to check some database error

13

Notified manup to see if he has interest.

14

Ad an even stranger update.
Just deleted the device from the devices and the sensors tables, started deconz again and guess what, I can’t add it anymore (also not after restarting deConz), so I guess (I don’t know the structure of the complete DB) there’s more to it to make sure you can re-add it.

to try to make sure nothing was wrong with my deconz instance/db itself, I added a new sensors that I still had laying around here and that worked as expected. coincidentally also Tuya TS0601, though this is a standard air temp/hum device, with another manufacture ID (slightly different) .

Device is not recognized by the phoscon GUI again, but does end up in deconz and is also added to Domoticz and is updated with new values ever since (both temp and hum devices), so it seems like deconz is not to blame on this end…

it DID notice that after (trying) to add the sensor the device ID does end up in the devices table though…

15

So you mean you can include new devices, but not this one ?

Have checked my database, and the device can be in

  • devices, can reconise it with mac
  • sensors, can reconize it with mac
  • ressources_items but I don’t think it can cause issue ???
  • sub_devices, IDK this table is for …

Something you can do, as you have a simple OS (without desktop if I remember ?) is closing deconz, restarting it with debug line deCONZ command line parameters · dresden-elektronik/deconz-rest-plugin Wiki · GitHub
And try to re-include the device

Can use flag info*2 and DDF

16

Note when editing the database file directly deCONZ must be closed.

I don’t have an idea what’s happening exactly but some more details what should happen after deletion via REST-API, and once the database is synced (sync happens by timer or also after closing deCONZ, might take a few seconds):

  1. sensors table entry gets deleted
  2. devices table entry gets deleted
    (this automatically also deletes respective sub_devices and resource_items table entries)

Steps 1) and 2) can also be done manually via SQliteBrowser while deCONZ is closed, after deleting entries “Write Changes” button needs to be pressed.

17

@Smanar ,

I created a debug file using the requested flags and did a retry of the addition of the device.
Do you want me to upload the log file to the case?

@manup ,

Deconz was shut down at the time of the edit and I used sqlite3 from CLI, and as far as I know, that used auto-commit as default. I didn’t clean any entries from the sub_devices and/or resource_items tables, so I might try that once…

18

@manup,

I just had a look at one of the backup db files, but I don’t see any data in the sub_devices or resource_items tables (that I can relate to it) so, i’m still amazed at this whole situation

19

Honnestly I dont think something in thoses 2 table can prevent a re-inclusion.
And yes If you can share to me the logs during the inclusion try with flag Info *2 (Error * 2 if it’s not too late, else we can skip thoses one) and DDF ?

20

Smanar,

De test I did yesterday was with DDF and info only, if you want me to redo a test with error@2 as well, let me know, I will do a retest.

In the meantime I’m trying to find out how to attach my log file to this case, as I cannot upload .txt files (almost only pictures)…