Look at the event source.
> When you're debugging in Firebug or someplace, what does your call stack look like?
Look at the data passed to the event. The callstack starts at the function attached as a listener to the event.
Is the event data incorrect? Then the problem is in the code that triggers the event.
Is the event data correct? Then the problem is in the code listening to the event.
> Say I want to add a component to a page. Which events do I need to trigger > to make it do the kind of things I want? What do I need to pass as a > payload to those events?
Documentation. That is indeed the cost of using an abstraction that decouples code, but it's also a cost that has benefits - good documentation is useful.
> How do I know if there's a consumer for my event or not?
It's not important. That's the point of an event-based system, it's a decoupling. De-coupling is an abstraction. It works on pages that are based on components or modules.
If you don't want that abstraction, then using code based on that abstraction isn't a particularly good idea.
Event-based frameworks do need documentation - but reusable code should be documented anyway. There's just more emphasis on getting the documentation done in event-based systems.