HABit

Thanks for info.

Hi @io_guy - GREAT NEWS about Hayward Omni. I have been looking for the API for some time. Did you have to execute an NDA to get access to the API - would love to get that info? In any case, this will motivate me to get an RPi and start using NodeLink. The Omni is seriously deficient in usability, so automating it with ISY would greatly help (especially what they call Themes). I believe Hayward is using a Linux O/S of some sort, and an old-school stack of pool control Ops, but poorly implemented user interface features over it. Are you using an RPi 4? I have a current requirement for a .Net Core project on a small footprint processor board. Also wondering do you use Raspian/Debian? I like freeBSD since happier in POSIX O/S, but don't think it'll run on RPi4 yet. Sorry for all the questions. Again, great news. I'd be willing to give you any help I can, testing, etc. Thanks for all your great contributions to the ISY universe.

@Michel Kohanim, This problem exists with the old MS too (at least on my ISY I see unwritten updates, until I attempt to write after MS ON command detected). I think this is an artifact of the firmware update to 5.x (when unwritten data started for me).

A few other things you can check to try to troubleshoot: Make sure PLM is not failing. Do a reset on PLM; Check links table against ISY links. The power supply is notorious for failing. Also the RF in the PLM (and all other Insteon devices) fails earlier than the switch or actual function of the device due to the poor quality capacitors used in manufacturing. Programs that rely on device Status will be more prominent failures if the PLM is starting to fail. Check the ISY power supply. While the ISY is usually always reliable, its power supply isn't. Consider replacing the SD card. My long decent into ISY Hell started with a failing SD card. Biggest symptom is long Admin Console load times, long backup times, failed firmware updates, etc.

+1 I have had the same unwritten data, buffer filling, and there was slowing, plus errors in the log. In all fairness, my SD card was slowly failing, so could have been that. However, all symptoms at least lessened, after I began attempting to write the unwritten data. You are right, fixing the writes is the best solution, but I would still like to see that status. If for some reason the ISY buffers device data, I can test that status and update the device.

@MrBill Thanks for the links. I have run into that problem, since I use so many Scene Adjusts and write the updates to the battery devices after it sends a command to the ISY. I was having Message Buffer Full errors in the log so found the links here/Forum saying that the unwritten data somehow queues up in the ISY. Writing unwritten data to battery devices after it activates solved the buffer problem, but all the updates are shortening the battery life. I have gotten around this somewhat by using a variable which is updated after a Scene Adjust, as part of the IF statement triggered on a battery device activation (ie On/Off, etc). @Michel Kohanim What I think could help us out with this problem is if a "Unwritten Data", or "Data Write Required" test could be added to the IF commands the ISY can test, for devices. I think the "unwritten data" state must be know to the ISY since the green Unwritten Data icon is displayed next to devices with pending data writes. This would allow a Program to test for the unwritten data state when the device sent a command and then initiate a write updates.

OK so what I was pointing out is that when I clicked on the Program line the drop-down lists did not reflect what the Program line displayed. I believe this is an artifact from when I updated from v4.7 to 5.0.15 and had many unconverted Scene Adjusts due to the superior/updated way that the ISY now controls insteon devices (nodes). I tried deleting and re-adding the program line, but still had the same outcome where clicking the actual line in the When part of the Program did not cause the drop-down list boxes to display the same command. Since then I completely deleted the Program and re-entered it and that has fixed whatever this was. As for the Scene Adjust command this brings up a question I have now: Using the Scene Adjust command the ISY allows me to set the dimmer switch On-Level (in the drop-down lists), since both the MD and dimmer switches are Controllers in the same Scene. Is this not allowed? There is a direct Device command which sets the On-Level for the Responder (I use for non-Scene devices), but aren't the two commands essentially identical in this situation since the Device command should effect the paddle switch On-Level, and the Scene Adjust sets a Controller's On-Level (which in this case is the exact same thing since the Controller is also the Responder too). I have been using the Scene Adjust reliably to adjust the local Controller (switch/dimmer or KP) in a Scene in my HA since the firmware update to 5.x, but want to be sure I'm not missing some detail.

I apologize beforehand if the answer to this is already on the Forum, but after searching I haven't found anything relating V5.0.16C: I understood that the ISY "parrots" what you have in a Program IF, THEN, or ELSE clause, in the drop-down list boxes. For example if I have the following clause: And click on it (as above), the drop-down lists should reflect this statement. Instead I'm getting the following: You can see that both the On Level and Retries are different than in the Program statement. It seems like this occurs in the Insteon device drop-downs AFAIK, but not always. So wondering if after SD replacement and also update from v5.0.15 some sort of Program corruption has occurred. I deleted the Program line where the drop-downs didn't correlate, and added a new line, but the behavior persists. When I have more time I'll delete the Program and recreate it to see if that gets rid of this behavior. I do have both v5.0.16c firmware and admin console.

I just started having a dimmer switch fail in that mode. It is installed in the toilet next to a fan switch (On/Off), and periodically after the fan turns off, the dimmer turns on. I also have observed that periodically when it it turned on at the switch, it flashes the red LED (UNACK) indicator. Haven't started troubleshooting yet as it's hard to (yet again) have to turn my attention to troubleshooting Insteon issues. I agree with you @hart2hart, that it is most-likely RF - failed cap in the RF circuit. This device is only 1.5 years old. Disappointing!

You can put a current sensing relay (available at Grainger. https://www.grainger.com/category/electrical/industrial-controls-automation-and-machine-safety/relays-and-accessories/current-sensor-relays?cm_mmc=PPC%3A+MSN+PPC&s_kwcid=AL!2966!10!79302366338600!dat-2331102090009837%3Aloc-71300&ef_id=XnIm8wAABT6Rb8wF%3A20200318134939%3As , etc), monitoring the motor L1/hot feed, and then connect the C - NO contacts of the relay to the IOLinc. This is a completely isolated monitoring circuit since the current relay detects when the dryers motor is running by sensing the current of the drum motor. The motor wire is fed through the relay, keeping it all isolated.. To make it simple, get a current relay that has a self-contained power supply (unless you plan to have an external power supply - typically this is 24VAC).

The motion detector is in "On-Only Commands" mode. Check inside that Jumper 4 is not installed. If you have Remote Management Mode enabled (Jumper 5 installed), then click on the MD device in the tree and then click the Options button at the bottom. Uncheck the "On commands only" box. Many people put a motion detector into the "On commands only" mode (no Off messages sent), so that they can use a program-timer to extend the On time of any controlled lights.

I'm trying to find the documentation regarding the available variables under the Alert category. I've found the documentation regarding the other categories, but not for any under Alert. What I'm trying to do is identify the source of a Device Not Responding status (ie the name or even address of the device) where one program is monitoring multiple devices (ie Insteon controls). So far using any of the variables in the notification under the Alert category yields a blank value in the notification.

Thanks oberkc. I do have the automatic updates button in the "Disabled" position, but I believe that in this mode updates are "held" by the ISY until you either right-click the device and select the "Write Updates..." option, or issue the Write Updates command from a program. I think that the MD is in the early failure stages. Whether this is due to the internal microcontroller I/O line not reading the jumper correctly (but the MD was working fine in remote management mode previously), or just device component failure, I can't tell. The MD is only 1 year old so kind of disappointing. I'm going to try Stu's suggestion to see if it restores the device, but why it failed, ??? This icon is something I've never seen before. Periodically this happens. Having used an ISY for years (but admittedly not as much as many here), sometime I see some new feature, etc and don't exactly know what it means/does etc.

Thanks. What does the grayed-out device update icons mean? - ISY doesn't get Ack from device writes; - ISY thinks remote management is not turned on. I probably missed this somewhere but I haven't seen a description of this icon indication.

A motion detector just showed up with a grayed-out "pending device update" icons. The MD has been in remote management mode for some time working OK. I've never seen this device write icon mode before so I'm guessing that it means that the MD is not receiving configuration update message ACK's. Is this a correct guess? The MD is still sending motion and dark messages. Remote management jumper in place. Battery not low/just changed.

Perhaps I offended some of you on this blog by using the incorrect response protocol. The offense was inadvertant. It would be helpful, however, to point out that your prefference is to use the cute little box to repeat the same statements again, rather than to devolve into snark. There was no intent at victimization here. Anyone taking offense to the dialog above did so entirely at their own volition. When someone makes a statement I want to understand the basis for it (and I'm sure others do too). There is/was no intent to discredit your expertise. Thanks Teken for the amplification and taking the time to do what I suppose I should have done using pictorials etc. My intent was to try to pass on some (admitted hack) to others but I have to admit my available time is limited so I just wrote it out in a hurry. I'll take in account the response I have received before I post anything else in this forum. Happy New Year!

Probably the easiest way for you to locate this system setting is to hover your mouse pointer over the toolbar buttons located at the top of the Admin Console, just under the menu. As the mouse pointer lingers over a button, a pop-up description will appear describing what the button's function is and what mode/state it is currently set to (as applicable). Look for the button that says something about battery powered devices and writing changes. You want that button to be clicked so that it appears grayed-out (won't show as a colored icon). The pop-up description window will appear even if the toolbar button is in the disabled/grayed-out state. You should go to the About window (menu Help-->About) and post what your ISY model, version and UI rev is.

You may just want to RMA it if it's within warranty. I recently purchased 3 2441TH V1 units but one of them failed in a weird way. The room it was installed in got very cold as if the heat wasn't running, but logs showed differently. However, that thermostat also controled the HVAC dampers into that room and after running tests I found that it was never reporting the heat/cool/fan service calls, even though it would make those calls to the HVAC (via hardware). I reasoned that it must have been programmed as a heat pump (which lacks those nodes for some unknown reason), and after contacting customer service the guy immediately realized the problem. Same kind of subtle failure you are seeing though - reported temp, setpoint, but not operating status (ie calling for heat/cool/fan). Query worked OK, but again never reported call status.

What would greatly improve this technique and extend battery life is if the ISY either did not arbitrarily send the configuration information to a battery device if nothing is pending/changed, or to add a new command something like: "Write Pending Device Updates" The ISY does seem to have enough current information to make implementation of these changes without having to add more status regarding battery devices. You can already see on the Device Tree in the Admin Console, the status icon changes to a green box, right-pointing arrow to indicate that there are pending configuration changes. @Stu: Have you measured the difference in battery life if updates are always written to a battery device? I'm curious to know what the additional battery drain is. The only appreciable increase on battery drain is when the transmitter is switched on for the handshaking with the updates message. When/If I get time I want to drag out the spectrum analyzer and see when the LO is cranked up to get an idea of the difference in transmitter operation. I suppose this also could be approximately determined from analyzing the message protocols - what is transmitted in response.

The reason this trick works (per Teken "on most motion detectors", however on all of mine-insteon it has worked reliably), is that when the motion detector issues its motion notification message, it then goes into the receive mode to listen for the acknowledgement. The return message time period is boilerplate - much more than needed for a typical acknowledgement. It's during this "receiver on, waiting for acknowledgement message period" that the motion detector will hear the configuration change message the Update program issues via the "Write Device Updates", and accept your configuration changes. This is actually a small flaw (or actually lazy programming) that allows this hack to work. After a notification message is transmitted the firmware author turns on the receiver for a set time rather than sensing when the ACK message is received and then immediately shutting down the receiver. You waste a minuscule amount of battery power, but hey you can also update your MD without that darn ladder. Folks, I can't speak for other types of devices. I came up with this hack b/c I hate to fish out the ladder and drag it to the MD (that's always stuck on the mounting bracket). Theoretically it could work on remotes and other battery operated devices, but I haven't tested on such.

Most of you know that when you install a motion detector (2842, etc) you have to press the set button to both link it to the PLM/ISY and also when you need to make configuration changes, such as darkness detect level, or retrigger time, etc. You can't avoid the first set button press to initially link the device, but you can setup an automatic update program to take the pain out of getting the ladder and risk breaking off the very fragile stem from the mounting bracket since it always seems hard to disengage (HINT: A little silicon grease spray such as used for window rollers helps lots). Here are the steps: First be sure to jumper the remote management jumper (#5 on the very right end), which should be installed by default from the factory. Click the Automatic Writes To Battery Powered Devices item under the File menu if it is not already grayed out (or click the icon usually located on the far right of the Tool Bar, if not moved, and make sure it is grayed out). To ensure you got the right option changed, hover your mouse over either the Tool Bar button, or menu item and look at the pop up context help message. It should say something like: "Do not include battery powered device...". Create the following program: ​Program UpdateMD ​IF Control XYZ:MotionDet is switched On ​THEN Wait 5 seconds ; Let the motion detector finish sending its notification, may need to increase time if it is controlling a scene with a few devices Set XYZ:MotionDet Write Device Updates If you are not making updates to a motion detector, you can disable this program to avoid unnecessarily running the program. I leave mine on since even though you theoretically utilize the available writing lifetime of the EPROM in the motion detector, in reality it would probably exceed several lifetimes before it was depleted (far shorter than the lifespan of the capacitors used in the device).