@smanar: Logfile (without the error option)
The (tried) inclusion is near the end of the logfile (I stopped the debug session right after the failed inclusion)
We can see deconz is updating the DB (devices table) before you start the inclusion, probably because the device is still on the network ?
17:50:03:691 DB sql exec UPDATE devices SET nwk = 2398 WHERE mac = 'a4:c1:38:58:c4:64:32:ad';INSERT INTO devices (mac,nwk,timestamp) SELECT 'a4:c1:38:58:c4:64:32:ad', 2398, strftime('%s','now') WHERE (SELECT changes() = 0);
17:50:03:692 DB saved in 0 ms
After that the device is detected
17:51:09:036 0x095E nwk changed to 0x50D6
17:51:09:037 device announce 0xA4C13858C46432AD (0x50D6) mac capabilities 0x80
17:51:09:037 set fast probe address to 0xA4C13858C46432AD (0x50D6)
17:51:09:037 FP indication 0x0000 / 0x0013 (0xA4C13858C46432AD / 0x50D6)
17:51:09:037 ... (0xA4C13858C46432AD / 0x50D6)
17:51:09:037 device announce 0xA4C13858C46432AD (0x50D6) mac capabilities 0x80
17:51:09:037 DEV Tick.Join: event/device.anounce
17:51:09:037 DEV Tick: fast poll 0xA4C13858C46432AD, mac capabilities: 0x80
17:51:10:411 DB sql exec UPDATE devices SET nwk = 20694 WHERE mac = 'a4:c1:38:58:c4:64:32:ad';INSERT INTO devices (mac,nwk,timestamp) SELECT 'a4:c1:38:58:c4:64:32:ad', 20694, strftime('%s','now') WHERE (SELECT changes() = 0);
We can see the inclusion step
17:51:09:925 [1] get node descriptor for 0xa4c13858c46432ad
17:51:10:598 [2] get active endpoints for 0xa4c13858c46432ad
17:51:10:902 [4.1] Get model ID
17:51:10:902 [4.2] get basic cluster attr 0x0005 for 0xa4c13858c46432ad
DDF is used too
17:51:17:226 DEV found DDF for 0xA4C13858C46432AD, path: /usr/share/deCONZ/devices/tuya/_TZE200_myd45weu_soil_sensor.json
But It seem it’s the last usefull line, the process not finish …
For me all seem good (up the end of log) @manup have you a way to explore ?
Smanar, Manup,
I just did a new test, this time I added the dbg-error=2 to the log and disabled the sensor before the test, so the steps this time were:
- disconnect battery from sensor, and after about an hour:
- stop service deconz
- sqlite3 zll.db and delete the entry holding the MAC from the devices table, all others seemed to contain nothing related to the sensor.
- started in debug mode at around 19:02:15 and let it run for a short while so it would be “done” with all inits.
- at around 19:04:00 I started the addition from a sensors in Phoscon again and put back the batteries.
- at around 19:04:30 I initiated a reset to the sensor, just to make sure it’ll go through an init.
at around 19:05:30 i stopped the logging this time, giving it a bit more time to conclude the proces.
I don’t think it made any difference, but I thought maybe just do this test as well.
Thanks again.
Logs can be found at: Debugfile including errorlog=2
Difficult to tell, since this is a sleeping end-device the DDF/Device state machine needs to know when the device is awake to proceed with further requests/configuration.
The tricky part is that “awake” is not simply the case when the device sends a command, but only if it sends a command and does a MAC Data Request (poll) the parent afterwards. This can only be seen in the sniffer if it is connected via a router, or in the deCONZ logs when it is connected via coordinator.
In regards to the DDF the { "awake": true } on a item should only be set for above commands, otherwise the machinery would send out commands which likely will end in a timeout, since the device is sleeping.
… but this is mostly only relevant for after joining, and once a DDF is assigned to the device. So even if configuration isn’t finished, as long as the device wakes up from time to time, due the DDF the setup can “self heal” even if it might take hours (e.g. Xiaomi devices waking up once per hour)
More info here: While joining a device the state machine is not just listening for awake events caused by above situation, but is also gets rapidly poll events which should trigger query and configuration in the expectation that the device is awake during joining.
Summary, it would be good to see a sniffer log
1 Like
Manup,
You mean the zshark sniffer log?
As long as Zshark isn’t reachable via CLI (instead of GUI) that’s an issue again (for now).
Just to be sure: do I get it right that you expect it might be possible that the device will turn up after all, if I just keep it powered on for a while to see if the awake situation will happen in the next hours? as the device has been powered on the whole last week (I disconnected the batteries for the test of last weekend) I doubt it, but no problem just keeping it connected for the day and see what it does.
I’m planning on creating a temporary deconz instance on a separate Pi400 (display connected), as i then will have the GUIs available, but that might take a few days as I’m waiting for my new SSD the come in.
Uh oh, I’ve just noticed that this DDF isn’t enabled by default, since it’s marked as Silver.
Can you please check the ~/.local/share/dresden-elektronik/deCONZ/config.ini
that silver DDFs are enabled:
[ddf-filter]
bronze=0
gold=1
silver=1
… in the deCONZ GUI this can be set via “Panels → Control → DDF”
(alternatively set { "status": "Gold" } in the DDF.
@manup that was the (last) trick!
after adding the DDF-Filter to the config it was recognized right away, still not visible in the phoscon UI though, but I don’t mind!
@Smanar Device is recognized in Domoticz as temp and as moisture and is reporting values as well as it went from 0 (not in soil) to 10000 (when put in wet soil as it rained a few hours ago) and is stabilizing (now at 9700 which translates as 6cb at the moment) GREAT!
1 Like
Seriously ? was just that ? But why the device is reconised in the API if the DDF is not used ?
BTW, it’s an out of topic but from the domoticz documentation
# 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
0 > 10000 are deconz value or domoticz one ? Because you need to have value from 0 to 200.
(can continue this issue on dicord, domoticz forum or plugin github if you need it)
now at 9700 which translates as 6cb at the moment
Or If I have understand 9700 is the deconz value (97%) and 6cb is the domoticz one ?
sorry for the confusion, the 0-10000 is the deconz one (as can be seen in the deconz plugin page), which translates into the 0-200 values in domoticz (cb). I’ll see what it does the next few days as we will be going through very very wet (at the moment) with even >50mm of rain tonight till 32C and very dry on saturday, so perfect testing conditions.
For now, thanks to both of you!