With Lee’s help I’ve been able to shed some light on this behavior.
It appears that the device state is maintained in the cluster entries in the devices file. I’m guessing that in order to establish protocol independence, the EZSrve actions process checks the cluster “status” entry for devices rather than parsing the Insteon (or other protocol) XML traffic. The CID=0 cluster has a status field that reflects the last event for that device (i.e. 0x02, 0x03, etc. for X10, 0x1101, 0x1301 for Insteon). When you restart the EZSrve and it loads the actions, for those with a device status condition, the EZSrve appears to check the cluster status entry and fire the effect if the status matches the condition.
I edited a saved devices.xml file to zero out the CID=00 status entry in the devices file for all but one of the X10 devices I am using to trigger scenes. I reloaded the devices file, restarted the EZSrve and rather than multiple flashing lights, the only scene that triggered was the one associated with the one X10 device I left alone. I also tested an action with a condition with an Insteon trigger and the effect occurred on startup when the device status in the cluster entry matched that trigger.
So in the future, I’ll be loading a “clean” devices file before I restart the EZSrve if my wife is around…
