@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.
The Device Grouping thing is a known issue with PyISY (the module HA uses). Glad you found out that the devices have to be ungrouped to be properly detected.
I’m away this week and will have to look at exactly what events are received for scenes from the ISY’s event stream. My recommendation for now would be to use something like @danbutter recommended for your automations and use an “OR” condition, one for each device you have as a Controller in the ISY scene, if you want to detect DFOF or DFON events.
@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.
