MWareman

Only if the ISY is the initiator of the scene. If a motion sensor or switch is the controller of a triggered scene, the ISY gets an on from the members in series, it does not get told that the reason for the on is a scene. So, in many common scenarios the ISY is completely oblivious to the scene being triggered, and is only aware of the devices state changing. This is why you have to use device status in your program triggers. So, ISY implementing this would result in inconsistent behaviour. No way around that.

Insteon scenes don't have a status. Only devices do. This...

I think the issue is that thermostats native to Elk are not expressed as native nodes on ISY, or thru it's API. To manipulate them, you need to make API calls via the Elk endpoints - not device endpoints. Only device/scene/program endpoints are available in the Echo integration. IMO, this is not that bad. You can create programs that implement the functionality you need and then access the program thru the portal and Echo. I really don't want to be able to disarm my Elk via my Echo!

The more I think about this, the more I feel there are situations where there will be undesirable results. I'm going to go ahead and move away from 'Auto' and write programs to manage which mode the stat is in. Effectively simulate 'auto' with programs.

Once you have a trusted cert and can access the site over https, then put a redirect on port 80 (to prevent http access). In a fully SSL encrypted session, .htaccess 'basic' authentication is just fine - although not pretty. I also use fail2ban on my host to firewall off IPs that make more than a couple of bad requests for an added tier of security, but with a strong password it may not be necessary. Michael.

Whenever ISY is configured to deliver SMTP mail directly to your providers SMTP ingress server, it will be *way* faster. There is no relaying involved. If you have ISY use 'Default', or any third party SMTP server - then the mail has to be fully received, processed, queued for resending and then resent. This will always add a delay - usually only a second or two - but sometimes many seconds.

Are you using the 'Default' mail server - or a custom one? I know the recommendation is generally to set your own mail providers server in there since there are occasions when UDIs is overloaded - usually due to spammers trying to abuse it I believe.

Looks like the url now also needs a 'domain' parameter. You can get your domain value from an api call to: The _id value is what you need to add to the original url as &domain=...... It should look like this: https://my.isy.io/api/voice/spoken/nodes?uuid=<UUID>&domain=<DOMAIN> Unfortunately, the API is not formerly documented - and subject to change. I discover this by analyzing chrome in developer mode... Michael.

How are you sending notifications? Email? IFTTT? Pushover? Pushbullet? etc....? Email can have delays - that's quite common with some providers. Same with IFTTT - usually very quick, but often delays happen. I've never had any delays with Pushover notifications though. Michael.

Yes like it! Any other vote for.... ''If in Auto mode, increase or decrease both setpoints by 1 degree"

My Insteon (wired) thermostat kept spontaneously changing its setpoint due to spikes on the 24vac supply. Smarthome replaced it - twice and never solved the problem. I simply couldn't rely on it at all. I changed to a Trane zwave stat, and its worked flawlessly since. Unfortunately, I've relegated the Insteon stat to 'junk' status...

This. The multiple 'or' conditions mean that if any one of them are true, the whole 'if' clause is true. If you want to group them together (as in ''If any of these are on"), then they need to be nested in a parenthesis.

The looks pretty slick! Nice job... Michael.

Basically, this downgrades the proxied requests to HTTP/1.0 from HTTP/1.1 - and in doing so disables HTTP keepalives... I feel this is a safe thing to do - and probably an advised thing to do. As far as I know, ISY does not fully support HTTP/1.1 or keepalives.... I've tested this - and it performs well. I've added this to the example in the wiki. Thanks for finding this! Michael.

Yes. The 99i cannot support any firmware starting at 4 due to insufficient storage space. There is still a very generous upgrade offer though...

That's very odd - I agree that none of that should be the source. There is something different though. I don't use Tomato - I'll have to look at it capabilities to know if any of its configuration options could cause this. Does it have any kind of service monitoring? I'm also interested by the http://homeon$ referer. It's not something I can find any info on - even in the Apache source code. It adds credibility to the idea that this isn't anything in the Apache proxy code itself causing this. Does it offer you any ideas? Michael.

Mark, I'm not getting these errors on my setup. Also, port forwarded connections wouldn't change the source IP to the IP of your router. This log is indicating regular connections from your router itself to some url on the Apache box, and its hitting a proxied url. It's obviously not getting a response it's expecting, and retrying at quite the rate! What type of router do you use? Does it have any kind of intelligence, like device identification? If we can identify the url that the router is requesting we can exempt it from being proxied, and the errors will probably go away. Michael.

I don't think it would - the Elk requests and responses are not http - and the Apache proxy mechanisms pretty much only work with the http protocol, without a module. A custom module for adding support for the Elk protocol would have to be written (just like there is a module for websockets).

I think it's named that way because that is its primary use case.... Glad you got it working though!

I think one of the older io_guy programs supported subscribing to the ISY and logging locally (isy_logger ?). This needs an always on computer though (like a RaspberryPI) - and the newer versions are being built as a node server (requires PRO and the network module).

That, is *very* cool! Mark, I *really* hope you are able to share more of what you are doing here. There are some extremely useful elements that absolutely should be put into a new HTML5 admin interface.... this being one of them (for Elk module owners!)

Also, prefix it with ~ and it will be suppressed from the web interface.

You can create web pages on the go with any number of devices...... For the ISY to perform certain functions (such as making API and other network calls), the optional module is needed that is not included in the base device, because not everyone has need for it. This is a way the initial cost of the device is kept down, and people that don't need it are not paying for it. You can either buy the networking module, or subscribe to the ISY Portal (which includes use rights to the module, and so much more!). IMO - it was the best $50 I ever spent. I do *so much* with it. Just look at the Network Resources page on the Wiki to get a taste of the possibilities.

If you have an Elk panel, use a zone as an entry zone (wiring it to the mag sensor), and use the output to trigger the door. This is what I do. It's been absolutely flawless. Thru the Elk module, you can still control! The door, and get status.

I don't use Locative (I'm an Android user), but I believe it can call any url. As such, get the IFTTT URL (the one you normally plug into the Maker channel to trigger the action) and plumb that directly into Locative. It should work. Hopefully, Locative supports a POST though, as that's required I believe. Michael.