mjcumming

@Tim McDermottI order the panel and a couple of switches from Aliexpress. Get them mid Feb

I am looking into the SONOFF product line. See SONOFF NSPanel WiFi Smart Scene Switch EU/US Thermostat Temperature All in One Control Touch Screen Work with Google Home, Alexa|Smart Temperature Control System| - AliExpress Not sure what other switches I would use but that panel looks awesome.

I wish one of the other technologies had a device similar to the keypadlinc.

I wonder why we just can use the extended command that can control the buttons directly.

A prolonged hold did not reset the device

probably not that long....will try again.

I have tried - and from what I have read - that only resets the password not the entire system

I cannot seem to find a way to "wipe" the ISY clean and start over...

In addition, simple rest queries no longer work via HTTP. Rest queries using HTTPS work. As well, I am still able to connect to my ISY that is at my cabin with no problems.

Hi, I added the ISY to the exception list. Using HTTPS from the launcher, I am able to login to the device but it fails when trying to Subscribe - Maximum Subscribers Reached.

Yes, I have made sure that firmware and admin versions are the same.

I have reverted back to .12 firmware and same problems. Tried restoring recent backups as well. Still same problems. I cannot get it back to a working situation.

Windows 10, Java 8 updated to latest release. Firmware .16 and admin console .16. I see the option to debug subscriptions - where is the output? Getting all sorts of errors ie "Socket Open Failed" "XML Parse Error" I essentially cannot connect to the device. Tried several different PC's. Rebooted everything. Replaced the SD card in the ISY. ISY Finder locates the device, launches the Admin console. But now, I cannot even logon due to Socket Open Failed - Timeout messages.

Upgraded from .12 to .16 and it has not gone well. The admin console is having problems connecting, and when it does its very slow, but it never gets fully connected as it give the "Maximum Subscribers Reached" message. Rebooting the ISY helps briefly but ultimately the connection is lost. Thoughts?

The ISY will report changes it detects for any members of a scene and turns that scene "state" ON if any devices in that scene are ON. Agave & OpenHAB show this behavior and it is the ISY generating the state of a scene and publishing it via the REST interface. I am well aware of how the Insteon protocol works having programmed thousands of lines of code around it since the days of the PLC.

Interestingly the REST interface generates scene ON/OFF events. If any light of a scene comes ON there is an ON event for that scene. If all devices are OFF then there is an OFF event for that scene.

great, thank you. explains some unexpected behavior :)

Its not quite clear to me from my reading if programs with empty IF statements run at startup?

I understand how scenes work already.. Good grief. The addition of the ISY generating events for scene states would not affect what you are doing in anyway. All it would allow is an easy way to keep Keypadlinc buttons in a state that makes sense. If you don't want to do that then fine. So me an easy way to solve for the room with 3 KPL without a bucket of extra code.

Imagine this use case. Large room, 3 entries into the room, 6 different lighting loads in the room, all controlled by SwitchLincs, 3 KeypadLincs at each entrance. Each KeypadLinc to be set exactly the same, 6 button mode, ON = all lights 100%, A = 80%, B= 60%, C= 40%,D = 20%. KeypadLincs do not have a local load. With a standard scenes on the ISY, there is no way for the KeypadLincs to be setup so that they represent the lighting scene last selected. Ie the only button that should be on would be the button representing the current scene. So if all lights are at 60%, only the B button should be lite. Or imaging this case. At the front, back, and side entry doors, there is a KeypadLinc with 1 button set to represent all the interior lights. So if any light is on in the house that KeypadLinc button should be ON and it can be used to turn off all the lights. In my situation, that becomes an IF statement checking over 100 devices. Yuck. And difficult to maintain that code. Now imagine if the ISY generated events for scenes. Events could be of 3 types, all devices in the scene correctly match the scene (ON event), all devices in the scene are off (OFF event), devices are in some state that does not match the scene (AMBIGUOUS event). Using these events, you can easily program button behaviour. And one other question, why do we have the create scenes to control buttons? Yes, you needed to do that for old I1 engine devices, but the I2 and I3 devices have a direct command to set the KeypadLinc buttons you want on/off.

Tracking should not affect anything - I would just like to see events that could be caught and then used to update (or not) keypadlinc buttons as you see fit. I did this in the Girder Insteon component - I wrote all the code that supported automated management of keypadlinc buttons based on the state of a scene. Scenes had 4 possible states: ON, OFF, LEVEL (devices are on but not at the expected level for the scene) and AMBIGUOUS (some devices ON some OFF etc). Based on that event you could decide to turn ON or OFF a keypadlinc button.

This is a feature request. I am not sure why you would say that trying to track the state of scene doesn't make sense. I actually had this setup with a different software package that could track the state and report the state of a scene. For example at my front, back and side doors I have a keypadlinc with an All button. I only want the All button ON when a light in the house is ON. Since I have about 125 devices, that becomes an extremely long IF statement to control the ON/OFF state of that button. However, the ISY would know if any light is ON and therefore I could update the state of that button with ease.

I disagree. There is no need to constantly poll. In most instances, the ISY will know the state of all linked devices. Its not perfect as sometimes the ISY might not see local changes if a message gets dropped. But the ISY will have in general an excellent idea of the state of the devices, it knows how the scenes are programmed and therefore could generate an event that represents what it thinks is the state of the scene.

agree, but the isy could generate an event that reflects the state of scene. this would greatly simplify programming.