Michel Kohanim Posted June 7, 2021 Posted June 7, 2021 @asbril, Do you have any network resources with names that contain &? If so, rename them and see whether or not the issue is solved. With kind regards, Michel
asbril Posted June 7, 2021 Posted June 7, 2021 1 minute ago, Michel Kohanim said: @asbril, Do you have any network resources with names that contain &? If so, rename them and see whether or not the issue is solved. With kind regards, Michel Hi Michel As you know I am not really technically advanced and the truth is that I don't understand what is meant with network resources and therefore don't know if I have any and where to find them. I am late bloomer with tech and the blooming is slow
Michel Kohanim Posted June 7, 2021 Posted June 7, 2021 @asbril, Configuration tab / Networking/ Network Resources. With kind regards, Michel
asbril Posted June 7, 2021 Posted June 7, 2021 2 minutes ago, Michel Kohanim said: @asbril, Configuration tab / Networking/ Network Resources. With kind regards, Michel It shows that I have no networking resources
asbril Posted June 7, 2021 Posted June 7, 2021 2 hours ago, MrBill said: if you're not used to reading the github issues and linked issues, the reason they closed your issue this morning is because 2021.6.3 will have the 60 second setup timeout. (probably based on what Javi said above) It's the same thing that your trying to load HACS so that you can install a special beta branch. @MrBill Any idea when 2021.6.3 will be available ? And what do you mean with " special beta branch "
MrBill Posted June 7, 2021 Posted June 7, 2021 1 hour ago, asbril said: @MrBill Any idea when 2021.6.3 will be available ? And what do you mean with " special beta branch " I don't know exactly how they schedule releases but it shouldn't be long. It looks like they are waiting on 4 other issues to close (but that doesn't mean they will wait for those either, they could bump one or more of those 4 to 2021.6.4. The "special branch" was what you were trying to do with HACS. A short explanation is that HACS is the Home Assistant Community Store. When you have it installed, it goes out to github and finds "projects" that are available to be installed with Home Assistant. Sometimes these are new things that may someday be released, sometimes it's a beta project, or sometimes its just something deemed so small who would be interested it will always just be available by HACS. In this case there was a beta project for the improvements to the released version of the UDI integration. I've been using the beta since about January and have not had any problems, I even suggested a change to how Insteon wireless devices work, and it was included. In 2021.6.0 all the changes that have been beta since that project started about a year ago were rolled into core. For reasons unknown exactly 2 people had a problem (so far)... you and me... mine went away for reasons unknown and I've tried to reproduce it several times since and can't. Yours persisted. Shbatm then created a new special branch of the beta for you to try, the only thing the "special branch" did was extend the timeout from 30 to 60 seconds.... they have now sent that change to the core release 2021.6.3 which will be released likely in the next few days.
asbril Posted June 7, 2021 Posted June 7, 2021 22 minutes ago, MrBill said: I don't know exactly how they schedule releases but it shouldn't be long. It looks like they are waiting on 4 other issues to close (but that doesn't mean they will wait for those either, they could bump one or more of those 4 to 2021.6.4. The "special branch" was what you were trying to do with HACS. A short explanation is that HACS is the Home Assistant Community Store. When you have it installed, it goes out to github and finds "projects" that are available to be installed with Home Assistant. Sometimes these are new things that may someday be released, sometimes it's a beta project, or sometimes its just something deemed so small who would be interested it will always just be available by HACS. In this case there was a beta project for the improvements to the released version of the UDI integration. I've been using the beta since about January and have not had any problems, I even suggested a change to how Insteon wireless devices work, and it was included. In 2021.6.0 all the changes that have been beta since that project started about a year ago were rolled into core. For reasons unknown exactly 2 people had a problem (so far)... you and me... mine went away for reasons unknown and I've tried to reproduce it several times since and can't. Yours persisted. Shbatm then created a new special branch of the beta for you to try, the only thing the "special branch" did was extend the timeout from 30 to 60 seconds.... they have now sent that change to the core release 2021.6.3 which will be released likely in the next few days. Thanks so much for your lengthy explanation. I now understand that I don't have to worry that HACS does not work and just have to be patient for 2021.6.3 ! I can do that . 1
asbril Posted June 8, 2021 Posted June 8, 2021 (edited) 2021.6.3 came out and it did the job...... Thanks @shbatm and @MrBilland @Javi Edited June 8, 2021 by asbril 2
smacbride Posted June 8, 2021 Posted June 8, 2021 I posted a few days ago that I upgraded to HA 6.2 and it was working, but I have since discovered an issue. I have HA setup with two ISY boxes, one local using a local IP, one in a vacation home using the UD portal URL. Since upgrading to 6.2, the local ISY works, but the one using the portal URL does not. When you turn on a light in the HA dashboard, the light turns on but then the display in the dashboard immediately toggles showing the light as off, even though it's still on. Re-loading the integration shows the correct status, but then when you toggle the light off, it immediately flips back to show on. I tried upgrading to 6.3, and the problem still exists. I reloaded a 5.5 snapshot and the problem went away, everything is back to normal. So something in the 6.x branch has broken the connection to my ISY on the UD portal.
shbatm Posted June 8, 2021 Posted June 8, 2021 17 minutes ago, smacbride said: Since upgrading to 6.2, the local ISY works, but the one using the portal URL does not. 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.
smacbride Posted June 8, 2021 Posted June 8, 2021 @shbatm Disabled the local ISY integration: The problem still exists. Added the debug to the config (this turned off the light, but it still shows as on): 2021-06-08 15:47:09 DEBUG (MainThread) [pyisy] ISY Request: https://my.isy.io:443/rest/nodes/57 FA EF 1/cmd/DOF 2021-06-08 15:47:09 DEBUG (MainThread) [pyisy] ISY Response Received. 2021-06-08 15:47:09 DEBUG (MainThread) [pyisy] ISY command off sent to 57 FA EF 1. 2021-06-08 15:47:15 DEBUG (MainThread) [pyisy.events.websocket] Starting websocket connection. 2021-06-08 15:47:15 DEBUG (MainThread) [pyisy.events.websocket] Websocket Server Not Ready. 2021-06-08 15:47:15 DEBUG (MainThread) [pyisy.events.websocket] Stopping websocket connection. 2021-06-08 15:47:15 INFO (MainThread) [pyisy.events.websocket] PyISY attempting stream reconnect in 60s. 2021-06-08 15:48:15 DEBUG (MainThread) [pyisy.events.websocket] Starting websocket connection. 2021-06-08 15:48:16 DEBUG (MainThread) [pyisy.events.websocket] Websocket Server Not Ready. 2021-06-08 15:48:16 DEBUG (MainThread) [pyisy.events.websocket] Stopping websocket connection. 2021-06-08 15:48:16 INFO (MainThread) [pyisy.events.websocket] PyISY attempting stream reconnect in 60s. 2021-06-08 15:49:16 DEBUG (MainThread) [pyisy.events.websocket] Starting websocket connection. 2021-06-08 15:49:17 DEBUG (MainThread) [pyisy.events.websocket] Websocket Server Not Ready. 2021-06-08 15:49:17 DEBUG (MainThread) [pyisy.events.websocket] Stopping websocket connection. 2021-06-08 15:49:17 INFO (MainThread) [pyisy.events.websocket] PyISY attempting stream reconnect in 60s. Here is the health status: Universal Devices ISY994 Host Reachable ok ISY Connected true Last Heartbeat Time Event Socket Status reconnecting
shbatm Posted June 9, 2021 Posted June 9, 2021 (edited) 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. Edited June 9, 2021 by shbatm
smacbride Posted June 9, 2021 Posted June 9, 2021 @shbatm I tried that and got the same results. It turns on the light but the status flips back to off: 2021-06-09 07:30:28 DEBUG (MainThread) [pyisy] ISY Request: https://my.isy.io:443/isy/{unique_url}/rest/nodes/57%20FA%20EF%201/cmd/DON 2021-06-09 07:30:29 DEBUG (MainThread) [pyisy] ISY Response Received. 2021-06-09 07:30:29 DEBUG (MainThread) [pyisy] ISY command on sent to 57 FA EF 1. 2021-06-09 07:30:31 DEBUG (MainThread) [pyisy.events.websocket] ISY HEARTBEAT: 2021-06-09T07:30:31.986441 2021-06-09 07:30:34 DEBUG (MainThread) [pyisy.events.websocket] Starting websocket connection. 2021-06-09 07:30:34 DEBUG (MainThread) [pyisy.events.websocket] Websocket Server Not Ready. 2021-06-09 07:30:34 DEBUG (MainThread) [pyisy.events.websocket] Stopping websocket connection. 2021-06-09 07:30:34 INFO (MainThread) [pyisy.events.websocket] PyISY attempting stream reconnect in 60s.
stevesreed Posted August 14, 2021 Posted August 14, 2021 I recently setup HASS and have most things working very reliably. I did it primarily for Homekit access and overall it seems more reliable and responsive than my previous homebridge setup. The one issue I have not been able to sort out is that one of my variable based switches (using the HA.switch folder setup) turns on in HASS every night around midnight, even though the state variable it is based on does not change and is still false. The rest of the time The HASS switch properly mirrors the state variable when changed by the ISY, and it updates the state variable correctly when changed via HASS. Has anyone else seen anything similar to this? I do have a program that runs at midnight to turn off a bunch of stuff, make sure the doors are locked, etc. but none of that changes the variable in question.
Mecheng70 Posted August 14, 2021 Posted August 14, 2021 Have you checked the ISY program details to determine if a program ran at that time? Check time stamps on all things connected to that state variable and or device.
stevesreed Posted August 14, 2021 Posted August 14, 2021 3 hours ago, Mecheng70 said: Have you checked the ISY program details to determine if a program ran at that time? Check time stamps on all things connected to that state variable and or device. Thanks, I forgot about the Program summary page. I'll check that right after midnight. I also just found out about "pyisy: debug" logging. I had perviously enabled "homeassistant.components.isy994: debug" but that did not give much info. pyisy: looging shows when programs are updated, which is very helpful.
stevesreed Posted August 15, 2021 Posted August 15, 2021 (edited) According to the Isy's program summary, the status program for the switch last ran at 2:55 am 8/15/21, and the status is true. However the state variable is false and says it last changed at 9:02pm, and the status program is a single line: "if vs.Movie_ighting_Switch is 1" How can the program status be true if the state variable is false? Also why did the program run at 2:55am if the state variable did not change since 9:02pm 8/14/21? Edited August 15, 2021 by stevesreed
Mecheng70 Posted August 15, 2021 Posted August 15, 2021 I don't know if this helps or not, but I always have the is and is not as AND in the IF statement. is 1 and is not 0 Also, I have not set up my system with the HA. prefix for anything. Here are my settings in HA. All my state variables have s. as the prefix.
stevesreed Posted August 15, 2021 Posted August 15, 2021 (edited) 1 hour ago, Mecheng70 said: I don't know if this helps or not, but I always have the is and is not as AND in the IF statement. is 1 and is not 0 Also, I have not set up my system with the HA. prefix for anything. Here are my settings in HA. All my state variables have s. as the prefix. I'll try adding "not 0", though that seem redundant. I think the sensor prefix only works for sensors. I want to show the variables as switches in homekit, so I can tell Siri to turn on/off movie lighting, etc. Edited August 15, 2021 by stevesreed
Mecheng70 Posted August 15, 2021 Posted August 15, 2021 (edited) Are you using an integer variable for the actual number other than 0 or 1? Use a state variable for anything 0 or 1. I am able to name integer and state variables with the prefix s. and have then show up in HA. I use an input text to change a variable in HA and then a script that changes the variable on the ISY if the number changes, then the ISY number will update showing that the number has changed. Also have HA update the init value incase there is a power glitch. Been using this with reprogramming the door code for visitor on the airbnb. Edited August 15, 2021 by Mecheng70 clarified
stevesreed Posted August 15, 2021 Posted August 15, 2021 My primary reason for using Home Assistant so far has been to enable Homekit integration with my ISY994 and all my devices. I've just recently migrated from using homebridge to Home Assistant+Homekit integration. For Homebridge there was a plug in (homebridge-isy-maker) that let you add virtual devices for Homekit by just naming state variable in a specific format. So I could make a virtual switch named "movie lighting" and have Siri turn it on and off by saying "Hey Siri, turn on movie lighting". In Home Assistant, variables with the sensor prefix show up as sensors and then in Homekit as read only. Using the the HA.swith program directory setup I can add them as switches and they show up in Homekit correctly as switches. Everything works great except for the mystery of the status program running and going to true on it's own, out of sync with the State Variable. I've made the change you suggested, so we'll see if it does it again tonight.
shbatm Posted August 15, 2021 Posted August 15, 2021 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 1
stevesreed Posted August 16, 2021 Posted August 16, 2021 The "Query All" program runs at 3:00:00 am. However, in looking into it, I noticed my "midnight shutdown" script runs a second time at 2:55am (I forgot I added that a while ago). It sets vs.Movie_Lighting.Switch to 0, so that is what causes the program to run, but it should eval to false. Maybe ISY is confused, since so many variables are set and devices are being turned off at that time? I tried using the if $vs.Movie_Lighting.Switch is 1 and $vs.Movie_lighting.Switch is not 0, but it still ran and evaluated as true last night. I'll try the template on the HA side, that should work. I'm new at HA and just learning templates, etc. I probably should have used that to start with, instead of HA virtual switch feature for ISY. I'm still a little concerned about the ISY running the program and returning an incorrect evaluation. The only other thing I can think of is the name of the program is "status" which is the same as several other programs in different folders (though those seem to evaluate correctly). Maybe ISY is confused by that somehow and is reporting a different status programs results for the one in "HA.Switch/Movie Lighting" folder.
MrBill Posted August 16, 2021 Posted August 16, 2021 37 minutes ago, stevesreed said: runs a second time at 2:55am (I forgot I added that a while ago). It sets vs.Movie_Lighting.Switch to 0, so that is what causes the program to run, but it should eval to false. Maybe ISY is confused, since so many variables are set and devices are being turned off at that time? Without seeing the program it's hard to second guess, but many people are surprised how often the Else clause of a program gets run, i.e. anytime the IF evaluates to false the Else statements execute. Most programs with compound If statements surprise users that if the program starts, then either Then or Else is going to be executed. 46 minutes ago, stevesreed said: The only other thing I can think of is the name of the program is "status" which is the same as several other programs in different folders (though those seem to evaluate correctly). The ISY internally only knows the program by it's ID number, the name string is simply attached to the ID number, it will not confuse programs with the same name. EXCEPTIONS: 1) Running ISY programs from other ISY programs. If you have multiple programs named for example "Alexa.on" will only be able to choose from one of them in the admin console dropdown, therefor to run an ISY program from another ISY program, then program being run must have a unique name. 2) When Running an ISY program from HA (using call service). The namespace of program names that HA creates when does NOT include folder or path information, only program name. You must be certain the ISY program has a unique program name to run it via NAME from HA.
Recommended Posts