shbatm

@MrBill Let know if you're able to get the Polisy working with Home Assistant--if everything is the same for the REST and Websocket interfaces like @Michel Kohanim mentioned, then I don't think there should be any changes needed for PyISY connecting for Home Assistant. Like I mentioned in our other chat--I've had some major life changes recently so I haven't been able to do much with my Polisy to test anything, but I do have the hardware if there is anything I need to test.

Versions v2.1.2 and v3.0.1 have been released with the corrected unsubscribe code. @Javi would you mind also checking the reconnect strings (same file further down) to make sure those are correct?

Sorry, in my example I included the `type` parameter and the `name`, you can either call it by name or by type+ID, if you remove the `type` lines from my example above it should work.

When do you have your ISY Query program run? It looks like a lot of the programs were triggering at 2:55am. Still doesn't explain why that program would return a different status than the variable. I don't think I've seen that before. Because you're seeing the Status program update in the ISY console, that should rule out the Home Assistant/PyISY side--but I'm still at a loss. As an alternative, you can shift the switch to the Home Assistant side to see if that helps eliminate the problem. The following should also give you a switch in Home Assistant that will control the variable on the ISY. 1) Change the ISY994 options in Home Assistant to use a variable sensor string of `vs.` (based on your naming above) 2) Add a template switch in Home Assistant to do the same thing as your ISY program should be doing: # in configuration.yaml or sub-file: switch: - platform: template switches: movie_lighting: value_template: "{{ is_state('sensor.vs_movie_lighting_switch', '1') }}" turn_on: service: isy994.set_variable data: name: "vs.Movie_Lighting.Swtich" type: 2 value: 1 turn_off: service: isy994.set_variable data: name: "vs.Movie_Lighting.Swtich" type: 2 value: 0

Can you please try one more thing: on the ISY portal under Tools > Information > ISY Information (or somewhere thereabouts) there should be a long unique my.isy.io portal url for your ISY (looks something like the random Nabu Casa url if you use the cloud integration on Home Assistant). Try using that as the url to connect to in Home Assistant and see if the websocket just isn't working with the portal url relay.

Can you please open an issue on the Home Assistant Github Page, make sure to include all the details and reference the isy994 integration? Also, do you have any ability to do some testing? It would be good to know if you remove the local ISY (temporarily) or test the Portal only on a separate instance/install of Home Assistant if it works with just 1 enabled. Also, if you do that, please check in HA under Configuration > Info > System Health > Universal Devices ISY994 to see what it says for "Host Reachable", "ISY Connected", "Last Heartbeat Time" and "Event Socket Status" (this system health info is new and unfortunately only works for the first ISY instance you have setup in Home Assistant right now; so it will only report one of the two if both integrations are set-up.) Finally, if you can enable logging, it will help greatly: # In your configuration.yaml: logger: default: info logs: homeassistant.components.isy994: debug pyisy: debug pyisy.events: debug @bdraco Won't be able to troubleshoot until tomorrow eve, but sounds like the websocket isn't connecting properly to the portal or the removal of the `hint` is causing an issue.

https://hacs.xyz/docs/configuration/start

@asbrilThe modified version you're testing with HACS will increase the timeout to see if that works--if it does we'll increase the TO in the next Home Assistant version. @Javi Thanks for the support and background! Having him try to bump to 60s for now and will go up more if needed.

@asbril I have something for you to test. I would agree with @io_guy, most likely the ISY is too bogged down to be able to download everything this integration needs within the 30s timeout allowed by the Home Assistant Integration. This is either caused by too many open connections to the ISY, or too many nodes, or both. To test, you will need to upgrade HA again, and do one of the following (easiest to hardest): Option 1: Install HACS (Home Assistant Community Store), then search for and install the Universal Devices ISY994 integration in HACS's interface and install the latest version -- 3.0.2 is a special version, identical to the Core version, but with a 60s timeout instead of 30s. Option 2: If you really don't want to install HACS, you can install the custom version directly by downloading this zip file and extracting it to your_config/custom_components/ (make sure all the files end up in your_config/custom_components/isy994, your_config/ is the folder with configuration.yaml in it). Option 3: If you know where the source files of your Home Assistant install are located, you can change this line from 30 to 60 and restart HA to test the change.

@asbril Please open an issue here so we can see if it is affecting other users and try and find a common thread. Include a link back to this conversation as well. Also, please include there any NodeServers you are using to see if there's a conflict we can find. @MrBill was able to get his instance to work after some combo of repeated restarts of HA and the ISY.

Good to hear. If you're on 2021.06.0 you should be able to un-install the HACS version now; everything has been merged over to the Core integration. I'm about to mark it depreciated.

@asbril-- For lack of a better option at the moment, I would try your upgrade again tomorrow and see if you still get the same error. @MrBill was able to get his up and working through several restarts and attempted troubleshooting, but we didn't find a smoking gun. This is a sporadic issue that we saw back in July 2020 when first testing this update, but even then we were never able to recreate, it just started working eventually. My best guess is something with the connection is getting hung open when HA restarts and tries to reconnect to the ISY and it's timing out. I'll continue trying to recreate on my end, but would be worth giving another shot after waiting awhile and attempting a full restart of both the HA machine and ISY again. (I know, cliche to say turn it off and back on, but hey, sometimes it does work...)

@MrBill Yours is still using the HACS version (custom_components is in the path). Try removing that and see if the core loads correctly.

If you can try it it'll let me know if there's a more widespread issue or not. The new version uses async to communicate and tries to open more connections to the ISY than the old version. You can also try the version in HACS if that's easier--it uses the same method.

@asbril or @MrBill -- Can one of you please use a web browser to go to http://your-isy-ip/rest/subscriptions and post/PM me the result? Thanks

The 12 Nodeservers may be the issue. You can downgrade by Install Terminal Add-on: Go to Supervisor > Add-on Store > Terminal & SSH and install/start the add-on. Click 'Open Web UI' Type this: ha core update --version=2021.5.5 and hit enter. EDIT: If you let Home Assistant take a snapshot before upgrading, that is the easier way to get back. It'll be in the Snapshots tab under Supervisor.

It was caused by a change made in the upgrade to 2021.6.0. Downgrading back to 2021.5.5 or restoring a snapshot should fix it for you until we can find the real cause of the issue. If I remember right, it's an issue with too many things trying to talk to the ISY at once and it just stalls. Do you use a lot of NodeServers on the ISY? Polyglot?

You'll most likely have to add it to the bottom of your `configuration.yaml` file if you haven't changed any of the default logging settings before. It won't be available in the UI/Lovelace, you'll have to edit the file manually in your config folder (if you are using the Home Assistant OS or Supervised versions, the easiest way is probably adding the VSCode Add-On.

I just remembered this was an old bug that we couldn't seem to pin-point. Caused by the ISY running out of available connections (I think max is ~10): https://github.com/automicus/PyISY/issues/123

If you don't know what it is, you're probably not using it--you wouldn't be using it by accident. https://hacs.xyz/ https://github.com/shbatm/hacs-isy994 Can you please try with this in your `configuration.yaml`, restart HA, and post the logs again: logger: default: info logs: homeassistant.components.isy994: debug pyisy: debug

2021.6.0 merged all changes from the HACS version into the Core integration. The changes weren't 'big' enough to make it into the headings of the release notes, but they're buried under all changes. You should be able to remove the HACS version. I just confirmed I didn't have any issues with upgrading from 2021.5.5 to 2021.6.0, so I'm not sure what is going on. What ISY Firmware are you using? Are you using HTTP or HTTPS to connect from Home Assistant? Are you connecting straight to the IP (e.g. host: http://192.168.1.10) or via the ISY Portal? Thanks

@Michel Kohanim I was the one that updated Home Assistant for the range issue; it now looks at the UOM provided for the device to see if it's a 0-100% device or a 0-255 (8-bit) device to determine which range to use. Home Assistant still works only in 8-bit brightness so it translates anything with a UOM=51 to/from 8-bit to 0-100%. This shouldn't break anything for v5 or Insteon users.

For the Avery 18667 I set the button face up and use the overhang of the labels to position it, then flip the button over and trim the excess with an xacto knife.

I used acetone a few years ago when I did this Avery Label method--works pretty well if you just use a bit on a cotton swab and take a few swipes then repeat with a swab that has water; don't over do it or you'll pull the glossy finish off too much. EDIT: I can't find the original link, but if anyone is interested in the label method: That was what I did a few years ago, and they stood up to a lot of use. Ready to graduate to the lasers now though. Thanks to everyone who's posted their experience so far; will be trying this soon.

There is no way to set the scene parameters for a specific device without adding the device to the scene, which jumps to a default of 0.1/100. To recreate: 1) Set the OL/RR of a device and 2) add it to a new scene by itself as a controller. What you may be referring to is when you add a device as a controller to an existing scene, in which case, yes--the new controller will inherit the scene parameters for the other devices in the scene, but it will still overwrite it's own OL/RR to 0.1/100.