Extend Wait times down to 0.1, 0.2, 0.5 seconds

[larryllix]

This could be immediately useful where MiLight bulbs & RGBW strips require a minimum delay of 100 msec.

 

After addressing any MiLight/LimitlesLED bulb or strip controller, colour changes and dim levels can be sent after a minimum of 100msec gap in the udp packet bytes.  This can be accomplished by using

 

    Wait 1 second

 

but I have 12 devices in one room that requires 12-15 seconds of wait times to change al light settings. Response time appear very slow as each light group turns on with the previous colour and after 1 second changes to a different dim level or changes colour. This is particularly annoying to see.

 

This should be fairly easy to implement for UDI and easy to add to the pulldown menus in Admin Console IMHO or add a 100msec delay symbol tool to the Network Resource udp binary strings, or both.

 

Shorter flashes of lights come to mind for other uses.

[fryfrog]

I have a program that blinks a light on a keypad according to what setting my house fan is on. It takes 5 seconds to display 5 flashes, a half or quarter second between them would be nice.

[andyf0]

Looking at my logs (which only show times with 1 sec resolution), the Wait duration isn't that accurate even with 1 sec resolution when there is a lot of activity and traffic occurring. I don't think the Wait timer could get down to ms resolution without some serious work.

 

Maybe it''s because I'm using mostly Z-Wave now with only a few Insteon devices, maybe it works well with just Insteon.

[andyf0]

I have a program that blinks a light on a keypad according to what setting my house fan is on. It takes 5 seconds to display 5 flashes, a half or quarter second between them would be nice.

I also blink a light on a KPL when my garage door is opening or closing. A wait of 1 sec between flashes still can produce uneven flashing, but that could be the response times of the KPL varying.

[larryllix]

Yes, even with Insteon, flashing an LED or beep on a device bogs my ISY down so that it becomes uncontrollable from the Admin Console. Programs stop running and devices operate 30-40 seconds later sometimes as my whole ISY system may lock up. I avoid flashing LEDs with Insteon signals. For a single isolated usage shorter delays work just fine though.

 

The shorter times would be mainly useful for Network Resources and non-repetitive delay usage.

[fryfrog]

Yes, even with Insteon, flashing an LED or beep on a device bogs my ISY down so that it becomes uncontrollable from the Admin Console. Programs stop running and devices operate 30-40 seconds later sometimes as my whole ISY system may lock up. I avoid flashing LEDs with Insteon signals. For a single isolated usage shorter delays work just fine though.

 

The shorter times would be mainly useful for Network Resources and non-repetitive delay usage.

 

Yikes, I should probably give this a look and see if it is happening on mine. The insteon device has a 'beep X times' thing, maybe I'll switch to that instead. Shame it doesn't have a flash X times.

[Xathros]

Yikes, I should probably give this a look and see if it is happening on mine. The insteon device has a 'beep X times' thing, maybe I'll switch to that instead. Shame it doesn't have a flash X times.

There is no "Beep X Times" feature. There is an unsupported Beep Duration (0-255) that makes no difference regardless of the value you choose.

 

-Xathros

 

Sent from my iPhone using Tapatalk

[larryllix]

Yikes, I should probably give this a look and see if it is happening on mine. The insteon device has a 'beep X times' thing, maybe I'll switch to that instead. Shame it doesn't have a flash X times.

In the Admin  Console you will see a "System Busy" box pop up. When it stops going away then your system is really busy.

[fryfrog]

There is no "Beep X Times" feature. There is an unsupported Beep Duration (0-255) that makes no difference regardless of the value you choose.

 

-Xathros

 

Sent from my iPhone using Tapatalk

 

Shoot. :/

[Michel Kohanim]

Hello larryllix,

 

As Mike suggested, this is not going to be very accurate especially if you have programs that depend on completion of Z-Wave/INSTEON operations.

 

With kind regards,

Michel

[larryllix]

Hello larryllix,

 

As Mike suggested, this is not going to be very accurate especially if you have programs that depend on completion of Z-Wave/INSTEON operations.

 

With kind regards,

Michel

Accuracy would not be a requirement for this fine of a time as HA signals are not going to control devices that accurately anyway.

 

I was mainly concerned with the 100msec requirement for MiLight udp packets but that could possible be handled with a special delay symbol/character that could be slipped  into the byte stream list of the Network Resource. Of course some mechanism to insert it there would be required. ( ^0.1, ^0.5 ?? )  This would equivalent to a Wait inside a Network resource.

 

{64;0;85;^0.1;66;24;85}

{64;0;85;/W0.1;66;24;85}

 

Some flash signals could use it with a warning about accuracy and repetitive usage.

 

set 'Light' On

Wait ~0.5 seconds

set 'Light' Off

...

[Michel Kohanim]

Hi larryllix,

 

Is this only to support delays in Network resources?

 

With kind regards,

Michel

[larryllix]

Hi larryllix,

 

Is this only to support delays in Network resources?

 

With kind regards,

Michel

The 100msec is my main need for MiLight support via network resources. Longer works also. Once a bulb is addressed, with an On command, the comm is open to that group of bulbs and a minimum 100msec delay is required before brightness level, hue and other parameters can be sent in rapid fire or even minutes between them. When another group/bulb is addressed then the comm to the first is closed. Wait 1 second between Bulb On and Bulb parameters works  but the delay times get too long when multiple bulbs need to be addressed.

 

I thought others may want the Wait 0.5 seconds also where 1 second may be too long for certain program delays and it could be implemented into the Wait times that are already built.

[Michel Kohanim]

Hi larryllix,

 

Thank you but I still do not understand. Is this put support delays in the network rule itself? We really cannot do anything in Programs.

 

With kind regards,

Michel

[larryllix]

Hi larryllix,

 

Thank you but I still do not understand. Is this put support delays in the network rule itself? We really cannot do anything in Programs.

 

With kind regards,

Michel

 

If no program support could be done with shorter times then  just an insertable delay of 0.1 seconds in the Network resources is all it would take. For 0.2-9 multiple inserted glyhic symbols could be inserted in series.

 

In a program the code would read something like this.

 

Resource MiLight1(on)

Wait 0.1 seconds

Resource MiLight1(red)

 

This would translate to one Network Resource (packets are three bytes each). This inserted delay would allow two or three bytes in each resource without a "Wait 1 second" between without colour change flashes in the bulb.

 

udp binary  86;0;85   ^0.1s 64;32;85

                        ^            ^          ^

                        |              |          + previously addressed lamp to red

                        |             +-----time delay of 0.1 seconds or more. use some graphic symbol char or kb symbol

                        +-------turn lamp on and open for further parameters

 

 

Now we could just use this syntax

    Resource MiLight1(red)

 

With working substitution of binary parameters this could all be syntaxed like this

   set $MiLight.hue = $cRed

   set $MiLight.brightness = 128   #50%

   set $MiLight.bulb' = 3

   Resource 'MiLight.set'

 

The 100msec delay would not be discernible in the bulb colour change.

 

Currently the Wait 1 second in program lines turns on a bulb with the last colour at maybe 100% and then changes the colour causing an annoying mood lighting disruption. The time delay also adds up for multiple bulbs and takes many many resources for every bulb group 

The MiLight bulbs and RGBW strips have a slight ramp time built in and can disguise a short 100msec flash.

 

    Resource 'MiLight3.on'

    Wait 1 second

    Resource 'MiLight3.red'

    Resource 'MiLight3.50%'

[Michel Kohanim]

Hi larryllix,

 

Thanks so very much for the details. 

 

This is a little tough since network resources are pretty much files stored in the file system which the firmware simply reads/substitutes variables, and sends out on a socket. It would be very difficult to interrupt this processing.

 

I am thinking that with 5.0 and node servers, all of this can be handled by the server and thus no need for network resources.

 

I am so very sorry to disappoint.

 

With kind regards,

Michel

[larryllix]

Hi larryllix,

 

Thanks so very much for the details. 

 

This is a little tough since network resources are pretty much files stored in the file system which the firmware simply reads/substitutes variables, and sends out on a socket. It would be very difficult to interrupt this processing.

 

I am thinking that with 5.0 and node servers, all of this can be handled by the server and thus no need for network resources.

 

I am so very sorry to disappoint.

 

With kind regards,

Michel

Thanks