Please show me the HA logs with errors related to the bridge communication, and also the bridge log, sending this command to the bridge from a terminal. It will help me debugging the issue, thanks.
curl -X GET 'http://nuki-ip:8080/log?token=xxxyyy'
Please show me the HA logs with errors related to the bridge communication, and also the bridge log, sending this command to the bridge from a terminal. It will help me debugging the issue, thanks.
curl -X GET 'http://nuki-ip:8080/log?token=xxxyyy'
Just to add, I’ve always used the internal IP of my bridge and it’s absolutely rock solid.
Yes, I think, judging from the logs I saw, that there are communication issues for some users. But the code should prevent adding the callback to the bridge 3 times. So the bug is present, in my case the DNS triggered the issue, in other cases I think it’s the wifi.
Thanks a lot for the feedback. Did you check HA logs for errors in your case? If you can post them you’ll help me collect more info, I’d appreciate it.
hi,
it keeps only few hours back, and the automation was disabled since yesterday, so I’ll send it next time it will go offline (BTW, I noticed that the lock state didn’t update when the automation was off)
if the problem comes up because of the automatic callback add to the bridge, I’ll be happy to let it go and do it manually…
if its an option I’ll appreciate it a lot if you could post the code for it.
Thanks again for all your effort!
The automation updates everything.
It’s not an option, I can’t maintain 2 versions of the code, I’ll fix it.
The log only shows events from the last hour. So I can’t see, what really happened, when the errors occured.
Thanks, if it happens check it please, it would help. Also HA logs.
Hi Allessandro,
I think the problem with the multiple registered callbacks is that if for what ever reason the “Nuki Bridge Callback List” rest call fails, the binary sensor nuki_bridge_callback is switched to off and that will trigger the “Nuki Card Callback” automation which will trigger the script nuki_bridge_check_callback. And there if the binary sensor nuki_bridge_callback is off a new callback url will be added. This keeps going on until a “Nuki Bridge Callback List” rest call succeeds…
So you’ll possibly have an endless loop…
It may also flood the bridge because every 5 seconds a call to the bridge is done in that case which might get the bridge in a kind of unresponsive state.
Hi Alessandro,
I might have an idea on how to achieve a better way for the translations. It might be possible to create a template file with tags that can be replaced by a bash script. The idea is then, to create an automation that is triggered by a change of the input_select and that automation will then:
It is just an idea, I’ll try to work on it tonight.
No endless loop, because I have a max loop number (5) exactly for that reason. The big issue is when the rest_command fails, for whatever reason, I need to reiterate the command, and the problem is that it doesn’t provide a status of the call.
Anyway, I rewrote many of those parts, now it’s much more robust, and when I add the callback, right after I use a wat_template with the state of the sensor and I added a timeout to the wait, as a safe exit. I also added the delete of the duplicate callbacks, but I need to test it well. I’m working on it since yesterday night.
We’re very limited to what we can do with pure yaml and templates. But it’s a nice challenge.
If you could help me test it once I think it’s ready I’d really appreciate it. So after your feedback I can release it.
Thanks a lot for being here.
You are becoming more creative (aka crazy) than me…I love it…
Don’t do it, I have a better solution, thought about it yesterday…I’ll give you a hint: the problem is reading a json data structure, I was looking for a way to do it from a file, but didn’t find a clean solution, there’s the file sensor, but it reads only the last line.
So suddenly I thought: well…I could send myself the data structure via the webhook: a rest_command (POST) with all the structure and then we send it through the same webhook and parse it where needed.
It’s crazy, I know, but if you think about it…and think again and again…you will start understanding how crazy I am…
The advantage would be to have ALL the strings in one section, so users can easily translate them to their language. Obviously the best way would be to have an external json file that we can import and parse, but I didn’t find a way with standard functions.
Let me know what you think…I was also thinking to creatd a discord channel so we can chat there when needed, and share ideas and stuff.
Ciao,
Alessandro
Hi Alessandro,
I’ve created an example package to dynamically set the values of some input_text entities based on the value of an input_select entity. The translations are defined in a separate json file “languages.json” that should reside in the packages directory:
{
"English (Default language)": {
"value_1": "Hello",
"value_2": "world"
},
"Nederlands": {
"value_1": "Hallo",
"value_2": "wereld"
},
"Deutsch": {
"value_1": "Hallo",
"value_2": "Welt"
},
"Français": {
"value_1": "Allo",
"value_2": "monde"
},
"Italiano": {
"value_1": "Ciao",
"value_2": "mondo"
}
}
The code for the language selector package, “language_selector.yaml”:
#######################################################################################################################
### ###
### Input Selects ###
### ###
#######################################################################################################################
input_select:
lng_language:
name: "Language selector"
options:
- English (Default language)
icon: mdi:blur-radial
#######################################################################################################################
### ###
### Input Texts ###
### ###
#######################################################################################################################
input_text:
lng_string_1:
name: "Language String 1"
lng_string_2:
name: "Language String 2"
#######################################################################################################################
### ###
### Automations ###
### ###
#######################################################################################################################
automation:
- id: "Language selector"
alias: Language selector
description: 'This automation will set the value of some input_text entities depending on the selected value of the input_select "lng_language"'
trigger:
- platform: state
entity_id: input_select.lng_language
- platform: homeassistant
event: start
condition: []
action:
- service: script.lng_set_language
data:
lng_ha_startup: >
{{ trigger.platform == 'homeassistant' }}
- service: notify.persistent_notification
data:
message: >-
{{ states("input_text.lng_string_1") }} {{ states("input_text.lng_string_2") }}
mode: single
#######################################################################################################################
### ###
### Scripts ###
### ###
#######################################################################################################################
script:
lng_set_language:
icon: mdi:blur-radial
mode: restart
variables:
lng_languages: !include languages.json
lng_languages_string: >
{% for x in lng_languages %}
{%- if loop.last %}
"{{ x }}"]
{% elif loop.first %}
["{{ x }}",
{% else %}
"{{ x }}",
{% endif -%}
{%- endfor %}
sequence:
- choose:
- conditions: >
{{ lng_ha_startup }}
sequence:
- service: input_select.set_options
target:
entity_id: input_select.lng_language
data:
options: >
{{ lng_languages_string }}
default: []
- service: input_text.set_value
target:
entity_id: input_text.lng_string_1
data:
value: >
{{ lng_languages[states('input_select.lng_language')]['value_1'] }}
- service: input_text.set_value
target:
entity_id: input_text.lng_string_2
data:
value: >
{{ lng_languages[states('input_select.lng_language')]['value_2'] }}
This way it is possible to maintain the translations in a separate file and relatively simple (more simple than to use rest commands and webhooks…). However, changing something in the json file “languages.json”, needs to have a restart from HA for the changes to be effective.
Thanks for putting me in the direction of using json. Now it should only be incorporated in your nuki package.
Hi everybody,
v8.0 is released. Sorry for the delay, I had to do much more work than expected: while fixing the bug regarding the configuration of the bridge, I noticed a lot of things that needed optimizations, so I went through all the code and with the things I learned in these months I optimized a lot of stuff.
I’m very satisfied of this version, in particular the new autoconfiguration of the bridge, I made a new script that should work very efficiently. Hope it works well also for all of you, I tested it extensively but the best tester is almost never the developer.
Please test it and let me have a feedback, if you could spend some time testing the autoconfiguration of the bridge (by removing the callback as first test, then adding 2/3 callbacks as second test) and reporting how much time it takes.
I moved the code of the package from the first post to my gist on github, posts have a limitation of 32k chars, and we hit it. Gist is much better for the scope, you can download the file, inspect the code more efficiently, etc.
UPDATE: v8.1 just released with some small changes.
Thank you and sorry again for the delay.
Alessandro
Spokin,
thank you for this. Now I’m too tired to look at your code, I spent many hours on v8.0 and I want to take a break, hoping that there are no issues with this version.
If you could test v8.1 and maybe integrate your localization automation, I can then revise it and we can publish v8.5.
I’m turning off the pc now, my eyes are really tired.
Ciao,
Alessandro
Morning,
I’ve just updated to v8.1 and following a reboot of my instance I’m seeing a few errors in the logs:
2021-07-23 08:04:42 WARNING (MainThread) [homeassistant.components.sensor] Platform rest not ready yet: Unsupported URL protocol ''; Retrying in background in 30 seconds
2021-07-23 08:04:42 WARNING (MainThread) [homeassistant.components.sensor] Platform rest not ready yet: Unsupported URL protocol ''; Retrying in background in 30 seconds
2021-07-23 08:04:42 WARNING (MainThread) [homeassistant.components.sensor] Platform rest not ready yet: Unsupported URL protocol ''; Retrying in background in 30 seconds
2021-07-23 08:04:53 WARNING (MainThread) [homeassistant.setup] Setup of input_text is taking over 10 seconds.
2021-07-23 08:05:08 ERROR (MainThread) [homeassistant.components.template.template_entity] TemplateError('JSONDecodeError: Expecting value: line 1 column 1 (char 0)') while processing template 'Template("{% if states('sensor.nuki_bridge_callback_list') != 'unknown' %}
{% if states('input_text.nuki_bridge_callback_list')|from_json|count == 1 %}
on
{% else %}
off
{% endif %}
{% else %}
off
{% endif %}")' for attribute '_state' in entity 'binary_sensor.nuki_bridge_callback'
2021-07-23 08:05:08 WARNING (MainThread) [homeassistant.components.automation.nuki_card_callback] Nuki Card Callback: Already running
2021-07-23 08:05:08 WARNING (MainThread) [homeassistant.components.automation.nuki_card_callback] Nuki Card Callback: Already running
2021-07-23 08:05:08 WARNING (MainThread) [homeassistant.components.automation.nuki_card_callback] Nuki Card Callback: Already running
2021-07-23 08:05:14 WARNING (MainThread) [homeassistant.components.automation.nuki_card_callback] Nuki Card Callback: Already running
2021-07-23 08:06:08 WARNING (MainThread) [homeassistant.components.automation.nuki_card_callback] Nuki Card Callback: Already running
2021-07-23 08:07:08 WARNING (MainThread) [homeassistant.components.automation.nuki_card_callback] Nuki Card Callback: Already running
2021-07-23 08:08:08 WARNING (MainThread) [homeassistant.components.automation.nuki_card_callback] Nuki Card Callback: Already running
2021-07-23 08:09:08 WARNING (MainThread) [homeassistant.components.automation.nuki_card_callback] Nuki Card Callback: Already running
2021-07-23 08:10:08 WARNING (MainThread) [homeassistant.components.automation.nuki_card_callback] Nuki Card Callback: Already running
Also received this notification
Everything does appear to be working though.
When you restarted HA, REST sensors took too long to start, so some variables were not initialized. But I can eliminate those warnings with some checks, it’s not a blocking problem though. Thanks for reporting it.
The notification appears when Nuki Card reconfigures the bridge (adding callback or deleting callbacks), I guess you were testing it, you removed all callbacks and Nuki Card added one at ID: 0. Correct?
I’m glad it works for you, I spent a lot of time on it in the last 2 days…
Thanks for the feedback.
Alessandro
Quick patch: replace line 228 with this, I added the second check:
{% if states('sensor.nuki_bridge_callback_list') != 'unknown' and states('input_text.nuki_bridge_callback_list')|count > 0 %}
I also updated the gist, but no version change for this.
Hi Alessandro,
I have implemented the translations in the Nuki Card v8.1 version with the patch from message 458. Where can I share the code? Gist doesn’t seem to have a proper format for implementing code in a comment…
Send it to me via private message, or put it on a file sharing service and send me the link in private message.
Maybe I should create a Nuki Card repository on github, so we can collaborate on the code. Do you have a github account? There are too many spokin-something users on github.
Hi, did install 8.1 including the patch for line 228 and recive the following errors every minute.
2021-07-23 14:09:09 ERROR (MainThread) [homeassistant.components.rest.data] Error fetching data: http://192.168.1.47:8080/callback/list?&token=ucqbkj failed with illegal status line: bytearray(b’155’)
2021-07-23 14:09:09 WARNING (MainThread) [homeassistant.components.rest.sensor] Empty reply found when expecting JSON data
2021-07-23 14:09:09 WARNING (MainThread) [homeassistant.components.automation.nuki_card_callback] Nuki Card Callback: Already running
2021-07-23 14:10:09 WARNING (MainThread) [homeassistant.components.automation.nuki_card_callback] Nuki Card Callback: Already running