MWareman

I do exactly this with my Elk sensors. All can be used to trigger programs on ISY, as long as you have the Elk module installed and configured.

I have a (Maker channel) skill defined as 'Goodnight' - calling my 'Goodnight' program (via the portal integration). 'Alexa, trigger goodnight' works every time. It's pretty much my only skill in common use.

I'd get two ISYs, one Zigbee the other Zwave. Soon-ish - 5.x will be able to have the two of them be node servers to each other - and you'll see the power details on the zwave ISY. Until 5.x can do this, you could add the networking module to the zigbee unit and write a simple set of network resources and programs to post the power values to the zwave ISYnfor use in programs.

What is your UI and firmware version? You must be on 4.4.3 to get this.

You cannot send direct dim commands to a scene - only a device. If you need scene members to come on at different levels that usual, you need to either adjust the scene (changing it back afterwards), or use multiple scenes (with the members having differing on levels).

I've been using the Tasker Autolocation plugin with no noticeable battery hit on my Nexus 6P and also my old Nexus 5 before it. This is because Autolocation registers the geofence with the OS, and since 2013 or so Android has supported hardware assisted geofencing (which Autolocation ties into). When you cross a geofence boundary, the OS tells Autolocation which triggers a Tasker profile, and you take action on that. It's all very power efficient. Full details on the Tasker Wiki page (though pardon the dust - I'm going thru it cleaning it up and adding screenshots) http://wiki.universal-devices.com/index.php?title=ISY-99i_Series_INSTEON:Networking:Tasker

You could write a program that adjusts the on level of both devices in a scene to 31% and then turns the scene on, finally resetting the devices scene on level back to 100%, and have Alexa trigger that... However, Insteon does not support turning a scene anything other than 'on' or 'off' directly. Finally, I don't think having a KPL button at 31% will cause it to be any dimmer than 100%. I thought those were purely on/off devices that can only be controlled via membership in a scene.

Everyone should reach out to Wes and ask that he put in separate username/password fields for HTTP and HTTPS - with a checkbox to have them be the same... Not all of us want to reuse a password. I know I don't!

I mentioned in your other thread - you'll either need the ISY Portal - or a commercial SSL certificate installed correctly on your ISY in order that the IFTTT Maker channel will be able to connect. The ISY Portal is recommended though. You would have to use the REST API to change variable values - this is all documented on the Wiki.

This. The firmware you have is the latest available for the 99i. UDI is still offering the fantastic deal on upgrading though!

Yep - You sure did! (Didn't see that until just now...) You encouraged, and I recommended...[emoji14] I think the important thing is to allow 'unsecure' devices... (Which is a bad term IMO). Google want users to use 2FA and application passwords - and if you try and use SMTP without that is is blocked by default unless you change this setting.

It was put there before the Portal was integrated with Alexa - and is used for the spoken name if you are using the Hue bridge emulator based solution for integrating with Alexa. I don't think it should be removed - but it should probably be synchronized to the Portal. However, that's made more complex now with the Portal now supporting aliases.

I generally recommend setting up a separate Gmail account for the ISY to use. You have to allow 'insecure' devices in the settings, which is something I'm not willing to do for my primary account. Then use this new account for the ISY to send from.... Saved me many issues.

Same with me - I have 3 Sonos zones where I listen to music or watch TV the most. Other locations is the house have nothing currently. I either want to buy more Sonos - or wait for Echos to support audio playback. It helps that I get a significant (personal use only) discount from Sonos thru my work though...

The body of emails can have the full character sert in them - so nothing needs encoding to send special characters (like a % sign). When sending via the URL or body of a POST, there is a restricted characterset - and URL encoding must be used. I actually encountered this when variable substitution first arrived for network resources - and worked with UDI to add the .raw suffix that's valid across all (I believe...) parameters that have a formatted value. Michael.

${sys.node.ZW006_1.BATLVL} is probably being replaced with a number followed by a % sign. This will cause an error because it's not being URL encoded. Instead, try ${sys.node.ZW006_1.BATLVL.raw} to get the raw value.. Michael.

IFTTT can also receive text messages. I have a (POC) set of IFTTT rules that receive text messages and set a Fanlinc (via Maker Channel / ISY Portal)to high, medium, low or off. I'd bet you could even add a temperature to set a thermostat.

Illegal implies criminal - and this would be a civil issue. However, the only advise you should take on this is the advise given by your lawyer.. Personally, I don't see how it's an issue to allow the end user to put their own API key in the product, with a disclaimer that the user needs to comply with the license and use terms, but then I didn't stay at a Holiday Inn last night...[emoji14] I for one am looking forward to being able to pipe in my own data from hyperlocal sensors with no latency. Nothing else will give accurate data to the evapotranspiration algorithms that even closely resembles my yard.

No, not currently. This is detailed on the purchase page for the ISY portal. You can configure Mobilinc app on your mobile device to talk with the ISY Portal though. Configure an ISY profile, HTTPS, my.ISY.io and use your portal username and password. Leave the HTTP URL blank. Works for many of us. Michael.

I think HS does the same thing that the Vera does - it implements the API but its not enabled by default. The user, when enabling it, has to setup their own account with Weather Underground to get their own API key and enter it into the product. That way, the licensing (and API restrictions) are between the user and provider, and the device vendor isn't involved - so no commercial use needs licensing. Perhaps a loophole. Maybe valid. Only a lawyer would be able to tell you I'm sure. One thing is for sure - ask the vendor and they will all tell you that you need to pay them - even if you don't. Perhaps it's worth exploring (for Weather Underground) - allow us to enter our own key and set the polling interval to suit our own needs (within our own account T&C). Michael.

Honestly, asking Wes to allow a different username and password to be (optionally) specified for the local connection would go a long way to solving the performance issue...

ALL-ONs happen external to ISY. That's why they are not reflected in the log. They are a collision of a completely wireless device doing its usual send three times colliding with the ISY issuing a scene instruction that was triggered by the first send (directly or indirectly). Wired devices don't send three times. I assume you have either motion sensors, wireless door sensors or wireless window sensors? They are usually a trigger when they drive a program, or when they are directly linked to a device that itself drives a program. The best solution is adding a 3 or 4 second delay at the top of such programs. That way, the program allows the wireless device to complete its sends before acting in it and generating new Insteon traffic. Thus avoids the collision, solving the issue for many (it did mine). Also, I've long campaigned to NOT use IOLinc devices to control a garage door. Its neither safe or secure. I've wired my control to an output on my Elk, which is designed to be safe (no unexpected operations). I do the same with water valves and heating elements to keep my pipes from freezing. I just don't trust Insteon as a protocol for these things.

How about turning off your alarm (if Elk integrated), open your garage door (if so integrated) and unlock your door (if so integrated) - all things many of us can do via our ISY. I have my ISY tell me via Pushover whenever events like these occur - just in case. Maybe my security background just has me paranoid though...

Larry, I do pen testing professionally. Our mobile apps all do cert pinning as a requirement. Our VPN clients look for certificates issued by a CA that we control key issuance from. I have now come across two ISPs that I have caught doing SSL interception due to our strict checking of certificates by our clients - one of them a major national ISP! This threat is, unfortunately, very real. Here is how this attack works... Bad guy does not need your cert. It's self signed. Turns out any self signed cert is fine - and the attacker can just generate their own. How would you know the difference? Do you know your ISY certs hash value to compare on the warning page? Normally, browser makes TCP connection to ISY. ISY sends its cert (public key) which is not able to be verified by the client because it's not trusted. You click past, client generates secret and encrypts it with the public key then sends it to the ISY. Communication continues using the secret for encryption. Secure - as long as nobody intercepted your initial TCP connection. Client => ISY Hack is bad guy intercepts your TCP connection (before the encryption is established) and proxies it to the final destination (ISY). ISY sends its public key to the intermediary, which generates its own private key with public exponent. The intermediary sends its newly generated cert (public key) to your client. Client still cannot verify the cert, but will generate a secret anyway (because you clicked to OK the transaction) and send it to the intermediary. The Intermediary also generates its own secret, and sends it to ISY. Now, you have two 'encrypted' sessions, one between client and intermediary and another between intermediary and ISY - with the intermediary having clear text access to your 'encrypted' session. Client => Hacker => ISY I know this works, because I've done it (in my lab!). This attack works on many public WiFi networks, from other connected clients. There are tools to spoof the MAC address of the default gateway to individual remote clients (on the same subnet). This causes the target client to send all internet bound traffic to you - all you have to do is forward it on to the correct MAC address. The only mitigator is to use a certificate on your ISY that is trusted by your client. That way if an intermediary performs this attack you will see an untrusted cert warning. If you run a 'public' or open WiFi network - turning on strict isolation also mitigates the attack - but it breaks peer-to-peer WiFi device communication (which affects things like upnp, file shares, Chromecast, Apple TVs etc...). The local attack depends on two WiFi clients being able to directly communicate with each other. Of course - ISPs can easily intercept this stuff and insert their own.... As I mentioned already - I have caught a couple already. Michael.

Problem with this is a malicious person could proxy your connection with their own self-signed certificate and still intercept your connection without you being any the wiser... You should add the self signed cert as a trusted root cert on your client - that should prevent the warning on that machine, and protect you from man in the middle issues.