Better MQTT Auto. Discovery for Home Assistant about nuki_hub HOT 37 CLOSED

I believe that MQTT discovery payloads can be improved a bit (based on my experience implementing similar stuff):

1. I see that you use device name to generate entity names, by adding prefixes to it, like name + "bluetooth signal strength". Instead, you can set name to "Bluetooth signal strength" and additionally generate object_id field using uidString. In this case, HASS will use object_id to generate entity ID, and it won't depend of device name (which is mutable) and entity name will be short but still linked to the correct device entity
2. I've got better results by using "optimistic": true mode, because, when Nuki and ESP32 aren't fast enough in connecting/executing/pushing state back, you can experience entity state flickering as HASS expects nearly immediate broadcast of updated status.
3. You generate JSONs as strings by concatenation, is there a reason for not using ArduinoJson library for that? Size constraints maybe? The library is small and handy and improves code readability and maintenance a lot

from nuki_hub.

Thank you for your feedback. My point is more about the fact that the lock will be seen as locked for a few seconds and may go back to its real state (or not if the publishing fails at that point). So, I am not sure if it will help for the "flickering state" issue. That could also be an issue if you have other automations that would trigger based on this "locked" state (a for: could help in this case). But indeed, I also have a few stability and connection issues here and there with my ESP32 so I will try it, knowing the potential side-effects of this option.

from nuki_hub.

You were a Nuki Card user right? ;)

There were template examples in that thread's OP, anyway, here's one very simple and basic with icon colors reflecting the state, and also the action for the lock based on current state:

Since I migrated to Mushroom cards, I created my personal lock card based on Mushroom Template Card that integrates the status of the lock and the door, plus battery and RSSI values, plus the buttons for Open and Unlatch:

And here's the code for that:

type: custom:stack-in-card
cards:
  - type: custom:mushroom-template-card
    layout: horizontal
    primary: >
      {% set lock_name = state_attr('lock.portoncino','friendly_name') %} {% if
      is_state('lock.portoncino','unlocked') and
      is_state('binary_sensor.portoncino_door_sensor','off') %}
        {{ lock_name }} | door closed & unlocked
      {% elif is_state('lock.portoncino','locked') and
      is_state('binary_sensor.portoncino_door_sensor','off') %}
        {{ lock_name }} | door closed & locked
      {% elif is_state('lock.portoncino','unlocked') and
      is_state('binary_sensor.portoncino_door_sensor','on') %}
        {{ lock_name }} | door open & unlocked
      {% else %}
        {{ lock_name }} | door state unknown!
      {% endif%}
    secondary: >
      {% set battery_level = states('sensor.portoncino_battery_level') | int |
      round(0) %} {% set bt_rssi_level =
      states('sensor.portoncino_bluetooth_signal_strength') | int | round(0) %}
      {% set wifi_rssi_level = states('sensor.portoncino_wifi_signal_strength')
      | int | round(0) %}
        Battery: {{ battery_level }}% | BT: {{ bt_rssi_level }}db | WiFi: {{ wifi_rssi_level }}db
    icon: >
      {% if is_state('lock.portoncino','unlocked') and
      is_state('binary_sensor.portoncino_door_sensor','off') %}
        mdi:door-closed
      {% elif is_state('lock.portoncino','locked') and
      is_state('binary_sensor.portoncino_door_sensor','off') %}
        mdi:door-closed-lock
      {% elif is_state('lock.portoncino','unlocked') and
      is_state('binary_sensor.portoncino_door_sensor','on') %}
        mdi:door-open
      {% endif%}
    icon_color: >
      {% if is_state('lock.portoncino','locked') and
      is_state('binary_sensor.portoncino_door_sensor','off') %}
        green
      {% elif is_state('lock.portoncino','unlocked') and
      is_state('binary_sensor.portoncino_door_sensor','off') %}
        yellow
      {% elif is_state('lock.portoncino','unlocked') and
      is_state('binary_sensor.portoncino_door_sensor','on') %} %}
        red
      {% endif%}
    badge_icon: >
      {% set battery_level = states('sensor.portoncino_battery_level') | int |
      round(0) %} {% if battery_level < 80 %}
        mdi:battery-{{ battery_level }}
      {% elif battery_level < 60 %}
        mdi:battery-alert-variant-outline
      {% else %} {% endif %}
    badge_color: >
      {% set battery_level = states('sensor.portoncino_battery_level')  | int |
      round(0) %} {% if battery_level < 80 %}
        orange
      {% elif battery_level < 60 %}
        red
      {% else %}
        green
      {% endif %}
    tap_action:
      action: none
    card_mod:
      style: |
        ha-card {
          background: none;
          box-shadow: none;
        }
  - type: custom:mushroom-lock-card
    entity: lock.portoncino
    primary_info: none
    secondary_info: none
    icon_type: none
    layout: vertical
    card_mod:
      style: |
        ha-card {
          background: none;
          box-shadow: none;
        }

from nuki_hub.

For instance, if the lock is jammed, HA will think the lock is locked but it will stay open

But, after the lock operation, Nuki_hub will publish the actual state, right? Otherwise, when "optimistic": false I see that Lock state is being changed to unlocked -> locked -> unlocked -> locked, because HA expects immediate response with the new status of lock, but Nuki_hub + Nuki aren't that fast to immediately apply new state

which is critical from a security point of view

Heh, I personally don't really think that any casual setup of HA + Nuki + whatever can be considered as more "secure" than just a lock. Convenient - yes, but not secure

from nuki_hub.

Hi,

noticed and some are already implemented. It's very tedious to generate the home assistant JSON in C++.

Which of the sensors and switches are most important to add?

from nuki_hub.

Not sure if it works, but there appears to be a library to help with that.

Edit: I read up a bit on the library and it appears to do more than just generate the autodiscovery topics. Probably not to useful then.

from nuki_hub.

Hi, for me personal is the most import the lock/doorSensorState.

from nuki_hub.

Yes the door sensor makes a lot of sense. I've added it in release 5.11.

from nuki_hub.

Bringing over the various configuration switches would be nice in the long run. Also some diagnostic sensors like uptime (to detect restarts) and #33,

from nuki_hub.

I believe that MQTT discovery payloads can be improved a bit (based on my experience implementing similar stuff):

@kvj your knowledge on Nuki APIs and HA could be really valuable if you decide to contribute to this project. I just received some M5AtomU and M5AtomLite to test. I hope we can finally get rid of the Nuki Bridge thanks to the work of @technyon. :)

from nuki_hub.

2. I've got better results by using "optimistic": true mode, because, when Nuki and ESP32 aren't fast enough in connecting/executing/pushing state back, you can experience entity state flickering as HASS expects nearly immediate broadcast of updated status.

I don't think using "optimistic": true is something safe, especially for the state of the lock. Lots of things can go wrong when you request the locking of the lock. For instance, if the lock is jammed, HA will think the lock is locked but it will stay open, which is critical from a security point of view.

from nuki_hub.

I don't think using "optimistic": true is something safe

It has been a recommended setting by Nuki dev team when I was debugging some issues with callbacks.

from nuki_hub.

Hello, I have integrated the lock with MQTT autodiscovery but I can't find any sensor on the lock status (locked, unlocked).
Am I doing something wrong? Thank you

from nuki_hub.

ello, I have integrated the lock with MQTT autodiscovery but I can't find any sensor on the lock status (locked, unlocked).

Ciao. Did you check the MQTT topics for autodiscovery? You should have a homeassistant topic and under that, a serial number representing the lock...expand it and you should see a json string with all the values of the sensors.

Like this (1bfxxxx is the id of my nuki lock):

Once you see those, go in HA integrations and check the MQTT integration, click on the devices:

Then click the name of the lock (mine is Portoncino):

And once you click on the lock, the device page should open with all the sensors:

from nuki_hub.

Forgive me, how can I see this information? Do I have to use a particular app? Thank you

from nuki_hub.

MQTT Explorer

from nuki_hub.

I'll try to propose a PR with discovery topics proposed by @MattDog06.
I discovered that I can request ChatGPT to generate the JSON code from the code of this project, then feed it with another JSON code and generate the C code to create other discovery topics without typing a line of C code.

from nuki_hub.

I discovered that I can request ChatGPT to generate the JSON code from the code of this project, then feed it with another JSON code and generate the C code to create other discovery topics without typing a line of C code.

I'm too old for this AI stuff. :)

What topics are we missing?

from nuki_hub.

Seriously we're using Chat GPT now :D. Sound great if I don't have to write the discovery JSONs.

from nuki_hub.

I'm a little scared about this AI stuff...it makes me think about SKYNET...:)

So this is the script: https://github.com/MattDog06/Nuki-MQTT-auto.-Discovery/blob/main/python_scripts/nuki_mqtt_discovery.py

@Mincka Are we missing important things in Nuki Hub?

from nuki_hub.

I just want everything. :D
For instance I could get native support for Uptime and you could get your reset switch. :)

from nuki_hub.

ello, I have integrated the lock with MQTT autodiscovery but I can't find any sensor on the lock status (locked, unlocked).

Ciao. Did you check the MQTT topics for autodiscovery? You should have a homeassistant topic and under that, a serial number representing the lock...expand it and you should see a json string with all the values of the sensors.

Like this (1bfxxxx is the id of my nuki lock):

Once you see those, go in HA integrations and check the MQTT integration, click on the devices:

Then click the name of the lock (mine is Portoncino):

And once you click on the lock, the device page should open with all the sensors:

Hello, I see the same sensors as yours.
Using the Nuki bridge I also have (I had it would be better to say) the status of the lock (locked, unlocked and open). Do you think it is possible to enter this status? Thank you

from nuki_hub.

Using the Nuki bridge I also have (I had it would be better to say) the status of the lock (locked, unlocked and open)

The lock. entity itself has a status. locked and unlocked. open is more tricky, as it's intermediary state, I don't think/remember whether it's being reported or not

from nuki_hub.

Using the Nuki bridge I also have (I had it would be better to say) the status of the lock (locked, unlocked and open)

The lock. entity itself has a status. locked and unlocked. open is more tricky, as it's intermediary state, I don't think/remember whether it's being reported or not

You're right, I was too naive and quick to ask rather than delve into it before asking

from nuki_hub.

What is exactly is the open status in the bridge? Unlatched or door is open as detected by the door sensor?

from nuki_hub.

I can't tell you, it was a state that gave Nuki native integration but I guess it was taken from the door sensor

from nuki_hub.

I "solved" with this simple template:
template:

• sensor:
  • name: "Stato Porta d'ingresso"
    state: >
    {% if is_state('lock.porta_d_ingresso', 'unlocked') %}
    Sbloccata
    {% else %}
    Bloccata
    {% endif %}

from nuki_hub.

You are confusing the LOCK state with the DOOR sensor state.

The Lock has its own status: locked/unlocked, the Door sensor: open/closed.

You don't need any template, you have two separate sensor states, as you can see from device logbook (Portoncino is the Lock, Portoncino Door Sensor is the door's state):

from nuki_hub.

I'm interested in the status of the lock and I get this with the template above.
The Nuki integration directly displays the state with a specific sensor, now I need this template.
The Nuki integration also added the "open" state which most likely took from the "door state"

from nuki_hub.

The lock is an entity and it already has a state, you don't need any template to show that. And if you have HA in your own language, the state is also translated accordingly.

If you want to check the state of an entity, go to Dev Tools->State:

from nuki_hub.

Yes, but what if I want to put the status on a Home Assistant card? Being ignorant (in the sense that I don't know how to do it differently) I created a template

from nuki_hub.

Of course, what I do with the template, you do in the card itself. In the end it changes little :-)
They don't even know the Nuki Card

from nuki_hub.

Of course, what I do with the template, you do in the card itself. In the end it changes little

Nope, in the first basic example I don't use any template. :)

I used template in Mushroom just because I wanted a really compact and minimal card with all the info, otherwise I would've used the Mushroom Lock card, and that doesn't require any templating, just 2 lines:

from nuki_hub.

I meant in the second you reported with several lines of code written

from nuki_hub.

Yes but looking at your needs you only need the first basic entities card, no templates.

Anyway, we're derailing this thread. If you need help contact me on HA forum.

from nuki_hub.

Yes but looking at your needs you only need the first basic entities card, no templates.

Anyway, we're derailing this thread. If you need help contact me on HA forum.

Thanks for this awesome implementation :-)

from nuki_hub.

I think almost everything now has auto discovery, so I'm closing this for now. If you need auto discovery for something specific, please open a new issue.

from nuki_hub.