Program Drop-Down Listbox Question

[HABit]

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.

[larryllix]

You are looking at two different light switches. One is a program and the other is a scene profile.

 

They are not related except they are controlling the same device.

 

A scene is a preset inside the device. When ISY or any other Insteon device calls out that scene on command the device just does it

 

Insteon devices can hold about 250 scenes each.

 

Sent using Tapatalk

 

 

 

 

[HABit]

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. 

[MrBill]

I assume MD is motion detector?

If so, its a battery device and in V5 there is a nasty bug covered in several threads (the two most recent):

 

[HABit]

@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.

[MrBill]

@Michel Kohanim has told me that my assertion that the unwritten data builds up is not correct.  However I'm not sure what to believe because when I remove the scene updates involving a battery device my queue full problem goes away.   For me the real solution is to fix the bug so that the scene updates only write to the non-battery devices, the way it worked in v4.x.

[HABit]

+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.

[Michel Kohanim]

@MrBill,

It's up to you what you want to believe! INSTEON uses a sequence of records at each location. So, even if there are 2 billion updates for the same location, ISY will only keep the last since all others are immaterial.

With kind regards,
Michel

[MrBill]

4 hours ago, Michel Kohanim said:

It's up to you what you want to believe! INSTEON uses a sequence of records at each location. So, even if there are 2 billion updates for the same location, ISY will only keep the last since all others are immaterial.

I believe you!  I also believe my observations.  Unfortunately those two things are mutually exclusive, hence my statement.    That bug and the GUI bug's around Backlight, On Level, and ramp rate also never seem to get love. 

[thruster999]

Hi @Michel Kohanim 

I continue to see these issues as well - I'm not sure about a queue of built up writes but my ISY appears to write to my motion sensor when there is a scene update. My  understanding is that only the responder should be written to. And on top of that my ISY *repeatedly* tries to write (and fails) to some of my motion sensors (and not the controller) even after a successful scene update . As a result I have to turn off writes to battery devices because these continual write attempts bog my ISY down ("system busy").

Anyway, to add to this discussion, I don't see this happening to all my motion sensors (I have 22). It appears to happen to only a handful of the same sensors. I might buy a few new replacement motion sensors to see if this fixes this issue. However, I'm a bit worried about the investment because the effected sensors are newer.

Thanks

[Michel Kohanim]

@thruster999,

Thank you for the feedback. What's the difference between these motion sensors? i.e. do you use Adjust Scene (programs) on all of them? How about the scenes they belong to?

With kind regards,
Michel

[thruster999]

 

6 hours ago, Michel Kohanim said:

@thruster999,

Thank you for the feedback. What's the difference between these motion sensors? i.e. do you use Adjust Scene (programs) on all of them? How about the scenes they belong to?

With kind regards,
Michel

Hello  @Michel Kohanim

I use Adjust Scene programs on all of them. And as for the scenes they belong to they are all pretty standard i.e. Motion Sensor as the Controller and a light switch as a Responder.

The only difference I see is the revision of the Motion Sensor.

For example, one of my Motion Sensors is a #2420M 1810 Rev 2.0 and I don't experience any issues with it - the related scene updates fine and there are no subsequent unnecessary updates. Notably (however), when the scene is updated BOTH the Controller and the Responder get written to.

Another example: I have a Motion Sensor 2842-222 1715 Rev 2.6. This is one of the Sensors where I experience the constant writes. The related scenes update fine (again both Controller and Responder get written to). However, subsequent to a successful scene update and then many times per day throughout the day, my ISY attempts to write to this Motion Sensor and fails causing subsequent attempts etc. I have no idea why these writing attempts are occurring i.e. there are no program triggering it.

I've tried swapping "good" sensors with "bad" ones in an attempt to track down errant programs. Its not the programs - its always the same sensors that have the issue.

Thanks

[Michel Kohanim]

@thruster999,

Thank you. So, it's always the MS IIs ... the bane of our existence.

With kind regards,
Michel

[HABit]

@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).

[thruster999]

1 hour ago, Michel Kohanim said:

@thruster999,

Thank you. So, it's always the MS IIs ... the bane of our existence.

With kind regards,
Michel

Hi @Michel Kohanim

No. I believe these are MS 1's (I don't have any MS II's). See the pics below - this is the "bad" sensor I describe in my last post.

Also, it is my understanding that when a scene is updated only the Responder should be written to. In both the "good" and "bad" examples I described in my last post the Controller is written to as well.

Thank you

 

[MrBill]

@Michel Kohanim is this not the same battery devices write bug many of us are patiently waiting for to be addressed?

[Michel Kohanim]

@MrBill,

I don't think so.

With kind regards,
Michel

[thruster999]

On 6/25/2020 at 3:07 PM, Michel Kohanim said:

@MrBill,

I don't think so.

With kind regards,
Michel

 

@Michel Kohanim  hi Michel, respectfully I think it is. I just wanted to point out (in my previous post) a potential reason why your team might not be able to replicate it.

thanks

[gduprey]

I can confirm that it happens on the MS1 too and while there may not be a full queue, the periodic "wake up and try to write" aspect (to a device that will never automatically wake up) really gums up processing.  I've been having an issue where some timed events (i.e. scheduled at a certain time of day) were being missed and it SEEMS to be tied to the ISY being busy trying to write to my MS1 periodically.  Once I disabled the program that writes to the MS1 (and cleared the write queue), my times have been reliable again.

[larryllix]

19 minutes ago, gduprey said:

I can confirm that it happens on the MS1 too and while there may not be a full queue, the periodic "wake up and try to write" aspect (to a device that will never automatically wake up) really gums up processing.  I've been having an issue where some timed events (i.e. scheduled at a certain time of day) were being missed and it SEEMS to be tied to the ISY being busy trying to write to my MS1 periodically.  Once I disabled the program that writes to the MS1 (and cleared the write queue), my times have been reliable again.

How did you manage to clear these write queues?
My ISY is starting to display the busy box frequently again, and I have all delayed write programs deleted and battery write delay features all disabled. Last time, I had to factory reset my ISY before  ISY events became very quick again as when ISY was new.

AFAICT, with polyglot and a few other variable injectors going on ISY cannot seem to afford these extra CPU time or I/O burdens.

I have had to add extra Wait times between NR sends again lately. Where I previously used Wait 1 second or no Wait line at all between NR sends, I have recently had to add Wait 3 seconds to avoid variable values being clobbered by the next NR call using those same variables.
It seems that ISY's I/O processing of Insteon affects I/O processing of it's Ethernet port also.

[gduprey]

Nothing fancy - I've had to disable the programs that try to change scenes (not a popular option for clients who have gotten used to differing light levels on motion-activated lights at different times of days), then wake the devices up, write changes and move on.  It is "clearable", but only if you are willing to lose functionality.  Which my clients are loudly telling me they don't want to lose