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.
So let me reiterate, these are the possible scenarios. I haven’t tested them all out but I will when I get a chance. Do you know if there is a way to see when a command was executed, specifically when HA starts to send a command to the isy component and send a webhook?
- ISY Portal -> ISY994 -> device/scene = FAST
- Google Assistant/Home & Alexa -> ISY Portal -> ISY994 -> device/scene = FAST
- HA (via native imported ISY994 devices) -> ISY994 -> device/scene = SLOW
- HA (via web hook) -> ISY Portal -> ISY994 -> device/scene = ???
- HA (via web hook) -> ISY994 -> device/scene = ???
Yeah, so that’s definitely not what I experience. However, I am not sure what you mean by “via web hook.” Are you using the ISY994 component or doing something on your own? There is absolutely no reason to have Home Assistant, which is on-prem, talk to the ISY Portal, which is in the cloud, which then goes BACK to on-prem for the ISY994. That would most definitely add slowness, and is not how this component works. Part of the whole point of Home Assistant is local to local control whenever possible.
Here is the full communication path for various implementations:
Without Home Assistant:
ISY994 Frontend -> ISY994 Backend -> Insteon PLM -> Insteon Device
Alexa Device -> Amazon’s Cloud -> ISY Portal Cloud -> ISY994 -> Insteon PLM -> Insteon Device
With Home Assistant:
Home Assistant Frontend -> ISY994 -> Insteon PLM -> Insteon Device
Alexa Device -> Amazon’s Cloud -> Nabu Casa -> Home Assistant -> ISY994 -> Insteon PLM -> Insteon Device
I use the last two cases extremely frequently on a daily basis and can say with confident that it’s ultra fast. There is no discernable delay when using the Hass frontend, and when using Alexa command I get the full resolution in about a second which is on-par with other home automation skills.
The only slowness that has been confirmed to be a technical issue somewhere in the chain is this:
Insteon Network -> Insteon PLM -> ISY994 -> Websocket to Home Assistant -> Change Reflected in Home Assistant
We’re not sure where exactly the issue lies in this chain, but I believe it’s on one side of that websocket step. At any rate, this known issue would not affect any of the scenarios you presented. I suggest that you turn on verbose logging in your ISY994 component and submit some clean logs showing some simple flows that are being super slow .
are there plans to support thermostats through the ISY component?
There is a thread about it in the feature requests section. I would love to see that myself. I have to keep going back to the isy webpage if I want to interact with the thermostats
Yep, I will be adding Thermostat support pretty soon. A Home Assistant user kindly donated their old thermostat to me so that I have one to develop against. And it’s getting cold, so I’ve got strong motivation to add it
awesome, thats great news, thanks!
Just added the new Motion Sensor II to my ISY and after restarting HA I get the following error:
Error while setting up platform isy994 Traceback (most recent call last): File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/helpers/entity_platform.py", line 128, in _async_setup_platform SLOW_SETUP_MAX_WAIT, loop=hass.loop) File "/usr/lib/python3.6/asyncio/tasks.py", line 358, in wait_for return fut.result() File "/usr/lib/python3.6/concurrent/futures/thread.py", line 56, in run result = self.fn(*self.args, **self.kwargs) File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/binary_sensor/isy994.py", line 55, in setup_platform subnode_id = int(node.nid[-1]) ValueError: invalid literal for int() with base 10: 'D'
This seems to have the affect of not finding any of the binary_sensors for ISY (old and new motion sensors).
I think I found the solution. When I added the new sensor ISY did not group the sub sensors (motion enabled and motion tamper, with it) I selected group sensors and that seemed to correct the issue.
I think the error you are seeing is the Home Assistant ISY Component assuming the node number is decimal instead of hexadecimal. Previous Insteon devices only had a few nodes so this was not a problem. The new Motion Sensor II (well new to ISY-994 users which only recently supported the Motion Sensor II) has a bunch of nodes and the number extends into the hexadecimal range (above 9).
Node D is the Motion Enabled node and is enabled by default. If you look at the Options page in the ISY-994 Admin Console for your Motion Sensor II you will see at the bottom of the list “Misc Nodes” and “Motion Enabled”. Set it to “None” and the node will disappear. Note there are other nodes you can enable like Low Battery.
Your second message indicated grouping the nodes together fixed your error. While this is true it fixed your error by hiding all nodes except the top node in Home Assistant. This is true for all grouped Insteon nodes in Home Assistant. I don’t know if this is a feature of the ISY-994 or the ISY-994 component in Home Assistant.
Just curious…what type of thermostat do you have? Insteon or zwave?
I have two zwave thermostats and would be happy to help test.
Well assuming I have access to the ISY at the time.
Still struggling with this off and on:
Thus far I have not done any development or testing of Z-Wave devices via the ISY994, as I do not have a Z-Wave module in my ISY, and I have been personally satisfied using a Z-Stick managed directly by Hass.
I would like to eventually dive in to making Z-Wave work via the ISY994 component as well as everything else, but it’s way down on my priority list.
So I tried this today since I have once again come across the issue with the ISY component not working and getting the following errors:
018-12-14 18:08:45 ERROR (MainThread) [homeassistant.setup] Error during setup of component isy994
Traceback (most recent call last):
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
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
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’
So I took my time and deleted everything that had isy in it which is a lot for me.
No dice same issue.
So I took a spare sd card, downloaded the latest hassio image and loaded it up.
I did nothing else for configuration other than add the basic isy stuff of:
and rebooted and got the same as above again.
I am using the latest 5.0.14 firmware, but it has worked while I was on this firmware…just intermittently.
I have tried to make sure all the names of all the things in ISY have no spaces, tried nothing grouped in ISY.
Tried adding variables and removing them all to no avail. Config checker says valid as it always has.
Anyone think of anything I can look at to try and make this work again?
Michel from UDI replied to a post of mine on their forum here:
Seems PyISY may need to be updated as the more updated firmwares are changing the way things work.