MWareman

Yes - your button modes are toggle. The High,Med,Low and Off buttons need to be non-toggle 'ON'. When pressed - it will always turn on. It will also send the scene on command - which also turns the button on - and the other buttons off. This will be true for all 4 buttons. Michael.

Non-toggle 'ON' is the correct mode for the buttons. In your admin console - select one of the scenes and post a screenshot. This is what my 'Off' scene looks like: The button that triggers the scene (in my case 'A') is red - identifying at the only controller in the scene. Additionally, the scene 'ON' levels are set - with the 'A' button being set to 100%, and all other scene members being 0%. The other 3 scenes do the same - but with a different button being the scene controller, and that same button being the one that is set to 100%. Post a similar picture of your 4 scenes, I'm sure we'll be able to spot whats wrong (make sure to make the window big enough to see it all!) Michael.

I put a onewire temp sensor outside, wired to my Brultech GEM which feeds the temp data into ISY via a Dashbox. Seems to work well for me when using external temp to make HVAC decisions. I'm also sending the temp in the HVAC ducts, before and after the furnace. It's interesting to track the increase (or decrease) due to the furnace or AC chiller....

The upgrade is less than $100.... Look on the sales page for the upgrade offer. There are also refrubs available there. When they announced this they told everyone that it wasn't a choice to not support the 99i, the firmware simply dosnt fit in the limited space available. This is reiterated on firmware updates, even today years later.

What is the client device? Could it be that it's new enough that it does not support SSL3 (most Android devices, all IOS devices, and Windows versions post Vista), but your ISY99i is old enough to only support SSL3? It might be time to upgrade to a 994i.

Two things to confirm.. Did you validate your email address?(an email would have been sent during setup of your portal account) Did you authorize the ISY into your portal account? (Portal tab, if I remember correctly)

When you do (in the Admin Console) 'Help' / 'Manage Modules' what happens? You said in the first post, but manage modules does not produce a list. 'Purchase Modules' does. Maybe you haven't gone into manage yet, and therefore have not yet installed the needed module. Michael.

What is your firmware and UI version?

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.