www.brultech.com

There are a few things I'd like to be able to monitor for failure and status.

Fridge failure. Too low over a period = broke?, or Too high over several hours = left open?
Furnace filter needs cleaning. Wattage between two parameters for over x minutes.
Heat pump failure. Too low when furnace fan wattage is at specific level for x minutes.
Left high powered items on, etc.
Dishwasher or clothes dryer finished running. Wattage above X for 15 minutes, then below X for a certain amount of time.

What systems are available to do this? I use the ISY 994, GEM and DashBox. The DashBox sending details to the ISY is too slow for it to be reliable.

Can you define too slow with integrating with the ISY Series Controller?


=========================

The highest calling in life is to serve ones country faithfully - Teach others what can be. Do what is right and not what is popular.

j0dan wrote:There are a few things I'd like to be able to monitor for failure and status.

Fridge failure. Too low over a period = broke?, or Too high over several hours = left open?
Furnace filter needs cleaning. Wattage between two parameters for over x minutes.
Heat pump failure. Too low when furnace fan wattage is at specific level for x minutes.
Left high powered items on, etc.
Dishwasher or clothes dryer finished running. Wattage above X for 15 minutes, then below X for a certain amount of time.

What systems are available to do this? I use the ISY 994, GEM and DashBox. The DashBox sending details to the ISY is too slow for it to be reliable.

The DashBox can be set up to send to the ISY up to every packet.

If you set:
- the GEM packet send interval to 5 seconds
- the DashBox ISY send interval to less then that (every 4 seconds for example)

The DashBox will send packets to the ISY every time the DashBox gets a packet.

You just need to be careful not to overload the ISY, Teken has had issues with that in the past, he has a pretty big system however.

Well it looks like I should have tried it again before posting. I had given up on it 6 months ago, but now they are talking reliably. Not sure if updates were made in that time..

Before with a 20 second configured update time, it could take 20-30 minutes for it to update the ISY.

I gotta say certain things require a lot of programs to track with ISY's desire to re-evaluate with every state var change.

j0dan wrote:Well it looks like I should have tried it again before posting. I had given up on it 6 months ago, but now they are talking reliably. Not sure if updates were made in that time..

Before with a 20 second configured update time, it could take 20-30 minutes for it to update the ISY.

I gotta say certain things require a lot of programs to track with ISY's desire to re-evaluate with every state var change.

Some bullet points regarding this sort of integration in no specific order of importance and relevance.

- The most reliable method to communicate with the ISY Series Controller is via ZigBee. Using the DB to send REST data via State Variables can offer delays and missed values.

- If you have lots of network resources connecting to and from the ISY Series Controller this can impact the system from operating consistently.

- Never have the ISY Series Controller perform *Tight Loop* processes. Meaning if you have the system doing math, counting, monitoring, at below 5-8 second intervals it will cause erratic behavior or lock up the controller.

- Do not set the DB to send to the ISY Series Controller lower than eight (8) seconds.

- The need and use for multiple programs are dictated by your use case and how you have scripted them.

- Your system(s) need to be all updated and using the latest software / firmware for the DB, GEM, and ISY Series Controller. As the latest iteration has fixed many bugs, and introduced many feature enhancements.

- If you're seeing *State Variables* literally taking 20 minutes to change you have many issues to address. The first thing is how is the DB->GEM connected together?

So it seems like it's still not 100% reliable for me.

Teken wrote:- The most reliable method to communicate with the ISY Series Controller is via ZigBee. Using the DB to send REST data via State Variables can offer delays and missed values.

I'm using network. No ZigBee radio on either device.

Teken wrote: - If you have lots of network resources connecting to and from the ISY Series Controller this can impact the system from operating consistently.

- Never have the ISY Series Controller perform *Tight Loop* processes. Meaning if you have the system doing math, counting, monitoring, at below 5-8 second intervals it will cause erratic behavior or lock up the controller.

I don't have devices that use the network resources more than one call/hour. Very light load.

Also, very few scripts even running any-more. I moved a few years ago and haven't programmed much since.

Teken wrote: - Do not set the DB to send to the ISY Series Controller lower than eight (8) seconds.

I've been using 20 seconds. Just changed it to 30.

Teken wrote: - Your system(s) need to be all updated and using the latest software / firmware for the DB, GEM, and ISY Series Controller. As the latest iteration has fixed many bugs, and introduced many feature enhancements.

For the DashBox, I've been using the April 2016 firmware and I'm now upgrading the GEM from 4.20 to 4.32.

It could be a problem with my program though, although it seems very simple. $energy.notify.furnace_filter is a state variable.
It triggered at 4:06 and 4:15 during this timeframe:

Your going to have to offer a little more info as I don't see how this chart reflects the filter needs to be changed?!?

What are you monitoring and how does it relate to the filter that would be a good start.


=========================

The highest calling in life is to serve ones country faithfully - Teach others what can be. Do what is right and not what is popular.

The data on the DashBox is stored on the minute, therefore in terms of watts it's the average amount of Watts used over that period. The data the ISY will be getting is in real-time.

If it was after 4:06, that alert would be captured in the 4:07 average. If you can get to the DashBox when it triggers, you should be able to see where it reacted in the Live data section of that channel (Live data holds a couple of hours worth of data).

My program monitors these variables:
and waits for this to remain true for 10 minutes.

I posted the graph as I'm not sure how that logic could be possible for even 2 full minutes. So is it a problem with my program or the interface between the DashBox and ISY?