tmorse305

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.

Thanks larryllix for your reply, That might work on android but my understanding with iOS is that there is no way to change the SSID from an app. The app can only direct you to the WiFi setting page. When I factory restore the plug and monitor for new SSID's using inSSIDer4 software, no new SSIDs appear. This software reports SSIDs that are hidden as well. When I look at the device from my FING box, the plug is present and FING indicates that it is in range but not connected to my network. It looks like any other device waiting to connect to the network. That's why I'm so baffled by this. I'm reluctant to keep this thing plugged in until I understand what it is doing. Could they be doing some kind of hack to get the information to the plug?

Thanks Paul, The steps you describe are what I'm familiar with with other devices. In this case however the plug is not generating a WiFi signal. I confirmed that using inSSIDer4 software on my PC. My phone stays connected to my WiFi during the connection process. I'm baffled how the information is getting from the app to the plug. I thought it might be Bluetooth from the phone so I shut that off and it still connects.

Yes, sorry it's a Coosa branded product from Amazon. I've never heard of the brand, I chose it because it was the cheapest one out there. https://www.amazon.com/gp/product/B073RGKSCH/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1 I actually type the network information into the app so the app and their server have the info, the question is how does it get to the plug if there is no network connection to the plug to start with.

Got it, thanks. That isn't related to the problem I'm seeing. Are you seeing a delay in your Alexa responses to ISY variable changes on the "detect" side of the actions?

Thanks larryllix, The routine that is delayed is a Device/Motion Sensor category in Alexa. The delay is on detection, I didn't see any delays, but I also didn't see a way to add a delay. If you wanted a delay is it added as an Action, similar to adding a wait in an ISY program? Tim

I bought WiFi plug recently (only $5!) to try interfacing to my ISY via a variable and Alexa. I was able to do that although the Alex response to the variable change is so slow that I don't think it's a practical solution. My question is about the configuration of the plug. How does the plug get my home WiFi credentials? Here are the steps: iOS platform Download the app on the phone Create an account Plug the device in and hold power button for 5 seconds to put it the mode that allows it to be seen by the app Select the device type on the app (plug) Enter WiFi SSID and password into the app Press connect Moments later, done, device is now connected The blue tooth is disabled on my phone, all WiFi networks available to the plug are password protected. My phone is connected to my home WiFi, not an AP coming from the plug. How is the plug getting my WiFi credentials???

I've notice recently that there is a ~15 second delay between an ISY variable changing and the Alexa voice response. It use to be just a few seconds at most. I'm aware of the 30 second debounce specification but I'm waiting minutes between attempts and it's still the same 15 second delay. Is anyone else seeing this? Did Amazon make a change? Thanks, Tim

Thanks Techman, I had done the query on the main node thinking it would cover all parameters of the sensor. Not so I guess, a query on the battery node reset it.

I have a 2842-222 v.44. At the last battery change, the battery low indicator is stuck 'on'. I did a factory reset, and restored it via ISY. It functions correctly, it's just that the battery low indicator will not shut off. I'm using a lithium type battery which I have used for years. It's a new battery and measures just slightly over 9 volts. Any suggestions? Thanks