"HCT-611 WiFi Water Timer" not detected properly #771
Comments
Original report #638 gave iot.tuya.com docs with dps 1, 7, 8, 10, 11, 12, 13 Later screenshots of iot.tuya.com dropped 12 (work_state) but the rest were still present. Actual logs from #771 show 1, 7, 8, 13, 14, 110. 14 and 110 are unknown, as not listed in the portal (though 14 may be a switch for the smart weather function, as per johgee device). Assume 10, 11, 12 might show up under some circumstances, and leave them as optional in the config.
|
The logs show dps 10 (weather_delay), 11 (countdown), 12 (work_state) are missing from the local status messages. Additional dps 14 and 110 are present, but the function is unknown. You may be able to find a name for these in the Device Debugger on iot.tuya.com (see https://www.zigbee2mqtt.io/advanced/support-new-devices/03_find_tuya_data_points.html for more details about this). |
make-all
added
awaiting confirmation
|
What about version reported? |
|
See details about 110 (Google Translate = Switch records)
|
|
12 is "work state" (don't know what should it do)
|
|
... and what about this ? ("standard instruction" vs "DP instruction")
|
|
Thanks, I will add the Smart weather switch to the config, and rename the others. I think work_state is just informational about what the device is currently doing, as it was in your original report under status, but not function. I'm not sure what changing the DP instruction in the Tuya developer portal does, but since this integration does not use the cloud API, I don't think it will be affected (but the standard tuya integration and mobile app may be affected). |
|
Many thanks! Do you think that you can enable support also for the Timer Programs (up to 8) as "read only"? Their pids are (but not sure if they are available without changing mode - see my previous post about "Standard instructions" vs "DP instructions") Thanks again |
|
Another thing.. do you think you can enable support also for the Gateway (as readonly data to be shown in HA)? These are some details I read on Tuya cloud Request URLCopy
|
|
Urrah!! Really really happy!!! See below!
|
|
All comands are reported (into logs) as "device itself" Still have to understand how the Timer (Countdown) is suppsed to work ..
|
|
And "weather delay" apparently doesn't work |
|
I forgot to tag this issue, but I added the newly discovered dps. For the hub itself, you will need to make a report with local logs, the same as with this device. The cid will be blank. But I am not sure whether the current implementation is able to support the hub and subdevice at the same time. Subdevice support is quite recent, and not all bugs are yet found and fixed. When I tried it some time ago, a hub that was already configured in HA was not able to configure any subdevices, as they appeared as duplicates to HA. One fix was submitted since then, and maybe it fixes that, but I have not had time to try again. |
|
Great! I will now try the new modified config file (that contains the Programs) About the Countdown/Timer (which apparently doesn't work).. are you sure about the current code?
|
|
Tested the new config file and the result is:
"data": { |
|
The timer is configured to allow setting and showing 1 minute resolution. Typically the Tuya mobile app will only allow setting timers in 1 hour or 30 minute increments, so this is still more precision than you get from that. Allowing 1 second precision would be misleading, because we cannot guarantee the timing that accurately, and the device does not report every second ticking down, so would just lead to bug reports that are limitations of the technology. The program attributes can be seen in the diagnostics output, they are set as attributes on the main switch, so you should be able to see them in the Developer Tools, and read them as attributes in automations etc. Since the format is unknown, I did not think they were useful to break out into separate entities. |
|
I confirm that Programs are visible as attributes of the switch
|
|
I think I found the way to interpreter the Program if is SET but ON or OFF and not SET Maybe you can improve this functionality to show, as attributes, these word instead of the code? Program 1 - fwcAALR = ON - AAcAALR = OFF Am I asking too much? ;-) Thanks anyway... |
|
Koenkk/zigbee2mqtt#16671 contains some info on those attributes. It would be better to completely reverse engineering this part of the protocol, but this is non trivial. Moreover, it is unclear if it relies on Tuya cloud or not. |
I can tell you that when I change the value from the Smartlife app .. I can read in the Cloud logs the changes.. (and as device itself I think it refers to HA that reads those data) Here we are talking about "just" showing if the Program is ON/OFF/Not Set Thanks
|
I tried to add the Gateway in order to be able to collect logs .. but it fails.. I am using the following data:
|
|
It depends on the exact error message, but as I wrote above "I am not sure whether the current implementation is able to support the hub and subdevice at the same time." |
|
I found these entry in diag output that seems to refer to it.. 2023-06-08 10:56:19.428 DEBUG (SyncWorker_5) [custom_components.tuya_local.device] Test refreshed device state: null |
|
OK, based on that log, it was able to connect to the hub, so the conflict between subdevices and hub seems to be fixed. The problem is that the hub is not returning any data. So there is nothing to match against, and nothing that could be displayed in HA if it was implemented. That signal strength must be cloud only. |
|
ok clear.. What about the possibility to show ON/OFF/not SET (for Program) based on my list above? Thanks |
|
I think the not SET is easy enough to pull out, as it is a single value (corresponding to a single null character if you decode that base64 data). But the distinction between on and off is not so easy to make without understanding the actual format of the binary data. |
|
Hi agree that decoding it is not easy.. but I was not talking about showing the "program data" (eg all day from 7:00 to 8:00 etc) but simply.. ON, OFF based on the difference between the "know" data .. As recap about the sensors created so far for this device:
That's all for now Thanks again for all of your effort to make this device working with HA
|
|
I suggest to read the link from @fcrozat above. It had some information about some of the specific pre-conditions for some of the dps to work as expected. I don't think the "smart weather" forecast is coming from the device itself, and therefore is not read-only (it was listed under "functions" in the portal information). Probably the cloud is driving it, and you can basically ignore it for local use, but I suspect if the device was blocked from accessing the cloud, then setting those would probably work as expected, and it is only that it is fighting against the cloud that is causing it to appear not to work now. |
|
At this point I can close the ticket.. |
|
I prefer to leave them open with the unreleased tag until the release is actually made. But thanks for confirming. |
make-all
removed
the
awaiting confirmation
|
Ok.. |
|
Tonight the integration stopped working.. this morning I updated it to latest version just released but the device continues to be unavailable.. no idea why (Smartlife see it online) |
|
Sorted out.. |
|
Maybe this is normal for devices connected via hubs. The hub does not have any data until it is triggered by something trying to connect to the device. This is probably useful information for the connection problems thread. |
See logs below..
The device is not detected as Water Timer (there is a specific config file named "ble_hct611_watertimer.yaml") but as "ASC wifi circuit breaker"
I also noticed that even if I installed 2023.5.2.. in the log I read 2022.5.2..
Do you know why?
{
"home_assistant": {
"installation_type": "Home Assistant OS",
"version": "2023.5.4",
"dev": false,
"hassio": true,
"virtualenv": false,
"python_version": "3.10.11",
"docker": true,
"arch": "armv7l",
"timezone": "Europe/Rome",
"os_name": "Linux",
"os_version": "6.1.21-v7",
"supervisor": "2023.04.1",
"host_os": "Home Assistant OS 10.2",
"docker_version": "23.0.6",
"chassis": "embedded",
"run_as_root": true
},
"custom_components": {
"hacs": {
"version": "1.32.1",
"requirements": [
"aiogithubapi>=22.10.1"
]
},
"ezviz_plug": {
"version": "1.0.0",
"requirements": []
},
"sonoff": {
"version": "3.5.1",
"requirements": [
"pycryptodome>=3.6.6"
]
},
"tuya_local": {
"version": "2022.5.2",
"requirements": [
"pycryptodome~=3.17",
"tinytuya==1.12.7"
]
},
"midea_dehumidifier": {
"version": "2.0.2",
"requirements": [
"midea-python-client==1.0.2"
]
}
},
"integration_manifest": {
"domain": "tuya_local",
"name": "Tuya Local",
"codeowners": [
"@make-all"
],
"config_flow": true,
"dependencies": [],
"documentation": "https://github.com/make-all/tuya-local",
"integration_type": "device",
"iot_class": "local_push",
"issue_tracker": "https://github.com/make-all/tuya-local/issues",
"requirements": [
"pycryptodome~=3.17",
"tinytuya==1.12.7"
],
"version": "2022.5.2",
"is_built_in": false
},
"data": {
"name": "Irrigatore",
"type": "asc_wifi_circuit_breaker",
"device_id": "REDACTED",
"device_cid": "REDACTED",
"local_key": "REDACTED",
"host": "REDACTED",
"protocol_version": 3.3,
"api_version_set": 3.3,
"api_version_used": 3.3,
"api_working": true,
"status": {},
"cached_state": {
"updated_at": 1686057348.059441,
"1": false,
"7": 5,
"8": "high",
"13": "cloudy",
"14": false,
"110": false
},
"pending_state": {},
"connected": true,
"force_dps": [],
"home_assistant": {
"name": "Irrigatore",
"name_by_user": null,
"disabled": false,
"disabled_by": null,
"entities": [
{
"disabled": false,
"disabled_by": null,
"entity_category": "diagnostic",
"device_class": null,
"original_device_class": "current",
"icon": null,
"unit_of_measurement": "A",
"state": {
"entity_id": "sensor.irrigatore_current",
"state": "unknown",
"attributes": {
"unit_of_measurement": "A",
"device_class": "current",
"friendly_name": "Irrigatore Current"
},
"last_changed": "2023-06-06T13:14:45.291566+00:00",
"last_updated": "2023-06-06T13:14:45.291566+00:00"
}
},
{
"disabled": false,
"disabled_by": null,
"entity_category": "diagnostic",
"device_class": null,
"original_device_class": "voltage",
"icon": null,
"unit_of_measurement": "V",
"state": {
"entity_id": "sensor.irrigatore_voltage",
"state": "unknown",
"attributes": {
"unit_of_measurement": "V",
"device_class": "voltage",
"friendly_name": "Irrigatore Voltage"
},
"last_changed": "2023-06-06T13:14:45.293919+00:00",
"last_updated": "2023-06-06T13:14:45.293919+00:00"
}
},
{
"disabled": false,
"disabled_by": null,
"entity_category": "diagnostic",
"device_class": null,
"original_device_class": "power",
"icon": null,
"unit_of_measurement": "W",
"state": {
"entity_id": "sensor.irrigatore_power",
"state": "unknown",
"attributes": {
"unit_of_measurement": "W",
"device_class": "power",
"friendly_name": "Irrigatore Power"
},
"last_changed": "2023-06-06T13:14:45.295940+00:00",
"last_updated": "2023-06-06T13:14:45.295940+00:00"
}
},
{
"disabled": false,
"disabled_by": null,
"entity_category": "config",
"device_class": null,
"original_device_class": null,
"icon": null,
"unit_of_measurement": "min",
"state": {
"entity_id": "number.irrigatore_countdown",
"state": "0.0833333333333333",
"attributes": {
"min": 0.0,
"max": 1440.0,
"step": 1.0,
"mode": "auto",
"unit_of_measurement": "min",
"icon": "mdi:timer",
"friendly_name": "Irrigatore Countdown"
},
"last_changed": "2023-06-06T13:14:45.302271+00:00",
"last_updated": "2023-06-06T13:14:45.302271+00:00"
}
},
{
"disabled": false,
"disabled_by": null,
"entity_category": null,
"device_class": null,
"original_device_class": "switch",
"icon": null,
"unit_of_measurement": null,
"state": {
"entity_id": "switch.irrigatore",
"state": "off",
"attributes": {
"device_class": "switch",
"friendly_name": "Irrigatore"
},
"last_changed": "2023-06-06T13:14:45.303648+00:00",
"last_updated": "2023-06-06T13:14:45.303648+00:00"
}
}
]
}
}
}
The text was updated successfully, but these errors were encountered: