How many Ethernet GEM's are supported?

[bsobel]

Hi,

 

Still very confused on what is and what is not supported with the GEM. In Mexico it looks like I'll need to put in 4 units. Due to the range and some obstructions (like a bunch of bedrock between two areas) I plan on using Ethernet. Can the ISY import data from 4 GEM units via Ethernet? If not today, can it in the future? And if 128 total channels (32x4) arent (or won't) be supported. Even if I'm limited to 32 can I pick different channels from the different GEMs to come up with that list.

 

Thanks,

Bill

[Michel Kohanim]

Hi Bill,

 

,

Still very confused on what is and what is not supported with the GEM. In Mexico it looks like I'll need to put in 4 units. Due to the range and some obstructions (like a bunch of bedrock between two areas) I plan on using Ethernet. Can the ISY import data from 4 GEM units via Ethernet?

No

 

If not today, can it in the future?

Unfortunately not. That's the whole reason behind moving to Zigbee so that would defeat the purpose.

 

And if 128 total channels (32x4) arent (or won't) be supported. Even if I'm limited to 32 can I pick different channels from the different GEMs to come up with that list.

No.

 

With kind regards,

Michel

[bsobel]

Why in the world would you prioritize a radio protocol which only some of your devices support over Ethernet which you all do?

[Michel Kohanim]

It seems that you are about 4 years behind!

 

With kind regards,

Michel

[Teken]

Michel

 

I think it would be helpful if there were some clarity for the sake of others. Please correct anything I have stated here if its not spot on.

 

1. With a GEM using Ethernet communications the ISY can only see one unit. There will be no nodes in the device tree to the left.

 

2. With a GEM configured and using Zigbee the ISY can support how many GEM's?

 

Teken . . .

[Michel Kohanim]

Hi Teken,

 

Correct. It can support 2 GEMs and 4 ECMs.

 

With kind regards,

Michel

[joehuber]

I would agree that Ethernet support is fundamental. Excuses about nodes (not) showing up in the tree are artificial and just a distraction.

 

Do whatever it takes to support standard IP protocols! IP is what the whole world is moving to, including ZigBee over IP aka ZIP.

 

Once you support IP, and divorce yourself from proprietary protocols it becomes much easier to support many kinds of physical device interfaces.

 

So yes PLEASE do prioritize Ethernet and IP support!!!!!!!

 

Thanks, Joe

[Michel Kohanim]

Hi Joe,

 

Pretty much out of context and generic. I suspect a spam but give you the benefit of the doubt.

 

With kind regards,

Michel

[joehuber]

Let me be more specific then. I'd like to use Ethernet to connect a GEM to my ISY so that I can track my energy consumption using an app link Mobilinc. Do you know of a way to do that? I have no interest in using ZigBee nor any other wireless mechanism to do this.

 

I've seen this and similar questions often, including in this thread. But I've never seen a clear solution. Do you have one?

 

Thanks, Joe

[Michel Kohanim]

Hi Joe,

 

Thanks for the clarifications. You can use Ethernet to communicate with ECM1240 but NOT GEM. There's currently no way around it apart from Zigbee.

 

With kind regards,

Michel

[joehuber]

Thanks for the info.

 

Hence my prior post to please request Ethernet support. It's the obvious way to provide this connectivity since ISY is already on the Ethernet and IP network.

 

Thanks, Joe

[Michel Kohanim]

Hi Joe,

 

I understand. We work based on ROI and based on the number of electricity modules we sell, there's really not much intensive to add this support except for commercial venues that already use Zigbee.

 

Furthermore, ECM requires a query which basically ties up networking resources which could be used otherwise. This is especially the case when you poll ECM in less than 10 seconds intervals.

 

With kind regards,

Michel

[arw01]

+1 on expanding Ip support over Zigbee.

 

Since we CANNOT have zigbee and Zwave without adding a second ISY 994i, zigbee is doa long term. Perhaps in the commercial market and only UDI can say do they sell more commericial to residential.

 

My question goes to the issue of the polling. WHY do you need to poll with ethernet, is that a software shortcoming on Brultech's end or a design issue on the UDI side in that a different listener watches the zigbee buss and can just sit idle until something pops up on the bus there?

 

I don't see why a simple broadcast over ip from the brultech would not accomplish the exact same thing without having any polling.

 

I love the concept of the gem, but it just seems too crippled on the ISY and the information is not all in one place over here to keep it straight as to what the ISY can and cannot do, or listen too, or react to. Really I have no idea. I rattle this around in my head quite often, thinking could I get along with 7 channels on IP with the ECM1240? I want to monitor the hot water heater, the heatpump, the dryer, full mains, after that I am down to 3 channels for the whole house to pick from, not exactly precision monitoring.

 

Please give us some specifics as to limitations that the ISY has to live with from the brultech side and perhaps we can put some collective pressure on brultech development to remove them.

[joehuber]

Excellent ideas. I completely agree with your comments. This kind of multivendor integration is exactly the value of IP, and UDI seems allergic to it for some reason. The internet grew as big as it has exactly because IP allows easy interconnection of devices from multiple vendors.

 

I've given up on using UDI/ISY for my energy monitoring needs and I'm looking at alternatives including Homeseer with the Ultra plugin or doing something myself on one of the little LinuxPlugs such as Ionics Plug.

[Michel Kohanim]

Hi Joe,

 

As much as I understand your disappointment, I cannot let you start an ad hominem campaign by such statements as:

This kind of multivendor integration is exactly the value of IP, and UDI seems allergic to it for some reason.

 

Please thoroughly read what I wrote before. The only things we are allergic to are sacrificing quality for quantity or going bankrupt while implementing features that "may be" used by a just few. You can use ECM1240 using Ethernet with ISY. And, if you are still unhappy, we'll be delighted to give you a refund.

 

With kind regards,

Michel

[joehuber]

Fair enough. I know how hard it is to be selective on projects and make the business tradeoffs to be profitable and healthy.

 

I have been in the networking business of rover 30 years and I have seen many very good proprietary solutions go by the wayside just because of the ubiquity of IP. I do encourage you to continue to be selective, but be sure to consider the potential benefits of a broad standards based communication fabric like IP. I've seen the many threads on the UDI forums asking for the same thing (phrased as Ethernet connectivity) so this isn't just an academic discussion... but rather a business opportunity...

 

Regards, Joe

[Michel Kohanim]

Hi Joe,

 

I think we have to separate two things:

IP Mac/DLL layer vs.

Application Layer

 

Most device communication protocols (including Zigbee) have standards at the application layer which brings some type of normalization and standardization to device communications. This is the case for INSTEON, Zigbee, Z-Wave, UPB, Bacnet, ModBus, etc.

 

Conflating IP with App layer basically means that we would have to implement a different application layer for each product. This is the case for RCS WiFi thermostats, 3M thermostats, CAI Web control, NEST, Honeywell, and basically all other IP based devices. Each one has its own proprietary application layer protocol and some even require you to go out on a server somewhere in the cloud. As such, for us, implementing IP is not really implementing IP but, rather, implementing specific application layer for each product. This becomes quickly unmanageable.

 

The only IP based application layer protocols for automation that I am aware of:

1. UPnP ... wrought with security issues and now relegated to media streaming devices and some printers

2. WebServices for Devices (Microsoft) ... not used except for some printers. Actually, Life|Ware bet on this standard and they went bankrupt because there were not enough devices that supported this standard

3. Modbus over IP ... very expensive and only used in commercial venues

4. Bacnet over IP ... same as Modbus

5. IPSO ... still in infancy and very minimal number of devices in the ecosystem

6. KNX (Siemens) ... only used in Europe

7. SEP20 ... which we will support but pretty immature when compared to Z-Wave, INSTEON, Zigbee, UPB, KNX, etc.

 

In short, as long as there is no application layer standard for communicating IP devices, we are left with having to implement each one based on user demand.

 

With kind regards,

Michel

[joehuber]

Yes, it does take compatibility at both the data link and application layers to create interoperable systems. And yes Home Automation is still in it's infancy and people are still in the early phase of using proprietary systems.

 

However I believe it is inevitable that to survive these systems will need to adapt their application standards to work over the ubiquitous IP data links.

 

ZigBee has already needed to do that as mandated by NIST the US National Institute for Standards and Technology.

Virtually all Smart Grid deployments are adopting IP, and the utility HANs will be a big influence on the home automation market.

 

The Internet of Things is a HUGE focus area for big organizations like Cisco, GE, ATT, Verizon and hundreds of other large companies and thousands of smaller ones. And almost by definition they will all be IP based devices, or at least have an IP based gateway at the edge of the network to account for non-IP legacy devices.

 

So at this point it's no longer a question of if this market will move to IP, it's only a matter of when. And yes the application standards will also need to be a part of the whole migration story. But it's already happening...

[Michel Kohanim]

Hi Joe,

 

Thanks for the response and I think we are in agreement: GEM does not fall into IoT neither do other one-off Ethernet devices.

 

As far as NIST, we were heavily involved in the H2G DEWG and thus I am pretty familiar with all the standards including SEP (ISY994i ZS) and OpenADR (for which you see a Group in ISY). For your information, SEP 2.0 (for which we will have our own implementation) was supposed to replace SEP 1.0/1.1 radios in Smart Meters. Of course you should already know the outcome.

 

In the meantime, we'll follow IoT related standards and implement those that have a chance for success.

 

With kind regards,

Michel

[joehuber]

IMHO GEM definitely is (or could be) a first generation IoT device. Measurement and monitoring is the first phase towards eventual broad scale analytics and control. GEM may not align with your priorities as a Controls oriented vendor, but GEM and other measurement devices (such as Smart AMI Meters) provide a lot of value to the first phase of IoT.

 

I already have a Smart Meter from my utility and that data is very coarse, both in acquisition and presentation.

I also have a whole house consumption meter as part of the net metering provided by my PV solar system. It has better time resolution (15 min) but 'whole house' is still too coarse to disaggregate important loads (EV, etc)

So circuit level monitoring like GEM would give me the the level of visibility I'm looking for. Unfortunately the GEM software picture isn't as rosy. Since UDI has a GEM module, I'd hoped to be able to leverage my existing ISY since they would both be on the same network.

 

Homeseer DOES have an Ethernet based GEM plugin and so I may need to invest in that for my EMS and consider using it to also replace my ISY for Insteon HA.

[Michel Kohanim]

Hi Joe,

 

It seems that we are going in circles. You are more than welcome to use HomeSeer and my offer still stands: we'll be more than happy to give you a refund for you ISY so that you can concentrate on HS implementation without any further hindrance.

 

With kind regards,

Michel

[joehuber]

I appreciate your very generous unsolicited offer. I may take you up on it once I can confirm the HS capabilities.

 

Thanks, Joe