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
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:
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).
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’`
@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.
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.
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.
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
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.
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.
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.
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:
Altersis
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.
I have an ISY and its integrated with HA. I am currently running v4.7.3 on the ISY.
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
Is there any support to get motion sensor battery levels in HA?
It’s on my backlog but lower down the list. Unfortunately the way Insteon motion sensors report battery level leaves a lot to be desired. Instead of sending a daily heartbeat like the door sensors do, they send a SINGLE “low battery” signal when they are getting low. This is frustrating to develop for because I can’t really trigger that happening from the real device, and it takes months for it to happen for real.
In addition, this method is prone to error - if Home Assistant misses the signal, either due to normal Insteon network unreliability, or HA being unavailable at the moment the signal is sent, we’d entirely miss the low battery notice.
So in the end, I haven’t found it worth my time to implement so far. I still want to do it, and it’s still on my list, it just feels like a low ROI for the effort it will take to implement.
Thanks for that info. Based on your insight might explain why my isy rules only work on low batt about once in 20. That is a poor signal protocol and means even if you did support it, its usefulness might not be any good due to the devices poor design.
Does anyone else have an issue with HA groups containing lots of ISY devices not all triggering? For example, I have a group called ‘First Floor Lights’, which contains roughly 14 ISY devices… when I call it on or off, only 1/3 go at a time, a second off call does another 1/3 and so on…
Same goes for my Kitchen Lights group… calling it turns on or off 5/7 lights… Seems like something is getting lost along the way.
Yes, the same thing would happen if you tried to rapidly change 14 ISY devices sequentially from the ISY interface. What is needed is probably a configurable delay between each device when a group is triggered, but I’m not sure the light and switch components are set up to do this well; I’ll have to check.
Most definitely the preferred way to do this, and the way I do it, is to make use of Insteon scenes and trigger those in your automations rather than large groups of individual Insteon entities.
@altersis before I started using HA, I used the ISY portal (subscription service) in which you can expose ISY994 scenes and switches. That is very fast to respond, less than a second most times. When I link that to Google Assistant, it too is very fast to execute commands. I guess the trick would be to figure out how the portal communicates to the ISY and emulate that. The only other cause could be the “action” on HA is taking longer than it should to send the command to the ISY994.
Every step in the chain is going to add some amount of latency, for which there is no way to avoid. However, we should be able to make that latency be very small.
I can say that I use Alexa to trigger ISY devices every day, and they are always about ~1 second to respond after the command is interpreted.
If you’re seeing slower performance, that’s new information to me. We know that there are currently intermittent issues with getting updates FROM the ISY, but not the other way around.
