MWareman

For the second year running, Google Assistant beat out Alexa, Siri and Cortana. “Google Assistant is smarter than Alexa, study finds But Amazon's assistant is getting better. The Amazon Echo might sell better than its biggest competitor -- the Google Home. But for the second year in a row, a study found that Google's digital assistant is smarter than Amazon's assistant, Alexa. Alexa is catching up, though, as it was far and away the most improved from 2017 to 2018. ..... The study found that Google Assistant attempts the most responses, and gets the most attempted responses correct. Strangely, Assistant performed even better on a phone than on a smart speaker. Surprisingly, Microsoft's Cortana took second place, with Alexa trailing both and Siri lagging far behind the rest.” Full details at: https://www.cnet.com/news/study-finds-google-assistant-is-smarter-than-alexa/ I have to say, we have started using Google Assistant on our phones way more. It seems to get things correct far more often. That may be due to the microphone being much closer though.

While you cannot charge from clouds yet, you can already charge batteries from the sun... https://www.amazon.com/Charger-Portable-Waterproof-Shockproof-Dustproof/dp/B00YOP7LV8/ref=zg_bs_2407762011_1?_encoding=UTF8&psc=1&refRID=23G2Q9R04NPN8P6Q0618

It claims to, yes. But it doesn’t in my experience. I had three Aeotec Range Extenders to support two locks. Communication between ISY and the locks was hit or miss. I replaced them with two Aeotec sirens - and have not had a comm issue since. Anecdotal for sure. Others have had the same experience.

Copying the original data may be copying corruption. Normally, you boot ISY with a blank card and it will rewrite its file system. Once written you use the admin console to restore a backup - or reconfigure from scratch.

They didn’t for me. I used two Aeon Sirens - about the same cost as the repeater but they actually worked. The repeaters were junk. (Didn’t support secure repeating apparently)

Locks must enroll securely with the controller (ISY), and the zwave protocol requires secure enrolling be performed when the controller and device are very close together - often as little as 1 or 2 feet is required. After enrolling, you can move them back. However, I will caution that most people experience significant problems when the network consists of the ISY and one (or more) battery operated device(s), like locks or battery operated motion or open/close sensors - and no powered devices that correctly support secure mesh routing. Sigma, the company behind zwave, strongly recommend a base network of the controller and at least two additional powered devices to create a base mesh. For this purpose I would get two of the Aeotec 6th gen devices and not look back.

That should work.

I use dusk/dawn triggers from the motion sensor and have each dusk or dawn trigger start/reset a 24 hour timer. If the sensor battery dies I get an alert once the 24 hours expires.

I think that’s a mischaracterization. ISY never sends an All-On message. Otherwise, ISY would know all devices are on - and it doesn’t. What is happening is a message collision on the power line, and it looks confusingly similar to the All-On message - and older devices are acting on that apparent message. Newer devices now ignore the All-On to avoid the problem. It’s possible that spamming the ISY API with messages could have caused such a collision between the ISY sending scene on messages rapidly and devices confirming the new status back to ISY - which would be retried if the insteon network is congested.

I posted somewhere how to setup Apache to reverse proxy ISY retaining support for the websocket subscription used by Agave. Unfortunately, I’ve not found a way to reverse proxy the SOAP subscription needed by Mobilinc or the Admin portal.

Two things. First, confirm you are using the second portal accounts username and password. Perhaps obvious, but worth checking. Second, if the second portal account, do you have the ‘Preferred ISY’ correctly selected? This is the ISY that Mobilinc will connect to.

In the second Portal accounts profile, did you set the preferred ISY?

I don’t believe so. You can set the notes field using the SOAP interface though.

The Polyglot web interface has an option to reboot the ISY as well... in case it’s needed...

Ahhh, yes. M5.large. Affecting enterprises everywhere.... Good luck with the changes! We’ve also hit issues with this issue stance type over the last few weeks and got advised to move away from them...

Do you have 2fa on your Gmail account? If so, you’ll need to use an app-specific password instead of your regular gmail password. You will also need to allow ‘less secure’ access to your gmail account. Otherwise, basic auth over TLS will not work.

4.6.2 is the latest stable release. The 5.x versions are Alpha (not even Beta yet), and so are not considered stable yet.

One does not simply add only the zwave add on though - especially for locks. As many of us found out - zwave requires at least 3 powered (non battery) devices to form an initial mesh. Locks don’t count, but the ISY does. Most locks need a security enabled beam forming repeater device - like the Aeon Siren (although other devices are now reported to be as good). Avoid the original Aeon ‘repeater’ - it does not work with locks.

When establishing an SSL connection, it’s the server (ISY) that has the computationally intensive task of calculating the session setup crypto. In commercial sites, many system use hardware assisted process for speed (at work, I use F5s...). The ISY, on the other hand, has a CPU less powerful than an Arduino (ish - it does not take much to keep up with Insteon and Zwave serial communication speed) - and no crypto processor. That calculation is going to take quite a while. Re-do your certificate at 1024 bits and you will see a 4 time improvement in speed (assuming your current cert is 2048bits).

I see the Else in the code example...

I wrote a PHP script on a Linux system that triggers on an API call from my ISY, obtains an image from the camera (a Foscam in my case), and then sends the image to Pushover (where it’s displayed on my phone, and can be saved to the local phone).

I have 4 minis and 1 regular Home. The most popular function is ‘Hey Google, broadcast.....’ and all Home devices wake up and broadcast the comment following. It’s become a whole house dinner bell... I also have my Minis ‘paired’ to either a Visio Smart TV or a non-smart TV with a Chromecast. My Vizios are connected to Sonos Playbars. This allows me to ask for any given piece of music and my Google Music Subscription springs to life playing thru the Sonos. It’s a very slick integration.

I don’t think Insteon devices support adjusting the ‘Button Hold’ ramp rate. I think it’s fixed in firmware.

Add a small wait (couple of seconds) before the notification is sent. And retriggering will cancel the wait and start the program again. Only the last trigger will get to the notification. A side item. Using an iolinc to control the door is not secure. Insteon has not security, and it can be spoofed.

Before implementing remote closing, consider the safety implications. Plenty of kids have got seriously hurt by closing garage doors even when the IR LOS safety devices are working fine. Doors usually have a power based auto-reverse as well - but it’s when this fails that the chance of injury rises significantly. My choice is not to do this without a camera to visually verify that the door closing area is clear - and add a closing siren (such as the MyQ system does).