shbatm

You should also check out mushroom-cards, the creator now works for Nabu Casa, but not all of the features have been integrated to the built-in tile card yet (e.g. Select).

To summarize: New services have been added in the hacs-isy994 (alpha testing) version and will also be added in an upcoming HA Core release (https://github.com/home-assistant/core/pull/88754). Add custom services to ISY994 to set and delete Z-Wave Lock User Codes, which use a different end-point then other ISY Z-Wave Parameters. Services to be added are: isy994.set_zwave_lock_user_code isy994.delete_zwave_lock_user_code

Yes

Get what you pay for, I guess? Try again with 4.0.8.

@Mecheng70 Try this: https://github.com/shbatm/hacs-isy994/releases/tag/v4.0.7 I don't have any way to test, so let me know if the services work.

No, but you can also ignore entire folders: I have "[i]" set as my string. I use rooms for my top-level folders and if there's things I don't want imported to HA, I add them to a subfolder named "[i]". /Bedroom/Node 1 - imported /Bedroom/[i]/Node 2 - not imported You can also just Disable the node/devices individually inside Home Assistant.

Always appreciate the support: https://github.com/sponsors/shbatm or https://www.buymeacoffee.com/shbatm There are some annual plans, maybe that's what you saw. I also pay to support the devs, but as mentioned above, there are a couple options for external access without paying for the HA Cloud service: https://www.home-assistant.io/docs/configuration/remote/ https://peyanski.com/connecting-cloudflare-tunnel-to-home-assistant/ https://github.com/tieum/haaska-tailscale (Amazon Alexa) https://www.home-assistant.io/integrations/google_assistant/ (Google Assistant)

The subscription is for the cloud access (akin to the ISY Portal) and funds the small full-time development team, but is not required to use the app. You can set up external access several different ways for free if you'd like. As long as the end service supports multiple connections, you'll be fine. I've only encountered a few (like Envisalink alarm) that only allow one connection at a time. Some cloud-based will have API limits (e.g. Openweathermap), you'll just need to consider both HA and NS are both connecting when setting your update frequencies. If you use both, I'd suggest using using an Ignore string in the folder name for your node server nodes. That will prevent them from loading in HA and creating duplicates. Use the HA integration for HA and your NS for IoX programs.

Some links to share: Custom Repository for use in HACS: https://github.com/shbatm/hacs-isy994 New Python Module repo: https://github.com/shbatm/pyisyox Wiki added for FAQs / Frequent Requests: https://github.com/shbatm/pyisyox/wiki Milestone Tracking: https://github.com/users/shbatm/projects/1 Discussions/Feature Requests/Path Forward: https://github.com/shbatm/pyisyox/discussions Issues for errors starting within "pyisyox": https://github.com/shbatm/pyisyox/issues Issues within Home Assistant (using alpha/hacs module): https://github.com/shbatm/hacs-isy994/issues Issues within Home Assistant (using core/normal version): https://github.com/home-assistant/core/issues/

OK... for anyone trying out the Alpha version: consider this your official "Here Be Dragons" warning. Up until hacs-isy994 4.0.3 and pyisy-beta 4.0.0dev3 everything was about getting the parity of the rewritten module up to the same point as the core PyISY / Home Assistant code. If you install the hacs v4.0.6 (pyisyox 1.0.0a2) you are crossing into the breaking changes. Unlike what I will have to do when this gets merged back for everyone--there are no deprecation warnings or grace periods. I'm making changes that need to be tested to try and get the new features and sorting for Z-Wave and Node Servers ready for prime time. Entities will change names, will change device classes, and will change controls. If you are using this on your main production system--you must back-up Home Assistant frequently, and be prepared to revert back to an old version, or uninstall the hacs version if something is not working for you. That being said, as @Mecheng70 pointed out, hacs-isy994 v4.0.6 is released and can be installed from your HACS page in the sidebar. You need to fully restart Home Assistant (not just reload ISY) after updating. The new version of PyISY (formerly PyISY-beta/PyISY 4) has been renamed and released as PyISYoX. This will be kept through the updates in Home Assistant's core in a few months. If you are trying to uninstall the hacs-isy994 version, and the normal version does not load when you restart Home Assistant: from a shell inside the docker container (e.g. `docker exec -it homeassistant bash`) you need to manually uninstall PyISY-beta and PyISY (`pip uninstall pyisy-beta pyisy`) and let Home Assistant reinstall it after a restart. Alternatively, time it with an update to Home Assistant, and it will give you a fresh container.

Good.

PSA: If you are using the Alpha version > HACS-ISY994 version >=4.0.5, please adjust/turn-on debug logging to help with troubleshooting. # In configuration.yaml (persists across reboots): logger: default: info logs: custom_components.isy994: debug pyisyox: debug EDIT: jumped the gun a bit... I will push the 4.0.5 version to Github/HACS later this afternoon. There are going to be some breaking changes: Node Servers now use their real names and values for the different sensors (see 4.0.4 notes here: https://github.com/shbatm/hacs-isy994/releases/tag/v4.0.4) Device State Properties (aux_properties) will now be broken out into sensors for Z-Wave (Insteon change was included in core last fall). Battery-status-only nodes will no longer report a state under the main entity, it will be under a "_battery_level" sensor entity--the special logic which used the battery level for the main state has been removed. In the future, this "main" entity will not be created if there isn't a valid state.

You're in the right spot, you already have the variables exposed. The additional configuration options @mecheng70 is referring to are just for the alpha test version, you don't need to worry about that. @MrBill above gave a good example.

Assuming you're trying to set the variable to the value of the sensor: use a template for the value: "{{ states('sensor.outTemp') }}"

Looks like the issue is with libbson being updated in the upgrade.polisy script, my fix wasn't as simple... Note: this is not advice from UDI. Follow at your own risk. This is the output of the update script. The following 2 package(s) will be affected (of 0 checked): Installed packages to be REMOVED: mongo-c-driver: 1.8.1 Installed packages to be UPGRADED: libbson: 1.8.1 -> 1.23.2 [FreeBSD] Number of packages to be removed: 1 Number of packages to be upgraded: 1 I updated "/usr/local/etc/pkg/repos/FreeBSD.conf" to the following (change "latest" to "quarterly") FreeBSD: { url: "https://pkg.FreeBSD.org/${ABI}/quarterly", enabled: yes, priority: 1 } Then ran: "sudo pkg upgrade -f mongo-c-driver" Which downgraded libbson back to 1.8.1 The following 2 package(s) will be affected (of 0 checked): Installed packages to be DOWNGRADED: libbson: 1.23.2 -> 1.8.1 [FreeBSD] Installed packages to be REINSTALLED: mongo-c-driver-1.8.1 [udi] Number of packages to be reinstalled: 1 Number of packages to be downgraded: 1 After that, all services were back.

*removed, see post below*

These 'claim' they are running on my polisy, but I don't have any isy ports open (sockstat), no isy log files have been updated since I mashed the button last night, and when I try and manually run the ISY binary it's complaining about a missing library object referenced online with the Mongo-c-driver.

Running into the same issue. Also have a ticket open. Looks like there's issues with the mongo-c-driver build on FreeBSD 13, not sure if that's still required or not (but restarting the udx service manually complains about it not being installed). https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269301 https://portsfallout.com/fallout?port=devel%2Fmongo-c-driver%24

Can't help much, but here's a couple links to get you in the right direction: https://companion.home-assistant.io/docs/notifications/actionable-notifications/#building-notification-action-scripts https://community.home-assistant.io/t/actionable-notifications-howto-and-examples/416738/4

Well, it's going to be a while now... Tried to reboot and hit Update Packages without thinking and now I have no ISY...

It looks like there's an issue with the python module versions competing with the same namespace. I'm working on renaming things and will post an update later today.

https://github.com/shbatm/hacs-isy994/releases/tag/v4.0.4

@Mecheng70 Continued from Here... So I reloaded again this morning and what I thought were missing last night looks like it was a fluke on something else I changed--everything I expected was back. One breaking change (on the alpha version only) that I need to capture in the release notes though: anything that was categorized as a sensor, but was really an "On/Off" or "True/False" entity, now correctly gets sorted as a binary_sensor--so some entities may have changed. Also, 4.0.4 includes the first pass that will correctly get the node server information, so anything that would show up before as "GV1 = 0" will not report correctly (e.g. "Node Server Online" = "On"). @Mecheng70 - please let me know if the devices that aren't showing up are just sensors that switched to binary_sensor, or if there's more that aren't appearing.

He was referring to this: @Mecheng70I noticed a few things missing too last night. I'll have to pull the release and investigate.

Can you capture /rest/nodes and /rest/status in that scenario and post/send to me? Does setting a full system query program to run at reboot fix the issue? Home Assistant's ISY integration doesn't "remember" anything about what type an entity is on each load. It sorts them based on the information provided from the ISY each time--that's the only dependable way to pick-up new (or purposefully changed) nodes, without creating a whole bunch of junk on the Home Assistant side. Home Assistant stores the custom names and icons based on matching "(platform/type, isy994 domain, isy_mac__node_address)" combos after evertyhing is loaded, but if that node doesn't get sorted the same (or exist) on the next load, those remnants are removed. -- This part can be disabled (it's the old cleanup entities service), but leaves the issue of those remnants piling up. Disabling it this case would keep the preferences when you query and reload, but you'd end up with duplicate sensor entities with unknown states after a reboot.