Event (notification) when a lock failed to get locked

[iRonin]

I've got issues with Gerdalock (Danalock) and Fibaro - oftentimes it wouldn't be locked via automation in Homekit. How difficult would beto add a notification or some event trigger to hook up further to IFTTT or something? I could sponsor the implementation maybe.

If the lock failed to lock (or was marked as dead which happens randomly and it works ok after forcing communication) there is no feedback from Fibaro:

Lock failed to lock

[2018-3-5 14:13:02] [FibaroHC2] Setting value to device:  41  parameter: Lock Target State
[2018-3-5 14:13:02] [FibaroHC2] Command:  secure, value: 0, to: 41
[2018-3-5 14:13:35] [homebridge-config-ui-x] Changes to config.json saved.

Lock has been locked

[2018-3-5 14:18:32] [FibaroHC2] Setting value to device:  41  parameter: Lock Target State
[2018-3-5 14:18:32] [FibaroHC2] Command:  secure, value: 0, to: 41
[2018-3-5 14:18:38] [FibaroHC2] Updating value for device:  41  parameter: Lock Current State, value: true
[2018-3-5 14:18:38] [FibaroHC2] Updating value for device:  41  parameter: Lock Target State, value: true

[ilcato]

Do you think it is a bug in the Fibaro API? Can you stress test it by using the API interface through the /docs UI? in order to understand where the problem is.

[iRonin]

This particular lock does not have proper Fibaro templates (I spoke extensively with the manufacturer; Gerda is well known company but Fibaro does not seam to care to about the support). Bug or not, I would feel more comfortable with a notification about failing lock command.

[ilcato]

So, if I understand, you want a form of notification for the first case in which after a specific timeout the bridge doesn't receive a feedback from Fibaro home center. Is an interface to an IFTTT Maker channel good enough? Or an MQTT message is better? I'm also able to generate an event on a specific Homekit Programmable Switch.

[iRonin]

Yes :) Event on a Homekit switch would be an elastic option, however I would hook it up to IFTTT anyways.

Thinking about it, it's more about a setting for a lock (or all locks), to supply a timeout after which a check to see if the lock has been indeed locked would be triggered (maybe without relying on what Fibaro returns but simply checking the state of the lock) and then sending configured notification to IFTTT or triggering a Homekit switch. Does it make sense?

[ilcato]

Ok, I do not have a lock, so I need your support for testing. Which is a suitable timeout for the check?

[iRonin]

I’m happy to do the testing! If you could do the timeout configurable that would be spledind; 5s as default should be enough. Thanks!

[ilcato]

I made a first draft of the implementation. Currently it only logs the difference between the target lock state and the measured one after the timeout (notification to IFTTT missing). Please update the following file and restart homebridge to test: dest/index.js and dist/setFunctions.js. In config.json add the two new parameters. Thanks

[iRonin]

(Un)fortunatelly the lock has been working properly recently. If you could add IFTTT integration it will be easier for me to spot it as I'm not the only user in my house and sometimes I don't notice when it does not work. Thank you!

[ilcato]

The new log already allows you to spot the event. Please, check if it works through the log and then I will add the IFTTT integration.

[iRonin]

I replaced the files and I will let you know whether the problems appear. Checking daily in the logs is cumbersome though.

[ilcato]

Did you configured configure.json?

[iRonin]

Yes, added "doorlocktimeout": 5.

[iRonin]

Is this an error log message:

[2018-3-22 20:34:15] [FibaroHC2] There was a problem setting value to Lock:  41

[ilcato]

Yes.

[iRonin]

Cool! Would you mind adding the IFTTT notification at your convenience? I only realized the lock was not locked 1 hour later.

On 23 Mar 2018, at 06:06, ilcato notifications@github.com wrote:

Yes.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ilcato]

Ok, done. In order to test:

1. replace dist/setFunctions.js
2. configure IFTTT makerkey in config.json

When the anomaly happens you will receive an IFTTT event on your makerkey with event = "LockError" and value1=the device ID in error.

[iRonin]

How about naming the event hbFHC2LockError (or hb_fhc2_lock_error) - it's good practice to have the error code namespaced, WDYT? I'm testing right away!

[ilcato]

Any news?

[iRonin]

Waiting for the lock to malfunction.

[iRonin]

It almost worked today :) IFTTT fault though

[2018-3-29 17:01:52] [FibaroHC2] Sent event:  LockError, to: XXX, for 41

[ilcato]

Are you able to see if the web hook received the complete info (i.e.: the ID of the device)?

[iRonin]

IFTTT does not show these details for failed applets. We have to wait until the next error.

[iRonin]

There was an error today but IFTTT knows nothing about it:

[2018-3-30 10:29:30] [FibaroHC2] Sent event:  LockError, to: XXX, for 41

It would be great if it didn't log maker channel key, unless in the debug mode and then it could log the whole request to IFTTT. The applet in my IFTTT works fine via curl:

curl -H "Content-Type: application/json" -X POST -d '{"value1":"123"}' https://maker.ifttt.com/trigger/LockError/with/key/XXX

[iRonin]

I've got a couple of more errors and none were registered by IFTTT.

[ilcato]

I think it's fixed now. A "?" was missing in the url.

[iRonin]

Updated, testing.

[ilcato]

Ok, I just renamed the IFTTT event name as per your suggestion and added generic IFTTT notifications.

[iRonin]

I already got a notification, cool!

[iRonin]

The event is firing too soon now; see the below log, I've got the timeout set to 5

[2018-4-7 09:38:30] [FibaroHC2] Getting value from device:  24  parameter: Contact Sensor State
[2018-4-7 09:38:30] [FibaroHC2] Setting value to device:  41  parameter: Lock Target State
[2018-4-7 09:38:30] [FibaroHC2] There was a problem setting value to Lock:  41
[2018-4-7 09:38:30] [FibaroHC2] Command:  secure, value: 0, to: 41
[2018-4-7 09:38:31] [FibaroHC2] Sent event:  LockError, to: XXX, for 41
[2018-4-7 09:38:35] [FibaroHC2] Updating value for device:  41  parameter: Lock Current State, value: true
[2018-4-7 09:38:35] [FibaroHC2] Updating value for device:  41  parameter: Lock Target State, value: true

The error event was fired after 1 second. I'll update the code to the latest now.

[ilcato]

The timeout is expressed in millisecond, if you want to set it to 5 seconds you must put a value of "5000". 5 ms doesn't allow to execute the lock command before the check. In the updated version the timeout is expressed in seconds.

[ilcato]

@iRonin, @darrenmcuk, in order to test the last version replace all the dist dir files and restart homebridge. I also change the name of the maker key config param. See the wiki entry. I just tested this version and I'm able to log all the events in a Google Spreadsheet doc via IFTTT.

[darrenmcuk]

Happy to give it a go....

1. Where do I get the files from?
2. Where do I put them on my Raspberry?

Sorry for such basic questions....

[ilcato]

@darrenmcuk

1. the files are here
2. they must be put in a folder on your Raspberry that depends on your setup, but it is always named node_modules/homebridge-fibaro-hc2/dist and can be in one of your lib directories.

Anyway I think that I will publish the current version on npm shortly after some further testing by myself.

@iRonin, please give me a feedback on the LockError side.

Thank you.

[ilcato]

published in 2.0.9

[iRonin]

Something is not right, I should have gotten the notification but didn't, here are the logs:

[2018-4-13 20:39:57] [FibaroHC2] Setting value to device:  47  parameter: Lock Target State
[2018-4-13 20:39:57] [FibaroHC2] Command:  secure, value: 0, to: 47

There was no response from the lock as it was marked as communication error in Fibaro interface.