Hi Golles!!! Thanks again…Right It was working before that update.
Code didnt work, do you think if I delete inegration, It will work again? I think I already tried
does it happen to anyone else?
Hi Guys,
As usual, a big thanks for your awesome work ! I have not been around for a while and did not follow the latest devs, but the latest release looks very interesting.
I have noted there has been a change in the Z-wave integration and was wondering if at some point automatic transition is planned ? I have a couple of radiators connected in Z-wave through micro modules embedded in the wall and i would be a pain to have to access them all to reset them, etc. But at the same time, I assume the old integration will be depreciated at some point.
Any insight ?
Cheers
You (generally) don’t need to re-pair the devices since the device is paired to the controller not the interface software.
All the update does is provides a different updated means to interface with your controller.
Hum thanks for the tip. If I understand correctly, this means I just need to disable Z-wave integration, and enable Open Z-wave and Voilà ?
Sounds too simple to be true 
Probably the name of your end devices will be different. You will need to check all your rules and interfaces towards them.
You should be moving to zwavejs rather than open z-wave at this point.
ZwaveJs is the recommended integration going forward.
There are a number of threads covering off migrating from zwave to zwavejs that are worth reviewing.
In particular:
Anyone else noticed an increase in CPU/Temp, with: core-2021.4.6?
Rpi4 (4Gb)-SSD:
Installed it yesterday and went from, average:
CPU: 9% to 39%.
Temperature (passive case): 48ºC to 57ºC
No errors or new warnings on the Logs.
thanks ! lots of exciting stuff to do this weekend !!!
Upgraded from what version?
Core-2021.4.5.
When I update from core-2021.4.4 to core-2021.4.6 I loose the main customized overview dashboard and it gets replaced with one that has all my entities. Any ideas why is this happening?
HI @golles I think found the issue.
Im using two netwoks eth0 on my ISP router and Wlan0 on my MIkrotik with differents ip address, so every time I connect to ISP router HomeKit worked and on my Mikrotik network doesnt, so…removed the patchcord form my isp, disable eth0 and its working again. Before that ive try using IP_ADVERTISE to use Mikrotik range ips but it didnt work.
thank for your time
Anyone know about how many hours updating 14 days of DB might take?
Been going well over an hour on my x86-64 server with the database upgrade…just since I logged in to check it. From what I see of the host system its not using that much resources seems like its not trying that hard…disk is on SSDs and don’t appear that active by the LEDs
EDIT: Finally finished…man that was a LONG wait, at least 2.5 hours!
I’ve been using that for automations, but from some quick experiments, it doesn’t seem to work with multiple filters…
test_script:
description: Test script
fields:
field1:
selector:
text:
variables:
field1_fixed: "{{ field1 | default | lower }}"
field1: "{{ field1 | default | lower }}"
mode: parallel
sequence:
- service: system_log.write
data:
message: "field1: {{ field1 }}, field1_fixed: {{ field1_fixed }}"
level: error
If the above script is called like this:
service: script.test_script
data:
field1: Test
The log output will be:
field1: Test, field1_fixed: test
So one can see that it will still take the input field instead of the variable with the same name, but the new variable (the one with different name) works just fine!
What you are trying to do there is a bit different than the use case I presented. My suggestion will substitute a default value if you do not provide an “optional” field parameter to suppress the variable warning.
You are redefining an already defined a field value as a variable. This can be done just by using a different variable name as you have done with field1_fixed. It can also be done by redefining the variable in the sequence block instead of the variables block.
For what it’s worth, I would have expected it to work in the variables block also, but as you discovered it appears it doesn’t. Not sure if it’s a bug or intended behaviour.
Try this example with the variable declared in the variable block and then again in the sequence block both calling it with a value defined for field1 and without.
test_script:
description: Test script
fields:
field1:
description: ''
example: ''
# variables:
# field1: "{{ field1|default('DEFAULT')|lower }}"
mode: parallel
sequence:
- variables:
field1: "{{ field1|default('DEFAULT')|lower }}"
- service: system_log.write
data:
message: "field1: {{ field1 }}"
level: error
1 Like
We are in agreement here, I too am not sure if this is a bug or not, but as the default filter works, I would expect any other filter to work too… I think I’m going to open a bug and see what happens!
You can’t overwrite an incoming variable.
I.e. the incoming variable will always take precedence and you should create a new variable.
EDIT: To further clarify, your issue is this:
field1: "{{ field1
^ ^
|--SAME NAME-|
not the use of multiple filters.
So what happens is, you’re getting your original input variable, not your altered variable.
Fair enough, I understand if that is the case, however I can’t find anything like that on the documentation - and I have tried to find something on it…
I’ve now open the issue on this matter, if it is now a bug it will at least be closed with a comment confirming that.
Right, but that’ll be shut down because your issue is not the filters and the use of the same variable.
Example: You provide the following variable to your script: foo: TEST and you have foo: "{{ foo | default | lower }}" in your variable section. No matter what, if foo is provided you’ll always get foo: TEST. and lower will never be applied because you cannot overwrite what’s incoming.
