MWareman

Also, isn't 'open' blacklisted by Amazon (they don't want to allow people to accidentally allow people to 'open' zwave locks by voice, by yelling from outside...

Sorry to shout - but it's worth it.... The story... I decided I wanted to get data from my ComEd meter into my data collection environment (to supplement and confirm the accuracy of my BrulTech GEM, as well as provide real time pricing data). So - I contacted ComEd to confirm that the ISY-994i ZS IR/PRO would work. They said it would. I ordered from Orchestrated Home - and received it a few days later. Got the device powered up and filled in the ComEd form to pair the device. That's where the troubles started... Long story short - ComEd admitted that I was the first customer in Illinois to do this with an ISY... and in the end they felt the ISY was somehow defective. Michel gracefully arranged for a replacement to be shipped out to me (from Orchestrated Home) along with return shipping. The new device did not immediately join either - but this time a small tweak to the Zigbee settings and an additional communication to ComEd - and I'm up and running. Real time usage and pricing data... Woo hoo! So - yet another display of fantastic customer service from quite possibly the BEST customer service focussed company available anywhere. Many, many thumbs up. We all appreciate it...

This one: https://www.adafruit.com/product/2821 And it would call the REST API to either maintain a variable, or run programs when events occur. I do agree - a CAI Board and Nodelink being 'native' is nice though. I guess I like tinkering with Arduino...

True. But an Adafruit Feather Arduino compatible wifi board is $17, and the other components needed less than $10. It makes a really cheap wifi current sensor for all kinds of applications. That being said, simple is almost always better. The relay solution (120v coil wired in parallel to the pump) is genius... still, I'd probably feed the relay contacts to a Adafruit Feather as well (with a pull up resistor) since it's so inexpensive. Total about $22 when using a single input. Oh, the Feather has 9 gpio pins. So, that's less than $2 per input. Cannot beat that!

Here is a circuit to interface a CT to an Arduino to measure current. I'll bet you could modify the sketch to call the ISY API via REST directly. It would be cheaper than a synchrolinc and not affect the reliability of the sump.... https://openenergymonitor.org/forum-archive/node/156.html

My sumps are each on a dedicated circuit to the panel, and I feed data to my ISY via a Brultech Dashbox with data from my Brultech GEM reporting use. Works well for me... with no increase in failure modes over a non-monitored solution. Brultech is pricy if this is all you are doing. I wonder if there are any cheaper solutions that use a CT clamp to monitor current and can trigger an iolinc based on thresholds... so we can avoid the failure modes of a synchrolinc....

Definitely before then. It was right when the Maker channel first showed up on IFTTT. 2014-ish I think...

Interesting. Maybe something changed - it's been quite a while since I first tested this.... they used to r next SSL connections ey were not able to establish trust to. I guess that probably changed...

IFTTT cannot call an API with a self signed certificate. It *must* be a paid, trusted certificate (no, cacert or letsencrypt will not work - I've tried them).

You may need to locate separate threads... there are several steps involved and it's not for the non-technical amongst us... From the top of my head.... You need a router capable of registering a dynamic dns name to your home IP address. You need a domain name with a cname record pointing to your ddns name. You need a trusted SSL certificate using the cname correctly installed onto your ISY. (It's rare to find certificate authorities that will issue certificates to ddns names, and the cname trick works around this) You need to port forward tcp port 443 to your ISY. You need to NOT be using an ISP that uses cgnat. Then, you can configure webhooks on IFTTT that can trigger scenes, programs and devices (refer to the API documentation n the wiki). You will need to trust IFTTT with the password to your ISY. Michael.

I have some battery sensors drive a program that turns a state variable to 1 or 0 (for on or off) and also sets the init value. My logic is then driven from the state variable rather than the sensor. That way, if the ISY reboots state is preserved... However, if the sensor changes while the ISY is off then they get out of sync. So, it does not work for all situations.

Forgive me (no coffee yet).... Got some mixed up logic. The not switched element is if you want to ensure that the correct then or else paths are followed when the on or off control signals are sent. Since you don't have a need for the else path, it's not relevant to your situation.... Personally, I'd separate to two programs. The first has the 'If' as you do now, but it simply runs the second programs 'Then' statement. The second programs 'Then' is the same as you currently have, but it's 'If' is empty. This prevents it from terminating at the 'Wait' if the condition changes, allowing the off command to run after then timeout...

The other thing to try is to prevent the trigger from evaluating false when the motion turns off... Change: And Status 'Motion Back Door-Sensor' is On To: And Control 'Motion Back Door-Sensor' is On And Control 'Motion Back Door-Sensor' is Not Off Then, a false condition won't occur when it turns off, but it will restart the timer each time motion is detected....

You mentioned 18 months. Could it be 24? It's pretty common for PLMs to fail in and around the 24 month mark...

Problem is, all geofence apps rely on IOS APIs. So, all are going to behave about the same... On Android, I'm holding out for Agave to add a geofence function (registering the device against ISY Portal as well as managing locations to fence). Another option, now the Locative app is open source, any IOS developer should be able to take that and add ISY Portal registration and location management to make it a better product. However, basic reliability likely won't change because it all depends on device APIs.

This is based on the portal you subscribe to, not the app you use. If you subscribe to 'Mobilinc Connect' - you need to connect Google Home with Mobilinc. If you subscribe to 'ISY Portal' - you need to connect Google Home to Universal Devices. If you don't subscribe to either portal, neither will work...

Insteon is not encrypted, and messages can be spoofed and/or blocked. It requires the attacker to be nearby, but I would never advise trusting Insteon with securing your house or garage.

This can happen if you use an iolinc in certain modes and have trigger reverse enabled. When the 'query all' runs the iolinc will flip state if trigger reverse is enabled. Best solution is to not use an iolinc to control a garage door. It's neither secure or reliable. I also use my Elk, but there are some secure zwave options as well...

Recent IOS and Android versions do not support the old encryption that the 99i supports. Your use may be limited to LAN without encryption.

If nearby, and with a SDR, it's technically easy to sniff and determine the address of the PLM and then any arbitrary device, by sniffing and observing. Find a house with the garage door kit and you'll be able to open the garage door at will. Oh, and there are in fact Insteon interfaced door locks (morninglinc).

It's also common for companies with agreements like the above to have NDAs in place that prevent talking about the other parties plans, products and sometimes even the fact that there are any agreements in place. Sent from my iPad using Tapatalk

The ability to work without a PLM was introduced when the 994 got zwave (or shortly afterwards). It's not available with the 99i. Without a PLM, it will always boot to safe mode I believe... Sent from my iPad using Tapatalk

You cannot send direct Insteon messages to non-primary KPL buttons. You must put each button into a scene (as a responder - to create scene responder records) and then turn the scene on or off from your program to light or extinguish the KPL button as you need.

I have not tried this yet, but for the scenario where you have a KPL and LampLinc in scene, why not assign the spoken to the LampLinc and have the status change of the LampLinc run a program that turns on (or off) the scene so the KPL follows? The KPL would operate the scene, so it works naturally locally. Google Home can get the status of the device when asked. The KPL will update when Google Home directly controls the LampLinc. The only issue comes up if the LampLinc is in multiple scenes, but if that is not the case it may work around the issue. Sent from my iPad using Tapatalk

Before Agave, I used only Tasker to control the things I wanted, and AutoRemote for updating widgets based on iSY events. I now use Agave, but have kept the AutoRemote bits. And yes, I purchased Mobilinc (Android) a long time ago. It's shelfware now mainly because it simply hasn't kept up. Anyway, my Tablet is IOS, and I do use Mobilinc there. I actually like the solution on iPad.. Sent from my iPad using Tapatalk