MWareman

...and in Powershell.... $isy_user = "ISY Username" $isy_password = "ISY Password" $url = "http://ISYIP:ISYPort/rest/vars/set/2/72/9" $authVal = "Basic " + [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($isy_user + ":" + $isy_password)) $response = Invoke-WebRequest -Uri $url -Headers @{"AUTHORIZATION"=$authVal} $response.Content

That's the expected behaviour. ISY is an event driven system. Any change in the triggering conditions causes the program to abort running an reevaluate (starting again in your case). You need two programs, as described above.

'Enable Internet Access' is a misnomer. What it really means is 'Use upnp to enable port forwarding in my router'. Most routers don't allow this automatically anymore (it's a security risk), that's why it fails. This is expected. Just configure a port forward manually on your router if you want to access your ISY from outside.

You can actually use a network resource to call the REST API on the same ISY. It works fine AS LONG as you DON'T use 127.0.0.1 as the host. This can cause the ISY to lock up randomly... If your ISY has a static IP (or a static DHCP reservation), you can use the actual IP in the host field.... Just make sure to add an Authorization header with your ISY username and password... Michael.

I'll modify the version int he wiki then. Chris - can you confirm the earliest versions supported? Thanks, Michael.

Chris, I hope you don't mind - but I've added this to the REST Wiki documentation page. Is it correct to say this arrived in 5.0.6? https://wiki.universal-devices.com/index.php?title=ISY_Developers:API:REST_Interface#Z-Wave Michael.

I think you are missing encryption overhead.....

I see a market for a tiny Arduino device in a button that connects to the local wifi network, and can call arbitrary URL, like the ISY directly.... I may disassemble that silly 'Easy' button I've had for a while.... Edit. Looks like the Adafruit Feather HUZZAH will do it. Arduino compatible tiny device with a full wifi stack. Battery charging circuit is onboard as well, all for $16 (US). One of those is going into my easy button....

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.