I changed also lines 222 and 223 to:
device_name = str(data.get(DEVICE_NAME))
device_model = str(data.get(DEVICE_MODEL))
so now I´am able to add device to MQTT devices without using data: in service: python_script.nuki_mqtt_discovery command BUT the script does not forward my device ID to the MQTT, so in MQTT topics I see string “None” instead of my Device ID. Maybe is is due my Device ID a string with letters, not only integers. The result is that data is not presented from Nuki device.
to:
device_id = DEVICE_ID
device_name = DEVICE_NAME
device_model = DEVICE_MODEL
and use python script without the data: helped me. But there are missing some entities which are published by the lock like as Firmware, connection status etc. It will be good if developer of this script apply all available values from Nuki to HA.
@Petr_Maizner
I do not use Home Assistant so i cannot check by myself, but the changes look like you are using the script wrong or in a wrong environment.
@Petr_Maizner your are using the script wrong. Please follow the instruction on the github page. I also released version 1.0.2, which fixes the error messages.
We should open a separate topic to say what we expect on this.
For example another setting for the final stage because the MQTT topic for auto-discovery can be changed IIRC, by default it is home-assistant be can be set differently.
Hi !
I have managed to get it to work with HA, and got all of the sensors and functionality, cool!
However, in the 2 weeks I had it working, my battery level dropped from 100% to 20%! normally this takes me 6-10 weeks.
I’ve noticed suspicious activity on the LED indicated quite frequently - as frequently as once a minutes. Could this configuration somehow cause the lock to abandon normal power saving methods and run through the battery on always-on WIFI connectivity?
Hilik
Anyone else experiencing this? In the full week since removing the MQTT entity created by the autodiscovery script my battery merely went from 100% to 90% - perfectly fine…
Would really love to restore the batery indicator functionality though…
When the debug mode of the Smart Lock and “LED signal on the Smart Lock” are
both active, the red LED of the Smart Lock acts as a traffic indicator for incoming
WIFI packets, similar to a traffic indicator of a network switch. Turn off “LED signal on
the Smart Lock” to disable this diagnostic feature.
And yes, this can drain your Smart Locks battery very quickly.
Thanks a lot for your work.
Because I sometimes prefer complicated things I have created a YAML configuration for my Smartlock and your script helped me to confirm I understood the documentation correctly.
To be honest, it looks like more state are supported by MQTT auto-discovery I.E. locking, unlocking and opening state are not available according to the Home Assistant documentation so I will miss some information so looks like using auto-discovery makes the integration more complete.
EDIT: after reading homeassistant/components/mqtt/lock.py, it looks like these states are not managed at all so YAML configuration and auto-discovery both provide exactly the same features.
To be honest, I’ve succesfully checked it by comparing with the script and syntactically but I’m still procrastinating the migration from the actual working integration using my bridge to the new with WI-Fi
I plan to do it tomorrow (I know, it looks like another procrastination ) and as soon as I will be sure it is OK I will share it for sure.
If you really need it before I test it I can share it with you but I prefer waiting to be sure it works before sharing anything
@fireballrs I posted my configuration in the topic about Home Assistant autodiscovery implementation specifications to avoid polluting this post which is specifically about the script made by @MattDog_06
thank you for sharing me the link to your config. Got it working but so far i never get live values and i can’t lock / unlock the door. So i think i need a bit more testing with the mqtt connection.
I’ve forked this script from @MattDog_06 to make it more complient to Home Assistant best practices for MQTT auto discovery.
Differences with original script
The smartlock ID is used for entity unique IDs instead of the name which could be changed
Using this method, if the smartlock is renamed in the Nuki app, the existing entities will be updated instead of create new entities (not visible actually but would be an issue when the smartlock will manage MQTT)
Node ID is not used anymore for MQTT topics
MQTT abbreviations are used
Locking, unlocking and jammed states are implemented. This change should be visible from Home Assistant 2023.2
Open and opening states are removed, these don’t exist in Home Assistant for lock entities
Apply conventional namming for entities, for example the door sensor of the smartlock Front door will be named Front door Door sensor instead of Front door Door Sensor
In the rot of the repository, there is now a script to remove original device and entities.
It uses the same parameters you used to add the smartlock entities, nuki_remove_old has to be used instead of nuki_mqtt_discovery when calling the service, you must place the python_scripts/nuki_remove_old.py to the python_script subdirectory of your Home Assistant configuration directory
I would recommand to use this implementation, particularly because the original one did not implement real unique IDs, in the case it would be used officially you would have two smartlock if renamming the old one.
Do not esitate if you need some help and if some idea about facilitating old MQTT topics removal.
I would honestly have prefered these modification to be implemented in the original repository but I unfortunately had no answer when I made pull requests. @mattdog_06 if you read it and are OK to discus about updating your script I would be glad if we could share our competences
Hi @Nardol,
Thanks for your work! Unfortunately I can’t install it correcty. Only the file python_scripts/nuki_remove_old.py
ist there after installing with HACS as described. The other one is missing. There is also no error in the log. Do you have any idea why this could Happen?
Any advice would be appreciated!
The reason looks being between my chair and my keyboard please test 2.0.1 and tel me if you still encounter any issue.
If it is the case I will create separate repository for the removal script.
In this release I also removed all unlatch related state to return unlocked, I think I made things to much complicated by doing this, lock should stay in unlocked state with previous information returned by the smartlock.
I have created a YAML configuration for my Smartlock and your script helped me to confirm I understood the documentation correctly.
