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

Share your Projects!
, , ,
651

Installed V10.1 this morning.

WARNING (MainThread) [homeassistant.components.script.nuki_bridge_polling_queue] nuki_bridge_polling_queue: Already running

This one is definitly gone. I have a few others, two of them are errors.

TemplateError('UndefinedError: None has no element 0') while processing template 'Template("{{ state_attr('sensor.nuki_bridge_endpoint_info','scanResults')[0]['paired'] if states('sensor.nuki_bridge_endpoint_info') != "unknown" }}")' for attribute '_state' in entity 'binary_sensor.nuki_bridge_lock_bt_state'
TemplateError('UndefinedError: None has no element 0') while processing template 'Template("{{ state_attr('sensor.nuki_bridge_endpoint_info','scanResults')[0]['name'] if states('sensor.nuki_bridge_endpoint_info') != "unknown" }}")' for attribute '_attr_state' in entity 'sensor.nuki_device_name'
TemplateError('UndefinedError: None has no element 0') while processing template 'Template("{{ state_attr('sensor.nuki_bridge_endpoint_info','scanResults')[0]['rssi'] if states('sensor.nuki_bridge_endpoint_info') != "unknown" }}")' for attribute '_attr_state' in entity 'sensor.nuki_bridge_lock_bt_rssi'
Error fetching data: http://10.10.11.138:8080/callback/list?&token=abcdefgh failed with
Error fetching data: http://10.10.11.138:8080/info?&token=abcdefgh failed with
Error fetching data: http://10.10.11.138:8080/list?&token=abcdefgh failed with

Maybe it`s only because there’s no answer from the bridge. Shame on me i forgot to disable the official integration, afaik this one is polling and maybe they polled the same time. Happened only 3 times too.
I have disabled it now and report tomorrow if the errors are still there. But i don’t think they affect the function, every time i use the card its working fine (and by the way, there are plenty of other integrations that throw an error or warning sometimes :wink: )

The times for the sensors are upside down for me (compared to joerg), about 1 second after the last turn of the lock and about 3 for the door sensor. But that is quite usable, no problem.

EDIT:
Official Integration is turned off, no errors in the last 10 hours. The Code works fine :slight_smile:

652

No need to apologise!

I run my instance on a Raspberry Pi 4 4Gb, via SSD.

I’ve just installed V10.1 and all seems good, everything is working. New warning in the log after the restart, which I’m guessing is along the same lines as the REST warnings from V10 and before. :slight_smile:

2021-08-04 20:44:52 WARNING (MainThread) [homeassistant.components.sensor] Platform rest not ready yet: The request to ':///' is missing either an 'http://' or 'https://' protocol.; Retrying in background in 30 seconds
2021-08-04 20:44:52 WARNING (MainThread) [homeassistant.components.sensor] Platform rest not ready yet: The request to ':///' is missing either an 'http://' or 'https://' protocol.; Retrying in background in 30 seconds
2021-08-04 20:44:52 WARNING (MainThread) [homeassistant.components.sensor] Platform rest not ready yet: The request to ':///' is missing either an 'http://' or 'https://' protocol.; Retrying in background in 30 seconds
653

Shame on you, still using the official one? Joking, I know you have it probably for the opener…but be aware that if they poll at the same time, the bridge can reboot. :slight_smile:

Well, I spent countless night hours to eliminate those errors, because for me it means it’s not yet as I wanted it to be (I don’t want to use the word perfect obviously, because it will never be). It’s not easy for me to say I’m satisfied of something…good enough is not good enough for me. :slight_smile:

Now I’m almost satisfied…almost…

654

I guessed from those warnings you ran on a Pi. :slight_smile:

I was running HA on a RPi 4 SSD too, I loved it, but after a couple of months it started to choke…moved everything to an old NUC I had lying around…the best decision I ever made: HA runs beautifully on NUC+SSD.

Anyways, happy it’s working for you, and you can safely ignore those warnings. They happen only at restart and if the system is a little slow.

655

Mike,

please post an output of /list and /info commands on your system, I’m starting to look at the Opener support and want to understand first how much there’s to change. Thanks. :slight_smile:

656

Here we go:

/list:

[{"deviceType": 0, "nukiId": 12345678, "name": "Zuhause", "firmwareVersion": "2.10.8", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 82, "doorsensorState": 2, "doorsensorStateName": "door closed", "timestamp": "2021-08-05T04:42:36+00:00"}}, {"deviceType": 2, "nukiId": 12345678, "name": "Opener", "firmwareVersion": "1.6.4", "lastKnownState": {"mode": 2, "state": 1, "stateName": "online", "batteryCritical": false, "ringactionTimestamp": "2021-08-04T18:00:48+00:00", "ringactionState": false, "timestamp": "2021-08-04T19:16:32+00:00"}}]

and /info:

{"bridgeType": 1, "ids": {"hardwareId": 987654321, "serverId": 12341234}, "versions": {"firmwareVersion": "2.9.3", "wifiFirmwareVersion": "2.2.0"}, "uptime": 38490, "currentTime": "2021-08-05T05:58:13+00:00", "wlanConnected": true, "serverConnected": true, "scanResults": [{"deviceType": 0, "nukiId": 123456768, "name": "Nuki_1D4705AE", "rssi": -71, "paired": true}, {"deviceType": 2, "nukiId": 12345678, "name": "Nuki_Opener_1DDE8B53", "rssi": -65, "paired": true}]}
657

Ok, thanks a lot.

Now I need to understand what are the user requirements, I mean what exactly you’d like the integration to provide, besides the system info about the opener. In terms of functionality that is. Try to be as more generic as possible, consider the several use-cases because not everybody has the same requirements as you. :slight_smile:

If other opener users want to contribute, please provide your comments in the discussion with Mike. Thanks.

Alessandro

658

Hi Alessandro,

no problem, thank you.
The main goal for me is to get rid of the nuki app on my smartphone. In relation to the opener this does the following:
Unlatching the external gate so you can push it open (in german it’s called ‘der summer’, don’t know how this is called in english). This is surely self explaining.
But pulling out the phone takes as much time as pulling out the key. The Opener has a function ring to open. When enabled, it unlocks the external gate when you ring the doorbell. The smartphone app has an automation when you enter your geofence it automatically starts ring to open.
So in general that’s what the integration should provide i think. Open the external gate (the summer :wink: ) and enable/disable ring to open.

Now let me explain what is my wish to go further.
The smartphone app has also a function to open the nuki lock if the bluetooth of the smartphone is detectet. So in theoretically you come at home, ring the doorbell, the opener opens (lock to open was active) and go to your apartement door and nuki opens the house door, after the ring you can go straight inside your appartment. But in real live you often wait before your house door and wait till it opens, sometimes more then 30 seconds. Your neighbours must think why is the idiot waiting before his door :wink: .
So i searched for a way to open the door when i ring the doorbell. If nuki submits the ringing it would be fine, but i don’t know if its doing this in a callback. But with the /list command it submits the last time of the doorbellring, if i had this as a sensor i would write an automation like:

if doorbell rang in the last 3 seconds and ring to open is active unlatch nuki lock (with some conditions to make it safe).

That would be me specific use case. But i don’t think this should be part of the integration because this use case is slightly different for many people. But what all need is unlatch the opener (then the external gate can be opened), unlock (then ring to open starts) or sometimes lock (ring to open ist disabled). Normally there is set a counter in for the ring to open which disables it after x minutes, if this could be set it would be nice but this is only done once time so herefore the official app could be used.

Let me know what you think about.

Mike

EDIT: changed to external gate / house door vocabulary so everybody understands me :wink: .

659

It’s called unlatching, so not only the lock “turns the key” but it gives it that extra half turn that unlatches the door and it opens up so you can walk straight through it. :slight_smile:

But I thought the opener was to be connected to an external gate, either through the intercom or through a relay, so that when somebody rang the external intercom, the opener detected the ring and it unlocked the external gate. Or if no intercom, connect it to the gate’s relay. Did I get it right?

660

Dear friends/nuki card users, a great news: @balloob just fixed the very annoying problem we had with templates in packages: Packages to support config platforms by balloob · Pull Request #54085 · home-assistant/core (github.com)

I’m very tempted now to go back to the old version of the Nuki Card, because I liked that version stylistically. I know that now the automation is working fine…but I’ll do it sooner or later. Maybe after the vacations.

Thanks Paulus. :slight_smile:

1 Like
661

Hey Ale, great job. Never setup an integration as fast as yours. One question is left: I couldn't find the nuki_card_callback_languages.json anywhere. The file is empty in my package_dir now. Did I miss anything? THX, kind regards and a nice vacation. Peter

662

Peter, sorry, it was a leftover in the instructions, I removed that file in v9.0, check the changelog:

v9.0 eliminated localization support in code, leveraging HA device_class so translation of status strings is automatically managed by HA (please delete the json file). Introduced two new input_select to configure the lock and unlock actions: you can decide what actions are executed when you press the lock/unlock button. Sensor names have changed, please update the lovecard code.

Sorry for that, I edited the initial post now.

The objective was exactly having new users up and running very quickly, glad it worked out. :slight_smile:

663

The opener is connected through several wires with the internal intercom where you can push a button to open the house door and which has the doorbell or is connected to the doorbell. To open it starts the same function as when you press the button to open/unlactch to door of the house (and because it’s connected it detects the ringing).
On the external intercom and the house door there is nothing of the opener.
Did i understand the question right and explained it ok?

Mike

664

Yes, that’s what I knew about the opener, but you wrote this and I got confused:

In relation to the opener this does the following:
Unlocking the door of the house so you can push it open

You meant the external gate, not the door of the house, right?

665

Ok, let it call external gate. The main door that is first opened to get to your appartement. (In German the building is called ‘das Haus’ and the habitat, the rooms in that you live is ‘die wohnung’) What i meant by house door ist the main door of the building where you leave to the street. I will it call external gate in future :wink: .

666

Grazie for the quick response Ale.

667

Thank you…communication and words are very important in order to understand each other. Sorry if I didn’t get it.So nuki_opener=external gate, nuki_lock=house door. :slight_smile:

668

Di nulla Peter. :slight_smile:

669 
{{ 'on' if states('input_text.nuki_bridge_callback_list')|from_json|count == 1 else 'off' }}
{% else %}
off
{% endif %}")' for attribute '_state' in entity 'binary_sensor.nuki_bridge_callback
Did I do anything wrong?```
670

Missing the first if?

          {% if states('sensor.nuki_bridge_callback_list') != 'unknown' and states('input_text.nuki_bridge_callback_list')|count > 0 %}
            {{ 'on' if states('input_text.nuki_bridge_callback_list')|from_json|count == 1 else 'off' }}
          {% else %}
            off
          {% endif %}

What are you trying to do?