Nuki Card with Callback support (supports both Lock & Opener, it replaces the official integration)

Hello, I have funny issue that sensor.nuki_lock_fw_version is presenting lower version of the firmware that is actually has.
And also, Buttons on the card lock/unlock dont work.
I have multiple times reseted Nuki to the factory settings, but still the same…
Here are my logs

image

Issue these commands from a terminal and post the results here:

curl -X GET ‘http://bridge-ip:8080/list?token=xxxxx’

curl -X GET ‘http://bridge-ip:8080/info?token=xxxxx’

Buttons are created by the lock template, it’s a standard HA component, so if they don’t work you have other issues, it doesn’t depend on the code.

You mean the Nuki bridge or the lock? In any case, I don’t think the Nuki has a problem.

1 Like

here it is

[
    {
        "deviceType": 2,
        "nukiId": 685954282,
        "name": "",
        "firmwareVersion": "1.6.4",
        "lastKnownState": {
            "mode": 2,
            "state": 1,
            "stateName": "online",
            "batteryCritical": false,
            "timestamp": "2021-08-28T15:56:30+00:00"
        }
    }
]

and second call:

{
    "bridgeType": 1,
    "ids": {
        "hardwareId": 703288811,
        "serverId": 702741587
    },
    "versions": {
        "firmwareVersion": "2.9.3",
        "wifiFirmwareVersion": "2.2.0"
    },
    "uptime": 3747,
    "currentTime": "2021-08-28T16:58:44+00:00",
    "wlanConnected": true,
    "serverConnected": true,
    "scanResults": [
        {
            "deviceType": 2,
            "nukiId": 685954282,
            "name": "Nuki_Opener_28E2D4EA",
            "rssi": -63,
            "paired": true
        },
        {
            "deviceType": 0,
            "nukiId": 705302436,
            "name": "Nuki_2A0A0FA4",
            "rssi": -74,
            "paired": false
        }
    ]
}

Well, I don;t know why my buttons doesnt work, but I believe when I resolve this inconsistency regarding differnt firmwares displayed in HA and in my Nuki Mobile app, then it will work lock/unlock commands from HA…

I know what the problem is: you have the opener in the list before the lock. So you first configured the opener in the nuki mobile app, then added the lock.

Nuki Card doesn’t support the Opener yet, and since I developed it using only the lock, when I get the values, I expect the lock to appear in the list first.

The strange thing is that the output of the list command only lists your opener with fw 1.6.4, and the lock is not present. You should fix that.

I advice to: delete everything from the Nuki App, and reconfigure, first the lock, and if everything works ok, Nuki Card included, then add the opener to the system.

Yes, that was a case. So first the lock, then bridge and the opener? right?

Yes, but the opener will not be supported in this version. Configure the opener only at the end, when everything else is working.

It’s a limitation of my code, I’m sorry for this, but didn’t take into account the opener at the beginning.

Now I dont have any info regarding firmware

here is my response:
/info

{
    "bridgeType": 1,
    "ids": {
        "hardwareId": 703288811,
        "serverId": 0
    },
    "versions": {
        "firmwareVersion": "2.9.3",
        "wifiFirmwareVersion": "2.2.0"
    },
    "uptime": 11,
    "currentTime": "2021-08-28T18:31:30+00:00",
    "wlanConnected": true,
    "serverConnected": false,
    "scanResults": [
        {
            "deviceType": 2,
            "nukiId": 685954282,
            "name": "Nuki_Opener_28E2D4EA",
            "rssi": -70,
            "paired": false
        },
        {
            "deviceType": 0,
            "nukiId": 705302436,
            "name": "Nuki_2A0A0FA4",
            "rssi": -78,
            "paired": true
        }
    ]
}

/list endpoint returns just empty response status 200OK:

[]

I erased everything, and I added just lock to my bridge

here are the logs error when I try to lock/unlock still present:

You still have the opener configured. As you can see from the output of info.

The /list command MUST give an output, otherwise you have a problem. Make sure the bridge answers to the list command.

Socket errors, are you sure your HA setup works? Try from a terminal the /info and /list commands, they must work correctly, and the opener should not appear in the responses.

Nope, I’m trying through postman…I dont know what should else I do, to remove fu**ing opener…
It shows me in the app that opener is not connected…

First: calm down, otherwise you won’t solve any fu**ing thing, ok? :slight_smile:

Second: you must REMOVE the opener through the Nuki mobile app, the OPENER must not be present in the Nuki system. The Nuki Card merely queries the bridge to have info on the Nuki system YOU have setup. So when I say remove the Opener you must UNINSTALL it from the Nuki system through the app. Ok?

If you use postman instead of terminal, like I told you to do, probably postman sends both commands at the same time: the bridge only supports one command in the same second. So please do as I told you. Use curl and the terminal.

1 Like

Thanks @alexdelprete now it works :slight_smile: Without you, I wouldn’t be able to solve this challenge (rather than “problem”) :smiley:
Many thanks!

No problem Stefan. Glad it’s working for you now. Sorry for the troubles due to the opener not being supported. Now if you add it to the system, I think it should work because it would be at the second place in the /list command. :slight_smile:

Unfortunately, it’s on the first place again :slight_smile: I dont know why…
maybe you can first order by deviceType (0 is for smart lock, 2 is for opener), and that’s how you can fix this little bug

it’s positional, I take first record of the json structure. :slight_smile:

Like I said, opener is not supported. But it’s the first time that I see the opener appearing before the lock.

1 Like

I know, but instead to use first element, you can take all elements, order by deviceType and take the first element, that’s how I would do it. In that case you are certain that you will be always taking deviceType 0 (if exists in that aub-object) and avoid my case…

Don’t worry, I know how to do it. :slight_smile:

When I add the opener support, I’ll take everything, it won’t be positional. :wink:

2 Likes

When can we expect that improvement? Maybe while you are writing a new i tegration for door lock and opener, just to put quick fix for thos my specific case?
Can I assist you somehow? I can maybe create a pull request…

First of all, try to understand why the /list command in your case gives a strange result: I expected both the lock and the opener in the output, but you showed a json output that only listed the opener. It’s not normal.

Check the /list output provided by @madface, that looks more complete, and much like I expected.

I will adjust the json parsing based on his output, it looks more complete.

After I fix the json parsing, I need to know what actions/commands to implement for the opener…

1 Like

Teaser for v11 beta…:wink:

cc: @madface @stefancvetkovic @beardedconti @floo @joerg @saeris @jero537 @Harry2

7 Likes