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

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

12 hours ago, John Vickers said:

There is still the problem that you can't seem to set an insteon scene to a particular percent. 

press the "play" button to be able to set a scene on percentage.  Be-aware this acts weird for complex scenes, however is useful for the typical "3-way switch" type of scene. 

@John Vickers This article will walk you though how to do what you want.
 

 

On 6/28/2023 at 11:03 AM, MrBill said:

press the "play" button to be able to set a scene on percentage.  Be-aware this acts weird for complex scenes, however is useful for the typical "3-way switch" type of scene. 

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.

 

On 6/28/2023 at 2:32 PM, kzboray said:

@John Vickers This article will walk you though how to do what you want.
 

 

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.

Quote

• •  

 

On 6/28/2023 at 11:32 AM, kzboray said:

@John Vickers This article will walk you though how to do what you want.
 

 

Expand  

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

While I accept your premise, I'm a bit fuzzy on the logic. Accepting your 100K maximum writes per chip which is very arbitrary and often much higher, and the program logic of the article being three changes per device per day, that's (100K/3)/365=91.32 years before I run into a problem. I think I can live with that. The caps will give out long before then.

Also while you may not like the solution it is best practice for the IoX / Insteon devices, but if you  find a better mouse trap please feel free to share.

 

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.

Edited July 1, 20232 yr by John Vickers

If your premise is correct Insteon devices would be dropping dead annually in installation of over 10 dimmers. Yet they don't. So where is the fault? In your logic or somewhere else? In homes with over one hundred dimmers something would be failing weekly and yet they don't. They often last for decades and it's the caps that give out not the flash.

Good read though. Well thought out and certainly something to consider, but the facts don't support the supposition.

 

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.

2 hours ago, John Vickers said:

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.

I think the point everyone is trying to make is that other things will cause a switch to fail faster than burning through the memory so it's something that most here just aren't concerned with including myself. 

If that is a major concern, create multiple scenes with the devices as responders and set to your desired levels. Then you can simply create a program which triggers those scenes. No additional writes necessary