PERL API

[sidlinger]

Wouldn't that be a cool feature!

 

If everything was exposed via SNMP and/or a PERL API then, for large/commercial applications, none of the GUI stuff would matter at all.

 

Wish list:

 

Full SNMP implementation including (especially) traps (not only for errors but also for INSTEON events) and a nice MIB

 

PERL API

 

Syslog

 

NTP

 

Provisions for redundant ISYs (e.g., that sync each other, etc.)

 

And maybe DynDNS for residential applications

 

-Bruce

[Mark Sanctuary]

Funny, there was another language just suggested too in the Lua Thread. I would tend to lean toward Perl or Tcl myself, but really we have to ask, "What is the best choice language for the Home Automation world?"

[Michel Kohanim]

Bruce,

 

Thanks so very much for the suggestion and feedback. Please see my comments below.

 

With kind regards,

Michel

 

Wouldn't that be a cool feature!

 

If everything was exposed via SNMP and/or a PERL API then, for large/commercial applications, none of the GUI stuff would matter at all.

Perl is mostly used as server side scripting. With our Web Services, you can do everything you can imagine without our GUI. Unfortunately, although we might include SNMP, but including Perl is a little bit outside of our realm and strategy as we move more towards a network appliance than a server environment.

 

Full SNMP implementation including (especially) traps (not only for errors but also for INSTEON events) and a nice MIB

We have it our list but at a low priority

 

PERL API

Please see above

 

Syslog

Please be more specific as to what you would in addition to what we already have

 

NTP

Yes!

 

Provisions for redundant ISYs (e.g., that sync each other, etc.)

Possible but we have to fully understand the use cases

 

And maybe DynDNS for residential applications

We might have provisions to recommend a dynamic dns solution (such as DynDNS). This said, however, why should we implement something that's already provided by ANY router especially in residential applications?

 

-Bruce

[evilpete]

Wouldn't that be a cool feature!

 

If everything was exposed via SNMP and/or a PERL API then, for large/commercial applications, none of the GUI stuff would matter at all.

 

Wish list:

 

Full SNMP implementation including (especially) traps (not only for errors but also for INSTEON events) and a nice MIB

 

PERL API

 

Syslog

 

NTP

 

Provisions for redundant ISYs (e.g., that sync each other, etc.)

 

And maybe DynDNS for residential applications

 

-Bruce

 

 

I also would love to see a PERL API as well as the ability to send log event via syslog.

[Michel Kohanim]

Hello evilpete,

 

I like the idea as well. This said, however, we must first implement support for increasing number of INSTEON devices and thus taking up RAM/CPU for other tasks takes a lower priority.

 

With kind regards,

Michel

[rickerdo]

Not to beat a dead horse (again), but no programming language would be needed if a serial interface existed. Why? Because whatever language is native to the system (outside of the ISY) can be used to send and receive simple ASCII commands.

 

Just my $.02 [again].

[evilpete]

I've begun throwing together a Perl based api that utilizes the REST interface.

 

I'm looking for input on what level of functionality to implement.

 

so far I have :

 

• 
  node_comm : Send a command to an Insteon device ( by name or addr )
   
  send_comm_simple : Send a command to an Insteon device
  (by address only intended for quick simple command with of Oo init delay )
   
  node_status : get status of an Insteon device ( node->property->value )
   
  node_names : returns a list of Insteon device names / addresses
   
  node_query : return all device properties
   
  x10_comm : send an X10 command by X10 addr
   
  prog_names : returns a list of programs
   
  prog_status : get status of program by name
   
  prog_query : return all device properties
   
  prog_comm : Send a command
   
  log_query : retrieve and parse log
   
  log_reset : reset the logs
   
  var_status : returns a hash of variables and their value.
   
   
  

 

any ideas / suggestions or requests ?

[Michel Kohanim]

Hello evilpete!

 

This is great! Thanks so very much ...

 

With kind regards,

Michel

[evilpete]

Hello evilpete!

 

This is great! Thanks so very much ...

 

With kind regards,

Michel

 

 

One thing I have bumped into is that device / program names are not unique, this is a problem since in the Perl API one can address devices and programs by their name or ID. If two programs have the same name this creates a minor problem.

Similarly with device ( node ) IDs (although the user can look up and use the Insteon Device hex address).

 

 

I have also noticed that when you query the logs ( or error logs ) you get a 404 error if the log file is empty ( recently reset ). This is the same error as when you enter a bad query to the rest API.

 

Is this intentional or an error / oversight or bug ?

[Michel Kohanim]

Hello evilpete,

 

Completely intentional: names should not be unique. This said, all IDs are unique.

 

With kind regards,

Michel

[tazal]

Syslog

Please be more specific as to what you would in addition to what we already have

 

If standard syslog messages could be sent for ISY activity then it essentially would allow for free and easy "subscriptions" and logging in some situations.

 

For example, in a linux/unix environment, and possibly windows, if I wanted to put together some code that logged status for devices in rrd databases so I could easily see history of a device, how often it has been on and the level for dim-able devices, etc then the easy way to do that is to run a cron job that does REST queries to find out status, etc. This is inaccurate to a degree and certainly more overhead than necessary.

 

A better way to do it is to write a daemon and subscribe to the ISY (I think that's close enough terminology for you to know what I mean) and then deal with events as they come in, etc. This is at least slightly challenging and it seems like I have read some possible issues with maintaining subscription, etc. Even if it's due to poor client side coding it's an issue.

 

If I have problems with my client I have to troubleshoot and debug and have probably lost data.

 

On the other hand... If all I had to do was enter in a syslog server IP address in the isy as well as a facility (in syslog terms) then any linux box could immediately and easily start receiving the messages using a fairly reliable and known protocol. There are windows syslog servers available as well.

 

If I take the 30 seconds to tell my linux box to put all local5 (or whatever) messages in /var/log/isy.log then I immediately have a log file with a complete history of my isy activities. I can use intelligent sysloging to do things like send emails based on severity level or put a change in to my rrd file for graphing.

 

Basically it would allow for all of the logging, history, etc to be offloaded to another box. I remember seeing a windows logger somewhere that opened a subscription to the isy and then spit messages out. Then I think that broke.

 

For the example of rrds you could also fairly easily add in a lookup table for power usage for an insteon device and see total energy usage with no expensive hardware. If I know there are 3 x 60 watt lightbulbs attached to an insteon device I can get a somewhat reasonable guess as to how much power is consumed based on the level its at and for how long each day. I have been thinking for a year that I should write some portable code that automatically creates an rrd for each insteon device and updates it with status changes and then write a simple web based front end for it. The problem is I can't bring myself to do it with scheduled rest queries and I haven't made time to write subscription code.

 

If you could easily implement syslog messaging it would greatly simplify what people might want to do externally. If nothing else with near zero effort people could keep a real time logfile off of the ISY of ISY activities.

 

See ya,

Al

 

P.S. if someone has some perl code that opens and maintains a subscription to the ISY that would be a welcome start.

[evilpete]

 

 

A better way to do it is to write a daemon and subscribe to the ISY (I think that's close enough terminology for you to know what I mean) and then deal with events as they come in, etc. This is at least slightly challenging and it seems like I have read some possible issues with maintaining subscription, etc. Even if it's due to poor client side coding it's an issue.

 

 

 

I got this running as a part of some demo code, that is a perl script that receives ISY events and republishes them at syslog events, I have not tested reliability.

 

But I agree, native syslog would be nice