bsobel

So this is just a coding style comment but the reason I rely on the state variables is so I don't have to put the trigger button into each program. This allows me to change just one program if I decide I want a different button or additional button to drive the programs.

So I have been working on this with Michel and I can't yet explain what we are seeing. A rule created on my system can not send a notification (it appears to connect but the ISY reports a connection error since the remote host closes the connection right after sending a 406). On an ISY test system Michael let me try it sends fine, the rule appears identical so I'm trying to find another setting that may somehow be effecting this. In the meantime you can use pushover.sobel.info on port 80, use the same settings for the body and path (/1/messages.json). This of course trusts your id in the clear (and that my server will relay it) but if you are ok with that you are welcome to use it until we work out the SSL issue directly. Bill

I thought folks wound up running multiple stacks over the same radio, or is that not possible (do they actually need to be different frequencies for example?)

Well it would be 'blind' meaning the system would remember where you were last and press and just go to the 'next' mode and cycle to the first one when you reached the limit.

Create a state variable to track the current mode init it to 0 current state 0. For this we will call it matrix mode Set one button to be always on (of off if you prefer to backlit) Write a program that increments the variable if CONTROL keypadbutton X is ON then matrixmode += 1 Write a limit program that ensures we 'roll over' when the limit goes to high: if maxtrixmode > 3 then matrixmode = 0 init matrixmode to matrixmode else init matrixmode to matrixmode (this ensures the variable is init'd to the current state no matter what) Write one program for each level: if matrixmode is 0 then networkresource 1 if matrixmode is 1 then networkresource 2 etc That should do it for you. Best, Bill

I saw your comment on interop and also noticed that HAI says "The ZigBee integration has been specifically verified with the Black & Decker Kwikset SmartCode locks, but it should work with other locks that support the standard ZigBee Home Automation profile lock cluster. " What are the chances of getting the profile lock cluster on the zigbee units? I'm going this way (I think) due to needing multiple energy monitors and hopeful eventual Hue light support. If this is standardized enough it seems UDI should be able to tackle this without info from Kwikset (that is suggested earlier in the thread is required)

Most insteon devices indeed send out a notification when the local state changes, but they are not 'broadcast' to all but rather to devices they are linked with.

The default color is a good white but being able to change colors for scenes is VERY useful. I've interfaced all of mine with my ISY based on network resources but I'd LOVE a direct integration with these bulbs. The Apple exclusive will expire but I do plan on changing most of my bulbs to these once the newer spotlight shaped ones come out (the current ones are too small for some of my cans (given the can angle on a sloped ceiling I find the small size very noticeable) Id suggest trying one set, you can do some pretty neat things with them an the ISY

Michel would you consider changing the ui text to something like 'catch up scheduled since midnight at restart?' I think that minor change would help clarify the intent. Best Bill

I found another post talking about this, looks like this may be 'as designed' (but I'd suggest not 'as expected'). I thought that the catchup and the graceperiod worked together, but if catchup is truely from the previous midnight then the behavior makes sense. I think many folks believe that if catchup is checked then only schedules within 'missed schedule grace period' are executed. For my system it looks like I just one the missed scheduled grace period set but not set the catch up schedules at restart (going back 17 hours [in this case] after a restart seems way too long for whatever thats worth) Catch up schedules at Restart - When this box is checked (default) the ISY will attempt to run all programs that are time dependent beginning at midnight until the present time. Missed Schedule Grace Period - If Catch up schedules at restart is not checked or if a program is not run because the ISY is busy this will check for programs that were scheduled to run from the period specified until the present time. Default is 15 minutes. Michel can you confirm the two options are independent and the second is not tied to the first? Best, Bill

Michael, this wasn't a restore, this was a simply upgrade from 3.3.8 to 3.3.9. In fact I can reproduce this 100% of the time now that I notice the issue by having the ISY reboot for any reason. Startup evaluation of something is broken, 'sunrise' should never eval to true (unless of course the unit was rebooted right around sunrise!).

Think I ran into a bug, just upgraded to 3.3.9 from 3.3.8 on my 99i. I have a program that runs every morning to ensure no lights get left on. Its: If Time is Sunrise or Time is Sunrise + 10 minutes Then Set Scene 'Main House Shutoff' off It's 5:45pm (certainly not AM or sunrise) and when the ISY rebooted after the install the program both ran and evaluated true. It is *not* marked 'run at startup' so something about the evaluation fired. I now realize I've seen this before on other restarts but hadn't put it together so clearly until this one (so probably pre-exists 3.3.. I do have 'catch up' turned on but its set for 15 minutes so know where close to the times in question based on Sunrise. Ideas? Bill

As written there is no caveat that the number of HTTPS sites is greatly limited to those supporting a very old and often not used cipher. I think that needs to be called out on the Network module for 99i users. When I use a browser and it says it supports HTTPS, I expect to be able to connect to if not all then a great majority of HTTPS sites. That is not true in this case. You did relay to me that this is not ideal but there is a physical capability issue (not enough memory to support the additional ciphers). I accept that fully, but do think you should make this clearer for all. This thread, the Pushover.net thread and at least one other shows that at least 3 of your users (make me 4) were not aware of the limitation. That should tell you that field understanding of the limitation is not widespread. A post in the network section that (for example) tells people they can use https://www.ssllabs.com/ssltest/ to see if the site they can't connect to uses the supported cipher would be good and a direct 'you'll have to upgrade' to the 994 pro for the the other ciphers would at least prevent folks from spinning on the issue. For me, got my 3 upgrade units and the first is going in later today once I cross the border. Cheers, Bill

"Network Resources allows the ISY to call other systems using HTTP/HTTPS/TCP/UDP/Multicast. Available HTTP/HTTPS commands include GET/POST/CONNECT/DELETE/HEAD/PUT/TRACE. POST and PUT allow the use of URL-ENCODED, RAW TEXT, and BINARY modes. Please see this page for some examples of devics you can control using this module: Network Resources (Examples & Downloads) You'll also find downloadable export files - save time and trouble by importing pre-configured Network Resources right into your ISY!" This is not true, a great number of HTTPS sites are not available. The documentation to linked to is for the 994 not the 99 (but I assume the 994 non pro applies) but this seems to be what you support on the unit acting as an SSL server. The network module (optional component which claims access to https resources) is what is being discussed. I'm unclear if the doc above is supposed to cover the network module as well. What is frustrating is the number of threads from folks trying to use HTTPS resources only to have to discover the network module does not match the description above. Bill

Ok its not you, its a bug in the network module. The network module does not support the cipher suite the site uses (and quite a few sites use) and simply won't work with pushover.net unless UDI offers a fix.

Michael, this is EXTREMELY limiting and what I would consider a major bug in the network module. As it stands most sites I want to connect to (and your other users do as well) will not work. Pushover.net simply will not work with MD5. They support: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH 256 bits (eq. 3072 bits RSA) 128 TLS_RSA_WITH_RC4_128_SHA (0x5) 128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) 256 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 256 bits (eq. 3072 bits RSA) 168 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 168 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) 128 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128 Can you please please please support at least one commonly used cipher suite in the network module. As it stands the module simply can not reliably do SSL to the vast majority of the internet.

This ever get resolved? I'm using pushover via email but was going to change to direct API and saw your post. Bill

I am also under the belief the active load should be off when the switch is red. Did you install this yourself? Have you verified the wiring done?

Got it, sorry thought it was a per resource item not global. Bill

I wasn't referring to Prowl actually. From your post I got the impression (wrongly?) that the admin console for the newer devices (994i vs my 99i) includes an option in the networking module to verify the ssl certificate. You had (I thought) disabled this in order to get the network module to talk to Prowl, I was asking if you tried disabling the same setting when you attempt to have your unit talk to itself (since this feels SSL/cert related)...

"I kept checking the Active Load LED Light. It seem to be GREEN a lot. Then it turned Off. Then turned GREEN again. I don't understand how can this work as a water heater timer, to save energy and money?" That just means your water heater is turning on/off as it should to heat the water. If you want to prevent it from heating at certain times you'll need to write an ISY program to open the relay during the times you want it off...

Was it a state variable, I believe it would need to be in order for the eventing logic to trigger the folder reevaluation...

While the commands are opposite it looks like they did not swap the meaning of the lights (which is good). So the status LED will be green when power can flow to the water heater and red when it can not. The ActiveLoad light tells you when the water heater is actually drawing current (e.g. it presumably has a thermostat so while that is allowing the circuit to complete the light will be on, once the thermostat turns off the heater that light should turn off as well)

Sounds like everything is working properly. The unit is normally closed so 'off' means 'closed' (the water heater has power). To turn off the water heater send it an 'on' which will 'open' the relay (break power to the water heater). Basically since its normally closed the commands are opposite of what you may fine intuitive but just swap on for off when you are away and off for on when you are home and it will be fine. Manual here: http://www.insteon.net/pdf/2477SA.pdf The green light means the relay is closed (unit is on 'off' mode) and the load is drawing power (e.g. the water heater is on). If you send an 'on' you should see that led turn off.

Saw this on another thread and thought of this one, could this be related? "edit: after careful examination of the Dashboard Network settings, my tired old eyes noticed a faint, grey check in the HTTPS Verify checkbox. After UNchecking that box and rebooting the ISY994, all is well now - Prowl is working fine once again."