grid connect/garage door controller

[isarib01]

Hi,

I have a garage door controller by grid connect, which I assume is generic. It seems to work fine with the tuya local out of the box, as I have used it for some time now.

I just can't figure out why the door will open itself whenever the wifi router gets rebooted, either HA/tuya local handles this door state funny when devices go out of reach or something else?

Below is what entities are within the garage controller.

{
"result": {
"active_time": 1666953964,
"category": "ckmkzq",
"category_name": "Garage Door Opener",
"create_time": 1662725912,
"gateway_id": "",
"icon": "smart/icon/ay1536534747810ekKBj/4aa444a268bf4c4657a7b0d31b4fac45.png",
"id": "",
"ip": "",
"lat": "",
"local_key": "*********",
"lon": "********",
"model": "SWS102HA",
"name": "Garage Door",
"online": true,
"owner_id": "65067975",
"product_id": "3vd7ybbeh10llcdc",
"product_name": "Smart Garage Door Opener ",
"sub": false,
"time_zone": "+08:00",
"update_time": 1666953964,
"uuid": "a7fa752238d5d80b"
},
"success": true,
"t": 1669133369099,
"tid": "0af22d066a8011ed854422b2ae449af7"
}

{
"result": {
"category": "ckmkzq",
"functions": [
{
"code": "switch_1",
"lang_config": {
"false": "close",
"true": "open"
},
"name": "control",
"type": "Boolean",
"values": "{}"
},
{
"code": "countdown_1",
"lang_config": {
"unit": "s"
},
"name": "countdown",
"type": "Integer",
"values": "{"unit":"s","min":0,"max":86400,"scale":0,"step":1}"
},
{
"code": "tr_timecon",
"lang_config": {
"unit": "s"
},
"name": "Opening and closing time",
"type": "Integer",
"values": "{"unit":"s","min":10,"max":120,"scale":0,"step":1}"
},
{
"code": "countdown_alarm",
"lang_config": {
"unit": "s"
},
"name": "the time of open door",
"type": "Integer",
"values": "{"unit":"s","min":0,"max":86400,"scale":0,"step":1}"
},
{
"code": "door_control_1",
"lang_config": {
"close": "Close",
"open": "Open"
},
"name": "voice control",
"type": "Enum",
"values": "{"range":["open","close"]}"
},
{
"code": "voice_control_1",
"lang_config": {
"false": "OFF",
"true": "ON"
},
"name": "Voice control Settings",
"type": "Boolean",
"values": "{}"
},
{
"code": "door_state_1",
"lang_config": {
"close_time_alarm": "Close the timeout",
"none": "NO",
"unclosed_time": "Open state timeout"
},
"name": "Door alarm status",
"type": "Enum",
"values": "{"range":["unclosed_time","close_time_alarm","none"]}"
}
],
"status": [
{
"code": "switch_1",
"lang_config": {
"false": "close",
"true": "open"
},
"name": "control",
"type": "Boolean",
"values": "{}"
},
{
"code": "countdown_1",
"lang_config": {
"unit": "s"
},
"name": "countdown",
"type": "Integer",
"values": "{"unit":"s","min":0,"max":86400,"scale":0,"step":1}"
},
{
"code": "doorcontact_state",
"lang_config": {
"false": "closed",
"true": "opened"
},
"name": "door status",
"type": "Boolean",
"values": "{}"
},
{
"code": "tr_timecon",
"lang_config": {
"unit": "s"
},
"name": "Opening and closing time",
"type": "Integer",
"values": "{"unit":"s","min":10,"max":120,"scale":0,"step":1}"
},
{
"code": "countdown_alarm",
"lang_config": {
"unit": "s"
},
"name": "the time of open door",
"type": "Integer",
"values": "{"unit":"s","min":0,"max":86400,"scale":0,"step":1}"
},
{
"code": "door_control_1",
"lang_config": {
"close": "Close",
"open": "Open"
},
"name": "voice control",
"type": "Enum",
"values": "{"range":["open","close"]}"
},
{
"code": "voice_control_1",
"lang_config": {
"false": "OFF",
"true": "ON"
},
"name": "Voice control Settings",
"type": "Boolean",
"values": "{}"
},
{
"code": "door_state_1",
"lang_config": {
"close_time_alarm": "Close the timeout",
"none": "NO",
"unclosed_time": "Open state timeout"
},
"name": "Door alarm status",
"type": "Enum",
"values": "{"range":["unclosed_time","close_time_alarm","none"]}"
}
]
},
"success": true,
"t": 1669134876721,
"tid": "8d8e10f36a8311ed854422b2ae449af7"
}

[make-all]

If you are using "auto" protocol detection, it may be triggering something as it scans the different protocol versions. If you download the diagnostics when it is running, the detected protocol version will be in there, and you can reconfigure it to use that.

[isarib01]

Thanks for the reply. I will change the protocol version to 3.3 static instead of auto - To see if it helps when I restart the wifi router.  Good way to test it! - Will let you know.   "data": {    "name": "Garage_Door_Controller",    "type": "dongguan_garage_door_opener",    "device_id": "**REDACTED**",    "local_key": "**REDACTED**",    "host": "**REDACTED**",    "protocol_version": "auto",    "api_version_set": 3.3,    "api_version_used": 3.3,    "api_working": true,    "status": {},    "cached_state": {      "updated_at": 1687786093.176336,      "1": true,      "2": 0,      "3": false,      "4": 20,      "5": 600,      "12": "unclosed_time"    }, Regards

…

____________________________________________ Imran Sarib ***@***.*** On Sunday, 25 June 2023 at 09:37:46 pm AWST, Jason Rumney ***@***.***> wrote: If you are using "auto" protocol detection, it may be triggering something as it scans the different protocol versions. If you download the diagnostics when it is running, the detected protocol version will be in there, and you can reconfigure it to use that. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[isarib01]

Hi, This has been stable for some time now, however in the last 2 months - the controller seems to go offline in tuya local. I was using HA 2023.7 when the issue started to occur, so now am on the current HA thinking it needed an update, an update to HACS and everything else. Attached is where the device goes off line, sometimes will reappear fine again, if not - a restart of HA maybe required. Does not appear to be the garage Controller itself, as the device is 100% functioning within the tuya app when this occurs in HA.

[make-all]

Is this on 2024.11.0?

Most likely the cause is short WiFi signal issues, which are causing the connection to become hung. 2024.11.0 contains some forced closure of sockets, but it may not be triggered in this case, as I was mainly focused on the reports of reloading the integration not working to fix such issues, and people being unable to reconfigure their IP address due to the issue.

[make-all]

I'm talking about tuya-local version, but if you are still on 2024.10.0 (did not update since Monday) there is a possibility it is already fixed.

[isarib01]

Gotcha, yep on 2024.11.0

[isarib01]

Would stronger wifi signal help in this situation or in the interim? Might reposition my wifi mesh to see if it helps.

[make-all]

Likely moving a mesh router closer to the garage would help. But it may be something else like your router applying firmware updates in the middle of the night, or your ISP applying config changes, rather than a signal issue if it is only happening at these times. Anyway, 2024.11.2 contains a potential fix for the slow / lacking recovery from these situations.

[isarib01]

I have moved the mesh closer, don't think it made any difference(not that I could tell).

I have now updated to 2024.11.2, which looks to have improved - checking logs and there has been no disconnects for the last 24hrs.