Virtual / Dummy device module

Is it possible to create a virtual module in Indigo?

ie. A device that pretends to be say an appliance module or dimmer and then takes the signals it is sent and executes code based on commands sent to it.

I seem to remember reading something about this at one point, but I can't seem to find it.

[matt (support)]

Not currently, but that is something we hope to add as part of a new plug-in architecture we are investigating.

well you can as an X10 module. just create it and since there is no 2-way coms (on most) Indigo won't complain. Then you can use your triggers and such.

well you can as an X10 module. just create it and since there is no 2-way coms (on most) Indigo won't complain. Then you can use your triggers and such.

Ah excellent. I can do that and tie triggers to it, I just want to be able to tie in some non-X10/Insteon devices (such as my rack power strip that I can control with SNMP), should be able to even create virtual 2-way with applescript and SNMP traps I think.

A native way as described above is still an appealing feature idea, but this should do until then.

Thanks!

-Chris

Matt - I was just curious how far along you are in conceptualizing this. I think it's a great idea and I would be likely to produce a few plugins if it comes to fruition.

From my perspective it would be ideal if plugins did everything via TCP/XML. This would allow plugins to be written under any license, in any language, and even to run on a remote system or embedded device. It would give them not only the ability to implement arbitrary devices but also to provide control logic and to generally have visibility of everything else in Indigo (as already provided for in the API).

I'm thinking that a device could be little more than some UI/syntax sugar around what is essentially a group of variables used by the plugin. A plugin would connect and say I'm this device and here is a list of my state parameters that I'll provide, and triggers that you can call. Even such a minimal interface could go a long way. I haven't given much thought to how "plugged-in devices" would look in Indigo's UI but I can imagine you have already...

I would imagine that most plugins would be scripts that run on the Indigo host, which in turn communicate with other devices over the network or a serial adaptor. It would probably make sense for Indigo to be responsible for launching the plugins in this scenario.

[jay (support)]

Matt - I was just curious how far along you are in conceptualizing this. I think it's a great idea and I would be likely to produce a few plugins if it comes to fruition.

From my perspective it would be ideal if plugins did everything via TCP/XML. This would allow plugins to be written under any license, in any language, and even to run on a remote system or embedded device. It would give them not only the ability to implement arbitrary devices but also to provide control logic and to generally have visibility of everything else in Indigo (as already provided for in the API).

I'm thinking that a device could be little more than some UI/syntax sugar around what is essentially a group of variables used by the plugin. A plugin would connect and say I'm this device and here is a list of my state parameters that I'll provide, and triggers that you can call. Even such a minimal interface could go a long way. I haven't given much thought to how "plugged-in devices" would look in Indigo's UI but I can imagine you have already...

I would imagine that most plugins would be scripts that run on the Indigo host, which in turn communicate with other devices over the network or a serial adaptor. It would probably make sense for Indigo to be responsible for launching the plugins in this scenario.

We're still hashing out the details, and your idea is interesting, but I think we're leaning towards something a bit more structured. However, if the "meat" of the plugin is off somewhere else, that would be fine. I guess what you're referring to as "UI/syntax sugar" feels much lighter than what we're planning, but in practice the plugin can do pretty much anything. And, certainly, we expect that many of the device plugins will be communicating via some type of network connection.

The other thing is that plugins will probably do more than just define devices: they can define events (i.e. iCal Event Starting), conditions (i.e. my friend is online in AIM), and actions (i.e. Post Tweet) that aren't necessarily tied to a device.

Of course, all this is still quite up in the air, but this is just what we're currently thinking.

...I'm thinking that a device could be little more than some UI/syntax sugar around what is essentially a group of variables used by the plugin. A plugin would connect and say I'm this device and here is a list of my state parameters that I'll provide, and triggers that you can call. Even such a minimal interface could go a long way. I haven't given much thought to how "plugged-in devices" would look in Indigo's UI but I can imagine you have already...

We're still hashing out the details, and your idea is interesting, but I think we're leaning towards something a bit more structured....

The other thing is that plugins will probably do more than just define devices: they can define events (i.e. iCal Event Starting), conditions (i.e. my friend is online in AIM), and actions (i.e. Post Tweet) that aren't necessarily tied to a device.

Of course, all this is still quite up in the air, but this is just what we're currently thinking.

My five cents would be to not complicate things too much, make different types of plugins that can be bundled together...

For example -- *.action & *.Event & *.device

- Benjamin