tmorse305

Open the portal go to Select Tool > Connectivity > Amazon Echo Click on "Variable" at the top of the window Use the pull down to find your state variable 'motion' (It has to be a state variable) Choose Alexa Category "Motion Sensor" Set the variable value that you decide means motion Give it a spoken name Save Discover devices on Alexa Your variable should now be a device with the name you gave it. Create a routine with your variable as the trigger, create a spoken action (BTW the action could also include your Amazon plug!) On the ISY side the variable value that equals motion should always be present for 30 seconds or more so Alexa doesn't miss it. Then reset it back to a "no motion" value. If you use other values for the variable just remember that every time the value changes you restart the Alexa 30 second debounce even if it didn't trigger the motion. For example say 0 is no motion and 1 is motion detected. If you change the variable value to 2 Alexa considers that the same as 0 and restarts the debounce interval.

Create a variable on ISY and expose it as either a contact sensor or a motion sensor depending on what you want to do with it on the Alexa end. Expose the variable to Alexa on the portal. Then create an Alexa routine that uses the exposed variable as a trigger and then create what ever action you desire. I have several of these in use. Just remember the 30 second debounce interval. Changes will only trigger the action if they are > 30 second apart. Examples of how I'm using this: I have a WIreless Tag on my birdfeeder. When a squirrel gets past the barrier (not too often) Alexa says "motion at birdfeeder". I have an Insteon Motion sensor outside on my driveway, when triggered Alexa says "Driveway motion".

I don't have an Amazon plug so I can't try this but I think this would work. Create a variable in ISY and expose it as a contact to Alexa via the portal. Then write 2 routines on your Alexa that triggers the plug either on or off when the ISY variable changes. Not ideal though because there is a 30 second debounce on the contact input so you can only cycle the light on 30 second intervals or longer.

DId you try to reboot Echo?

Thanks Benoit, Since it works fine with as a contact sensor, it seems you can leave the other as is. Regards, Tim

Hi Benoit, The door sense(open/close) is now correct in Alexa. I also created a routine using the door as the trigger condition and that also works. I configured the door in the Portal as a contact sensor. I also tried it using the new category 'Device with Open/Close syntax'. When Alexa discovered it this way it comes through as a device that displays as 'Power is On/Off'. That was a surprise, is that correct? Thanks for fixing this, it works correctly when configured as a contact sensor. Tim

@saphotoexpress, thanks for making the upgrade to 5.x. Sorry to see the contact sensor is still an issue. I'm sure UD will fix it an upcoming revision.

I'm not running 5.0.16C yet but I would say the the problem has not been corrected yet. If you're up for trying something else I would reset all and start over this time add the repeaters first, make sure they install correctly and appear correctly in the console. Then add one lock. Once added, operate the lock a few times, open and close the door a few times before adding the second lock. What I found was when the lock was initially installed only one node appeared in the console. Then after I operated the lock the second node appeared. That said even if the 2nd node appears it looks like there might still be an issue with the lock configuration in 5.0.16C.

That might be the difference. I’m running 5.x software. If you open the door and then lock it does it show as locked? The 4.x software might not support the contact. This last time I tried the 5.x software it showed the 2 nodes but the contact node did not work correctly. Sent from my iPhone using Tapatalk

Did you install and configure(in the August app) the door position sensor when you installed the lock? When I had my lock installed, it looked like this.

Great news, I'm glad you got it working. I'm curious how the 2 nodes for each lock show up in your ISY, is it Door Lock and Door Lock 2?

I ran into the null database issue too when I first tried to set up the lock. I fixed it by factory resetting the dongle, 2 plugs, and the lock. On the next attempt everything was included. It's the nuclear option but as long as you don't have too many devices it's not that bad.

Does the lock show up in your ISY like this or does in now appear as a lock and contact sensor?

From my experience communication with the August lock is very unreliable even with repeaters. The communication with the lock is far more complex than with a simple plug or switch. There was an issue with the lock joining with the ISY, I'm not sure it has been fixed yet. The lock is 2 devices, the lock and a contact sensor to indicate door position. The 2 nodes were not created correctly in the ISY and added to the communication issues I was having. I let UD know about the problem so it may be fixed already. I stopped trying to connect it directly to ISY as the connection was so unreliable. I now use a dedicated Hubitat located very close to the lock and connect Hubitat via the portal. This has proven to be pretty reliable but not perfect. Occasionally the lock status in Habitat and the lock do not agree. There were zwave issues with the August lock by their own admission. August lock support finally downgraded the software in my lock to a version that was more stable but I suspect still not perfect. The version I'm running is "undefined-1.59.0-1.8.15". I also tried IFTTT but there was an issue at the time (~6 months ago) that delayed the communication to the IFTTT servers. As a result lock change status could take upwards of 10 minutes to receive. August lock claimed that was an IFTTT issue but I use IFTTT for lots of things and this is the only device that acts like this. I hope you have better luck, I like the lock but communication outside of the August App is troublesome.

When using routines in this manner remember that Amazon enforces a 30 second debounce period when a sensor changes state. This can make it appear that the routine is not working correctly. For example if you have a routine that announces when motion is detected, when that routine is triggered it will not re-trigger for 30 seconds even if the sensor changes state again. Further, if a trigger occurs during the debounce period and then goes away before the debounce period ends, the routine will never be triggered. Make sure your variable value that triggers the routine stays at the trigger value for longer than 30 seconds if you expect to have triggers close together (< 30 secs)

This may be an instance where the conventional definition of 'open' differs between Alexa and Security Panels. Perhaps @io_guycan weigh in on this. Meantime, I can just use a program to flip the definition for Alexa purposes.

<nodeInfo> <node flag="0" nodeDefId="DSCZone" nls="102Z"> <address>n001_dsc1_z03</address> <name>Garage_Door_1</name> <family instance="1">10</family> <parent type="3">6745</parent> <type>1.1.0.0</type> <enabled>true</enabled> <deviceClass>0</deviceClass> <wattage>0</wattage> <dcPeriod>0</dcPeriod> <startDelay>0</startDelay> <endDelay>0</endDelay> <pnode>n001_dsc1</pnode> <ELK_ID>M12</ELK_ID> </node> <properties> <property id="ST" value="0" formatted="Closed" uom="25"/> </properties> </nodeInfo> Looks like the value 0 is associated with 'Closed', right? Does 0 correspond to 'Open' in the Alexa world?

The sensor status coming from my security panel is flipped in Alexa. I'm using the NodeLink Server to connect my DSC panel to ISY via Envisalink. The status is correct in ISY(closed) but it gets flipped on it's way to Alexa(open). Easy enough to fix but I'm wondering if that is normal or do I have something set up incorrectly. See screen shots, ISY, ISY Portal, and Alexa. Thanks

Yes, otherwise there is a change that the routine won't trigger.

I wonder if your routines are being effected by the 30 second debounce. The other issue is that if you are in the middle of a debounce delay and the trigger condition goes away, then the routine will never run.

I finally figured out the cause of the delay so I thought I would share it in case anyone else is experiencing this problem. I am using a state variable configured as a Alexa Sensor in the Portal. I have the sensor trigger value set to 2. I am using the same variable for program control so there is a brief moment when the programs are running that the value is set to 1. It would appear that when the value changes from 0 to 1, the Portal communicates to Alexa that there is No Motion. Then when the value changes to 2 the Portal communicates that there is motion. The problem is that Amazon imposes a 30 sec debounce rule, so the first communication triggers the debounce and delays the spoken message. I'm not sure if this is intentional behavior or a bug but heads up to anyone that is using variables in this way.

I live in NH and I'm using this same setup. It worked right through last winter and this summer without a problem.

Turns out it is a bit of a hack, although created by Texas Instruments. Don't know if you saw my explanation, see last post.

I finally got an explanation from a different manufacturer (Tuya) as they also referred to EZ mode in their instructions. From Tuya: Smartconfig (EZ) distribution network mode: Smartconfig means that the mobile APP sends a UDP broadcast packet or a multicast packet containing the WIFI username WIFI password. The WIFI chip of the intelligent terminal can receive the UDP packet, as long as the UDP organization form is known, The WIFI username and password are decrypted by the received UDP packet, and then the WIFI username and password received by the intelligent hardware configuration are sent to the designated WIFI AP. Smartconfig is a TI proprietary provisioning technique. Once I knew the proper name, the internet is full of information as you would expect. From TI (see page 4): http://www.ti.com/lit/wp/swry011a/swry011a.pdf A very detailed explanation from a blog I found: http://depletionregion.blogspot.com/2013/10/cc3000-smart-config-transmitting-ssid.html In summary the SSID and the password are encoded in multiple packets, the encoding is done in the length of the packets. Who knew... Definitely not the most secure method.

I agree, the credentials are getting into it somehow, I just can't figure out how. There is a manual, it says "Open the Smart Life app, click +, and select "Electrical outlet", now your mobile phone is connected with your WiFi socket". And in fact it is! I dug around inside the app and came across an FAQ page. The device can be connected using 2 different modes. The default is EZ mode which I have described already. The other is AP mode which in fact generates an SSID that you must connect to in order the connect the device. This is the method that I think we're all familiar with. When I choose AP mode the app requires me to go the the iOS setting screen to switch the WiFi to the SSID coming from the plug. Then the connection is made in the usual way. So the question is how does EZ mode work? I have reached out to the vendor via Amazon to see how EZ mode actually works, waiting to see what they have to say. I'll share it if it's anything interesting.