MWareman

I have my sonos directly play a .mp3 stored on my NAS with this network resource: POST /MediaRenderer/AVTransport/Control HTTP/1.1 Host: <ip.of.sonos>:1400 Connection: Close Content-Type: text/xml; charset="utf-8" Content-Length: 486 SOAPACTION: "urn:schemas-upnp-org:service:AVTransport:1#SetAVTransportURI" <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <s:Body> <u:SetAVTransportURI xmlns:u="urn:schemas-upnp-org:service:AVTransport:1"> <InstanceID>0</InstanceID> <CurrentURI>x-file-cifs://<ip.of.nas>/announcements/alarm_set_to_arm_away_in_5_minutes.mp3</CurrentURI> <CurrentURIMetaData></CurrentURIMetaData> </u:SetAVTransportURI> </s:Body> </s:Envelope> Change <ip.of.sonos> to the IP of the sonos zone device, and <ip.of.nas> to the IP of the storage. The storage must have a share set to allow 'Everyone' read access (since the sonos will not authenticate). This way - you can define many network resources, each pointing at a separate .mp3. The permissioning of the share on the nas was very finicky though....

True. I use MythTV, and when MythTV is playing something I opt for network screen pop-ups instead. Much less distracting.

Tonight (when I get home), I'll find my .PHP script. I have built an API that calls the Google TTS service and references an mp3, saving the mp3 for future use. It then directs Sonos to play it. I'll see if it can be modified to be call specific mp3 files directly. I do everything thru a single zone currently though. I gave not looked into multi-zone announcements (yet)

I guess I should have said 'rain proof'...

I use them to monitor temp and humidity in several points around my house, including in my fridge, freezer and wine chiller. I just ordered three waterproof tags for outside use (mailbox and my two yard gates). Been using them for a while now, and am very happy with them.

On the first question, only you can decide. Just because someone else can access the hardware token does not mean they could logon as you. They need your password as well. The more important consideration is how long would it take you to notice it was missing if a guest removed it? Personally, I wouldn't (but that's mainly because I probably wouldn't notice for a few days....). On the second question. The Gmail app uses a variation of oAuth to authenticate (sometimes called 'bearer' authentication). 2FA is only used on initial setup to get the bearer credential and from then on the app 'just works'. No additional auth. If you lose your phone, you can revoke the oAuth authorization from your account online, and 2FA will be required next time to re-link. Another reason not to configure a recovery account on your phone's Gmail app!

Or you can put a switch in the strike plate to detect locked (hooked to an IOLinc)... Never done it myself, but there are references out there. However, a zwave device is better. Zwave is at least built for security, while Insteon is not. I wouldn't put any lock on Insteon.

Yubikey is indeed a hardware token. They offer USB, mini USB (as in virtually invisible) and a combo USB/NFC hardware token. They support services that use U2F in their authentication flow (Google and Facebook do) and other services that directly support Yubikey directly (like LastPass). It's my go-to hardware 2FA solution. The only thing to add - in your notification only account, use a Yubikey for 2FA to backup the soft token on your phone. Also, make sure to configure an app-specific password for ISY to use as well as enable 'Less secure 'Restore apps... (which appears counter intuitive at this point, since it's enabling a far more secure environment).

If you setup a secondary account (I use this myself for ISY emails) then don't use it as a recovery email address for your primary with 2FA. Otherwise, if the secondary is compromised an attacker could probably switch off 2FA on your primary. Keep it dedicated and seperate for the ISY to use. Still turn on 2FA on it and use an app specific password.... Personally, I opt for no recovery email (to close that attack vector entirely). I have two Yubikeys registered to my Google accounts, one on my keyring and the other in a safety deposit box. If my phone died (where the authenticator app runs) I can easily recover the account with a Yubikey. However, that's likely a little extreme... However, the Yubikey is a great backup to the phone missing/out of reach problem. I use a secondary mostly for aesthetics - the sent mail didn't appear in my primary accounts sent folder. And hey, it's free - so why not. Michael.

No. 'Secure Apps' just means it uses Google's identity provider and does 'bearer' based authentication. The reason it's more secure is the password does not need to be stored on the client, and the authentication can easily be revoked. Given you own the client (ISY), the risk is lower. If you want to mitigate, enable 2FA in the Google account and generate an 'Application Specific' password for your ISY to use. You'll still need to enable 'Less secure Apps', but the risk is much lower since your regular Google account password cannot then be used against the SMTP service. Michael.

Static IP on the ISY has been known to do this. Try setting a DHCP reservation in your router instead and setting the ISY back to dynamic. Otherwise, the DNS server can also cause this. If you don't have split DNS, try setting the ISY to use 8.8.8.8 as it's DNS server.

There are none I've had direct experience with, as I have my garage door hooked up to my Elk for both control and monitoring (it allows my alarm to be triggered instantly if anyone tries to force the door at night, for example). However, there are several zwave dry contact devices out there. Look for one that supports the security profile. If this would be your first zwave device, you should consider adding a couple of additional devices (like the Aeotec Siren) to establish a mesh. Otherwise, there may be communication issues.

Sounds like you need to change your magnetic contact from n/o to n/c (or vice versa) so that trigger reverse is not needed. Otherwise, there is no way to keep things in sync. Related, I personally (strongly) advise against using an IOLinc to control a garage door. It's not a secured device, and significant security issues in the Insteon protocol puts your garage security at risk. If you have zwave, there are zwave devices that are much more secure for this application.

Trigger reverse only reverses the trigger event, not the results of a query (it's a flaw in the IOLinc itself). It is strongly advised to not use that option if using this event in programs on ISY, because when the overnight query all is run it will false-fire anything triggered of an IOLinc sensor.

When you have network wide issues like this (when it was functioning fine before), it's more often than not the PLM. They can fail in odd ways. If you do replace it, make sure you carefully follow the wiki. DONT 'Delete' the old one!! If you have battery devices, you'll have to wake each in turn after the PLM is changed.

Try doing a 'Restore' on the PLM node. The PLM could have lost the links, meaning it will guide the messages.

Cable Internet does not have that requirement... Apparently they only enable the power backup in the box at the end of our yards in my area if you subscribe to the phone service.

I have my ISY, GEM and Dashbox all on a UPS, with the PLM and the GEM voltage transformer directly connected to an outlet at my power panel. The Dashbox reports the GEM CT current values to ISY variables. I then have a program on the ISY that looks for my load at my power panel inputs dropping to zero to indicate a power out condition. I call a network resource on my Pi to begin shutdown of my MythTV frontends (all are on small UPSs) and other non-critical devices. My MythTV server waits for a low battery condition before shutting down (thru the ups USB connection). Even though my cable modem, firewall and switch are on a UPS, my Internet does not work (upstream device that requires power in the community I guess) so I have my ISY trigger a rule on my Elk to call my cell phone (it uses a cellular dialler, again battery backed). This works well enough for me... . A little expensive to setup from scratch if you don't have the Brultech and Elk kit already though...

Purchase the ISY Portal module first. It may be that this now automatically disables the Mobilinc module, not sure. If it does not, Contact UDI Support, they will take care of the deactivation for you. Are you using IOS or Android? If IOS, be aware that Mobilinc was enhanced for Connect specific features, and there is some feature loss when you switch to ISY Portal (push notification, for instance). That can be replaced by adding and configuring Locative to your IOS device. If Android there is no functional change between the two portals, because the Android Mobilinc app was never enhanced for Connect specific features.

This. I highly recommend it. I've used it myself for years.

Chris, Does this mean we can now set the username on the ISY to match the username on ISY Portal (ie, an email address)? If so, that sure would help Mobilinc Users.... Michael.

Every time I consider getting a robotic vacuum, my Wife reminds me of this post: https://m.facebook.com/jesse.newton.37/posts/776177951574 (Don't be drinking anything when reading this...!)

Make the switch a controller of the scene. Then when you operate the switch, the scene is what activates. You can then use a program to adjust the scene based on time of day.

Possibly shouldn't do that. The ISY may come up before the router is ready to serve, causing issues.

What is the current value of %URLPrefix? It's set based on which Instructions you followed. It's either a slash (/), or the secret key for your organization accounts (with a /). There are two companion variables, bother with URLPrefix in them - you set these manually. The state programs copy the appropriate one live for use based on the detection of the wifi network. So, check you have all 3 URLPrefix variables, and they have sensible values.