Generator On Notification

[scottmichaelj]

I currently have a Generac 20Kwh generator installed with an SIEMENS GENTFRSWTCH Automatic Transfer Switch in my SIEMENS Load Center panel.

The installation manual can be found here:

https://www.downloads.siemens.com/downl ... BTLV_23761

My goal is that when the main power is OFF (power loss from the POCO) and the generator is then activated and being used, I can somehow get a notification. This is especially useful if I am away from home.

I have a Dashbox, two GEMS (with an avail channel) and an Universal Devices ISY. Maybe add a CT sensor (I have extra Micro 40s) to the switch, then when there is a load on "X" and NOT on "Y" send a notification? This would be another reason notifications feature added for Pushover would be useful.

The transfer switch seems to have a Battery +/- and a "XFER" connection. Should I put a relay or sensor on it or find the breaker/circuit for the generator that is zero then just put the CT on it, then when it gets current I will get the notification. This still doesnt solve how to get the notification. Maybe someone with an ISY could chime in and I could push a variable to it which then in turn could trigger the notification based on a program.

I was thinking something like. CT sensor on the generator load, then push that one circuit data as a variable to the ISY. Then a program in the ISY when the variable is 50W for 3 mins send the pushover notification.

Another thought I had was seeing if the XFER was "ON" when the generator is ON and OFF when OFF. Then I could add a ELK 6022 wireless sensor with reed switch connected to the transfer switch. When the generator is ON the ELK sensor would become "violated" thus trigger the notification from ELK.

Anyone have any thoughts how to do this or have done this already? Thanks in advance for the info.

Edit: Here is the switch connections mentioned.

[Teken]

I believe one of the many projects I documented in my install thread could offer you that insight. My suggestion moving forward is to use from basic to advanced methods to track the state and offer email notification.

On page 30 of the install thread near the bottom is the first step for basic tracking the power loss state. Oddly enough this idea and solution was created for another friend asking to monitor his back up generator like you. In that thread I call out all of the pros and cons of such but given you have most if not all of the required equipment this is something worth while to use as the *Basic* portion.

To add to this solution is what you had posed early on and that is to use the power of the Dash Box and send the state variable to the ISY Series Controller. This offers several things which the *Basic* solution doesn't which is power and voltage.

Keeping in mind the *Basic* hardware solution was created for specific purpose because it was dumb and was pretty much fool proof in its operations. Where as the *Advanced* solution using the DB is intended to compliment the *Basic* one.

You need only create the state variables in the ISY Series Controller first. Next replicate the very same in the DB once in place those state values will show up in the ISY Series Controller. Once those values are in place you can define what parameters need to happen before it fires off an alert message etc.

So the above portion has been offered as not only the template but high level view of what can be done using the tools you already have in place.

Let me know if you need anymore insight or guidance in this endeavor.

Its about time you started making some use out of that power you have sitting idle!

http://www.brultech.com/community/viewt ... &start=290

[scottmichaelj]

I believe one of the many projects I documented in my install thread could offer you that insight. My suggestion moving forward is to use from basic to advanced methods to track the state and offer email notification.

On page 30 of the install thread near the bottom is the first step for basic tracking the power loss state. Oddly enough this idea and solution was created for another friend asking to monitor his back up generator like you. In that thread I call out all of the pros and cons of such but given you have most if not all of the required equipment this is something worth while to use as the *Basic* portion.

To add to this solution is what you had posed early on and that is to use the power of the Dash Box and send the state variable to the ISY Series Controller. This offers several things which the *Basic* solution doesn't which is power and voltage.

Keeping in mind the *Basic* hardware solution was created for specific purpose because it was dumb and was pretty much fool proof in its operations. Where as the *Advanced* solution using the DB is intended to compliment the *Basic* one.

You need only create the state variables in the ISY Series Controller first. Next replicate the very same in the DB once in place those state values will show up in the ISY Series Controller. Once those values are in place you can define what parameters need to happen before it fires off an alert message etc.

So the above portion has been offered as not only the template but high level view of what can be done using the tools you already have in place.

Let me know if you need anymore insight or guidance in this endeavor.

Its about time you started making some use out of that power you have sitting idle!

http://www.brultech.com/community/viewt ... &start=290

The one thing I disliked about your insteon install was well, because its insteon which is not always reliable. I wanted something really more hardwired and solid.

That being said maybe I should reevaluate my position since this is not mission critical.

[Teken]

There are some limitations that need to be considered that is for sure and that is why I called out all the pros and cons of such. There are lots of moving parts in the *Basic* solution but the premise is sound and is pretty bullet proof from a hardware perspective.

Even using the DB -> ISY solution hinges on many things also going right and back ups in place to ensure a correct fail over along with expected behavior. Regardless of all of the above if you read any of the how to's, projects, etc.

You will quickly notice I always stress testing, validation, and follow up.

It doesn't matter if it looks good on paper - it doesn't matter if it works when all is good. What matters is (IF) you thoroughly test out the solution and find holes in the endeavor. When you have solved all of the known / unknown problem issues you have completed the first step.

The next step is diligent follow up to validate the system continues to operate very much like the weekly generator start up process. The system can start up 51 out of the 52 weeks - but when you need it on the 52nd week and it doesn't?!?!

That is when it matters most . . .

NOTE: Keep in mind the Insteon option is the *Basic* solution. As mentioned if you have the GEM monitor a specific CT and relay the same information to the DB. That *hardwired* solution is in place for you there. Keeping in mind this too relies on many things going right all the time.

[scottmichaelj]

There are some limitations that need to be considered that is for sure and that is why I called out all the pros and cons of such. There are lots of moving parts in the *Basic* solution but the premise is sound and is pretty bullet proof from a hardware perspective.

Even using the DB -> ISY solution hinges on many things also going right and back ups in place to ensure a correct fail over along with expected behavior. Regardless of all of the above if you read any of the how to's, projects, etc.

You will quickly notice I always stress testing, validation, and follow up.

It doesn't matter if it looks good on paper - it doesn't matter if it works when all is good. What matters is (IF) you thoroughly test out the solution and find holes in the endeavor. When you have solved all of the known / unknown problem issues you have completed the first step.

The next step is diligent follow up to validate the system continues to operate very much like the weekly generator start up process. The system can start up 51 out of the 52 weeks - but when you need it on the 52nd week and it doesn't?!?!

That is when it matters most . . .

NOTE: Keep in mind the Insteon option is the *Basic* solution. As mentioned if you have the GEM monitor a specific CT and relay the same information to the DB. That *hardwired* solution is in place for you there. Keeping in mind this too relies on many things going right all the time.

So you rambled on but didn't offer me a solution. Humph Typical Teken.

[ben]

The transfer switch seems to have a Battery +/- and a "XFER" connection. Should I put a relay or sensor on it or find the breaker/circuit for the generator that is zero then just put the CT on it, then when it gets current I will get the notification. This still doesnt solve how to get the notification. Maybe someone with an ISY could chime in and I could push a variable to it which then in turn could trigger the notification based on a program.

It looks like the BAT + / - are used to power the switch it looks like, without those connected the automated switch won't work. The XFER port isn't documented anywhere I can see, but I'm guessing it's something as you suspect (high when on, low when off).

Is there any downtime when it transfers? If so, you'll need to have the GEM, ISY and DB connected to a UPS if you want a near instantaneous response. Keep the GEM PT off the UPS.

You may actually be able to use the GEMs voltage reference in order to detect the switch. Set an ISY alert when the voltage drops to a certain point. You'll have to do some trial and error to find a good value.

[scottmichaelj]

The transfer switch seems to have a Battery +/- and a "XFER" connection. Should I put a relay or sensor on it or find the breaker/circuit for the generator that is zero then just put the CT on it, then when it gets current I will get the notification. This still doesnt solve how to get the notification. Maybe someone with an ISY could chime in and I could push a variable to it which then in turn could trigger the notification based on a program.

It looks like the BAT + / - are used to power the switch it looks like, without those connected the automated switch won't work. The XFER port isn't documented anywhere I can see, but I'm guessing it's something as you suspect (high when on, low when off).

Is there any downtime when it transfers? If so, you'll need to have the GEM, ISY and DB connected to a UPS if you want a near instantaneous response. Keep the GEM PT off the UPS.

You may actually be able to use the GEMs voltage reference in order to detect the switch. Set an ISY alert when the voltage drops to a certain point. You'll have to do some trial and error to find a good value.

Ben, thanks for the info. This sounds like a solution but like you said a bit of trial and error to get things right. The GEMS are not on a UPS so will need to figure out how to either add then to one or adj for them to get back online.

My initial thought is after the switch turn on (generator = on) I could use the CT40 for that line. Normally it should be zero so if it showed any watts I could assume it was on. Of course with the delay of GEM coming back online being a delay.

The other option was using my Elk alarm system with alarm reed hooked to a current sensor relay. No current could be "normal state" and sensed current = "violated state", then tripped have the Elk send me a Pushover notification and email. The dashbox and isy are on a UPS.

Ill have a play and report back. I know I am not the only one who wants to do this. I'm close but not there quite yet.