larryllix Posted July 1, 2015 Posted July 1, 2015 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 Posted July 1, 2015 Posted July 1, 2015 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 Posted July 1, 2015 Posted July 1, 2015 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 Posted July 1, 2015 Posted July 1, 2015 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 Posted July 1, 2015 Author Posted July 1, 2015 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 Posted July 1, 2015 Posted July 1, 2015 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 Posted July 1, 2015 Posted July 1, 2015 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 Posted July 1, 2015 Author Posted July 1, 2015 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 Posted July 1, 2015 Posted July 1, 2015 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 Posted July 2, 2015 Posted July 2, 2015 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 Posted July 8, 2015 Author Posted July 8, 2015 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 Posted July 8, 2015 Posted July 8, 2015 Hi larryllix, Is this only to support delays in Network resources? With kind regards, Michel
larryllix Posted July 9, 2015 Author Posted July 9, 2015 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 Posted July 10, 2015 Posted July 10, 2015 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 Posted July 10, 2015 Author Posted July 10, 2015 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 Posted July 10, 2015 Posted July 10, 2015 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 Posted July 11, 2015 Author Posted July 11, 2015 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
Recommended Posts
Archived
This topic is now archived and is closed to further replies.