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:
Insteon thermostat.
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
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â
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:
isy994:
host: ISY_ADDRESS
username: ISY_USERNAME
password: ISY_PASSWORD
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.
1 Like