[APP] LOQED - Your personal doorman

Apps
,
82

Okay, ill have a look tomorrow.
Could you make a printscreen of you When cards, so i can match my setup to yours? Thanks!

83

This is a “When”-card

84

It’s just a tip I didn’t ment it as an insult but ok, i had a lot of f ups with apps that had auto updates on and decided that i want to read the changelogs first before updating.

85

Yes i know. But i need a printscreen of all available When cards so i know what options your lock has.

86

Ah sorry, this should be it

Capture 2024-02-22 at 08.38.03@2x
Capture 2024-02-22 at 08.38.03@2x816×558 43.6 KB

1 Like
87

@JvdMeulen

Well, its clear to me that you were never on the (old) testversion (3.3.0, when i toke over the app development). I just found out that one already had the bug in it making legacy devices not function properly.
Appareantly, the Homey Webhook used for the “old” devices has just been “stolen” to be used for the new OAuth devices, thus making the legacy devices not work anymore.
The sourcecode is still in the master branch tho, and i am busy solving it right now.

However, to not let you install 10 times to solve it, there is one thing i would need to know.
Could you run this HomeyScript (replace the Testdeur with your lock name):
return _.find(await Homey.devices.getDevices(), x=>x.name=='Testdeur');

In the response, you will find

"data": {
    "id": *****
  },

I need to know if the id is only a few numbers, or also contains leters.
Could you let me know? Then i have a fixed version within the hour i think.

88

I never said i was, did i?

Thanks, i appreciate that.

Who did that?

It’s exactly 5 numbers

89

Thanks.

I have just solve the issue for “legacy” devices, and its already pushed to live:

Update your app, and it should work as it did before.

If you still run into issues, please let me know.

1 Like
90

No you didn’t :wink:
If you did, you would then have already had this issue.
For me, this insight gave me a way of tracking the issue, through comparing the 2.2 sourcecode to the 3.3.0 (and later) sourcecode.

Well, i am assuming the previous developer.
It seems that version 3.3.0 was not ment to keep supporting legacy devices, but would have required users to switch to the new devices.

Personally i think everyone would do good to remove the locks from homey and re-pair them with the new driver. When connected through the new driver, you get a lott more options, beter insights, beter tags, etc.
However, imho, the legacy driver should stay active to give users the possibility to re-pair the locks when the have the time.

Now, personally, i wasn’t aware that version 3.3.0 (which i took over) already broke the legacy driver.
I didn’t have LOQED before i took over.
And to be fair, while i did test the legacy driver, to see of you could open/close the lock, i appareantly didn’t test well enough, because i didn’t notice the status of Homey not being updated when the locked changed through the LOQED app (or psychically).
My bad.

But, afaik, it should no be fixed in version 3.4.3.

1 Like
91

It looks like this event is triggered twice

92

That’s all fine, but “you” ( developers in general ( and maybe athom can/should add some setting to prevent breaking changes )) shouldn’t push updates that “breaks” apps/flow that are in test.

Maybe i’ll upgrade, but i really want to keep the status change trigger. And no, i dont want to define/hook up-- all the if-cards.

Thank you for quickly take actions and solving the problem(s).

93

I’ll try my best.

BTW, version 3.4.3 will not activate the Lock Status Changed trigger if it has been changed through Homey.
Update 3.4.4 solves this issue and is in review by Athom right now.

1 Like
94

I have just added this flowcard in version 3.4.5 for the new OAuth Devices.
It’s in review now and will be published shortly.

95

I experience since a day a lock which I cannot access. The device is offline. “Apparaat onbeschikbaar” I have version 3.4.5.

I did execute two weeks ago the API Reset and that worked fine. Now I cannot repair, deleted the device and re-installed it.

b3ff3c53-6918-46d4-8717-bbff67effbe7 is the report ID I shared with you.
And just to be sure, this is part of the script output:

“uiIndicator”: null,
“available”: false,
“unavailableMessage”: “The device is offline”,
“warningMessage”: “De status van dit slot is onbekend.”,
“ready”: true,
“repair”: true,
“unpair”: false,
“images”: ,
“color”: “#002746”

96

What happends if you do repair?
Do you get the loginscreen? Does login goes as usual?

97

Yes all goes as expected after repairing

98

@Wout_van_den_Dool As in, its working again?

99

nope unfortunately not…

100

@Wout_van_den_Dool do you have other locks that do work? Or just the one?

101

Just that one…, think I found a root cause, bridge is disconnected from the WiFi (dead)