Calling all ISY994 users!

Hardware
43

@OverloadUT,

Thank you for the feedback. The main question is this: do you get immediate status updates in the Admin Console? If so, it’s quite unlikely that the issue is in ISY since all event publications take the same path one of which is websockets (persistent connection). So, the first thing I recommend is to make sure:

  1. Whether or not you get immediate feedback on the Admin Console
  2. Whether or not the subscription is stale (you can use /rest/subscription and look for your subscription id)

With kind regards,
Michel

44

Yeah, I’ve been meaning to do some proper tests to isolate where the actual delay is occurring. Right now we’ve got:

Insteon Network -> ISY -> Websocket -> PyISY python code -> Home Assistant

Right now I can be reasonably confident that the issue is not with Home Assistant because I’m very familiar with everything that is happening in that code. So my next step will be to check for delays between Insteon->ISY, and Websocket->PyISY. If both of THOSE show clean, only then will I suspect we’ve got an ISY issue :slight_smile:

Now that I know we’ve got your attention here, I’ll do this testing sooner rather than later!

45

Hi OverloadUT,

Thank you. Before spending time sifting through the code, it’s quite important to check the Admin Console and make sure you get immediate status updates.

With kind regards,
Michel

46

Hi @mkohanim and @OverloadUT. Michel, thanks for proactively joining this conversation. I read your answer to my post on the UDI Forum, and could only do a more or less formal test today, all done from a user perspective. I will get wireshark captures with the actual network traffic, but wanted to share my preliminary findings now. I put the ISY Admin console side by side with the HASS web UI (the regular one, not the Lovelace one), ISY on left, Hass UI on the right, and used the Debut Screen recorder software to record first the audio of an insteon motion sensor button click, showing the state on the ISY Admin Console, then the updated status on the HASS UI. Unfortunately, the HASS forum does not allow me to upload video (it’s very small, around 1.7 MB), so I’ll have to send the video to @OverloadUT via email, and to you Michel, to the place you indicate. In summary, what the video indicates is that the first try around 00:04 I turn the sensor ON and the ISY admin displays ON almost immediately, but the HASS UI takes until 00:19 (15 seconds) to show that the sensor has detected motion. Then come a sequence of 10 transitions between OFF and ON that the ISY reflects immdeiately, and HASS follows very closely, which is what I expect. On the 11th transition (an ON) the ISY reflects the status almost immediately, but HASS takes once again 15 seconds to reflect the ON status. Don’t know what this shows, but that’s what I can say I can replicate almost consistently.

47

Hi @altersis,

Thanks so very much for the feedback. From ISY perspective, subscribers are notified in a queue. So, what your experiment tells me is that a) events are being published immediately and b) somehow HASS is not processing the events.

The next test would be to use /rest/subscriptions to see whether or not HASS is even subscribed. Maybe HASS has not subscribed to ISY or the subscription crashes and it’s retried after 15 seconds and it’s successful.

With kind regards,
Michel

48

Hey @OverloadUT, I have finally had the chance to set a proper environment to catch this problem. I’m going to send you an email with the video of the failure happening plus a wireshark capture with the traffic between the ISY and HASS. All details will be contained there. It appears to me that the ISY notifies HASS immediately about a state change, and once every few notifications, HASS takes 10-15 seconds to process it. From the wireshark trace I can see that this coincides with some sort of re-negotiation of the TCP session between the ISY and HASS, but my lack of understanding of the ISY api prevents me from understanding the exact problem. I hope this gives you enough to move forward. Now that I have setup the networking and figured out a way to capture the problem, I’m in a position where I can send you additional data if you need it, just let me know, ok?
Cheers!

49

Thank you very much @altersis; I am confident that you’ve found the smoking gun here. I didn’t get a chance to dig in to it this past weekend but I will get to this as soon as I can. The delay is devastating to my current automations and it’s on the top of my to-do list.

Pretty much all that’s left is to figure out if the drop and reconnect is caused by the ISY or the PyISY library we’re using on our side. If it’s the latter I’ll get it fixed, and if it’s the former I will create a simple script that reproduces the issue for @mkohanim without all of the complexities of the full Hass integration

50

Hi @altersis,

Thank you very much for the details. Just so that you don’t waste your time, the subscription socket (websocket) is persistent and thus there should not be any negotiations UNLESS it’s a new connection. So, based on what you are describing, I suspect the subscription is dropped and reconnected.

With kind regards,
Michel

51

Thanks Michel, I get the same impression. I would like to understand the protocol a bit more. Can you please point me to the manual/wiki that shows:

  1. How an event is represented and reported to the subscriber? From what I saw, it is an XML, but I would like to understand what each tag carries, and the sequence that is expected to happen.
  2. The data flow (I believe it is also an XML) used to drop and establish a subscription?

This will probably help me to understand a bit better what I’m seeing in WireShark, and possibly help @OverloadUT to focus on the code that is more likely to be giving us trouble.

Thanks in advance!

Altersis (I’m Gercas in the UDI Forum).

52

Anyone update to 80.1?
I did and isy is gone.
Logs say:
File “/usr/local/lib/python3.6/site-packages/homeassistant/setup.py”, line 148, in _async_setup_component
component.setup, hass, processed_config) # type: ignore
File “/usr/local/lib/python3.6/concurrent/futures/thread.py”, line 56, in run
result = self.fn(*self.args, **self.kwargs)
File “/usr/local/lib/python3.6/site-packages/homeassistant/components/isy994.py”, line 379, in setup
use_https=https, tls_ver=tls_version, log=_LOGGER)
File “/usr/local/lib/python3.6/site-packages/PyISY/ISY.py”, line 84, in init
self.nodes = Nodes(self, xml=self.conn.getNodes())
File “/usr/local/lib/python3.6/site-packages/PyISY/Nodes/init.py”, line 52, in init
self.parse(xml)
File “/usr/local/lib/python3.6/site-packages/PyISY/Nodes/init.py”, line 238, in parse
Group(self, nid, nname, members, controllers), ntype)
File “/usr/local/lib/python3.6/site-packages/PyISY/Nodes/group.py”, line 43, in init
self.update()
File “/usr/local/lib/python3.6/site-packages/PyISY/Nodes/group.py”, line 83, in update
if self.parent[m].status > 0:
File “/usr/local/lib/python3.6/site-packages/VarEvents/init.py”, line 255, in gt
return self._val > other
TypeError: ‘>’ not supported between instances of ‘NoneType’ and ‘int’`

53

@danbutter Looks like this issue: https://github.com/home-assistant/home-assistant/issues/17404

Please add any detail to that GitHub Issue if you have anything more to share, such as your ISY version. I’ll be fixing this as soon as I cave out some hours.

54

I looked at that link and seems to be the same situation I’m in. It has happened to me before also, but I thought it was because of something else at the time.
Right now I’m on 5.0.13A. Will get to 5.0.13D when time permits.

55

I posted this in the hardware forum but maybe the question is better asked here.

Is it possible to run multiple ISY-994i’s with Home Assistant? The Home Assistant documentation doesn’t indicate the possibility of more than one ISY.

The use case is two buildings each with its own ISY-994i controller and Home Assistant bridging between them.

56

Hi @OverloadUT, hope you are ok. Over the past few days, I have been working with Michel from UDI on the other problem I mentioned to you in my original responses to your thread (the ISY not turning on a device in 5.0.13D), and in that case, all points towards a problem with the ISY firmware. Are you still on one the 4.XX firmware versions of the ISY? Release 5.0.14 came out on Monday, so I’ll update my ISY tonight to see if this problem is still present in 5.0.14 (long shot, I know). Is there anything I can do to help you with the issue related to the event subscription?

By the way, do you have any idea of the number of folks using the ISY integration in HASS? I’m curious about this number…

Cheers,

Altersis

57

after I posted about this the first time I upgraded hassio and the ISY control came back.
Had several restarts messing with configs and it kept working.
Today upgraded to 0.81 and it still worked.
I tried to start messing with Tile Board today and when I restarted for that it gave the same errors again.
Not sure if this really means anything, but thought I’d share what I’ve seen.

58

Upgraded two more times and still not working.
Anyone know how to wipe the memory of the ISY component from HA so I can start over and see all my entities again?
I know I can start from scratch, but the rest of HA works well for me so I’d rather not have to do that each time this happens.

59

Hi @danbutter, I also have an ISY and have never seen this problem, but I’ll try to answer your question.

The ISY component does not have a “memory” per sé… when it is initializing, it queries the ISY to know which devices exist in it, and uses the entity registry to see if a definition for that particular device already existed in HASS. The entity registry is a file located in the .storage folder inside your config folder, which is commonly exposed through the Samba add-on. This is how the folder appears in the windows explorer. You’ll probably have to enable viewing hidden directories. The highlighted folder is the one that contains the entity registry.
image
This is a JSON file. You’ll have to edit this file while HASS is down, and eliminate all entries that have the value “isy994” in “platform”. For instance, this is a sample of an entry coming from the ISY:

image
image594×580 24.8 KB

Please be very careful when editing this file, when you eliminate an entry be certain to delete only the portions that I highlighted for you. We’re not supposed to edit this manually, but in your case it might be the only option.
Hope it works,

Altersis

60

Thanks for the reply. I had seen that file and noticed the isy references, but was kinda scared to mess with it.
I upgraded again to 81.5 and ISY is back. Gonna wait for a while before I do any more updates.

61

I have an ISY and its integrated with HA. I am currently running v4.7.3 on the ISY.

62

I’ve been using Home Assistant for a couple years now, and the ISY component integration has been nearly flawless, especially with the refinements this year. This weekend, I ran into an issue while adding binary_sensor status programs for some new ISY variables. The prior discussion concerning the entity registry in the .storage directory provided a workaround/fix for me. Thought I’d share…

Home Assistant is 0.81.5, while ISY is 4.7.3.

So the symptom, after adding the new program folder and status program in ISY, then restarting HAss, I could not find the new binary sensor in HAss. Looking at the dev-state page, I’d find something like the following:

binary_sensor.furnace_closet_leak on friendly_name: TempFolder

I noted that the new TempFolder binary sensor was getting confused with an old sensor/program for furnace_closet_leak, which was deleted some time back. From that it was obvious that the HAss/ISY integration was holding onto IDs for programs, even when they no longer exist. The new ISY program was obviously re-using an old ID, confusing the HAss ISY component. Looking in the .storage/core.entity_registry file, I saw the old association:

{
“config_entry_id”: null,
“device_id”: null,
“disabled_by”: null,
“entity_id”: “binary_sensor.furnace_closet_leak”,
“name”: null,
“platform”: “isy994”,
“unique_id”: “002C”
},

So, deleting that entry from the JSON, restarting HAss, I get the following:

binary_sensor.tempfolder on friendly_name: TempFolder

And:

{
“config_entry_id”: null,
“device_id”: null,
“disabled_by”: null,
“entity_id”: “binary_sensor.tempfolder”,
“name”: null,
“platform”: “isy994”,
“unique_id”: “002C”
}

With this corrected, I was able to proceed with configuration of the new binary_sensor, based on an ISY variable. Knowing this now, I will have to be mindful when creating new programs in ISY for use in HAss, as they will likely make use of other program slots in the ISY, and result in the same confusion.

So, has anybody else run into this? Found a better fix/workaround?

Thanks,
Sam