Network queue flag request

[TJF1960]

Would it be possible to add a feature to the ISY whereby an assigned variable or some other sort of flag would be set during any ISY activity that queues incoming network REST commands? For instance during Insteon device programming or querying and also during opening of the admin console and program tab and such.

This variable or flag could then be used in a program to alert the network devices and have them refresh or update the ISY of any events that might have been missed.

 

Thanks

Tim

[Michel Kohanim]

Hi Tim,

 

I am not sure I understand. Do you want to send System status to the networked device? Or that in some point in the past system was busy?

 

With kind regards,

Michel

[TJF1960]

Hi Michel,

 

No, just a flag of sorts Anytime ISY is busy and incoming network rest command are being queued.

[Michel Kohanim]

Hi Tim,

 

That would be very difficult ... unless of course you have an ISY client which is automatically notified of ISY's busy status. Are you referring to DSCLinc and, if not, what's the exact problem/issue?

 

With kind regards,

Michel

[TJF1960]

Hi Michel,

 

Yes, DSCLink is one but I am not sure if it is a client or not. I also have a number of CAI webcontrol boards and a few other similar programs which randomly update variables in the ISY all the time via REST but are not clients (if I understand that term correctly). Perhaps I am way off base and please tell me if I am. A nightly query on my system takes approximately 1 minute. Opening the admin console and program tab also takes about a minute total. Restoring Insteon devices takes anywhere from 15 seconds to 4 or 5 minutes depending on the device. During that time (presumably) DSCLink and the others are sending REST commands to update ISY. ISY from what I understand queues the REST commands. If there are too many to queue some may be lost and the variables might not get updated correctly during or after that period.

My thinking is while Network Rest commands are being queued the ISY would have a flag or some other mechanism which could be placed in the condition of an ISY program which would run sending refresh requests to DSCLink and similar programs after it is finished.

 

Thanks,

Tim

[Michel Kohanim]

Hi Tim,

 

Hi Michel,

Yes, DSCLink is one but I am not sure if it is a client or not. I also have a number of CAI webcontrol boards and a few other similar programs which randomly update variables in the ISY all the time via REST but are not clients (if I understand that term correctly). Perhaps I am way off base and please tell me if I am. A nightly query on my system takes approximately 1 minute. Opening the admin console and program tab also takes about a minute total. Restoring Insteon devices takes anywhere from 15 seconds to 4 or 5 minutes depending on the device. During that time (presumably) DSCLink and the others are sending REST commands to update ISY. ISY from what I understand queues the REST commands. If there are too many to queue some may be lost and the variables might not get updated correctly during or after that period.

All web requests go through the web server which has an infinite number of tasks. Now, certain operations may lock certain aspects of ISY. For instance, if you are querying ISY network only INSTEON driver is locked. The same is true for restoring INSTEON devices. If you are saving a program or a long running program is running then D2D (programs) is locked. Just because certain sub systems are locked it does not mean that you cannot update variables or send http requests. Web requests are only queued at the socket level (called backlog) ... so, there's no queue concept like other activities.

 

My thinking is while Network Rest commands are being queued the ISY would have a flag or some other mechanism which could be placed in the condition of an ISY program which would run sending refresh requests to DSCLink and similar programs after it is finished.

I am very interested in knowing the exact use case that's failing or other anomalies since what you are suggesting sounds like a temporary solution for something that might be quite serious.

 

With kind regards,

Michel