ISY Power Module / Brultech GEM

[MWareman]

So, I don't currently have the power module on ISY. I currently use the Dashbox to push power data to ISY variables.  However, I can't help feeling I'll get better utility with the power module and being better able to correlate device status with power response.

 

That being said - I don't even know if it will work. I don't have a Zigbee ISY - but my question is about sending over WiFi from GEM using protocol 11 (labeled as 'Universal Device ISY Format' - attached)

 

Question: Can ISY with the power module receive the data from the GEM over the IP network (NO Zigbee) via protocol 11 from GEM into the power module on ISY?  If so - do all 32 power channels show up?

 

http://wiki.universal-devices.com/index.php?title=ISY-99i_Series_INSTEON:Electricityseems to suggest that ONLY the ECM-1220 is supported by the module (ECM-1240 is the current version from Brultech - indicating that the documentation is old...), unless you have Zigbee in which case the GEM is supported. I don't know if this is a documentation oversight - or real limitation. If the latter - are there any plans to support (natively) GEM data over the network - since Brultech seem to have done their part with the protocol implementation on GEM.

 

I know - there is probably little to be gained as opposed to the Dashbox sending data as ISY variables. However - if I can reduce the number of variables I have it would be worth the $49 to me - and it's a way I can give back (more) to the cause!  

 

Michael.

[Teken]

So, I don't currently have the power module on ISY. I currently use the Dashbox to push power data to ISY variables. However, I can't help feeling I'll get better utility with the power module and being better able to correlate device status with power response.

 

That being said - I don't even know if it will work. I don't have a Zigbee ISY - but my question is about sending over WiFi from GEM using protocol 11 (labeled as 'Universal Device ISY Format' - attached)

 

Question: Can ISY with the power module receive the data from the GEM over the IP network (NO Zigbee) via protocol 11 from GEM into the power module on ISY? If so - do all 32 power channels show up?

 

http://wiki.universal-devices.com/index.php?title=ISY-99i_Series_INSTEON:Electricityseems to suggest that ONLY the ECM-1220 is supported by the module (ECM-1240 is the current version from Brultech - indicating that the documentation is old...), unless you have Zigbee in which case the GEM is supported. I don't know if this is a documentation oversight - or real limitation. If the latter - are there any plans to support (natively) GEM data over the network - since Brultech seem to have done their part with the protocol implementation on GEM.

 

I know - there is probably little to be gained as opposed to the Dashbox sending data as ISY variables. However - if I can reduce the number of variables I have it would be worth the $49 to me - and it's a way I can give back (more) to the cause!

 

Michael.

As I understand it if you obtain the energy data via Ethernet / WiFi only 7 channels will be made available and there will be 7 nodes in the device tree. It should also be noted that response time and accuracy using the Dash Box method to obtain energy, temperature, voltage, pulse, etc is delayed and not as accurate when compared to the native energy module via ZigBee.

 

There are a few people who have deployed the method you have described above. To date I have never read of one person indicating they are happy or unhappy with that specific solution.

 

Lastly, it should be clarified that the purpose and intent of the Dash Box (DB) in having the ability to push state variables to the ISY was to provide more access and data not currently supported by the current energy module platform.

 

The only limitation to using this method is what I stated above which is slower response time and (sometimes) missed readings which either are peak, low, or instantaneous readings.

 

These three attributes are extremely important if mission critical monitoring is expected and wanted as I do. As many who follow my *Install Thread* know the benefit of using the DB to relay the 32 channels, 8 temperature, 4 pulse, is having the flexibility of installing and using Z-Wave.

 

Some would consider the above a great balance and trade off . . .

 

While others who are more focused and concerned about mission critical energy monitoring use the ZigBee method.

[MWareman]

Thank you sir! That's pretty much what I thought. I would really like to get the native data GEM => ISY using the power module, but I have 32 CTs so it seems to be a non-starter currently. The DB is working well within its limitations - but I do notice the delay when trying to program laundry notification and fridge monitoring programs. I'd like to get rid of the delay and dependency if possible.

 

I wonder if there are any plans UDI wise to expand the capability of the power module, since Brultech seem to have done their part?

[Teken]

Thank you sir! That's pretty much what I thought. I would really like to get the native data GEM => ISY using the power module, but I have 32 CTs so it seems to be a non-starter currently. The DB is working well within its limitations - but I do notice the delay when trying to program laundry notification and fridge monitoring programs. I'd like to get rid of the delay and dependency if possible.

 

I wonder if there are any plans UDI wise to expand the capability of the power module, since Brultech seem to have done their part?

 

A few other issues I have noted using the DB -> ISY method is slow to long variable reaction. Meaning if a device comes on it can take 20-90 seconds for the variable to change state. You also have the case where variables continue to run long after that energy state has ended.

 

I have tracked this strange behavior for a year now and have never found a solution or explanation as to why this happens. Initially I considered and tried changing the send interval to much shorter bursts. But, as many of us know if there are many network devices doing the same this can impact the ISY Series Controller in performing other aspects.

 

For me I've determined a 25 second send interval is the best balance of network traffic, response, and operation. For those who have nothing else that is banging away at the ISY Series Controller a send interval of 10 seconds is OK.

 

Lastly, given the small amount of users who actually have a GEM / ECM unit in place and couple that with actually using a ISY Series Controller the odds of more development for the Energy Module are not very likely in the next few years. You can do your part and spread the word in what ever forums you're a member of and this in the long run will drive adoption and increased sales.

 

I know personally that my *Install Thread* has brought lots of attention, awareness, and sales for Autelis, Brultech, and UDI. Letting people know there is some little box(s) available that can help aggregate, track, and manage a persons electrical energy in the home is the next big push for the HA space.

 

Sadly, the reality is HA took more than 25 years to see mass adoption and penetration in the market place. Energy Management and tracking is just now getting that same exposure. My belief is it will take another 5 years until the *general consumer* sees value, benefit, and use from such wares.

 

On the plus side Brultech and UDI are well positioned to help those who wish to adopt such measures. My hopes is by the time these people see the light and want to use the Energy Module it will be more mature and feature rich.

 

Let the games begin . . .

 

Ha . . .

[io_guy]

I've been chatting with Brultech on getting a GEM. If things work out I'll be writing a V5 node server to integrate via Serial/Ethernet.

[Teken]

I've been chatting with Brultech on getting a GEM. If things work out I'll be writing a V5 node server to integrate via Serial/Ethernet.

 

io_guy,

 

For the benefit of others can you explain what are some of the use case and benefits of having a node server in place. I am trying to envision what kind of features and abilities that can be seen by this.

 

As always the membership thanks you for sharing these link programs!

[ppitkin]

io_guy,

If you get a node server created for a GEM put me down for 2. It would be fantastic to get it showing up as a proper node in ISY.

[io_guy]

So I have a GEM coming my way.

My program will use the standard Ethernet module (not the Dash Box or Zigbee) and provide all data to the ISY.  This should include channels, counters and one-wire temperature as well.

[Teken]

io_guy,

 

For the benefit of others can you explain what are some of the use case and benefits of having a node server in place. I am trying to envision what kind of features and abilities that can be seen by this.

 

[ppitkin]

Io_guy,

If you are going to develope something please make it also compatible with the Dashbox. I use the network output from the Gems to connect to the dash box so it wouldn't be available to a node server. Make sure it can also handle multiple Gems.

 

Thx.

[io_guy]

Got my GEM late last week and started playing. Should be no problem getting this running.

I'll be making an ISY V5 node server for this that will make all energy channels, counters and temperatures available.

 

I'll support a few data formats so that data can be sent to SEG at the same time (for example).

[io_guy]

Io_guy,

If you are going to develope something please make it also compatible with the Dashbox. I use the network output from the Gems to connect to the dash box so it wouldn't be available to a node server. Make sure it can also handle multiple Gems.

 

Thx.

Multiple GEMs is no problem. I'll have to investigate Dash support once things are up and running.

[Teken]

io_guy,

 

For the benefit of others can you explain what are some of the use case and benefits of having a node server in place. I am trying to envision what kind of features and abilities that can be seen by this.

 

 

 

Lets try this a 3rd time . . .

[io_guy]

I have no idea what you're asking.

I've told you what the app will do, if you want info on node servers read the V5 forum and docs.

[Teken]

I have no idea what you're asking.

I've told you what the app will do, if you want info on node servers read the V5 forum and docs.

 

I've read most of the material on this forum and its still unclear to me what I will see in the ISY if anything. A break down of what a person will see and where it resides would probably clear things up for me and others.

 

This whole node server thing never seems to be addressed head on by any single person as to what kind of UI or interface will be had.

 

Not sure why this is so hard for people to break this down in plain English?!?!?

[io_guy]

Not trying to be difficult, but I still have no idea what you're asking in the first paragraph of your post above.

[Teken]

Not trying to be difficult, but I still have no idea what you're asking in the first paragraph of your post above.

 

Here are two basic questions and we can go from there.

 

1. What will a person see in the ISY Series Controller that is attached to a node server such as a RPi?

2. How will the 32 circuits, 8 temperature, 4 pulse channels be represented and where?

[io_guy]

1. See my post in V5 as an example. I have a Venstar thermostat showing up as if it was a native stat. The creator of the node server has a lot of flexibility here.

2. These would all show up as native ISY nodes, similar to devices or weather info, etc. They can be used in scenes, programs, whatever.

[Teken]

1. See my post in V5 as an example. I have a Venstar thermostat showing up as if it was a native stat. The creator of the node server has a lot of flexibility here.

2. These would all show up as native ISY nodes, similar to devices or weather info, etc. They can be used in scenes, programs, whatever.

 

Nice . . .

 

Some follow up questions if you can answer them.

 

1. Will your program have the ability to reset the counters in the GEM system? If so would you be able to integrate a clock / calendar where these counters could be reset on a given schedule?

 

2. Will your node server implementation track the KWH for each channel as well as a global counter?

 

3. Will your node server be able to show *current / amps* for each 32 channels and use them in programs, scenes, etc?

[io_guy]

Yes to all.

[Teken]

Yes to all.

 

Nice . . .

[Teken]

I wanted to add some visual aids for those who don't have full ZigBee integration to their Brultech GEM system. Below is how the nodes are represented in the system as of today called nodes

 

In another screen capture called Main 1 you can see what the system currently provides. I would like to see all 32 channels show the current / amps but also have direct access to those values in scenes and programs.

 

As can be seen in this image the ISY does not show or reflect the amps as global counter.

 

In another screen shot called single channel there are only two items available for viewing. One being the ever changing watts that fluctuate from moment to moment based on the send interval from the GEM. The other is the total KWH consumed for that specific channel.

 

I would like to have the ability to reset KWH counter only in the ISY Node Server and not on the GEM or ISY Series Controller. Ideally there would be two counters one acting as a monthly counter and the other a global counter like an odometer on a vehicle which could also be reset but only on the ISY Node Server.

 

I am making this distinction because there are use cases where you want to keep the total value but not impact the GEM's real time counters.

 

Also, it would be great if you could incorporate the following values in each channel to be viewed and tracked: current watts, low watts, high watts.

[io_guy]

All channels will have the info you show in main, accessible in programs.

I'm not terribly keen on keeping separate counters within the node server - you miss data if it's not running for some reason.

[Teken]

All channels will have the info you show in main, accessible in programs.

I'm not terribly keen on keeping separate counters within the node server - you miss data if it's not running for some reason.

 

Understood about missed data if the server happens to be off line etc. But, I am sure most people can appreciate these are things that need to be kept top of mind. I also have to gather those going this route would have to accept the fact this is not the primary method and is an auxiliary method to bolster an existing system in place.

 

I already have lots of over lap in some areas but I like the fact your node server solution will finally offer features sadly missing in its current form.

 

ie. Your node server will offer amps, pulse, temperature, which are not available.  

[io_guy]

Progressing well, will be released once V5 stabilizes.