Can`t select a NUKI in Dropdown about node-red-contrib-nuki

[mabunixda]

@ctr49 thanks for finding this issue. i already created a new version and this is available on npmjs.org and also flows.nodered.org

[mabunixda]

Did you publish the workflow? This just happens after first deployment

[nachbelichtet]

Same here. The node says "got nuki list" but there is no device to select. I've tried multiple depolyments, flows etc. Node Red 1.1.2 and NPM 6.14.7

[nymJ]

I don't know what it was, but I'm fine now. I have restarted and deployed several times. Suddenly it worked.

[akowasch]

I’ve experienced the same problem. I found out that the Bride knew the Smart Lock, but was not paired with it. It lost the connection when activating the Nuki Bridge API. After the renewed pairing and a node-RED deployment, everything ran as desired.

[mabunixda]

The Connection code must be rewritten - that's just some hack which requires some background information and is not easy to use

[Armageddit]

maby wrong API keye?
don't use Web API!

[mabunixda]

yeah a rewrite of this code is mandatory!

[djiwondee]

Same issue since a couple of weeks

Have also double checked the API-Token of the bridge, and dropped all nuki nodes (incl. config node) from my flow setup. After re-creation issue still exists.

NUKI FirmwareVersion: 133897
NUKI HardwareVersion: 2817
Node-red 2.0.6
node-red-contrib-nuki 1.0.4
nodeJS Version v12.22.7
Running on Raspberry Debian 5.10.63-v7l+

[mabunixda]

When you downgrade to version 1.0.3 - still the same outcome?

[mabunixda]

you might try adding this flow and call your nodered instance by

http://<nodered>/bridge/info and http://<nodered>/bridge/log to get more details about your bridge - if it is connected to nukis at all.

On the first call you should get a response like this one

{
  "bridgeType": 1,
  "ids": {
    "hardwareId": 234189529,
    "serverId": 291317518
  },
  "versions": {
    "firmwareVersion": "1.19.4",
    "wifiFirmwareVersion": "1.2.0"
  },
  "uptime": 1024606,
  "currentTime": "2021-12-01T10:26:12+00:00",
  "serverConnected": true,
  "scanResults": [
    {
      "deviceType": 0,
      "nukiId": 123456,
      "name": "Nuki_123456",
      "rssi": -79,
      "paired": true
    },
    {
      "deviceType": 0,
      "nukiId": 1234567,
      "name": "Nuki_1234567",
      "rssi": -63,
      "paired": true
    }
  ]
}

Actual Bridge flow:

[
    {
        "id": "3e04f3d52d738c01",
        "type": "tab",
        "label": "Nuki Bridge",
        "disabled": false,
        "info": "",
        "env": []
    },
    {
        "id": "3e390185adc93fdf",
        "type": `"nuki-bridge-control",`
        "z": "3e04f3d52d738c01",
        "name": "192.168.1.100:8080",
        "bridge": "81f5214b.bd586",
        "x": 890,
        "y": 320,
        "wires": [
            [
                "0dd9f9ee4a87e20b",
                "9d010bf18a9a59cd"
            ]
        ]
    },
    {
        "id": "0dd9f9ee4a87e20b",
        "type": "debug",
        "z": "3e04f3d52d738c01",
        "name": "",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "true",
        "x": 1120,
        "y": 320,
        "wires": []
    },
    {
        "id": "c91781a94e30738e",
        "type": "function",
        "z": "3e04f3d52d738c01",
        "name": "",
        "func": "msg.topic = msg.req.params.action.toLowerCase()\nreturn msg;",
        "outputs": 1,
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [],
        "x": 650,
        "y": 320,
        "wires": [
            [
                "3e390185adc93fdf",
                "c8d7dff6cdf6f99a"
            ]
        ]
    },
    {
        "id": "4bc262b6855cc1a3",
        "type": "http in",
        "z": "3e04f3d52d738c01",
        "name": "",
        "url": "/bridge/:action",
        "method": "get",
        "upload": false,
        "swaggerDoc": "",
        "x": 340,
        "y": 320,
        "wires": [
            [
                "c91781a94e30738e"
            ]
        ]
    },
    {
        "id": "9d010bf18a9a59cd",
        "type": "http response",
        "z": "3e04f3d52d738c01",
        "name": "",
        "statusCode": "",
        "headers": {
            "Content-Type": "application/json"
        },
        "x": 1110,
        "y": 360,
        "wires": []
    },
    {
        "id": "c8d7dff6cdf6f99a",
        "type": "debug",
        "z": "3e04f3d52d738c01",
        "name": "",
        "active": false,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "true",
        "x": 850,
        "y": 240,
        "wires": []
    },
    {
        "id": "81f5214b.bd586",
        "type": "nuki-bridge",
        "host": "192.168.1.100",
        "port": "8080"
    }
]

[djiwondee]

When you downgrade to version 1.0.3 - still the same outcome?

I've just upgraded to 1.0.4 because with 1.0.3 same behavior.

[mabunixda]

Does the nuki bridge know about your nukis ?

[djiwondee]

Does the nuki bridge know about your nukis ?

I assume, yes. If helpful, the NUKI bridge and Lock are working well (except geofence - but this is not relevant here ;-). I also have a flow calling the cloud API, which provides details about the lock connected to the bridge:

[djiwondee]

Just an idea: does your code have a problem with "German umlauts"?

@nachbelichtet what is your lock name?

[mabunixda]

Well i actual have the same naming on 1 of my nukis ;-) and this is working...
the communication is setup on the nukiId - not the actual name.

Did you try to use the nuki bridge node to get information about the actual nuki bridge configuration?

[djiwondee]

Did you try to use the nuki bridge node to get information about the actual nuki bridge configuration?

my config info above is not coming from your bridge node flow, since it is still not working. It is coming from my nuki.io web API call.

[mabunixda]

i know, but can you also get the output from the bridge with a msg { topc: "info" } to the bridge node?

[nachbelichtet]

Just an idea: does your code have a problem with "German umlauts"?

@nachbelichtet what is your lock name?

Sorry for not getting back to you sooner. I've also tried it with other names, and the lock name "Eingang" without any success. But I gave up on this and handle it now directly via Home Assistant.

Markus

[djiwondee]

i know, but can you also get the output from the bridge with a msg { topc: "info" } to the bridge node?

No, there is no output coming from the request- The request gets stalled.

[djiwondee]

Hi @mabunixda ,

that's interesting! I've just upgraded my raspi to the latest release state using apt-get update...

After a reboot of the raspi, the NUKI lock appears again in the dialog as expected:

...and with that the functionality comes back again. I've recognized this entry in the node-red-log

Don't know, what has been changed on my Nuki bridge (except using the latest iOS beta of the the Nuki app since it brings well working Geofencing back)

[mabunixda]

Ok, @djiwondee just wondering if it was now the update/upgrade, the restart of the raspi or even just the restart of the node-red installation. I do not think that geofencing logic is within the bridge and made any updates, I think this is more related to the app.

[djiwondee]

if it was now the update/upgrade, the restart of the raspi or even just the restart of the node-red installation

Unfortunately I can only speculate, however its is running again.

Btw.: Do you have plans (and time) to enhance the API? I'm especially interested in to get the doorstate from the bridge. If I understand it right, you don't access the nuki.io cloud API? In my setup I get the door state from that and there are some seconds latency until the call back send the doorstate.

I do not think that geofencing logic is within the bridge and made any updates, I think this is more related to the app.

Totally agree! It was just a side note. "The hardware is alive and it is evil" ;-) I wouldn't wonder if NUKI has also made some changes...

[mabunixda]

I have access to the nuki.io cloud API ... but i did not implement/use it in this node code. Does it make sense to implement also the web API in this node?

At the moment the doorstate is not implement within the library that is used. The only way is to implement this callback from #36 - which I gonna give it one more run/try .

Also the V3 Pro seems to have some different implementation

[djiwondee]

Does it make sense to implement also the web API in this node?

This would be helpful to simplify such a node setup:

I use exactly this setup to get the push notification from the Nuki.io API in case the door gets opened/closed. But I wonder if the door state is also available early on the bridge, rather than the Nuki.io API

[mabunixda]

I ran now into the same problem - it seems that the bridge can hangup sometimes. I also experienced in this time, that the Web Interface ( web.nuki.io ) was not able to interact with the actual bridge.

May be a try-retry loop/integration will fix this

[mabunixda]

with the latest commit in the alpha branch also the actual callbacks are working 👍

[eddriesen]

Hmmm, back to this issue in 1.1.0. Don't know if related. The "nuki bridge in" works fine, the nuki-lock control doesnt.
Doublechecked tokens and dit some tests;

Note the second command. Dit a hello world test and some obvious hits/misses

[mabunixda]

and there are not/any errors on node-red at this point?

[eddriesen]

and there are not/any errors on node-red at this point?

[djiwondee]

Same at my setup after upgrade to release 1.1.0

Delete and recreate nuki control in node hasn't solved the problem.

Node-red restart and raspberry reboot hasn't solved the problem as well

[mabunixda]

seems that there was no response from the bridge :(

[djiwondee]

I wonder because the other nuki bridge in node is working quite well with exactly the same properties. Is there a way for debug?

[zen85]

i have got the exact same problem here... i also restarted the bridge and the raspberry. but unfortunatly it does not show up and shows the exact same as [eddriesen] 's screenshot.

Did anybody find out what can help here? if i sent "info" with msg.topic to the bridge the looks show up...

[Phalynx]

Same here. The umlaut should not be an issue, as I have another Bridge with the name "Fahrräder" without any issues.
Its the the bridge with the Nuki named "Haustür" which will fail with the error already described. The bridge connection is okey, I can handle the Nuki without WIFI and Bluetooth.

[mabunixda]

Can this be some encoding mistakes? 🤔

[Phalynx]

Can this be some encoding mistakes? 🤔

I doubt this. "Fahrräder" works, "Haustür" and "Haustuer" (I renamed the device for a test) on another bridge does not.

I switched back to 1.0.3 and it does not work on that version either, but it worked few weeks ago. The Nuki named "Haustür" worked since 2019 in the current config.

[Phalynx]

Update, it works now.
I'm not sure what was the issue, I've just completely removed the nuki nodes / configuration and created all from scratch.

[mabunixda]

Yeah that is of course the behavior of this issue: it is not reproducable and so hard to fix 👎

[eddriesen]

Yeah that is of course the behavior of this issue: it is not reproducable and so hard to fix 👎

If I can assist in anything; I still have that problem (addon 1.1.0, NR 2.2.2)

[ctr49]

I also have the same problem. The XHR (or standalone request) to http://node-red:1880/admin/nuki-bridge/list?id=xxx fails with a 404. I have recreated the bridge in node-red several times to the same extent. The token is valid and the bridge node also returns valid responses to list and info topics - but the list command towards the nuki-bridge url node doesn't work.

It's like the function is never called. If it was it should also return an empty json when specifying no ID and and actual error message when specifying a wrong ID ... but nothing like that happens.

 RED.httpNode.get('/nuki-bridge/list', function(req, res) {
    if (!req.query.id) {
      return res.json('');
    }

    const configNode = RED.nodes.getNode(req.query.id);
    let result = {
      state: 'error',
      msg: 'bridge not connected',
      items: [],
    };

[ctr49]

I could identify the problem.
the /list request should go to node-red's httpNodeRoot, but it actually goes to httpAdminRoot which obviously doesn't know object.
I suppose it's working fine for all folks that use httpRoot in settings.js (instead of separate httpNodeRoot and httpAdminRoot

see #43 for a potential solution

[djiwondee]

@mabunixda Just installed 1.1.1 and it is working again! Thanks! Also special Thanks to @ctr49 for his investigation!