shbatm

As @MrBill said, that's a broad range, best course is to ask when you run into problems. That being said, some frequent topics: - Use HTTP not HTTPS to connect ISY to HA, unless you have a good reason (e.g. not a local, trusted network). It will be faster to respond and there are some ongoing Cypher issues we're working through with the newest version of python used by HA. - Make sure you have created at least (1) program, (1) state variable, and (1) integer variable on the ISY console. The lazy developer has not fixed the errors caused by not having these defined. - Use Insteon Scenes defined on the ISY where possible to control multiple devices. Using Scenes and Groups in HA will fire a single command for each device on the ISY which can cause changes to be delayed or commands dropped. Using an ISY scene and turning that on from HA fires a single command to the Insteon network. - You can use 'isy994_control' events in HA to pick up button/switch pushes from Insteon devices and control automations on the HA side. Eventually this will be migrated to HA's Device Actions that you'll see for other HA integrations, but it hasn't been changed yet. This allows you to separate a light being turned on from HA/Alexa/Google and someone physically controlling the switch. Comes in handy for things like using Keypadlincs to control Zigbee/WiFi lights for example. - You must reload the Home Assistant ISY994 Integration after you make changes in the ISY Admin Console, such as adding nodes and creating or renaming programs or variables. EDIT: Updated for PyISY 3.0.10 changes.

The easiest way is to use a web browser and go to http://yourisyipaddress/rest/networking/resources Use something like https://www.xmlvalidation.com/ to show you where the problem is.

I will take a look when I get a chance, but are you trying to set the init value or the current value? Does it give the same error for both? init: true sets the init value.

Glad you got it working. @MrBill thanks for the reminder I need to work on the fix for empty resources.

Echoing what others have said - Insteon Scenes (and actually Zigbee Groups and Z-Wave Associations) can be stored natively in the devices, so it only takes 1 network command to trigger a scene/group. Trying to create the scene/group in Home Assistant just results in individual calls to all of the devices which causes significant IP and insteon network traffic. Wherever possible, you should try and use the native groups. To handle this, Home Assistant exposes a state attribute "group_all_on" for each group/scene -- this is only "on" if all of the devices in the group are ON--not a guarantee that they are matched with the scene, but at least handles the case where one device of many is on and the group is shown as "on". More details here: https://community.home-assistant.io/t/isy994-hacs-version-with-pyisy-beta/166897/4?u=shbatm For scenes that should really be scenes (e.g. set lighting levels, not just a group of devices) in Home Assistant Dashboards I've found that its easier to use buttons and assign service calls (switch.turn_on / turn_off), rather than rely on the toggles from an entities card. Sending a "turn_on" service call to an ISY Scene will still cause it to trigger the scene--even if it already shows as "on" in Home Assistant. Also as an aside for keeping states in-sync when manually adjusting--adding in a link to an older post on "follower programs" that I use. The short version is--I use ISY programs to "watch" devices that should be in-sync, if they don't match after 2 seconds (which they should if the command was inside the insteon network/direct link, but not if it was a Home Assistant/Alexa command to a single device) the program updates the other statuses to match.

@dbb1 Did you get this resolved?

By the way, sometimes if you're not getting help on the HA Forums try reaching out on Discord or Reddit (r/homeassistant). Sometimes that's much quicker to get a response.

Good! Glad it was something simple. Guessing it was only selecting to the first ".". I know I've had issues before with shell scripts not liking it containing some special characters ("_" or " ' "), so just another couple gotchas to keep an eye out for in your testing.

Last thing: and not to insult your intelligence here, but asking the stupid questions: For the long-lived access token, you are not using the name of the token, correct? You need to use the full string it gives you when created (e.g.: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJiYzlkODU5NjM0MTc0MDI1ODRkZDIwMDcyN2MxMGMwMCIsImlhdCI6MTY2MDk0NjEyNCwiZXhwIjoxOTc2MzA2MTI0fQ.xP0aUadYH8nyf4F8-eBR39RPgtRW1LjLPdpkrj7bkEI)

If you haven't changed anything in configuration.yaml then don't worry about the default_config and http: comments. (default_config is the first line in the configuration.yaml file by default. http: allows you to add restrictions on IPs and proxies, etc). I'm about at a loss of things to try. Enable the debug logging level to see if there is anything helpful when you try to connect: - Developer Tools > Services > Logger: Set Default Level - In the yaml box: service: logger.set_default_level data: level: debug - Call Service (don't restart after, this won't persist across restarts unless you add it to configuration.yaml) - Then watch the logs under Settings > System > Logs > Load Full Logs About the only other thing I'd say is you can try to disable IPv6 (Settings > System > Network) and then try just over IPv4.

Another thing to check is running the curl command with a '-v' flag, just so it prints the headers and you can make sure nothing is getting mis-quoted, truncated, etc. curl -X GET -H "Authorization: Bearer LONGANNOYINGTOKEN" -H "Content-Type: application/json" -vv http://hass:8123/api/ Note: Unnecessary use of -X or --request, GET is already inferred. * Trying 192.168.x.x:8123... * Connected to hass (192.168.x.x) port 8123 (#0) > GET /api/ HTTP/1.1 > Host: hass:8123 > User-Agent: curl/7.74.0 > Accept: */* > Authorization: Bearer LONGANNOYINGTOKEN > Content-Type: application/json > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Content-Type: application/json < Content-Length: 26 < Date: Fri, 19 Aug 2022 20:27:00 GMT < Server: Python/3.10 aiohttp/3.8.1 < * Connection #0 to host hass left intact {"message":"API running."}%

That's what I was trying to link to

Are you trying to run your script on the Pi or from another computer? It shouldn't matter (Docker vs HA OS) if it's from another computer. Mine is from a WSL terminal to HA OS on a VM. It may be a little squirrelly if trying to do it from within HA OS on the same pi. If you have the SSH & Terminal add-on, you can try it from the terminal and see if it works. Nothing -- just to be able to distinguish tokens down the road if you have multiple and need to delete one. Do you have anything customized in your configuration.yaml file like removing `default_config:` or `frontend:` (frontend is included in default_config so one or the other), or restrictions under `http:`?

Some other things to try: 1. Try a new LLAT just in case. 2. use the mDNS name (usually `homeassistant.local` or IP address instead of localhost, just to confirm it's not a listening issue 3. Make sure your user with the LLAT is an Administrator (check here: http://homeassistant.local:8123/config/person) Also, attaching a script I've used for controlling a HA plug with a Raspberry Pi GPIO, just in case it helps. 3d_printer_power.py

Also, are you using HTTP or have you set up any SSL/HTTPS on your HA Instance? Just to confirm the following worked fine for my instance on HA 2022.8.3 curl -X GET -H "Authorization: Bearer LONGLIVEDACCESSTOKEN" -H "Content-Type: application/json" http://homeassistant.local:8123/api/states

Just to confirm: the Bearer token you are using is a Long-lived Access Token created from your profile?

Here's my working example. Loose the value line. trigger: - platform: event event_type: isy994_control event_data: entity_id: light.art_light control: DFOF

2 options that I use: - Use a State Variable that you change with a home assistant service call and a program on the ISY that sets the backlight to match the state variable. - Generic On/Off: use ISY programs to create a custom switch to turn the backlight on/off from Home Assistant Here's my example for the second one:

What kind of devices are the controllers? Is one a battery operated device or a Keypadlinc secondary button? Are they both set to controllers in the scene?

Here's my workaround for this scenario. Let me know if you have any questions This let's you use the load controlling device directly from 3rd party controllers (HA, Alexa, etc) and will keep the other devices in sync. It waits 2 sec just to allow Insteon traffic to clear and to make sure it wasn't a local button press (which would sync everything by itself).

You should be able to use a template in the service call, something like: value: "{{ states('sensor.entity_id') | int}}"

Have you tried a full restart of Home Assistant itself? Looks like it's getting hung up on something in a Scene. If the full restart doesn't fix it, try enabling debug logging, re-add the integration and post back the details:

In the Admin Console check which tab you are on under Variables.

Make sure you use a state variable and not an integer variable for the status. Integer variables will not update.

Chiming in on migrating from the Home Assistant side. There are two main issues when migrating that could cause some hiccups: IP Address and MAC Address changes -- Home Assistant doesn't provide an easy way to to change IP addresses of an integration (yet, I know it's been discussed), and the ISY994 integration uses the MAC Address to set the unique IDs for each entity--this is to allow multiple ISYs to be used simultaneously. Migration Options -- (disclaimer: YMMV, and you should ALWAYS backup your Home Assistant config before messing with anything in `.storage` or making significant changes, I'm not responsible if you bork your installation). 1. If you have not done a lot of `entity_id` renaming inside Home Assistant, the easiest way to migrate is to remove and re-add the integration. Once you re-add the integration and it reloads, it's best to restart HA, but not entiriely necessary. Your renaming of `entity_id`s and friendly names will need to be redone. 2. Using a text editor: Find and Replace all instances of the old ISY IP address and MAC address with the new Polisy details inside the following files in your config directory, then restart Home Assistant (safest to stop HA first, but you can do it online as well). core.config_entries core.device_registry core.entity_registry