MWareman

If you 'installed' the Admin Console by using: http://isy.universal-devices.com/994i/4.4.1/admin.jnlp ..then you'll need access to that URL to open the console. Try using the url: http://your.isy.ip.address/admin.jnlp (but of course change your.isy.ip.address to be correct!). This will load the console from the local ISY rather than from UDIs server. If you look in your Java cache, you'll see things are tied to the URL that you load the .jnlp file from, and that's where the java classes are loaded from during initialization. You won't be able to use a different version that what is installed on your ISY though. Michael.

Native integration? Yes. It's been said this will require the portal. This is part of Amazons requirements and, I believe, a deciding element for UDI to develop the portal at all. More services will likely come - native IFTTT for example. You can also do Alexa integration via the Maker channel, if you want to hack it yourself. You can also use one of several 'Hue' emulators to link to Alexa without the portal.

I know the nest offers a compelling use case, but I also sold my Nest (came with the house from the builder as a promotion) and switched in a Trane zwave stat. Much happier! Nest is fantastic, unless you want to integrate it with third party systems.... UDI are not keeping the details of the Alexa integration secret - its just that the information is somewhat spread around the forum, and mixed in other threads. I'm just waiting for Amazon to approve the skill and connected home submission, then will be able to speak with first hand knowledge... Should be any day now, I hope! Shouldn't need a 5.x upgrade - the integration point is the ISY Portal, and this works on the latest 4.3.x.

Nest needs the client to support oAuth. ISY won't support that for quite a long time, if ever. The portal can, but UDI is prohibited from working with Nest without giving up a substantial income. Doubt that's ever going to happen, unless Google change their policies. As far as Alexa, UDI is making two interfaces. Native 'Connected Home' and a skill (Izzy). The first will be exactly like the Hue emulator (or a native Hue bridge). Same command set - and same limited vocabulary. The skill will allow many more command types, but has a requirement to invoke the skill by name (Alexa, tell Izzy to...), with the advantage that you can have arbitrary commands after that, not limited by the connected home vocabulary. Both will need an ISY Portal subscription. The certificate changes (ability to add an intermediate certificate) will allow the IFTTT Maker channel to send triggers to ISY (as well as unchecked 'trust all certificates' in Tasker... - I can't wait for this!), and Alexa can trigger IFTTT (Alexa, send ....). So, you will be able to trigger ISY programs from Alexa using this method, without the portal (if you are comfortable having your ISY password configured at IFTTT). There may be a change in the future to allow the Maker channel to make ISY REST calls without needing the ISY password - by using a security token instead. Hopefully, this change comes quickly on the heals of the cert change.

My view is this. The early products were advertised as having the feature to turn on after a power failure. The near fire was caused by a combustible being placed over a halogen light, then the control device behaving and performing as designed. How is this ISY/Insteon/Smarthome's fault? It's a buyer beware world. We cannot complain about problems we cause ourselves when the product itself did exactly what the vendor said it will do. Poor design choice - sure. I agree. However, its not like Smarthome said it wouldn't do this. It's obligant on us as buyers to assess the suitability for its purpose when selecting products. This is why its not a good idea to use an iolinc to control a garage door opener - its not a device refer for an application where security is a need. That, and allon.... I'm glad things worked out though.

I've been using a 2456S3E for a number of years now, still performs flawlessly (Chicago area, so some pretty chilly winters as well). Designed for outdoor use, but single band. I don't think they sell them anymore though.

It's in beta version 5.x... It's beta though - currently with some rough edges. In the latest 4.x version, you can use the network module and variable substitution to do the same thing.

Yes! We'll be happy to help. Hopefully, this means they've approved it, but the 'technical issue' is in publishing the approval.

UDI not being able to work with Nest is a Google enforced restriction. They (Google) simply prohibit any company that does demand/response energy management from using the API. The new Honeywell stats work with IFTTT now, and ISY can control them by using the network module and the IFTTT Maker channel already. You currently cannot easily get feedback from the stat though, without running a third party process. There has been some success with other WiFi stats as well - but I haven't followed these.

I'm starting to move to Aeotec zwave smart switch devices, since they report energy consumption as well as allowing the ISY to control them. The Smarthome sale was not good enough for me to justify this year's addition - they lost a sale from me.

That's good to know! Some of my sensors may be getting to a low battery state in the next few months...

Looks like the HTTP/1.0 profile can set the 'Authorization' header by you filling in the 'HTTP Authentication' box with the username[emoji14]assword of your ISY. For the rest, put the ISYs IP (with a trailing : and then the port number for the non-ssl port on the ISY) in the destination, and configure the rest api URL in the 'CGI-Path' - leaving the 'Message' blank.

Batch files cannot themselves call a rest api. You'll need to find a helper binary, such as curl or wget (compiled for windows) and then use that as a command in your batch file to call the api.

The camera would (currently) need to be able to set a 'Basic' 'Authorization' header to requests to be able to utilize the rest api. Not many can.

Historically, I've seen many delays with email to SMS gateways on AT&T and T-Mobile (never had Verizon). It's why I switched to services like Pushover for those time I need instant notifications.

ISY doesn't run Linux....

Hopefully, the delay is just the approvers enjoying Thanksgiving with their families, and they'll issue their approval early next week.... I know I'm not the only one checking the Alexa app regularly...

This... I actually bought the Elk io expander so I can start replacing several iolincs for more critical control (I have a water shutoff valve, for instance). Also, newer Insteon devices won't respond to the perceived reception of an 'All On' signal anymore, but that doesn't help those of us with extensive number of older devices. If only Smarthome allowed reflashing firmware....

Yes. Don't use an iolinc for garage door control. I use an input and output on my Elk, with the added bonus that the sensor triggers my alarm entry delay.

I don't think it's published - or necessary to know. UDI wrote its own real time OS for its custom designed hardware. It's like asking the CPU and ram of a clock radio - it doesn't matter. It just does its job very well.

Good to hear! Thanks for the feedback. I look forward to being able to test in these areas of the product. Michael.

OK, thanks. I'll be content that it's on the list - even if fairly low. To others: the best way around this is to run a Raspberry PI. Either with Apache/PHP or one of the various Python solutions on here you can create an inbound proxy to the REST API that the Maker IFTTT channel can call. I'm using PHP and have posted my script above. You can use any paid certificate on the rpi as long as its installed correctly.

OK, thanks. So this is another deviation from the requirements of TLS 1.2. Normally, only the root need be installed. It's up to the server to send its own cert and any needed intermediaries ultimately chaining to a root that's in the ISY. By not implementing this (required) ability, we have to manage not only the roots, but also the intermediaries directly in the ISY. Given that intermediaries change fairly often with most CAs, this is entirely impractical. That being said, asking people to deselect 'verify' to work around this creates a vulnerability - and this alone should cause the issue to raise above 'low' priority. Would it not be better to advise people to simply import the Globalsign root and RapidSSL intermediate root into their ISY with the Dashboard and leave 'verify' checked? (Especially if they've previously been successfully using the ISY with 'verify' checked in the client). Michael.

So, with the global client side 'Verify' checked, all connections to servers that have a chained certificate will fail because ISY doesn't process the chain at all - client or server side. The user would have to import the root AND intermediate certs for all services they need to connect to if they needed 'Verify' checked. How do customers using their ISY for power integration also use the portal, if global 'verify' must be unchecked for the ISYPortal to work, but I suspect this would violate policy for OpenADR? How will processing change with connection based policies? Will this include the processing of a chain? As I mentioned, by needing 'Verify' to be unchecked it leaves open a vulnerability, as any self-signed cert with the common name 'my.isy.io' on a proxy, and a DNS cache poisoning attack can be combined to compromise the encrypted communications between the ISY and the ISYPortal. I feel that on its own justifies higher than a 'low' priority fix. Michael.

I don't really think high priced certs are feasible for most people - so I'm not sure the value testing this option. Thanks for the offer anyway! I did just edit the post above referencing another post. Can you confirm why 'Verify' needs to be unchecked in the TLS client to work with ISYPortal? Thanks! Michael.