MQTT Beta Feedback & Beta 3.5.0

Today firmware 3.4.x was released to the public. The MQTT API was not part of the public release. If you want to continue using the MQTT API your Smart Lock has to be on 3.5.x from now onwards. 3.5.0 has also been made available today and will be automatically installed if automatic updates are activated.

I would like to take this chance to ask for any feedback from the 3.4.x beta: Is there anyone out there who used the MQTT API? Any feedback, experiences, problems that you want to share?

Thanks, but if it is still only supporting WiFi smartlocks and not the Bridge, then I cannot test it.

I don’t know who actually tested it…didn’t read a feedback of a single user up to now.

I think you had way more Bridge users that could have tested vs SL3.

Hope it works…:slight_smile:

1 Like

Hi Jürgen,
I´ve got version 3.4.9 now. How can I get and install version 3.5.0 with MQTT?

Thanks. Regards, Petr

I think most of us „Smart Homers“ are Nuki owners for a long time, and therefore Bridge users with Non-Wifi Nuki‘s.
Possibly you might extend the beta group to users that have voted for the MQTT suggestion.

If desired, I could ask and pre-select possible applicants in the Loxone community. I‘m with Nuki 2, otherwise I already would have tested it.

It’s all mentioned in the API specification. Your Smart Lock has to be in Beta.

Yeah. Posted there already but will do it again.

So I promised to post a script here if there was anything to share. This will create an MQTT device in Home Assistant with the following entities:

  • Lock
  • Locked/unlocked state
  • Battery level
  • Battery charging state
  • Battery critical state
  • Open (unlatch) button, since the HA lock entity doesn’t seem to provide a simple way to do that, just lock/unlock buttons

Edit the first lines according to your setup and run it, a new device should appear in your MQTT integration.
This was just a first attempt to have the MQTT entities going in HA, make sure I’m on the right topics and payloads. In the near future I plan to rewrite this in Python, have it auto-discover all locks on the nuki base topic so you won’t have to manually specify the serial, model and name.

NUKI_SERIAL='12345678'
NUKI_MODEL='Lock 3 Pro'
LOCK_NAME='Nuki Front Door'
DISCOVERY_TOPIC='homeassistant'
MQTT_USER='myuser'
MQTT_PASS='mypass'
MQTT_HOST='mqtt.example.com'

# Editing below this line should not be necessary

# This is where the lock will post its messages
BASE_TOPIC="nuki/${NUKI_SERIAL}"

# Turn device name into lower case with underscores to use as identifier in HA
DEVICE_NAME="${LOCK_NAME,,}"
DEVICE_NAME="${DEVICE_NAME// /_}"

# MQTT connection parameters
MQTT_OPTS="-h ${MQTT_HOST} -p ${MQTT_PORT:-1883} -u ${MQTT_USER} -P ${MQTT_PASS}"

## Example line for removing incorrect config
# mosquitto_pub ${MQTT_OPTS} -t "${DISCOVERY_TOPIC}/lock/${DEVICE_NAME}/${DEVICE_NAME}_lock/config" -n -r

# Read firmware version
NUKI_FW=$(mosquitto_sub ${MQTT_OPTS} -t "${BASE_TOPIC}/firmware" -C 1)

# Define device so entities will be grouped
DEVICE="\"dev\":{\"name\":\"${LOCK_NAME}\",\"manufacturer\":\"Nuki\",\"model\":\"${NUKI_MODEL}\",\"sw_version\":\"${NUKI_FW:-0.0.0}\",\"identifiers\":[\"${NUKI_SERIAL}\"]}"
# Availability topic for all entities
AVTY="\"avty_t\":\"${BASE_TOPIC}/connected\",\"pl_avail\":\"true\",\"pl_not_avail\":\"false\""

# Lock
PAYLOAD="{\"uniq_id\":\"${DEVICE_NAME}_lock\",${DEVICE},\"name\":\"${LOCK_NAME} lock\",${AVTY},\"stat_t\":\"${BASE_TOPIC}/state\",\"stat_locked\":1,\"stat_unlocked\":3,\"cmd_t\":\"${BASE_TOPIC}/lockAction\",\"pl_unlock\":1,\"pl_lock\":2,\"pl_open\":3}"
mosquitto_pub ${MQTT_OPTS} -t "${DISCOVERY_TOPIC}/lock/${DEVICE_NAME}/${DEVICE_NAME}_lock/config" -m "${PAYLOAD}" -r
# Binary sensor for lock state (locked/unlocked)
PAYLOAD="{\"uniq_id\":\"${DEVICE_NAME}_state\",${DEVICE},\"name\":\"${LOCK_NAME} state\",${AVTY},\"stat_t\":\"${BASE_TOPIC}/state\",\"val_tpl\":\"{{ value }}\",\"pl_on\":3,\"pl_off\":1,\"device_class\":\"lock\"}"
mosquitto_pub ${MQTT_OPTS} -t "${DISCOVERY_TOPIC}/binary_sensor/${DEVICE_NAME}/${DEVICE_NAME}_state/config" -m "${PAYLOAD}" -r
# Sensor for battery percentage
PAYLOAD="{\"uniq_id\":\"${DEVICE_NAME}_battery\",${DEVICE},\"name\":\"${LOCK_NAME} battery\",${AVTY},\"stat_t\":\"${BASE_TOPIC}/batteryChargeState\",\"val_tpl\":\"{{ value }}\",\"device_class\":\"battery\",\"unit_of_meas\":\"%\",\"ent_cat\":\"diagnostic\"}"
mosquitto_pub ${MQTT_OPTS} -t "${DISCOVERY_TOPIC}/sensor/${DEVICE_NAME}/${DEVICE_NAME}_battery/config" -m "${PAYLOAD}" -r
# Binary sensor for battery charge state
PAYLOAD="{\"uniq_id\":\"${DEVICE_NAME}_battery_charging\",${DEVICE},\"name\":\"${LOCK_NAME} battery charging\",${AVTY},\"stat_t\":\"${BASE_TOPIC}/batteryCharging\",\"val_tpl\":\"{{ value }}\",\"pl_on\":1,\"pl_off\":0,\"device_class\":\"battery_charging\",\"ent_cat\":\"diagnostic\"}"
mosquitto_pub ${MQTT_OPTS} -t "${DISCOVERY_TOPIC}/binary_sensor/${DEVICE_NAME}/${DEVICE_NAME}_battery_charging/config" -m "${PAYLOAD}" -r
# Binary sensor for low battery level
PAYLOAD="{\"uniq_id\":\"${DEVICE_NAME}_battery_critical\",${DEVICE},\"name\":\"${LOCK_NAME} battery critical\",${AVTY},\"stat_t\":\"${BASE_TOPIC}/batteryCritical\",\"val_tpl\":\"{{ value }}\",\"pl_on\":1,\"pl_off\":0,\"device_class\":\"battery\",\"ent_cat\":\"diagnostic\"}"
mosquitto_pub ${MQTT_OPTS} -t "${DISCOVERY_TOPIC}/binary_sensor/${DEVICE_NAME}/${DEVICE_NAME}_battery_critical/config" -m "${PAYLOAD}" -r
# Button for opening, HA Lock entity doesn't seem to show this by itself.
PAYLOAD="{\"uniq_id\":\"${DEVICE_NAME}_open\",${DEVICE},\"name\":\"${LOCK_NAME} open\",${AVTY},\"cmd_t\":\"${BASE_TOPIC}/lockAction\",\"payload_press\":3}"
mosquitto_pub ${MQTT_OPTS} -t "${DISCOVERY_TOPIC}/button/${DEVICE_NAME}/${DEVICE_NAME}_open/config" -m "${PAYLOAD}" -r

@Juergen the 20220928 API doc shows true/false as example states for the boolean type topics, but it appears that they are in reality 1/0.

1 Like

Thanks for the hint. The API is correct. Will be changed with the next firmware release to true/false.

Hi Erik,

I´am not sure if I know how to run your script. Could you please help me? It can be done from HA or something else?

Thanks, regards,
Petr

Hi Jürgen,

thanks, Now I´am a meber of beta testing so:

  1. I enabled debug mode on my Nuki Pro 3
  2. made an upgrade of firmware to version 3.5.0
  3. add to the Home Assistant a new user with name nuki and with password of hash of my WiFi password

With this created user I´am able to login to my MQTT server but after 30 minutes I can´t see the Nuki device connected into my MQTT. Do you know why, please?
Maybe I missed some info or made some wrong, but I don´t have any idea.

Thanks, Petr

Hi all.

  1. entered the android beta program
  2. enabled debug mode on both locks
  3. sent my lock ids to contact@nuki.io

But no beta lock firmware is available. Did i do something wrong?

Thanks.

Most likely beta has not been activated on your Smart Locks yet. If you DM me the ID of the locks, i can have a look.

Does your mqtt server resolve to mqtt.local (MDNS) or mqtt (DNS) inside your network? If not you will have to ensure that this is working.

Hi Jürgen,
Ok, I made some changes on my network. Currently I installed new DNS server with the requested DNS record named mqtt:


Also I can confirm that I´am able to connect my MQTT server with the DNS name and user nuki with SHA256 hash of my wifi password

but the result is that I dont see the Nuki device connected to my MQTT yet (yes, I rebooted the Nuki lock)

also I can confirm that Nuki Lock asked my DNS server for mqtt DNS record
image

I don´t have any idea now whats wrong.

Maybe the sha256 hash of the password. It has to be all lowercase!

Next step would be to look at the mosquitto logs and check if there is a connection attempt of the Smart Lock. Understanding and Configuring Logging - Mosquitto Broker Configuration

Hi Petr,
Please note that the DNS server output you pasted shows a failure to look up the DNS record.
The NXDOMAIN response means that the server couldn’t resolve the domain to an address.

OK, I made some changes on my network and now I can see the Nuki device in my MQTT :wink:

Both locks connect to mqtt without a problem.

I prepared a quick and dirty integration into homegear/node-blue and i can lock, unlock and unlatch the doors. State changes look reasonable.

But the doorsensorstate does not change with the 3.5.0 beta firmware. This worked with the 3.3.5 firmware before.

It may be a strange coincidence, but the door sensor completely stopped working. Either the battery is done (after about 2 months of use), or the device itself is broken. I just have one door sensor, so i need to wait for a new battery.

Added a new battery to the door sensor and mqtt api works including the door sensor.
States are working as expected.

Problematic is, that the new door sensor battery is directly marked as “critical”, but that should go to another thread.

Edit:
Door sensor state critical due to wrong batteries ER14250-3V instead of ER14250-3,6V.