Unfortunately it was the only workaround I found to have a global parameter, in order to make it very easy for the user to configure this integration. I’ll show you what I mean, check these two REST sensors:
These two sensors are the ones responsible for polling data. The interesting thing here is that I didn’t want to use static URLs etc, because I just need those 3 parameters you put in secrets to dynamically construct the URL. While implementing it, I found out you can’t recall secret items in there, so I had to use a sensor’s state. If there’s a better way to pull in there secret items, I’m happy to adapt the code.
Unfortunately not, because I don’t have it and so I can’t test it. And furthermore, the official integration in the future should have support for callbacks etc, so probably this integration, if that one does everything this does, won’t be needed anymore. We’ll see what happens…
For me it’s been an excercise to force me to learn HA more. I’m happy that it’s working for you.
I see the problem. Maybe, it is slightly better to stick the values into an input_text and not a sensor as strictly speaking, they are not changing and thus the sensor is not sensing anything. That’s the logic discussed here: How to use !secret in sensor template - #4 by AhmadK
I have one so I might for the sake of following your learning curve experiment with it. If I get anything setup, I’ll share it here. But you’re right, ideally the native integration would pick this stuff up.
From a configuration perspective, it’s easier to just ask the user to configure all user-parameters in secrets (they are secrets) and then I pull them up as sensors when users pastes all the code in the sensor file. If I used input_texts there would be additional user steps to follow, that’s all. So, either I ask to put everything as input_text or as secrets, I didn’t like mixing things, the instructions are already too complex for my taste.
If you don’t like the sensors being recorded, you can filter it out.
Feel free to adapt it to your needs if you prefer input_text. The code is there to be changed/adapted by anybody.
The beauty of HA is that you can solve the same problem in 100 ways, I chose one, and I explained why. I could argue that putting my sensitive information in input_text is not something that I like, but it’s subjective.
Like I said, input_text would require extra configuration steps, and I preferred to minimize those.
I’ll be more than glad, once it’s working, to add the opener bit to the integration. Let’s make sure that someone else with the opener can test it, obviously.
I went the easy way and simply used your callback idea to force an update of the Nuki integration itself. That includes the opener then, but it lacks all the wonderful attributes that you pull from the bridge.
Setup is fairly easy and I created a blueprint for that:
It’s a nice feeling being able to click “ignore” while still having a fully working integration, that provides all info about the Nuki, and faster status feedback.
Great work! This method is so much faster then just using the rest api.
Is it possible to get the lock_state on callback? The current binary sensor only updates when a door status change is triggered.
I’m trying to create a binary sensor, which is on when the lock is unlatching or unlocking (7 or 2) but can’t get it working.
It’s already like that. Lock state and Door state are separate and update independently, each time a callback is received.
If it doesn’t work for you, make sure you configured everything correctly.
If you look at the code of the trigger sensor you should be able to understand how to do it. Take into account that the way I implemented it is a special case: it is a device_class door binary sensor and it is a sensor that is updated BOTH via callbacks from the bridge and polling via REST sensors.
You can create a simpler template trigger binary sensor, that is updated only by callback, and when called, you check the lock state (2 or 7) to turn it on/off. Or you could use this integration: The Lock state is represented by this attribute of the binary door sensor: state_attr('binary_sensor.nuki_door_state', 'lock_state'). If you check the code of the lock sensor, you will see that its state is retrieved by that attribute.
Thanks for the help! Yes I’ve seen the attribute, but for me it only updates from locked to unlocked (and vice versa).
It never reaches unlocking/unlatching (2/7). I’ve looked at the callback content and it seems like Nuki doesn’t send one on lock state change to 2/7, but rather it goes directly to 1 or 3. Seems like my use-case doesn’t work with the current callback logic.
I think the callback is done only on 1/3, check this log from the bridge: at 32:27 I do the unlock, at 32:31 the lock is completed, at 32:37 the callback is done. That means the callback is done only at the end of the action, so you will never receive the status changes you were looking for.
When you say paste the code above in the file templates.yaml, do i need to create such a file in the config directory? How do i reference it then in configuration.yaml?
You are right, I took for granted that every user knows how to better organize the config.yaml file when it becomes too complex, I’ll show you the end of my config.yaml, so you can understand what I mean in the instructions. Let me know if it’s clear.
what do you have at line 1210? You probably have strange characters in config.yaml. Type it instead of copy&pasting the line. HA is telling you that there’s an illegal character in that position.
i figured it out, it ws the n´ in lock n´ go, it was written in ansi encoding and when i switched it to utf 8 , questionamarks appeared so i had to retype it.
Go figure
