Question about ELK M1G and using it with an ISY-99.

[Xpendable]

I'm planning on getting an ELK M1G pretty soon. I also already have an ISY-99. I'm assuming if you get the Ethernet interface for the M1G, as long as the M1G and the ISY are on the same local network they should be able to talk, right? I guess I'm just looking for verification that the Elk doesn't need it's own ISY separate from the ISY I already have. That would seem very impractical.

Thanks for any help in advance!

 

[Xpendable]

I'm planning on getting an ELK M1G pretty soon. I also already have an ISY-99. I'm assuming if you get the Ethernet interface for the M1G, as long as the M1G and the ISY are on the same local network they should be able to talk, right? I guess I'm just looking for verification that the Elk doesn't need it's own ISY separate from the ISY I already have. That would seem very impractical.

Thanks for any help in advance!

Wow... I can't believe the M1XEP is $214.21 at both Smarthome & Automated Outlet. That seems so ridiculous that this device would cost *this* much for what it does. I mean you can buy an Ethernet shield for the Arduino micro controller for a whopping $40. I feel like I'd be better off just building my own security system using an Arduino and some easily written code.

 

[kdub]

To answer your original question, the M1EXP will allow the ELK to communicate with your ISY-99.

It does seem a little overpriced, but is probably more capable than the Arduino with the Ethernet shield. If I recall correctly, that WizNet chip the Ethernet Shield uses can only have a total of 8 connections. I think the M1EXP is capable of many more connections, including NTP and Email. Additionally, the M1EXP has a fairly extensive dynamic graphical interface that may be challenging to obtain on the Arduino. All in all, you're definitely paying for the development of the firmware.

 

[Xpendable]

To answer your original question, the M1EXP will allow the ELK to communicate with your ISY-99.

It does seem a little overpriced, but is probably more capable than the Arduino with the Ethernet shield. If I recall correctly, that WizNet chip the Ethernet Shield uses can only have a total of 8 connections. I think the M1EXP is capable of many more connections, including NTP and Email. Additionally, the M1EXP has a fairly extensive dynamic graphical interface that may be challenging to obtain on the Arduino. All in all, you're definitely paying for the development of the firmware.

Yes, but do you really need 8 simulatenous connections? I hear what you're saying. Thanks for confirming that this is what I'll need if I want my Elk to talk to my ISY.

 

[apostolakisl]

You don't need (or even want) another ISY. The ISY will talk to the Elk via the ethernet and to your home via its connection to the PLM. You will not need the Elk XSP module as the XEP will handle the Insteon commands via the ISY.

 

[gatchel]

You could always stick to a direct serial connection... :lol:

I really don't think is that far off considering a quality serial server will run you about $150 and you are also getting the Java interface web browser keypad. When the Arduino micro controller can do what the elk does, then let's talk. Of course you could always use the Arduino micro controller and make your own HA setup...

 

[wuench]

You could always stick to a direct serial connection... :lol:

I really don't think is that far off considering a quality serial server will run you about $150 and you are also getting the Java interface web browser keypad. When the Arduino micro controller can do what the elk does, then let's talk. Of course you could always use the Arduino micro controller and make your own HA setup...

All I can say is the M1XEP is money well spent. They should just include it as part of the M1.

The ISY/M1 configuration is a little hokie, in that you have to export/import a file, since the ISY supports UPnP, the only info that is really needed to find and communicate with the ISY on the network is the username and password. That's what the CQC driver I wrote does. But once setup it all integrates pretty well.

 

[gatchel]

All I can say is the M1XEP is money well spent. They should just include it as part of the M1.

The ISY/M1 configuration is a little hokie, in that you have to export/import a file, since the ISY supports UPnP, the only info that is really needed to find and communicate with the ISY on the network is the username and password. That's what the CQC driver I wrote does. But once setup it all integrates pretty well.

Maybe on the M2 we'll see networking right on the main board....

Powerhome has a configuration file that has to be uploaded to the M1-XSP also. It's seems that that is the only way to get the cross of information between the different systems, regardless.

 

[Xpendable]

I bit the bullet and ordered an ELK M1G with the M1XEP.

 

[wuench]

All I can say is the M1XEP is money well spent. They should just include it as part of the M1.

The ISY/M1 configuration is a little hokie, in that you have to export/import a file, since the ISY supports UPnP, the only info that is really needed to find and communicate with the ISY on the network is the username and password. That's what the CQC driver I wrote does. But once setup it all integrates pretty well.

Maybe on the M2 we'll see networking right on the main board....

Powerhome has a configuration file that has to be uploaded to the M1-XSP also. It's seems that that is the only way to get the cross of information between the different systems, regardless.

Yeah, and the Elk integration with ISY happened very early on in the ISY's lifetime. I think that was before they had all their web services stuff worked out. And Elk probably never felt the need to go back and redesign all that.

 

[Xpendable]

Yeah, and the Elk integration with ISY happened very early on in the ISY's lifetime. I think that was before they had all their web services stuff worked out. And Elk probably never felt the need to go back and redesign all that.

So the integration is not that great? Wonderful.

 

[apostolakisl]

Yeah, and the Elk integration with ISY happened very early on in the ISY's lifetime. I think that was before they had all their web services stuff worked out. And Elk probably never felt the need to go back and redesign all that.

So the integration is not that great? Wonderful.

UD is promising a firmware upgrade soon that will allow the ISY to have near full integration with the Elk. Right now, the only menu driven information is control of Insteon. There are promises that the ISY will be able to see the status of all of your Elk inputs/outputs and control outputs as well as arming commands. The developers on the UD forum state that they have been working on it and it will be the next major firware update once they complete the current firmware.

 

[wuench]

Yeah, and the Elk integration with ISY happened very early on in the ISY's lifetime. I think that was before they had all their web services stuff worked out. And Elk probably never felt the need to go back and redesign all that.

So the integration is not that great? Wonderful.

It's OK, just all the configuration of lighting controls in the Elk is done by file import. So if you change your lighting configuration in the ISY, add/remove devices, etc, you need to export from the ISY and re-import the file via ElkRP. It would be nicer if the Elk would just subscribe to the ISY and changed it's config automatically like CQC does. I have also found the need to edit the exported file to get rid of extraneous lights I don't need in the Elk and to reorganize/rename things a bit. For example, if I only use a group to turn on lights and I don't need individual control of each light in a group, I delete the individual ones from the file. The Elk still uses dummy X10 group/house codes to track the lights and groups so it's space is limited.

But like I said above, once it's all setup, it works well.

The stuff Lou is referring to is the other way around, the ISY can control your Elk via the Elk protocol. But I don't think any of that will allow for lighting config changes on the Elk automatically. The Elk RS232 protocol doesn't have that ability AFAIK.

 

[apostolakisl]

Yeah, and the Elk integration with ISY happened very early on in the ISY's lifetime. I think that was before they had all their web services stuff worked out. And Elk probably never felt the need to go back and redesign all that.

So the integration is not that great? Wonderful.

It's OK, just all the configuration of lighting controls in the Elk is done by file import. So if you change your lighting configuration in the ISY, add/remove devices, etc, you need to export from the ISY and re-import the file via ElkRP. It would be nicer if the Elk would just subscribe to the ISY and changed it's config automatically like CQC does. I have also found the need to edit the exported file to get rid of extraneous lights I don't need in the Elk and to reorganize/rename things a bit. For example, if I only use a group to turn on lights and I don't need individual control of each light in a group, I delete the individual ones from the file. The Elk still uses dummy X10 group/house codes to track the lights and groups so it's space is limited.

But like I said above, once it's all setup, it works well.

The stuff Lou is referring to is the other way around, the ISY can control your Elk via the Elk protocol. But I don't think any of that will allow for lighting config changes on the Elk automatically. The Elk RS232 protocol doesn't have that ability AFAIK.

Once ISY gets ability to observe and control Elk parameters, you will be able to completely ignore the Elk lighting section and just do everything on the ISY. This would be ideal since, as you said, every time you change anything in ISY as far as lighting you have to re-export/import and if any address locations change you need to go into the rules section and redirect the lighting rule to the new address of that light.

ISY programming is generally better than Elk rules so it will be nice to use the ISY as command central instead of Elk.

 

[wuench]

Yeah, and the Elk integration with ISY happened very early on in the ISY's lifetime. I think that was before they had all their web services stuff worked out. And Elk probably never felt the need to go back and redesign all that.

So the integration is not that great? Wonderful.

It's OK, just all the configuration of lighting controls in the Elk is done by file import. So if you change your lighting configuration in the ISY, add/remove devices, etc, you need to export from the ISY and re-import the file via ElkRP. It would be nicer if the Elk would just subscribe to the ISY and changed it's config automatically like CQC does. I have also found the need to edit the exported file to get rid of extraneous lights I don't need in the Elk and to reorganize/rename things a bit. For example, if I only use a group to turn on lights and I don't need individual control of each light in a group, I delete the individual ones from the file. The Elk still uses dummy X10 group/house codes to track the lights and groups so it's space is limited.

But like I said above, once it's all setup, it works well.

The stuff Lou is referring to is the other way around, the ISY can control your Elk via the Elk protocol. But I don't think any of that will allow for lighting config changes on the Elk automatically. The Elk RS232 protocol doesn't have that ability AFAIK.

Once ISY gets ability to observe and control Elk parameters, you will be able to completely ignore the Elk lighting section and just do everything on the ISY. This would be ideal since, as you said, every time you change anything in ISY as far as lighting you have to re-export/import and if any address locations change you need to go into the rules section and redirect the lighting rule to the new address of that light.

ISY programming is generally better than Elk rules so it will be nice to use the ISY as command central instead of Elk.

Yeah, that makes sense, now. No need to have lighting control directly in the Elk. I could definitely go for that.