No deviceFilter= for Events?

How come I can say

Code: Select all

    <Action id="sendir" deviceFilter="indigo.device,self.iremitter">


but I can't say

Code: Select all

    <Event id="ircomplete" deviceFilter="indigo.device,self.iremitter">


? (Well, I can but it's ignored.) Just as Actions can apply to devices, so Events can apply to them. Sure, I can put a menu-list field into the configUI of the Event, but why the visual discrepancy?

Cheers
-- perry

[jay (support)]

Because we believe that most device events will fall under the "Device State Changed" trigger, which already has built-in device selection.

We'll consider adding it to a future release.

Because we believe that most device events will fall under the "Device State Changed" trigger, which already has built-in device selection.

So in this very specific example - a transmission device and an action "send this IR command through this device" - how would you model "the command has been sent" as a "Device State Changed" trigger? Obviously I can make anything a state change trigger by simply having an ever-incrementing state counter (say, "number of successful transmissions"). Is that really what you think I should do instead of a plugin Event?

Cheers
-- perry

[jay (support)]

I'm not suggesting anything. I'm only telling you what our logic is for not supplying it in the current API. We don't think (at this moment) that your scenario is going to be very common (and we have a TON of other things to get done before GM) - but we're willing to revisit that in the future if it turns out that it's more common than we think.

I have little idea really what your plugin's archtecture is, so clearly you should do whatever is best for your device(s). If that means putting a device selection popup inside the event config then by all means do so - that's why it's there.

[jay (support)]

Although, if you're attempting to model the state of an IR emitter, it might very well be done better through states: idle, sending, receiving, and error? Unless there's some way to pair up the send message with some kind of confirmation, then that's really the only thing that you can realistically model, right?

I haven't thought too much about this though so I may be missing some critical piece of the puzzle.

Although, if you're attempting to model the state of an IR emitter, it might very well be done better through states: idle, sending, receiving, and error? Unless there's some way to pair up the send message with some kind of confirmation, then that's really the only thing that you can realistically model, right?

Yes, Consumer IR is all open loop - one of my design goals is to make it easy (well, easier) to close the loop within Indigo with whatever happens to be handy - LV sensors, IR receivers, power monitors, etc. (That's the glorious thing about Indigo - it can now combine different technologies to get stuff done.)

IR transmitters are very slow, so the software needs to queue up transmissions and then monitor as items pop off the transmit queue. I think I'll try a numeric "number of codes in queue" state and see where I get with that. Thanks for the hints.

And by the way, I really appreciate your rapid responses to all our questions. You're doing great.

Cheers
-- perry