MWareman

I'm out of town currently, so it will be a few days before I can look into it. Can you detail the profiles you've created, the results you get etc. Tasker can create a runtime of actions as well (check the Tasker manual). This can really help also. Be sure to sanitize the API key and any username/password that it will almost certainly contain... Michael.

Sounds like the sort of symptom I had when I had my CPU overclocked.

This is what I use, with great success. I have three of them as a base mesh...

Zwave is a mesh network - it's communication relies on having several non-battery devices to form a mesh, ideally spread around the house. It you are planning on secure devices, the requirement tightens somewhat requiring security capable non-battery devices to form the mesh. Plan for at least 3 other powered devices from the beginning, in addition to any battery devices you are planning for.

You can only turn on or off a scene. You cannot turn it on to some level other than 100%. For that, you'll need separate scenes. When the address is a scene address, the number after DON is ignored. It's only useful for devices. This is because a scene is a logical construct of a specific combination of devices, each with a specific brightness. Scenes have no status, and no 'current level'.

Not true with the Homeseer zwave switches. 'Control' works just fine with these on 5.0.8.

Yet another reason I don't think it's a good idea to use IOLincs to control a garage door.... In my case a random opening would set off my alarm, and cause a police response!

In my case, I have a Smarthomes brand water valve currently connected to an IOLinc - only because I didn't have any more outputs on my Elk. Since then, I've purchased an output expansion for my Elk. I've not installed it yet - but my plan is to move the valve over to it. There is no need to use the Elk specific valves - they are very overpriced IMO. Reliability is very important in this particular system. I have water sensors in some key places hooked as non-alarm zones on the Elk, so my logic is going to be entirely on the Elk once I've completed the move of the valve. I just don't trust Insteon for this system, just like I don't trust it for my garage door... (Which is also connected only to my Elk). Michael.

I have a First Alert relay installed in the back-box the basement smoke is on, and it has low voltage wires coming out. The smoke is a 120v one. At first, the code officer thought it was an issue. I sent him the manufacturers instructions, and after some research to he code official passed it. So, in general, yes. Cannot mix low and line voltage. However, as always, there are some exceptions. Just have to find a suitable device that's code compliant.

Didn't mean to over estimate! Apologies... I, for one, am *very* excited about the impending demise of Java on my machines...

Yes! Perfectly. During troubleshooting, it's usually relatively real-time anyway. Thank you! Michael.

When I had an Echo, I used to connect my phone's Bluetooth to it and use it as a speaker...

You must split to two programs. Have the first program call the second programs 'If'. I'm concerned though that your thinking about programming in the traditional 'flow' sense. ISY is event driven. Sometimes we need to think differently. Edited: typo

Adding to this. If you have the new-fangled AFCI breakers they will trip if the live/neutral are unbalanced. This means you cannot share a neutral without being unable to reset the breaker. Just don't do it!

TL;DR; "Please add and expose logging to ISY Portal for inbound requests containing the users inbound key.... with the HTTP code response..." .... So, spending time messing with Google Home (Assistant) - and it's really cool. One thing I'm working on right now is fan control. So, I have 4 scenes ('Fan-Off', 'Fan-Low', 'Fan-Medium' and 'Fan-High') and these all work flawlessly with a KPL. I have created ISY Portal IFTTT triggers for these scenes: https://my.isy.io/api/ifttt/family_fan_off/key/{GUID-removed-for-security} https://my.isy.io/api/ifttt/family_fan_low/key/{GUID-removed-for-security} https://my.isy.io/api/ifttt/family_fan_medium/key/{GUID-removed-for-security} https://my.isy.io/api/ifttt/family_fan_high/key/{GUID-removed-for-security} POSTing to the URLs results in correct activation... All good so far, and nothing unusual here. In IFTTT, I have created a applet with 'Google Assistant' in the 'If' section, and 'Maker' in the 'Then'. Here are the details: Say a phrase with a text ingredient What do you want to say? "set family fan $" What's another way to say it? "set family fan to $" And another way? "set fan $" What do you want the Assistant to say in response? "Setting family room fan $" Make a web request URL "https://my.isy.io/api/ifttt/family_fan_{{TextField}}/key/{GUID-removed-for-security}" Method: "POST" Content Type: "application/x-www-form-encoded" For those that are used to Alexa, Google Assistant has the ability to parse a word, value or a word and value from what you say, and use that element in the response. In this case, I'm having it parse 'off', 'low' etc from my verbal request, and using it in the response URL to Maker (and ultimately the ISY Portal). Should be very cool - except when I ask 'Hey Google, Family Fan Low', Home responds 'Setting family room fan low' but nothing happens. If I look at the IFTTT activity log for the applet, I see two errors logged for the verbal action: "set family fan low" "! Maker Error - An error with Maker prevented your Applet from working" and "! Action Skipped" After some digging around, I found the site to look at what Google home heard (you have to enable request logging in your Google Account first - ... 'https://myactivity.google.com/item?product=31' I discovered that Google Home was hearing 'set family fan love' instead... resulting in the URL being 'https://my.isy.io/api/ifttt/family_fan_love/key/{GUID-removed-for-security}'. This results in a '400 - Bad Request' from the ISY Portal when Maker sends it... It would be nice if they added the ability to constrain $ so one of a list of possible words (something like ${low|medium|high|off}) - but it's still a pretty cool ability. What took me 4 rules with Alexa I've done with one on Google Home. Now, the feature requests.... On ISY Portal - clearly the currently named 'IFTTT Inbound Events' can, in fact, be used for services other than IFTTT. It's likely more properly named 'Inbound webhooks' or 'Inbound triggers'. Any chance you could consider renaming this? Also, renaming the key (from "IFTTT inbound key" to "Inbound key")... Second, there is no logging of requests exposed. Under 'Logs' - could you expose inbound requests that contain the users current key... This way, we can see requests that have the key, but do not otherwise match configured rules... If we had this, it would have been trivial to see the problem (I would have seen a request to 'https://my.isy.io/api/ifttt/family_fan_love}/key/{GUID-removed-for-security}' with the 400 error that resulted...). It would make troubleshooting *much* easier... Thank you! Michael.

If you currently have a 99i, you may find the upgrade offer more attractive than a refurb. It's on the UDI sales page...

We are told that Yes - ISY management is moving away from Java. It will likely take a while - likely in the order of years. That being said, I use Win 10, hate Java yet I use my ISY admin console all the time without issue. We need to debug what's wrong with your system to figure out your trouble. You'll be needing Java for a while to come...

Sounds like a device with a defect in manufacturing. Never seen this myself, by I'd contact Smarthomes warranty Dept...

Here is the link to apply for early access to voice actions for assistant. In the vertical, they list 'Home Automation'. https://assistant.google.com/developer/eap/ It was listed in a blog post by Google earlier today: https://android-developers.googleblog.com/2016/12/start-building-actions-on-google.html Conversational actions look rather like Alexa's skills. You initiate a conversation 'Hey Google, talk to Izzy' then the custom action takes over. It would be neat if UDI could get 'Talk to home'...

Sometimes, I write program to have devices set integer variables to track their state, just so I can use the integer variable as a condition in another program without having the program trigger every time the device changes state...

Also to note, when the ISY is rebooted the ramp rate may show as 9 minutes for devices until the device has been successfully queried. This can be especially noted if 'query at startup' is not on. Not sure if this is only with some versions or not, it's not something I've checked for in a while. Coupled with a comm problem, or dying PLM I could see this as a symptom.

This.... I'll add to say I *REALLY* trust UDI....

You can actually get the Sonos to play arbitrary .mp3 files without needing to hook a Rpi up to the line in of a Sonos, purely with the network module and a SOAP request pointing Sonos to the url of the .mp3 file. I tested this a few months ago, but the delay was about 2-3 seconds on top of any conversion delay. Too much for my application.

The dashboard is the only way to set client and server TLS settings, and manage certificates to secure communication to and from the ISY.

I use voice announcements via my Elk system. Expensive if that's all you need, but if you have an Elk already it may be an option.