MWareman

If there was a hex representation of 'device x changed' pushed to the portal and to the GCM API (each time any device changed) - if the device is listening it can then go get the new state of device x. If not, it gets discarded after some time (few mins). Android has a system called Intents. An app can register an intent such that when messages are received thru GCM the OS will wake the app and deliver the event for it to process. The app itself isn't actually running all the time. It's an incredibly efficient way of running an app that needs to receive notified pushed from a cloud service.

I have my inner mud room door on my alarm system as well. When the outer door is violated (entry zone), the inner door is NOT a walk zone. Meaning if an intruder comes in that way and opens the inner door before disarming the alarm - the entry delay terminates and the alarm activates immediately. I have a keypad in the mud room. At least that's my reason.... But we are in the habit of keeping the inner door closed (cat will get behind the washer/dryer if we don't!)

Gmail replaces the 'From' address with the address you set in authentication. No way around that. To filter, use a subject line prefix and create rules in Gmail. Michael.

I think what Michel is saying is that although the ISY maintains a persistent outbound connection to the portal, it does not actually send any events unless there is a client also connected and subscribed to the Portal. This means that if the Agave (or Mobilinc) is not running and connected to the Portal, as it is now the Portal will not receive events, so its not possible to then push anything anywhere. This was probably done as a performance optimization on the Portal side - one I can somewhat agree with. I'm not sure how well the Portal would handle thousands of ISYs streaming events real time, without significant additional investment - especially when there is any purpose to the Portal listening for events when there is no client connected to the Portal. The only way around this would be to stand up our own cloud server, have a process on it 'subscribe' to the Portal (thus establishing the outbound stream of events from ISY) and then pushing the events to GCM (managing the messaging key ourselves). However, even this would put a significant additional load on the Portal if lots of people do it. Michael.

Maybe a way for third parties to host their own cloud service that can receive notifications from the Portal (if so authorized). Then, the developer of the other service can implement whatever they want. I feel that James is looking for a way to have Agave receive events thru the Google push service (GCM), without having to leave a subscription open. Michael.

The reason that UDI includes the Network Module if for this kind of functionality, but at the ISY end of things. Personally, I'd love to see the equivalent of the Networking Modules but hosted on the portal. It can then have recipes for easy integration to other cloud services (Pushover, IFTTT, Hue, Honeywell, etc, etc).

Small correction... writing the exact same value does not cause a retrigger... only writing a different value. So, the value would have to change - but I suspect that's the case anyway coming from the GEM. The other thing I note, on 4.5.2 writing 2.33 into a variable via the API causes a 404 error (and the integer does not get updated, program not triggered). What firmware are you running on ISY? I'm just not sure how you are getting a non-integer stored into the state value... unless you are running the alpha ISY code and/or this is a zigbee GEM integration (rather than via a Dashbox). Thanks to @larryllix for reminding me I'm not always correct!

Calling a disabled program does not enable it. It just runs it (based on the run branch selected - If, Then or Else). I do this a lot. Simply right-click the 'Action' program and select 'Disable'. No - it's not a bug per-se. It's a symptom of ISY being fully event driven. Natural program flows often get broken in ways you might not expect when everything is driven by events. Michael.

Example for two programs... First: Voltage_Low - [ID 0002][Parent 0001] If $Brultech_Voltage < 100 And ( $Brultech_Voltage < 1 Or $Brultech_Voltage > 4 ) Then Run Program 'Voltage_Low_Action' (Then Path) Else - No Actions - (To add one, press 'Action') Second (disable this program - thus preventing it from any auto-triggering. This will allow it to only be triggered from your main program): Voltage_Low_Action - [ID 0003][Parent 0001] If Then Send Notification to 'Voltage Below 100 Volts' Wait 1 minute Disable Program 'Voltage_Low' Wait 10 minutes Enable Program 'Voltage_Low' Else - No Actions - (To add one, press 'Action') This will decouple the 'Wait's from the triggering events... Michael.

So, every single time the variable gets written, even if it dosnt change, will cancel the running of 'Then' (at the current wait) and reevaluate 'If'. So, the 'Then' may be cancelling before the disable is reached - if your GEM is sending more often that the initial delay (it probably is). You may need to seperate to two seperate programs for this to work.

Silly question... '$Brultech_voltage'. Is this a State or Integer variable?

With this: Disable Program 'Voltage_Low' Wait 10 minutes Enable Program 'Voltage_Low' The enable will never run. The 'Disable' followed by a wait will cause the 'Then' to terminate at the Wait.

Waits will get interrupted, as will loops. A program with just a set of steps (no waits or repeats) will execute 'atomically' - once triggered it will always complete. So, your test (having a wait) will terminate when the triggering condition changes. Since disabling a program is essentially just turning off triggering, this would terminate. If you have a program with no waits or repeats, it will complete even if disabled mid execution. I think... [emoji14] Try one program... 1) Turn light on 2) disable this program 3) Turn light off Does the light turn off? I would expect it would...

More secure, yes. Not sure I would say 'very secure' though. It's still based on an insecure protocol transmitted in the clear. If someone was so inclined, they could still just turn the outlet on first.

I don't *think* so. There is a stop program as well... Disabled programs can still be run manually, and run from other programs. I don't see why they would stop just because triggering was disabled.

It's likely that your cameras would have to support SSL, otherwise you may get a mixed content warning (and some browsers won't render).

The micro modules have a sense wire, which is normally used to sense power when a controlling switch is turned on. You could use this (with no load) to trigger a scene that turns on and off the bedside light. It would need a suitable box to put it in, but would probably be the cleanest result.

If in the U.S., I've had great success with Watchlight (alarm relay). They charge $120/year with (I think) a $35 setup fee...

No. Yes. The network module allows you to make outbound network requests from the ISY in response to events. It's not required for external devices to use the API to trigger events (etc) on the ISY.

Honestly, don't get rid of the Elk M1! It's one of the premier security systems available, and interfaces seamlessly with ISY like no other alarm system. You can add a wireless transceiver to it and wireless sensors to supplement or replace existing sensors.

No, it might not. Yet another reason to dislike iolincs connected to garage door openers!

Get a second ISY... [emoji14]

2FA is an acronym for 2 Factor Authentication. I always recommend everyone uses it - it provides very strong protection for your account. I'm glad you got things going!

If 2FA is NOT enabled, allow 'less secure apps' on this page: https://www.google.com/settings/security/lesssecureapps If you have 2FA enabled, create an 'app specific password' to use instead ontyour usual Google password and 2FA PIN via this page: https://security.google.com/settings/security/apppasswords Michael.

Do you have 2FA enabled on your Gmail account? You need to make sure to modify your Gmail account to allow unsecure clients, and make sure you are using an application password (if 2FA is enabled)