Network Module / EventGhost / TCP / UDP / Etc.

[dpower]

Greetings all,

 

I've just started to investigate the ISY-99i's Network Module capabilities and would like to know other people's experiences -- especially as they relate to integration with EventGhost and/or Girder.

 

I've searched high and low -- on this forum, EventGhost's and elsewhere -- but haven't yet found anything definitive regarding how to make the ISY talk to EventGhost.

 

I gather EventGhost's Network Receiver Plugin isn't going to work in this context as it requires elaborate handshaking and hashing. But I'd expect the Broadcaster Plugin -- which is a simple UDP listener -- should work. Has anyone had success with this or any other network communication methods? Would you mind sharing?

 

Thanks,

dp

[ih574]

dpower,

 

I use the ISY network module to send http commands to EventGhost to control several PC functions. EventGhost provides a web add-in which I run on the PC to act on the commands. I use it for announcing events, warnings, and reminders as well as to control garage and outdoor audio played from a PC. For example, when the garage door opens, the ISY registers the event (based on the garage door sensor) and then sends an HTTP get command (using a Network Resource with ipaddress/index.htm?GarageOpen) to the EventGhost PC. The add-in web server running on the PC receives the http request and sends the event "HTTP.GarageOpen" to the EventGhost process (running on the same PC). The PC then plays the sound "The Garage Door is now open" through the PC speakers. I have separate Network Resources for each voice announcement. My next task for the voice announcements is to have the PC speak the announcement through the intercom (which I have working but is proving to be a bit rube goldbergian) or to play it through a 70v distributed audio system (which doesn't yet exist).

 

For the outside audio, ISY sends similar EventGhost web commands (for volume up/down, mute, playlist, start/stop) to another PC which plays garage and outside music. Again, separate Network Resources for each command. I trigger these commands from an ISY served web page with buttons linked to REST commands that call ISY programs. Those programs invoke the Network Resources. Very handy to control those actions from the Patio with the iPhone/iPad.

 

While this seems busy, it all works amazingly reliably, enough so that my wife and kid use it without even thinking about it. If our best automation investment was the ISY-99, the ISY Network Module is the second best. It allows reasonably simple, extremely reliable, and imaginative integration with ip based systems.

 

r-

 

Tom C.

[dpower]

Thanks much, Tom. It's great to hear you're having success integrating the ISY and EventGhost. Sounds like you're doing some interesting work as well.

 

I'm curious as to why you chose HTTP over UDP or TCP. How's the responsiveness of HTTP? I ask because -- as a protocol -- it has a tremendous amount of overhead versus UDP/TCP. Had you experimented with the other protocols at all?

 

Just this week, I've had success in integrating the ISY and EventGhost over UDP. It seems to be reliable and fast. The only odd thing I've noticed is the UDP screen insists I specify a "host" IP. As my network -- which has numerous PC's, routers, switches and other devices -- currently runs on DHCP, I'd prefer not to assign static IP's if I don't have to. Unless my understanding is inaccurate, UDP is a broadcast protocol (i.e. sends an IP-agnostic packet across the network). I don't understand why it's necessary to supply an IP address to a broadcast packet. Is there a way to get around having to specify a host on the ISY's UDP resource screen?

 

Thanks,

dp

[Michel Kohanim]

Hello dpower,

 

UDP is not a broadcast protocol in and of itself and thus will require a host. The difference between UDP and TCP is that UDP is connectionless and thus does not have the TCP overhead (as you mentioned).

 

If EventGhost supports Multicast (i.e. it belongs to a group), then you can use Multicast instead of UDP.

 

With kind regards,

Michel

[dpower]

Thanks, Michael. I appreciate the distinction.

 

I am, however, confused by the fact that the ISY's multicast implementation requires a host as well. Why would this be the case?

 

Thanks,

dp

[Michel Kohanim]

Hello dpower,

 

You are correct: the label should not be called host but Group Address. For instance, UPnP multicast address is:

Group: "239.255.255.250"

Port: 1900

 

With kind regards,

Michel

[dpower]

Michael... Is it correct to assume the only way I can reliably ensure the ISY hits its UDP or multicast target is to assign fixed IP addresses to those targets?

 

If so, would it follow the only way a remote machine could reliably hit ISY via REST would be to assign a fixed IP to the ISY?

 

Thanks,

dp

[Michel Kohanim]

Hi dpower,

 

1. No ... for multicast, you have to ensure that the end device is always registering to the multicast group as a member. This is independent of its IP; it just means that that device will always respond to the multicast signals. I am not sure how you can do this on a PC without a dedicated software that ensures group membership

 

2. Yes/No ... you can do two things:

a. Static IP address for ISY

b. DHCP reservation for your ISY in your router

 

With kind regards,

Michel

[ih574]

dp,

 

I use HTTP and its fine. I am sending very simple HTTP payloads from the ISY to EventGhost webserver, i.e., single keywords per event. The webserver is built into EventGhost making this really easy. I don't have to establish a separate UDP listener on the EventGhost host.

 

Regarding IP addressing, I assign static addresses to any listener/server devices (e.g., ISY, EventGhost, web servers, etc.) and use DHCP for client only devices. I expect you are know how simple it is to assign a static address to ISY, perhaps well outside of your DHCP scope range to eliminate duplicate address problems. Also, if you really want to use UDP broadcasts to eliminate the need for static addresses, seems you could use the subnet broadcast address (e.g., 192.168.1.255 for a Class C) as the target address in the ISY resource. I can see that a UDP broadcast method is pretty clever if you want multiple machines to act on an event.

 

r-

 

Tom C.

[kingtd]

If it's of interest to you, I wrote an eventghost plugin for the ISY-99i a while back. It's still a work in progress (as all of these things tend to be) but it already does quite a bit. I've attached my latest version here in case you want to play with it. It automatically shows events and allows you to send commands.

 

Device status is monitored and stored in a python list called eg.plugins.ISYEvent.plugin.devices, so you can use that in conjunction with the Eventghost webserver's Jinja templates and for loops to show status (which is my primary use case).

 

~K

ISYevent.zip

[dpower]

K,

 

Since my last post, I went ahead and created an EventGhost plugin of my own. Managed to get it in service within a few days thanks to the UDI's REST interface.

 

That said, your plugin is quite slick and very helpful. Your event subscription implementation is a huge asset. I haven't been able to get your SetDevice or SetGroup actions working yet -- I'll have to troubleshoot my environment this weekend. But all-in-all, a great and useful plugin. Thank you for sharing.

 

Questions:

 

1) I've noticed you've opted to create explicit SOAP headers / messages rather than using the ISY's REST interface. I've found the REST GETs far easier to code (i.e. a single line rather than 7 or 8 ) and fairly responsive -- no noticeable delay. I'm wondering, is there a specific reason you took the SOAP route? Performance? Control? Other?

 

2) Your plugin uses some elaborate string parsing to pull apart XML responses. While you've obviously do this very well -- as evidenced by the fact that it works! -- I'm curious as to why you chose to parse them yourself rather than using minidom functions (for example) to do the heavy lifting for you?

 

Thanks again,

dp

[kingtd]

Hi dpower,

 

When I started working on this, I had an ISY-26 and there was no rest interface. It actually took me a while to convince the UD guys to give me the web services information back then. So since it works, I never went back and tried to rewrite it. For the XML parsing, there were some issues with either the formatting that gets sent by the ISY, or trying to get minidom working in the limited python set that comes with Eventghost (or that did at the time of coding). Sadly it's been so long I can't remember. =)

 

But I've had this thing in operation for a few years now, and it's been stable. I use an eventghost timer against the ISY heartbeat signal to reconnect to it if it drops. Honestly, the biggest problem is that if you go into the ISY admin interface, it still (stupidly, after all this time) resets the log level to 0! This blinds the plugin to a lot of commands until I notice it and resend the command to set it back to 1.

 

If you make any changes or want to share what you've done with the REST stuff, I'd love to see it.

 

~K

[Michel Kohanim]

kingtd,

 

The reason for stupidly turning the level back to zero is unnecessary network traffic. It's like running in debug mode and for devices that are connected to the Internet (some with 3G modems), the extra traffic is approximately 300 - 500% more than at level 0.

 

What I do not understand is: what in debug information do you need for your EventGhost? In my view, all important events are already published.

 

With kind regards,

Michel

[kingtd]

Unless something has changed, you don't see button presses that aren't tied to insteon loads without log level 1. As I mentioned, it's been a while since I wrote the plugin so I'd have to go back and look at the specifics. But I have an exposed feature on my web interface under "fixes" that sets the log level to 1, specifically to undo it when I eventually realize I'm missing commands.

 

I get that you generally want lower traffic, but if I'm actively setting that option, don't override my decision in an undetectable way when an admin runs the console. That'a completely counterintuitive to automation.

 

~k

[Michel Kohanim]

kingtd,

 

Are you specifically looking for button presses (i.e. Control) or status?

 

There's no easy way to assertively figure out if someone is "actively" changing the debug level. We might have to implement a global one.

 

With kind regards,

Michel

[iDVB]

If it's of interest to you, I wrote an eventghost plugin for the ISY-99i a while back. It's still a work in progress (as all of these things tend to be) but it already does quite a bit. I've attached my latest version here in case you want to play with it. It automatically shows events and allows you to send commands.

 

Device status is monitored and stored in a python list called eg.plugins.ISYEvent.plugin.devices, so you can use that in conjunction with the Eventghost webserver's Jinja templates and for loops to show status (which is my primary use case).

 

~K

 

 

kingtd, are you still working on this plugin? I would like to offer my services in development as well.

Maybe startup a github project for it. A plugin like this would be very useful in my mind and something I would love to have personally. Rather then firing ISY Network Resource calls to EventGhost's Webserver.

 

- iDVB

[GeneInSoCal]

I recently had this plug-in working fine with an ISY-99i. I had Event Ghost announcing voice commands. I could also see the "heart beat" of the ISY-99i.

 

Last week, I upgraded to an ISY-994i and seem to have lost the ability to communicate with Event Ghost. I can no longer even see the "heart beat" of the ISY-994i. Is this plug-in not compatable with the ISY-994i or should I be looking somewhere else for my problem?

 

Thanks

[arw01]

Maybe the firmware versions are different a slight change to the subscriptions process could "breaK' the isy end. To diagnose after you get what you think if one piece talking to the isy open an browser and use the rest command:

 

http://(your isy address)/rest/subscriptions

 

you should see a session that is not expired if the subscription was successful. Then you have one piece eliminated from your trouble shooting steps.

 

If you have the admin console going as well, you should see TWO sessions not expired when you have eventghost and company subscribed.

[Michel Kohanim]

Hi Gene,

 

Also, are you certain that your old ISY has the same IP address/network/URL as the new one?

 

With kind regards,

Michel

[Drosen]

Hi Michel,

 

Slightly different issue here. I have been running EventGhost with speech and ISY plugins. ISY994i FW 3.3.10.

When I upgraded FW to 4.0.3 , the logger (left pane) stopped logging events. ??

 

Thanks,

Dave

[Michel Kohanim]

Hi Dave,

 

I am sorry I do not have EventGhost ... but can you still get feedback from devices?

 

With kind regards,

Michel

[Drosen]

No Isy events logged and hence no audio alerts. I went back to FW 3.3.10, and Isy voice is back. Hopefully it wil be resolved before I must go forward in the firmware. For those familiar with the EventGhost logger, I was getting an event telling me that subscription to " my Isy ip was closed".

[Michel Kohanim]

Hi Drosen,

 

I think I know what the issue is: we removed UPnP subscriptions in 4.0.x version because of security concerns. If you know the author of ISY plugin for EventGhost, please have them contact us.

 

With kind regards,

Michel

[GeneInSoCal]

It seems as though Kingtd is the author of this plug-in. (page 1 of this post) I am having the same problem as everyone else.

 

Thanks,

 

Gene

[Michel Kohanim]

Thanks Gene. Sent a PM.

 

With kind regards,

Michel