I just upgraded and so far so good. The IOLincs are again split into switch/sensor appropriately and I see my mini remotes as switches as well (not that I do anything with those currently via. hassio). I have set the clock back to 24 hour time, I’ll try restarting hass tomorrow again and see if it comes up correctly.
Thanks again for all the work you have done with this, things are looking really good!
Awesome. Thanks for the update. Keep me posted on any bugs.
For what it’s worth, the fix for the IOLinc being detected as a sensor has also fixed a similar issue I was seeing with the EZRain/EZFlora Irrigation system controller. It was appearing as eight sensors but now correctly appears as eight switches. Check another device off as good! 
I stumbled into a small issue this evening – similar to the above issue with IOLincs being detected as sensors instead of switches. This is happening with an Compacta/Smartenit EZIO2x4 module I have – it has two relays and four sensor inputs (two digital and two analog/digital). In my HA I see two sensors and four switches – they’re transposed. I’m guessing it’s the same or very similar problem as with the IOLincs but something unique to this module; it appears correctly in the ISY console (there the relays are identified as 1 and 2 and the sensors are 9, A, B, and C). @shbatm let me know if there is any more info I can provide to help diagnose and/or fix. 
(I am running the latest version from HACS, btw.)
Please post or send me the REST XML for the nodes (ether the section of /rest/nodes that contains these nodes or the individual /rest/nodes/ADDRESS results) and I’ll take a look.
Sent you a DM with the details. 
What version of ISY is everyone running? I am on 4.73, thinking about upgrading to 5.0.16
5.0.15. Haven’t upgraded to the 16RC yet.
I’ve been on v5 betas for ~2 years (I think) with a ~40 Insteon device network and really no significant issues caused by v5.
I have two – one at my place and one at my folk’s. They’re both on 5.0.13D and running with no problems that I’ve noticed.
I’ve been on 5 since it went into beta (5.0.16 atm), mostly because I wanted to play with the BlueIris and a couple other polyglot servers. It’s been working well, the only issues were getting everything working again after upgrading from 4.x.
Thanks everyone, I was able to upgrade to 5.0.16 with no issues.
Question…tonight I was playing around a bit with events, trying to capture an instant-on event.
The stock ISY994 component mentions these “isy994_control” events, which I do see firing, but they only seem to occur when my thermostats or motion sensors do something; I don’t see the events when anything else happens. That said, I’m still sort of new at this so it’s possible I’m doing something terribly wrong; I thought I’d bring it up here just in case something actually is broken.
Not exactly sure where your instant on event is coming from, but I use a double tap off to trigger a notification.
It looks like this in my automation:
alias: Notify Laundry timer on double tap off
trigger:
- event_data:
control: DFOF
entity_id: switch.laundry_light
event_type: isy994_control
platform: event
condition: []
action:
- delay: 01:10
- data:
data:
caption: Laundry is Done
message: Laundry is Done
service: notify.notifyall
Hope that helps in some way.
@danbutter, thank you for the example – it was helpful! With the nudge, I was able to figure out what was going on with my setup. Details follow…
I have two (8-button) KeypadLincs where the H buttons are linked together. This is defined as a scene in the ISY994 where both H buttons are “controllers” and, as such, HA sees it as a switch – this is all expected. The KPL buttons were “grouped” in the ISY so HA would only see a single device.
I was trying to tie the automation to the “switch” aka ISY scene with two KPL buttons in it. It appears that the isy994_control event is only generated by a specific device and it is not triggered when a device that is part of an ISY scene generates an instant-on/off event that would (de)activate the scene.
I was able to “fix” it by ungrouping the buttons for the KPLs in the ISY (which allows HA to see all eight buttons now) and then by tying the automation to the specific device (in this case, the H button on each KPL). I’m not sure if this is expected behavior, but what I will say is that it would be nice if the isy994_control event was fired when an instant-on/off event is generated by a device for a specific ISY scene. Not sure if this is something that’s possible without a major effort but it seems like it would be logical in terms of the way Insteon stuff operates.
@kbx81 Glad you got it working!
Any else see this message in their logs? Anytime I make change to the temp, I see this message.
3:01 PM custom_components/isy994/climate.py (WARNING) - message first occurred at 3:01 PM and shows up 2 times
@mbrunton I also see these messages/warnings whenever I trigger a change (manually or via an automation). Even so, the change still occurs so it doesn’t seem to be of any consequence – just noise in the log.
One behavior that I have noticed more recently is some strangeness with fan entities. I can’t quite put my finger on what’s happening but I can describe some behavior I’ve seen:
If I open the modal for a fan entity and select a speed from the drop-down, it doesn’t always “take”. For example, if I select medium, sometimes it bounces back to Speed, like if nothing is selected in the drop-down (which shouldn’t be possible – if the fan is off it should have off selected, otherwise some speed should be selected). When this happens, despite the weird UI behavior, the fan speed still gets set on the device. Clicking on the drop-down and selecting the speed again usually activates the speed in the UI, despite that the fan hardware at this point is already set to the speed I selected with the first attempt.
While this weirdness happens, it also seems to have some impact on the value in the fan entity’s entity.attribute.speed; an automation I have based on this doesn’t fire until the second (sometime third) time I select the speed in the UI. It’s pretty bizarre.
Even more odd is that this can happen when the speed is set by an automation. The automation that handles my climate control sets fan speeds. Sometimes I come home and, while the fan speeds are set correctly on the hardware, the automation I mentioned above (it sets KeyPadLinc button lights to correspond with the fan speed) hasn’t fired and the UI will again exhibit this behavior if I click into it.
That all said, I’m not sure if this is somehow related to the ISY integration or if it’s a HA bug. At the end of the day, everything works one way or another, the UI behavior is just a little off.
Sorry I’ve been away and haven’t had time to respond. I will say I’m an idiot and totally forgot there is logic in the custom component (my) version to ignore certain control events to avoid spamming the system. It was a good idea at the time, but I’ve since found value in having the individual on/off events as well as the device status changes. Edit these lines in your custom_component directory to remove DON, DFON, DOF, and DFOF until I can push an update.
I’ll double check on this one. I can’t remember if this is a limitation from the ISY or how the python module handles scenes.
I noticed similar issues with the fan-entity-row lovelace card where if I click MED, the fan goes HIGH, but if I click MED again, it gets set correctly. I think it’s related to the asynchronous updates (similar to the “on-off-on” behavior with a light toggle) but I have not been able to pinpoint it exactly (change drop down, command sent in background, UI updates based on current (old) state, device finally reports a change in state, UI/hass updates state to new state–somewhere in here there’s an issue).
Oh no worries! I’ve got everything working nicely now so I’ll wait for your next update to roll out.
Regarding the fan stuff, I’m just glad to know it isn’t just me. What you’re saying about async updates makes sense; pinning that down sounds like it will be…fun. 
Cheers!
Topic has been consolidated here: