Lomota garage door opener no longer reliably opens
guillochon opened this issue · 13 comments
Checklist
- I have read the common issues wiki page
- I have checked to make sure the plugin is up to date
Describe the bug
While my garage will open/close sometimes, it seems to no longer reliably do so after the latest update. I see no error/warnings in the logs to indicate something is wrong, but the garage remains stuck either open or closed when I attempt to control it in the Home app. Only after manually opening/closing the door with my RF garage opener will the app start responding again.
To Reproduce
Updated to the latest version of plugin (3.1.0).
Expected behavior
Garage door opens/close on demand.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):
- OS: Raspbian
- iOS version: 17.3.1
- Homehubs: Apple HomePod
- Node Version: 20.10.1
- Plugin Version: 3.1.0
- Accessory Type: Lomota Garage Door Opener
Im having a very similar issue but with eKyro as the manufacturer. I seems like a broader issue with garage door control. It used to work prior to the 3.x version and seemed to have stopped working
Just as a follow up to this. I resolved this issue by removing the device in the Tuya app and re-adding it. This effectively re-establishes a new local key. I've updated the new local key in HB plugin config and all works now with my garage door.
That solution doesn't make sense to me...why would refreshing the local keys fix this? I feel like it shouldn't work at all if that was the issue, but in my case it works sporadically.
Honestly, I have no idea. I’ve had it up and running for 2 days since I’ve done this configuration change and it has been working consistently. Perhaps, my issue is completely unrelated to yours bust behaviorally it appears similar? I will revert to this if things change. I just wanted to give an update.
Another update....This issue has resurfaced...Also, in the form with other devices (eg. a EGBW Light...similar to issue #443.). I also have the Tuya integration to HomeAssistant which devices are showing as unaffected.
I am just thinking but could be this related to the new local keys?
the new keys have very random signs. Could be one of those generating issues? For example if the local key has a quotation mark, this (maybe) is not properly managed during all the pipeline.
In this scenario, the suggestion made by @guillochon would make sense as when refreshing in it, you are changing the characters.
ana I agree that could be related with #443
- I have no clue how the keys are managed by the different processes. So I can be wrong
My local key has only alphanumeric characters. The problem is still here and I'm tempted to downgrade to the prior version where it worked, but I'm worried my config might get entirely ruined by downgrading (I know at the very least I'll have to re-add all my devices to all my automations, which I'd really rather avoid).
Is there any chance this will get addressed any time soon?
I have a little more insight on this problem, but no solution: it appears that whenever we use our regular garage door opener (the remote or the keypad), the homebridge extension gets "out of sync" and seems to think the door is the opposite state. Only once the garage has been reverted manually to the correct state does the plugin work again. So I think this is an issue where the plugin is not properly tracking the garage door state anymore as of the new update.
If a dev could take a look at this I'd really appreciate it, been debating downgrading the plugin but reaaally don't want to do that to have to re-add my devices to all the automations again. @05TEVE
Hi @guillochon ,
The timeout issues people are seeing in #443 I believe may be related to either the logic for the local key changes introduced in 3.10 (Merged in to allow new devices to be added at all) or the Tuya protocol that the device is using. When homebridge starts, does the device say 3.3 or 3.4 in the log? I am not sure if rotating the keys will help if you are still using one of the original keys. Are there any timeout errors at all in the log? Or is it just getting out of sync? If the timeout errors aren't there my guess is that this is unrelated to that.
As far as i can tell, there hasn't been any major changes to the Garage door code since 2.0.1 other than logging fixes. I have found a few issues popping up in other areas though as I cut the new version off of the latest master. This unfortunately however had a large number of changes from the 2.1.0 Beta that were never fully rolled out. Are there any messages in the homebridge debug logs when the issue is occurring? (i.e does it receive the notification but not process it correctly).
Debugging this sort of thing is rather challenging without having the device myself unfortunately however i'll see if i can see anything obvious in the code.
Hi @05TEVE, thanks for replying.
When the plugin starts I see the following:
Discovered Garage Door (xxx) identified as GarageDoor (3.3)
I do not see any timeout errors in the logs.
Here is the config I have for the garage door. I am not sure if I am using the right DpStatus or DpAction settings here, I think they are correct looking at the Tuya page but again, not sure. As I said it does work unless the physical button is used to toggle the door. Anything here look amiss?
{
"type": "GarageDoor",
"name": "Garage Door",
"id": "censored_but_only_alphanumerics",
"key": "censored_but_only_alphanumerics",
"manufacturer": "Lomota",
"model": "MSG100",
"dpAction": 1,
"dpStatus": 101,
"flipState": false
},
It is possible I had used a modified version of this plugin (not the main branch) to get the garage working, I realize, but which branch I do not recall (it's also possible I'm misremembering). Sorry, this is all kinda of a mess!
On Tuya, this is what is reported for the device when I query properties:
{
"result": {
"properties": [
{
"code": "switch_1",
"custom_name": "",
"dp_id": 1,
"time": 1710629932024,
"value": false
},
{
"code": "countdown_1",
"custom_name": "",
"dp_id": 7,
"time": 1706417622159,
"value": 0
},
{
"code": "mdk",
"custom_name": "",
"dp_id": 101,
"time": 1710629943878,
"value": false
},
{
"code": "tr_timecon",
"custom_name": "",
"dp_id": 102,
"time": 1706417622159,
"value": 12
},
{
"code": "countdown",
"custom_name": "",
"dp_id": 103,
"time": 1710630203094,
"value": 0
}
]
},
"success": true,
"t": 1710630358389,
"tid": "xxx"
}
I don't see anything here that's obvious "DpStatus", I currently use 101 but here it's listed as "mdk".
A little more testing: when I use the homebridge plugin to toggle the garage state, the mdk item toggles between true and false when the door is opened/closed. When I open my door manually however, the door's state does not toggle, and then the next time I try to use the homebridge plugin it doesn't do anything, even though in the Home app it properly shows the state of the door.
@guillochon Im seeing the exact same behaviors on my side. I dont have an mdk property however...I use dps 1 and 3 for action and status respectively...
{
"result": {
"properties": [
{
"code": "switch_1",
"custom_name": "",
"dp_id": 1,
"time": 1710615615130,
"value": false
},
{
"code": "countdown_1",
"custom_name": "",
"dp_id": 2,
"time": 1708756630064,
"value": 0
},
{
"code": "doorcontact_state",
"custom_name": "",
"dp_id": 3,
"time": 1710621603867,
"value": false
},
I use protocol 3.3 as well...
Discovered Single Car Garage Door (xxxx) identified as GarageDoor (3.3)
Id say comfortably this doesnt just affect Lomota garage door openers.