John Vickers

I think you may have misinterpreted one point. N is the number of dimmers in a particular scene that is being updated, not the number in the total install. I have something like 50 dimmers total, but the scene I am talking about only has 5 (my biggest multi way circuit). If you did have a scene with many more dimmers and you were updating the turn on levels for all combinations with many controllers of the scene it would be a *LOT* of writes. You can actually see this in ISY by changing one setting in the scene and watch how many times it writes to each dimmer in the scene. I would really hope they are using some sort of wear leveling on the flash. It isn't hard to do, there are a lot of libraries that will do it for you, so there really isn't an excuse not too, but I have seen many implementations that they do not because they just didn't consider the burn out. If they have good wear leveling and the settings only take up a small portion of available memory, you can turn 100K writes of the settings into many 10's of millions. The last embedded system I wrote could store the settings a minimum of 50 million times and that was only using a portion of the memory available (I had to keep a pretty big hunk available for remote programming of the system with redundancy). So my point was more that flash writes are a limited supply, so why burn through a lot of them unless it is really needed.

A little flash info. Most flash chips are chunked into pages. Small flash chips like Insteon probably uses (or maybe even a section of flash that is part of the microcontroller) have to be erased as entire pages. You can write a single byte if you want, but can only erase in pages. It is the erase cycles that are normally speced, and 100K is normally how many times you can erase a section. Some chips will have much better endurance than that, but that is what the spec sheet will say. This is also true for the flash used in NVME/USB/SATA drives etc, but the built in controller for computer hard drives does really impressive wear leveling to spread the writes around the disk. Unless you have a very full disk, then start editing files in a very rapid fashion, you will probably never see a sector fail because of this. This is one reason why they will tell you not to completely fill a disk because the write manager needs space to wear level with otherwise you can quickly destroy the capacity of your drive. It is also rare for most people to be writing to drives at regular intervals other than the OS doing logging. The number of writes problem is because you are not just updating 1 address per change. It looks like the number of changes to the link table is 2N where N is the number of dimmers in the scene (assuming they are all controllers which mine are). So if you have 2 dimmers in a traditional 3way switch configuration, to change the levels that both use in the scene would take 4 changes to the link table. You should be able to write this more efficiently, but watching the writes happen in the ISY portal, it appears to write each change independently instead of computing the batch of changes and doing a single write to each device. This is still only accounting for the write required for this one program. There are other writes that happen to the devices as well. Since Insteon dimmers remember their state through power outages, this means every change to a dimmer (on, off, level change, etc) is a write to memory about it's current state. Every time you touch a switch, you are making all the dimmers in the scene write to memory, potentially many times if you are changing a dim level instead of just an on/off single push. So if we make the assumption that you will actually apply the scene you just created at least once, we are now up to 3N writes per device. If they went with the simple but inefficient memory method, you put the link table at the same memory address every time, so to change it you wipe the table and write the new one. In this case (3 changes per day) you would be using 100K/3/6/365 = 15 years just for your program changes, and not including the actual use of the device during the day to turn on/off/dim etc. I have 5 dimmers in this particular circuit which would be 100K/3/15/365 = 6 years. Now this isn't looking so good. Now if they implemented even the trivial wear leveling of 2 memory locations and ping pong between them, that doubles the time period from 6 to 12 years. I really hope they did this, but unless they open source the code or someone reverse engineers them there is no telling. This is also assuming that they minimize writes by checking the memory for a change before writing to it. If they just dumbly write to memory every time there is an update to the switch, it could be many more writes than expected. They all add up and can burn out flash faster than you realize. Because of this it is generally a good practice to not cause a ton of memory writes in a program that is firing at a regular interval. My approach the only downfall is the LED strip that shows the dim level doesn't change at the same time on all 5 switches when you use automation to change the dim level. It takes a little under 1 second per dimmer to update in sequence. Since you are not normally standing at the switches when making a change through automation this would rarely be noticed. When you make a change directly to the dimmer it is instant between the dimmers as they are using the scene to update each other on the fly. This other approach you have a longer delay while it is updating the scenes on all the devices then they all get changed at once, but takes many more write events to memory.

This is basically what I tried, but instead of hard coding a value, I am setting the scene to a variable. I have a program that whenever the load dimmer has a different value than the variable, update the variable, then set a scene that only has the paired dimmers in it to the variable level (where the other 4 dimmers are all responders in the scene). I tried changing it to a hard coded number, but the behavior is the same. In both cases, any level >0 and <=100 just turns all the dimmers to whatever the action % is in the scene. I think this article is actually really bad advice. This person is rewriting the scenes in their Insteon devices multiple times per day. If you have a scene with multiple controllers in it, that is a lot of memory that is being rewritten in the onboard memory. If they didn't do wear loading with a good size flash chip, you could burn it out pretty quickly. Most flash chips only have about 100K writes per address. If I wanted to update the level of the scene to match the % value of the load dimmer, then activate the scene, that would make them all change at the same time, but would take longer to update the scene than to just send the % command to each switch in sequence. From everything I have read about how Insteon implemented the scenes, I don't think it is possible to do what I want, but I will try any other suggestions you may have.

Ah, I just found that when you have a scene with multiple controllers, ISY makes a group for each controller, and you have to set the on level for each device in each group to get it to respond as expected. There is still the problem that you can't seem to set an insteon scene to a particular percent. The best I have found is to detect when the non-load switches are not at the same level and set them each in turn. If anyone has a better solution let me know! Thanks, John Vickers

So I have a light that is controlled by several dimmers. Only one dimmer is controlling the load, then all of the dimmers are in a scene together. When I had the on levels at 100%, this behaved as expected where you could click up on any of the dimmers, the light would come on full, and all the dimmers in the scene would show 100%. You could also hold up or down to dim up or down on any of the dimmers, and all of them would track together and the light would dim accordingly. The problem I am having now is I want the default on level to be 30%. I set this "On Level" for all the dimmers in the scene. If you press up on any of the dimmers, that dimmer shows 30%, but all the other dimmers in the scene go to 100%. This means that if you press up on the master switch, the light will be on at 30%, but if you press any of the other switches it will go to 100% because the master switch goes to 100%. The other interesting side effect of this is if you press up on a switch (so it is at 30%, but the others are at 100%), then dim down 10%, that switch will show 20% and the others will show 90%. Am I missing a setting or is this the expected behavior? Thanks! John Vickers

This has happened to every switch I have tried so far. I was just working along these lines of exploring the link tables. It looks like somewhere along the way of updating the PLM, my ISY tables lost the address of the PLM. This may be from before I knew my previous PLM was toast, I tried restoring it, which may have zero'ed out the addresses. The ISY and Device table were matching on the fan that was not responding correctly, but the first 4/5 address were all 0. After deleting and re-linking the fan, the address for the new PLM showed up in the first 4 links. Is there a way I can edit the full ISY link table as an XML? I should be able to do a find/replace on the 4 address types for switches and dimmers to replace the 0 address with my new PLM address? Then I should be able to do a Restore devices to push the ISY table out to the devices themselves correct?

Second restore PLM made no difference.

I would have to go through and count, but it is around 34 devices. I don't really want to upgrade until I figure this out. This version was working for me quite well before, and none of the fixes listed since then really apply to my network. It really seems like the issue is the switch not knowing which device to send it's update messages too since they are not showing up in the diag event viewer, but the switch is responding when it receives commands from ISY. What I don't understand is why just relinking the switch without removing it from ISY isn't working.

My old PLM died, thankfully Insteon just started shipping their new upgraded PLMs with better caps for supposed better longevity. So this is a brandy new PLM hot off the presses! PLM table has 75 entries. Firmware and UI are both V 5.3.0 LED is solid green. Rebooting the system (PLM then ISY) didn't help either.

Same behavior, no change.

The red light no longer blinks when the switch is changed locally, but the status is still not coming back to the ISY994i. I also checked the event log this time set to level 3, when the switch is pressed, nothing is coming up in the event log. Another switch right beside it that I did delete and re-link does have a lot of traffic in the log when switched locally.

I just replaced my PLM modem with my ISY994i. I did the File / Restore PLM sequence, and it completed successfully. Here are the symptoms: If I tell a switch to change status from the ISY, it does change and the status of the switch updates to the commanded state. If I change the switch locally (IE press the switch directly), it will change, but there is a red flashing light and the ISY994i status doesn't update. If I re-link with any of the linking options, there is no change. If I delete the switch and re-link, it will work properly. I don't want to rebuild my network from the ground up as that would be very tedious. Any ideas on how I can repair the links to get all the devices to report to the new PLM properly? Thanks! John Vickers