matapan

While testing the Wake On LAN feature, I deleted a program that appears to be running in an infinite loop. This locked up the ISY, if it wasn't locked up already. After restarting ISY, I could access the devices and configuration tab, but not the Programs tab. A dialog would come up stating the programs were loading, but the dialog would eventually be dismissed and nothing would load. None of the programs I had work. Any suggestions?

Sorry, I didn't make this clear. For mutually exclusive buttons, the button pairs control a single load, so a button pair set to be mutually exclusive would have ON OFF or OFF ON as valid pairs. OFF OFF and ON ON are supposedly not allowed, if I understand the functionality correctly. Perhaps this assumption is incorrect? What I want to do is have each individual button in a set of two buttons each control its own load, with the follow additional rule: ON ON is not allowed. ON OFF, OFF ON, and OFF OFF are legal states for the set. Again, each button controls its own circuit. What is the best way to set this up?

When a Keypadlinc is selected in the Admin Console, there is a reference to mutually exclusive buttons. I searched through the wiki page and found more info on this. I want to make sure I understand what this feature is about: - The capability of specifying pairs of buttons to assign on/off function for a single circuit. - For mutually exclusive buttons, as one button in a pair lights up, the other turns off. Additionally, is it possible to set up sets of two buttons to be remain toggled individually with the following behavior: Button 1 Button 2 OFF OFF allowed OFF ON allowed ON OFF allowed ON ON not allowed In this matrix, if Button 1 is turned on, and Button 2 is already on, button 2 will turn off. Is this best done in a program?

I'm on 2.8.16. Are any repro steps useful to capture and report?

Is there a way to restart ISY if it locks up for some reason remotely? I ran into a situation where the ISY I use locked up after I was trying some REST requests to the ISY. After that, I could not access the ISY remotely, nor could I login to the admin console when I was at home. Physically pulling the power from the unit and reapplying it finally addressed the issue. It would be handy to restart ISY remotely when these situations occur.

Thank you for the explanation!

I'm writing a very small script to alert me if and when any of my motion sensors end up in a low battery state. How do I avoid receiving a flood of notifications after the initial one is sent in the script, assuming the low battery warning is broadcasted from time to time by the device? Set the condition for state change only using Control? Thanks.

Does anyone have any advice or best practice related to analyzing logs for things like: - PLM failure - Device failure - Excessive noise problem on a leg - Network broadcast saturation, caused by having too many access points or Dual Band devices What would one look for to identify these issues, assuming these issues to be discrete?

Using ISY 99 with 2.8.16 firmware, a Keypadlinc Relay dual band device I added came up in the Admin Console as an unsupported device. Probably not surprising if the Keypadlinc came out after the ISY firmware was released. The device responds to basic on / off commands, but does not respond to scene commands. Is this device supported in the current beta firmware?

I just purchased a Morning Industry QF series deadbolt and Morninglinc interface from Smarthome. Upon adding the device to my setup, I noticed there were two entries for the device, one with the suffix on and the other with the suffix off. I didn't see the difference between the two entries added. Both lock and unlock the device using the same ON or OFF commands, and return the lock state. What is the purpose of having two entries in the device list? I'm sure there must be a reason for this which wasn't apparent to me after reading the Morninglinc installation Wiki page. Thank you.

I noticed the same thing using an IOLinc. If the power goes off, then the garage door will open when power is restored if the door is closed before an outage. Not acceptable. The relay must be set to an ON state temporarily for the IOLinc to toggle. What exactly happens when power is restored? What is the workaround to prevent this from happening when the ISY is restarted?

At some point, the Admin Console was updated to segregate thermostat information, from one entry per thermostat to 4 entries. In addition to the thermostat information, there is Heat State, Cool State, and Fan State. In reading this thread, the information is simply a placeholder for any unsolicited messages from the thermostat to the PLM. What was the intention for the use of this information? It seems that polling the thermostat device at will or at specified intervals would get most of this information as well. Is there something more that can be gleaned from these extra entries that is useful which cannot be obtained through the device entry itself?

Tried upgrading by using the admin console app for this release downloaded locally and launched. A dialog came up requesting confirmation to use the certificate for this app, then a "Not Found" error dialog came up subsequently.

Tried downgrading back to 2.8.8. The process also went up to 12%, and the same errors were generated.

Upgrade process went to 12%, then failed with the following two errors: Nr. 1 - Upgrade falled: failed uploading file (reported written size is invalid) Nr. 2 - Socket timeout error Downloaded the file twice, but upgrade generated the same error each time. Environment: MacBook Pro 13" 2009 edition OS X 10.6.6 Java SE 6 1.6.0_22-b04-307 (32 and 64 bit) I upgraded from 2.8.8. What should I revert back to?

I have a 2441V v2 Thermostat Adapter. The fan state is reported to be on under the thermostat's Fan Control node. The fan is not on. I queried the thermostat interface's main node to see if this was a refresh issue. Apparently not, as the Fan State node is still set to ON when the fan isn't on at all. Anyone else seen this in this firmware release?

Sure, I've thought about it. An abstraction layer would be required to handle the logical grouping of load circuits. If the console or app handled the creation of the n-way switch, it could manage the supporting scene/group and all the links required. Working in the physical abstraction reminds me of the days when apps used to have to manage read/writes to a floppy disk device - too device/implementation-dependent, not user-friendly.

Thanks for the responses. MikeWu is correct in the original intent of the post. It would be helpful to be able to set up a logical grouping of switches and scenes in one view instead of separating them. I understand the physical setup and the Insteon Group command and what it does. But I think most non-Insteon users like to view their switch organization in the traditional single pole, n-way setups. Here's an example, to illustrate the point: I have a scene consisting of 4 switches that control one load. If I want to turn on that load, I have to know which switch actually handles the physical load and toggle it. If I turn on any of the other 3 switches, the switch state is on, but the load turns turn on from the web interface or from Mobilinc Pro. I have to go down to the list of scenes, and toggle the scene to turn the load on or off. The physical abstration of separating devices and scenes as it applies to single pole and n-way switches is particularly intrusive when you use the Mobilinc Pro iPhone app. Instead of looking at loads, you are looking at a list of devices in one view and a list of scenes in a separate view. Wouldn't it be useful to look at a list of loads in a single view and have the ability to control it there, without going in and out of device and scene views? I know the uses for scenes/groups go well beyond the scope of n-way switches. But I wager that the most common use for scenes/groups is to set up n-way switching. Nice to know Insteon does more than this with groups. I use groups for several other things too.

There is an opportunity here for ISY to go beyond the physical grouping of scenes/groups and individual devices to map to a logical grouping which puts single pole and n-way switches in one group together. Maybe separate them by rooms, floors, whatever. It sounds like sending a group command is a one way deal, and requires a switch to identify itself as part of a group in order to respond. Smarthome describes how to set up n-way switching in their documentation, so the concept of n-way switches isn't a foreign one with Insteon. It's a matter of devising the logical wrapper around it.

One feature of ISY I have never been comfortable with has been the separation of scenes and devices with respect to multi-way switch setups. If you have a multi-way switch setup, it appears you must use the scene to toggle the multi-way switch and have all the switches in the setup toggle status at the same time. You could toggle just the device handling the actual load from the devices list, but then you'd end up with the other switches in the multi-way setup not updating their status at the device. This seems really weird and counter-intuitive from a user perspective. Why not group multi-way setups with devices in a single view so that the visibility of the logical function is promoted, or comes through? I use the Mobilinc Pro iPhone app, and this is where the low level grouping of Devices and Scenes really makes little sense from a user perspective. You have to go to the Devices list to toggle one thing, and Scenes for other stuff. What do you think? I respect the existing organization from a computing/coding perspective and see why it was done this way.

LeeG: Thank you for your helpful suggestion. It turns out that the X10 tranceiver module's ability to send X10 signals died, even though it responded to Housecode 1 commands itself.

I tried a basic script that looks for an X10 ON or OFF command and turns an Insteon module on or off based on the command sent. The Insteon module is never toggled - it appears that ISY is not listening for the X10 commands. I am having ISY look for On (3) and Off (11) commands in the script. The X10 commands are being sent wirelessly using a Keychain remote and a TM-751 module is converting the wireless command into one on the powerline. Anyone seen this? I think ISY used to work with X10 commands in previous firmware versions.

Summary: The Program Details and Program Status tabs will occasionally not show any information in the tabs when you navigate to them. Information will display in the Main and Configuration tabs when this occurs. No repro steps available yet. Environment: Mac OS X v.10.6.5 Java 1.6.0_22-b04-307. Cache was cleared after installation. Admin Console v.2.8.8 ISY Firmware v.2.8.8 Upgraded from 2.7.15 [/img]

Environment: Mac OS 10.6.5 Java v. 1.6.0_22-b04-307 Insteon Thermostat Adapter v.91 (v.2.0) Admin Console v.2.8.8, ISY Firmware upgraded from 2.7.15 to 2.8.8 Issue: Thermostat fan state displayed is incorrect. Fan state shows fan is ON when the actual state is AUTO. One of my thermostats also shows Heat/Cool state info, while the other one does not. Information displayed correctly in Admin Console 2.7.15 w/ISY firmware 2.7.15

Was the thermostat update in ISY a feature in the thermostat adapter v.2.0 update that was not present in v.1.0?