Callbacks not working - NodeRED

[Alejandrix (Alejandro García Talón)]

Hello,

I have a my Nuki lock controlled with NodeRed, using the node-red-contrib-nuki (node-red-contrib-nuki (node) - Node-RED), wich then I connect to Homeseer. The lock actions work fine, I can lock, unlock, unlacht…

The problem I have is getting the status of the lock using callbacks. I have succesfully registered callbacks in the bridge:
http://192.168.1.56:8080/callback/list?token=T****R gives me:

{
    "callbacks": [
        {
            "id": 0,
            "url": "http://192.168.1.45/nuki"
        },
        {
            "id": 1,
            "url": "http://192.168.1.72/nuki"
        },
        {
            "id": 2,
            "url": "http://192.168.1.45:8080/nuki/17E1C9A2"
        }
    ]
}

192.168.1.56 is the IP of the nuki bridge, and 192.168.1.45 is the IP of the computer running NodeRED.
Then I have this flow:

I haven’t got into parsing the JSON to update device status, just trying to get some response from the bridge when the lock state changes. No matter what I try I dont get any callback from the bridge.

Thanks,

Alex.

EDIT: In the bridge log I see this entries whenever y perform an action on the lock:
{“timestamp”: “2021-08-05T21:37:57+00:00”, “type”: “HTTP-Post”, “nukiId”: “184CA51D”},

Does this means the callbacks are being sent? In that case the error is in the way I’m trying to read the callback? Any suggestions so I can test it rather than using node-red? Is the only method I know.

[Stephan (Stephan Lendl)]

@Alejandrix

EDIT: In the bridge log I see this entries whenever y perform an action on the lock:
{“timestamp”: “2021-08-05T21:37:57+00:00”, “type”: “HTTP-Post”, “nukiId”: “184CA51D”},

Does this means the callbacks are being sent

Yes, this should be the entries for the callbacks.
The payload of the callback is always a JSON in the documented format, so everything should be working for you.

Does Node-Red have any built in tools to test if the “HTTP-in” is receiving requests?

[Alejandrix (Alejandro García Talón)]

That is what Im trying to do, test with node-red the HTTP, with a debug node. If I poll the lock I can get the lockstatus with the debug node. Adding a POST node to receive the callback and then a debug note, but nothing is coming in.
Don’t know what could be wrong, I used the flow from a user in this forum…Node-RED / Redmatic (Homematic) integration listening to callbacks
@ueffchen maybe he can give me a hand… thanks

[ueffchen (uwe w)]

The first thing I can think off is the path.
Are the entries in your callback pointing to the right path?
If you look at your http-in node, you have nuki/17E1C9A2, which gets added to your relative path. In my case that is addons/red. You see that when you look in the http-in node edit window.
In my case, running nodered on a homematic, this would mean: addons/red/nuki/17E1C9A2
What is you relative path for the http-in mode?
You need to make sure that the whole path is entered as callback URL. I don’t have 8080, but it might depend on your redmatic
Can you export your nodered flow and post it here?

[Alejandrix (Alejandro García Talón)]

The callback path is http://192.168.1.45:8080/nuki/17E1C9A2, as shown from the bridge when doing http://192.168.1.56:8080/callback/list?token=T****R

Then, on the node red http-in node I just set as relative path nuki/17E1C9A2. I am running node-red on a windows computer. Maybe I should have a different relative path?

Thanks for your help

[ueffchen (uwe w)]

in my case, the HTTP-in node shows below relative path.

How does yours look?

In my case, that is the complete path from root. I assume that a Nodered installation on a windows PC has a longer path, and I guess that must be added to the callback URL

[christianTF (Christian Fenzl)]

Try to use curl and post any json data to your callback url. This is the easiest way to debug your receiving side.

[Alejandrix (Alejandro García Talón)]

Can you please elaborate? Where do I use the curl? In node red? Thank you.

[christianTF (Christian Fenzl)]

From the shell, e.g.

https://gist.github.com/subfuzion/08c5d85437d5d4f00e58#post-applicationjson

[Alejandrix (Alejandro García Talón)]

Hi,

My callbacks are still not working.

• Receiver side is working fine. Checked node-red with a curl and json data is detected by the receiver.
• The callbacks are set in the bridge: http://192.168.1.9:8080/callback/list?token=T6zROR returns: {“callbacks”: [{“id”: 0, “url”: “http://192.168.1.45:1880/nuki/nuki-bridge/callback-node”}]}
• The log shows callbacks fired with lock actions: {“timestamp”: “2022-03-01T15:34:55+00:00”, “type”: “HTTP-Post”, “nukiId”: “184CA51D”},

Bridge and lock updated to the latest firmware.

But still there is no callback sent.

Any suggestions?

[ueffchen (uwe w)]

can you export your NodeRed flow and post it here?

[jakubkasparek (Jakub K.)]

for me too. please.

[ueffchen (uwe w)]

[{“id”:“447f2b23.ad5774”,“type”:“debug”,“z”:“427fc89b.e34038”,“name”:“Nuki DoorsensorStateName”,“active”:true,“tosidebar”:true,“console”:false,“tostatus”:false,“complete”:“payload.doorsensorStateName”,“targetType”:“msg”,“statusVal”:"",“statusType”:“auto”,“x”:460,“y”:2420,“wires”:[]},{“id”:“ffdccaa1.768fe8”,“type”:“http in”,“z”:“427fc89b.e34038”,“name”:“Nuki HTTP-in”,“url”:“nuki”,“method”:“post”,“upload”:false,“swaggerDoc”:"",“x”:90,“y”:2400,“wires”:[[“3de5525d.a3a98e”,“1a51e3b2.5f8894”,“447f2b23.ad5774”]]},{“id”:“3de5525d.a3a98e”,“type”:“debug”,“z”:“427fc89b.e34038”,“name”:“Nuki StateName”,“active”:true,“tosidebar”:true,“console”:false,“tostatus”:false,“complete”:“payload.stateName”,“targetType”:“msg”,“statusVal”:"",“statusType”:“auto”,“x”:420,“y”:2380,“wires”:[]},{“id”:“1a51e3b2.5f8894”,“type”:“debug”,“z”:“427fc89b.e34038”,“name”:“Nuki”,“active”:true,“tosidebar”:true,“console”:false,“tostatus”:false,“complete”:“payload”,“targetType”:“msg”,“statusVal”:"",“statusType”:“auto”,“x”:390,“y”:2340,“wires”:[]}]

Important is that your Nuki Callback is sending the messages to the right path where your NodeRed is listening

[jakubkasparek (Jakub K.)]

@ueffchen

[{“id”:“447f2b23.ad5774”,“type”:“debug”,“z”:“427fc89b.e34038”,“name”:“Nuki DoorsensorStateName”,“active”:true,“tosidebar”:true,“console”:false,“tostatus”:false,“complete”:“payload.doorsensorStateName”,“targetType”:“msg”,“statusVal”:"",“statusType”:“auto”,“x”:460,“y”:2420,“wires”:[]},{“id”:“ffdccaa1.768fe8”,“type”:“http in”,“z”:“427fc89b.e34038”,“name”:“Nuki HTTP-in”,“url”:“nuki”,“method”:“post”,“upload”:false,“swaggerDoc”:"",“x”:90,“y”:2400,“wires”:[[“3de5525d.a3a98e”,“1a51e3b2.5f8894”,“447f2b23.ad5774”]]},{“id”:“3de5525d.a3a98e”,“type”:“debug”,“z”:“427fc89b.e34038”,“name”:“Nuki StateName”,“active”:true,“tosidebar”:true,“console”:false,“tostatus”:false,“complete”:“payload.stateName”,“targetType”:“msg”,“statusVal”:"",“statusType”:“auto”,“x”:420,“y”:2380,“wires”:[]},{“id”:“1a51e3b2.5f8894”,“type”:“debug”,“z”:“427fc89b.e34038”,“name”:“Nuki”,“active”:true,“tosidebar”:true,“console”:false,“tostatus”:false,“complete”:“payload”,“targetType”:“msg”,“statusVal”:"",“statusType”:“auto”,“x”:390,“y”:2340,“wires”:[]}]

cant import

[ueffchen (uwe w)]

[{"id":"1a51e3b2.5f8894","type":"debug","z":"427fc89b.e34038","name":"Nuki","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":390,"y":2340,"wires":[]},{"id":"ffdccaa1.768fe8","type":"http in","z":"427fc89b.e34038","name":"Nuki HTTP-in","url":"nuki","method":"post","upload":false,"swaggerDoc":"","x":90,"y":2400,"wires":[["3de5525d.a3a98e","1a51e3b2.5f8894","447f2b23.ad5774"]]},{"id":"3de5525d.a3a98e","type":"debug","z":"427fc89b.e34038","name":"Nuki StateName","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload.stateName","targetType":"msg","statusVal":"","statusType":"auto","x":420,"y":2380,"wires":[]},{"id":"447f2b23.ad5774","type":"debug","z":"427fc89b.e34038","name":"Nuki DoorsensorStateName","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload.doorsensorStateName","targetType":"msg","statusVal":"","statusType":"auto","x":460,"y":2420,"wires":[]}]

Try again, looks like something went wrong in the export/paste

[jakubkasparek (Jakub K.)]

thanks. I finally use exec (curl) node. Works fine.
Only i need is state of door senzor (to Homekit)

[ueffchen (uwe w)]

Hi Jakub
I don’t think using frequent curls is a good idea, especially when they go to the SL itself (instead of the bridge, not sure what you curl, maybe you can explain that). Two reasons:
you will not get a message from the SL/bridge, in between two curls, if the door gets opened
if you do too frequent curls, i.e every minute, then the SL battery will drain if you ping the SL directly
I think it’s smarter to use the SL callback function, because that will send a message once the state changes.
Or am I wrong?

[jakubkasparek (Jakub K.)]

@ueffchen , thanks for this info. I called to url of bridge. Not straight to senzor or locker.
But bridge change status very late, have 10 second delay. It is unusable for me.

Can you help me to create better flow?

[ueffchen (uwe w)]

Hi @jakubkasparek , one thing to note: also the callback mechanism of the SL doesn’t work in realtime. I cannot check today, but I think it has a few seconds gap. But still, the advantage is that you don’t have to poll the SL/bridge, instead it pushes the messages. If you need something in realtime, then I think a classical window/door sensor with a magnet , connected to a smarthome, is needed. What is your application?

[ueffchen (uwe w)]

I checked, the callback messages from SL2 are issued with ~10 seconds delay. For my application this is not critical. I am running a presence detection afterwards, which sends a telegram message if the door has been opened and NO known smartphone is detected on Wifi. As you can imagine, this is a queue of non-realtime events :). If you have something time-critical, ie. switching on a light when the door opens, then you would need a window/door sensor (not the one of SL1/2) in my view.