Back before the Garage Door opener (cover) I am using was fully supported updating zwave was a common thing for a small group of HA users.
Basically, I have a fork of the HA open-zwave, I manually updated the usercode.cpp file, I then install that version in my HA instance. It’s actually kind of a pain, because I have to do this almost every time I update HA.
These are the basic steps to what you need to do
I forked the HA open-zwave
I then changed to the HASS branch and updated the usercode.cpp (I used the web GUI to do that)
If you dont want to do that you can use my fork
https://github.com/ptdalen/open-zwave
on my HA server
logged in with root user
systemctl stop [email protected]
sudo su -s /bin/bash homeassistant
You should already be in your home directory, but just in case
cd /home/homeassistant
git clone -b hass https://github.com/ptdalen/open-zwave (or use your own updated git fork)
source /srv/homeassistant/homeassistant_venv/bin/activate
export LOCAL_OPENZWAVE=/home/homeassistant/open-zwave/
pip uninstall -y homeassistant-pyozw==0.1.4 (or whatever the current version is)
pip install homeassistant-pyozw==0.1.4 --no-cache-dir --no-deps --install-option="--flavor=dev" (make sure to match the version of pyozw)
I did consider variables a while ago, but now that is so easy to rename entities in the UI, I never went back to it. I did add lovelace code to my main lock package. it’s commented out since I dont think you can add lovelace in a package at this time. I need to update the other two packages, but just have not gotten around to it.
I will say that I am using this lovelace
with the swiper card, and I really like it. Mainly for me I dont change codes too much, and having the codes a few swipes away makes them a little less visible to users.
I dont have a quick answer for you. I dont have access to the template test area at the moment.
My lock names were pretty much based on the naming convention that HA named them when I first started with HA several months ago.
If I was starting over I’d probably rename my locks something closer to what you have, but i have so many automation, scripts, sensors, etc now, I’ll probably not do that.
Ultimatlly the goal of the code
{% set lock_name = "_".join(object_id.split("_")[3:-1]) %}
{% set lock_id = 'lock_' ~ lock_name ~ '_door_lock' %}
{{ states['lock'][lock_id].attributes.node_id }}
is to get the zwave node ID of the lock, so lock_id needs to end up being front_deadbolt. If you only have one lock you could just set it as such
{% set lock_id = 'front_deadbolt' %}
This should work (might have to play with the quotes though) if you want to keep it open for multiple locks. Just make sure to get all the places.
@ptdalen I plan on having a separate .yaml for every lock to make it easier to navigate. My only issue with node ID is that since HA no longer names the entity cleanly like it used to, when I rename them, there is no longer a node ID to grab from the name. IS there a way to look up the node_if if its not in the name?
The Node_id is in the items attributes. (attributes.node_id)
So you end up with an entity that is your lock name, and it pulls the node_id from that.
And totally your call on having three separate packages, but the code will be 95% the same. So, you’ll end up with more lines of code to process in the long run. But probably talking miliseconds, so it probably makes no real difference.
I’ll add, that even though the naming convention for the locks may not be your preference, you’ll rarely ever deal with them. If you just change the names to match the code, it will take 5-10 minutes to set up all three locks in a single package.
@ptdalen I keep getting the following error on config check, I’ve re-done it from scratch several times not sure what’s going on. I renamed my sensors and lock to match yours. I’m just using the single lock YAML file. quite literally the only thing I changed was moving to clear codes with random since im on Hass.io and the email address for pushbullet.
Configuration invalid CHECK CONFIG
Invalid config for [sensor]: required key not provided @ data[‘platform’]. Got None. (See ?, line ?). Please check the docs at https://home-assistant.io/components/sensor/
********ok figured it out. turns out the uptime sensor is not optional… you have to put that in configuration.yaml
Ahh, probably should have made that clearer in the header comments. I mention it, but list it as “nice to have”, but should say, if you dont want to use it, just remove it from the package.
It’s probably not that needed for these packages, but I use it in most my automations, it keeps things from accidentally running on restart (which I seem to do a lot).
Good job on finding the issue, I was about to reply saying it looked like a typo somewhere.
@ptdalen looks like I see all the entities appear, but when I uncomment the group: section to see all the user templates, HA refuses to even boot up until I remove it. I’m thinking maybe to just skip and move to Lovelace, but having issues (new to Lovelace) as to how to install your Lovelace code and also where to place the swiper card code resource:.
Adding the group section should not cause any issues, if HA is not starting then there is probably a tab or typo somewhere, check the logs, it will usually help a bit. But with that said if you are on 85.x or above, the group section actually wont do anything for you at all.
So in that case you want to go to my door_locks.yaml package, have a look at the end and copy the lovelace code there. clean it up for a single lock, and make it match your names as needed.
I’m just starting lovelace myself since 86.x, what I did was open the raw editor and paste the entire thing where you want it to me. If you’re totally new to lovelace, just look a the code, usually each tab will start with badges, but maybe not. Just looks for the areas, entites, etc that match the tabs in your UI and use that to determine where each tab starts and ends, then paste the code in there.
I will say I recommend you copy the entire raw lovelace somewhere safe before you begin so you can revert if you mess up.
Once you get that working, the swiper card will be easy (but require copying files, and creating directories, etc)
The code above pasted here does refrence the swiper card. I prefer that, but it requires you to configure the swiper card. The link to how to set up the swiper card is in the post.
has lovelace at the end of the package (commented out), that will provide a lovelace view that matches what the old group view displayed, it does not require any special cards, but since I only made it for three locks (at the moment), you’ll have to clean it up for your install.
it works, just takes a bit