James Peterson

For some reason my ISYs no longer respond via port forward. Everything was fine till about a week ago. I had a problem like this last year but it resolved itself, but honestly this type of issue shouldn't happen. Actual setup: External port 653 : Internal addr:port 10.1.1.154:443 Current setup for testing: External port 81 : Internal addr:port 10.1.1.154:80 . - not working External port 653 : Internal addr:port 10.1.1.154:443 - not working External port 80 : internal Rpi 10.1.1.35:80 - working - I have rotated the forwarded ports with no change to ISY response. ISY responds just fine internally on both HTTP and HTTPS I really think that my router hates my ISYs. Netgear X4S R7800

Great. I have been misinformed for a while then. I always assumed that the ISY skill had to be enabled for Alexa to to the ISY at all. Thx. Sent from my Nexus 5X using Tapatalk

Unfortunately not removing the custom skill negates the security of not having the unlock enabled in the Alexa skill since locks can still be unlocked using the custom skill. Is there anyway to disable the custom skills? Sent from my Nexus 5X using Tapatalk

Good to know. Will the ability to unlock the door be removed from the custom skill?

According to the wiki: http://wiki.universal-devices.com/index.php?title=ISY_Portal_Amazon_Echo_Integration#Supported_Commands * For Door locks only the following commands may be used: * Is Locked: "Alexa, is front door locked?" * Is Unlocked: "Alexa, is front door unlocked?" * Lock: "Alexa, lock the front door" * Please note that, for security reasons, Unlock is not supported However these command never seem to work. I have had to use the alternate syntax: Alexa, ask izzy if the front door is unlocked or Alexa, tell izzy to (un)lock the front door . <- unlock is the reason why I do not use these devices atm According to the wiki unlock is not supported, but I can tell from experience that it does work. Is the new update going to fix this? Or is this an anomaly?

Known amazon issues. I believe it is being resolved. Sent from my Nexus 5X using Tapatalk

The ISY skills seem to recognize the my door locks just fine although I refuse to set them up. Like I said, I don't want anyone to be able to yell from outside to unlock the doors. What confused me about his post was that the command order. I guess I'm just thinking to much into this.

I noticed this post today from Schalge. http://www.schlage.com/blog/categories/2017/02/how-to-use-schlage-connect-amazon-alexa.html It claims the following commands work through these devices once setup: “Alexa, is my front door locked?” Alexa: “The Front Door is unlocked.” “Alexa, lock my front door.” I do not have either of these devices but would like to know if these statements are correct. I would think that these commands fall under the security protocol for Alexa and would need to be passed with the alternate spoken commands “Alexa, ask XXXX if my front door locked?” Alexa: “The Front Door is unlocked.” “Alexa, tell XXXX to lock my front door.” I know this is how the ISY handles these type of commands. Can anyone confirm this post? For what its worth, I don't agree that Alexa should have this control anyway without being able to distinguish or identify voices. We have tested and been able to unlock a door from outside by yelling through a window.

Have you enabled upnp on your router or do you have the ability to port forward? Sent from my Nexus 5X using Tapatalk

LOL!!!!!! Apple Fancy. Thats awesome. but yes, I do plan on updating the UI to be more intuitive and less mechanical. I just don't know how. UI is not one of my finer skills. I'm hoping to enlist the wife to handle that as she is a fairly qualified web developer on her own. I hope she can push some of that forward. A lot of this really depends on its "worthwhileness". This is not exactly a profitable quest so it is all in spare time right now, and I am in short supply. Thank you for helping out the cause and please feel free to submit requests and bug reports. I can't make it better without all of your help.

I like the idea of selecting the devices, scenes, variables that you want notifications from. My basic concern for wanting this is to be able to receive alerts to my phone even when the app is not running. Then be able to take that notification and take the user to the appropriate response location. But I think we are finally getting on the same page. I don't notifications that my living rooms lights just turn on while I am home, but if I am on vacation and they just turned on and no one is supposed to be home, yes, I want that notification.

http://www.agaveha.com/versions/ That should help.

yes maybe, but not necessary. yes na

Honestly I feel like Steve Jobs trying to convince IBM about personal computers and being told why would normal people want a computer in their home... As for bandwidth issues? Yes, some of us have access to lots or up to unlimited amounts of data. When I or anyone spins up a subscription, quite a bit of data is transferred from the ISY or Portal to the subscription client, then sits and waits for subsequent notifications. When you are running this client on a mobile phone and walking between cellular towers and wifi to data and so on and so forth, this constant reconnect starts to eat up data and begins to be unreliable. I do not believe that the socket idea was designed for this type of use in particular sine the connection need to be maintained and mobile clients do not like to maintain these types of connections for long periods of time. The idea I am finding so hard to explain would never need to maintain a connection and or spin up sending massive amounts a startup and current state data. My Idea: Create a new network module that can be purchased and installed on the ISY just like any other module. This module will handle sending the data to the GCM endpoint. Users will have to register their messaging key with the ISY directly and no portal involvement. NOTE: If the ISY is going to complete with mobile internet providers providing their own HA products and other standalone HA on the market it has to start making moves towards more mobile friendly tools. The ISY is a great tool and was a great standalone product for a while, but clients are no longer standing still.

100% Gary!! on the mark. That is exactly what this is kindof. a subscription. but instead of sending notifications through the subscription socket they would be POSTed to exp: https://my.isy.io/GCM/endpoint.php From there the event notification would be processed and posted to FCM host at google with the message KEY identifying the device to send it to. FCM then sends the message to the device. If the app is offline, it is cached and sent later. You wouldn't even need an ISY app to receive these notifications. but if you did have an app that could process the notifications as they came in, they could then be directed to specific app activities and respond to whatever was needed if it needed attention. OMG my mind is exploding with all the awesomeness of this!!!

Do apple apns have an Android lib? If not I don't support them. GCM/FCM has both an Android and Apple lib so that is why I suggested that. As long as it's compatible with both I won't have preference. But you are on point that the portal or some external server needs to handle this and not the isy specifically. Sent from my Nexus 5X using Tapatalk

I don't know maybe I am miss describing what I am trying to describe here. From what I know there would not need to be a subscription from the isy to the portal for this particular type of service. Sent from my Nexus 5X using Tapatalk

I don't think it would need to be an always on connection. :::Imagine I'm using my hands here:::: 20000 feet overview.... Add an API endpoint to the Portal that instead of sending commands to the ISY, receives subscription info. Update the portal setup on the ISY to send these subscriptions messages to the new endpoint if messaging KEY exists Your app registers with Google and receives a messing KEY. - the App then notifies the portal that you have a MK(messaging Key). - the portal notifies the ISY to begin sending messages OR portal begins accepting messages from that ISY Begin Infrastructure already in place: - now that the Portal has a messaging key associated with the account it can send all messages received from that ISY to the GCM/FCM endpoint at google. - https://firebase.google.com/docs/cloud-messaging/send-message Since the device is now registered with a MK it will receive all messages from the ISY without having to be connected. This will save data for the users and no more constant sockets drops to the ISY as a mobile app walks between networks. I know its a bit more then this to setup, but I don't think it would be all that hard to do. And the benefits are off the charts for bringing the ISY into some serious mobile capabilities.

Winner!! Sent from my Nexus 5X using Tapatalk

I just want it for the push notifications. And using the portal technology as the implementation for it bypasses the need for the user to have to have an external accessible IP address. Without the external accessible IP address even if I were to create a secondary server to host the push notifications that user would not be able to use it. My only other option would be to create my own portal setup for the isy that a user could purchase on the Udi Market. That would be the only way that I could reliably assure the user that they would be getting all of the notifications from the isy using push notifications. Sent from my Nexus 5X using Tapatalk

any plans on adding cloud messaging to the portal? It seems that all the infrastructure is already in place and just an API call to pass the messaging KEY to the portal and it would be up and running. This would allow for services and apps that are not currently connected to the portal to still receive notifications. Ya.... BOOOM!!! mind BLOWN!!!

Now that we have Amazon Echo support, when or is there a plan to add Google Home?

I was having this issue till I used the command "Alexa - tell izzy to open/close the garagedoor" instead of "Alexa open/close the garagedoor" "garagedoor = program for determine correct garagedoor status and action"

I recently purchased 2 new garagedoor openers after a failure. The new garagedoors were the chamberlain whisper drives with myQ. I neglected to read up on the interface and it turns out, as I have noticed quite a bit on the forums that there is no way to communicate my IOLincs directly into the opener itself. So..... I looked around and found some information about them and wired my IOLinc directly into my opener remote. I have put up a tutorial up here: http://www.agaveha.com/documentation/chamberlain-myq-bypass/

I am not sure how others accomplish this, but I put all of the buttons in a scene for each state of the fan and set the appropriate levels for each button and fan motor depending on the button press.