io_guy Posted July 19, 2016 Posted July 19, 2016 I am having trouble with sequential writes to one hub and then the next hub with successive lines in ISY programs. If I put a WAIT 0 seconds between "Hub1/All on" and "Hub2/All On" it helps somewhat but doesn't always work to fix the second hub missing commands on some, or all, bulbs. Not sure what to do here, if this is an issue it's a piss poor product that gets flooded by UDP traffic not directed its way. The hub should only be reacting to UDP commands addressed to itself. If it can't take stray command then it'd get flooded by every UDP device on your network.
larryllix Posted July 19, 2016 Posted July 19, 2016 Right now I find that with "All On" commands and a second delay between Hue bulb commands and between MiLight Hub commands the response is vary sporatic no matter how many repeats I have selected 1-3. I found this problem when I didn't use the 100msec or greater delay after any On UDP packet while experimenting. Is it possible the 100msec delay is not reliable in the code somehow? Not sure if you have a hardware timer or not. Is the nodesetup.zip file new again within the last 24 hours?
io_guy Posted July 19, 2016 Posted July 19, 2016 It is a minimum 100ms, there are no hardware timers. Just reviewed the code. I set the delay between "different" sends, per the API. Meaning I turn the bulb on, then wait 100ms before setting brightness and/or color. I currently do not have a delay between same command retires. Meaning the ON command is blasted 3 times, 100ms, 3x blasted brightness, 100ms, 3x blasted color. Yes, just sent the new zip. Should fix the program display issue with colors.
io_guy Posted July 19, 2016 Posted July 19, 2016 Just found a good bug, the retry was ignored. Commands were only sent once. Never mind, I can't read my own code anymore. I'll cut a new version tonight. It'll include the adjustable delay on dim prior to off, and an adjustable delay between retries.
larryllix Posted July 19, 2016 Posted July 19, 2016 I'm not sure I am reading that right but.... hitting the On three times before the parameters are sent is probably not the best way. I am not sure that accomplishes any more security of Tx. I have the version with the options and it has definitely helped to have successful comms but it is way too slow in spots. It seems as if the Off delay dimming is affecting all operations, maybe.
larryllix Posted July 20, 2016 Posted July 20, 2016 Just found a good bug, the retry was ignored. Commands were only sent once. Never mind, I can't read my own code anymore. I'll cut a new version tonight. It'll include the adjustable delay on dim prior to off, and an adjustable delay between retries. Here is the technique I use to drop the lighting levels, change colours and then bring the room back up in the new colour. It has a much smoother look than the abrupt colour change snap at full brightness. and different time delay for changing differet devices doesn't look as bad whenout of sync by a small amount. Another trick is to try to co-ordinate with the long smooth colour/level changes exhibited by the Hue bulbs. It's all like sleight of hand magic = misdirection of the eye. Colours.mauve - [ID 00BC][Parent 00C5] If $sGathRm.colours is $cMOOD.MAUVE Then Set 'Gathering Room / ML1' to 10% Set 'Gathering Room / ML2' to 10% Set 'Gathering Room / ML1' Color '$cCOL.MAUVE.STRIP Index' Set 'Gathering Room / ML2' Color '$cCOL.MAUVE.ML Index' $Hue.hue = $cCOL.MAUVE.HUE $Hue.saturation = 254 $Hue.brightness = 150 Resource 'Hue.set(all)' $TVBackLamp.hue = $cCOL.MAUVE.BLOOM $TVBackLamp.saturation = 255 $TVLeftPot.brightness = 255 Resource 'TVBackLamp.set' Set 'Gathering Room / ML1' to 100% Set 'Gathering Room / ML2' to 100% Else - No Actions - (To add one, press 'Action') So far it is working fairly well. There are still some random problems with the colour settings. One program I had to use the other colour setting command. It seems that once white is turned on some colour commands don't work to change it back. I have all my colour mood programs converted over now and will continue to try to identify what some of the remaining quirks are. The time delays are probably slightly too long yet but much more reliable comms. There are multiple ways to set colours and possibly too many options (that could be trimmed back in the ISY menus) that seem the same, but some colour settings don't seem to work in some programs. Can't figure that one out. I wondered if you (io_guy) had dropped the Hex $55 sync byte from the three byte packet. I had bad results when testing that. It got flakey when the timing ws quick between packets, and things just worked much better with the $55 sync byte included, despite the claims it wasn't needed in later protocols.
io_guy Posted July 20, 2016 Posted July 20, 2016 I'm setting the repeats and commands as the sample code shows on LimitLess' dev page. I include 55.
larryllix Posted July 20, 2016 Posted July 20, 2016 In the first four lines of the program above. dim hub1, All groups, to 10% dim hub2, All groups, to 10% set hub1, colour to Mauve set hub2, colour to Mauve There is a distinct delay where the groups fade down to 10% and then just sit, waiting, for almost another full second before changing colours. This happens between each hub's fade all to 10% also. I don't know where this time delay is created, but it could be shortened to help visual appearances. EDIT: V0.5.8 fixed this mostly.
larryllix Posted July 21, 2016 Posted July 21, 2016 Pleased to report all is working very well! Even with just Tx x 1, success is almost 100% now. I think with 40-50 calls of (4) groups x 2 hubs colour changes, it only missed a colour change twice on one group. The fact that all other groups on the hub changed but one bulb/strip didn't tells me the code went out OK but one group didn't hear properly. Will need some explanation of where the On packet is sent, if not all combinations of commands. There may be some fast change technique tricks that can be used with this knowing where the device selection is done. I haven't plyed with white lights much at all, but they seem to work just fine. I had some switching back to colour problems earlier but I think 0.5.8 fixed it. I can't recreate it now. Also, it would be real nice to have ISY access to the "Dim before Off" option in the NodeLink Nodes. This could make colour flashing possible despite usually wanting fading before Off to avoid abrupt light changes. I will continue experimenting at the "try to trip the system up" level, now. Not MiLights: In NodeLink web control, some indicator of what device's page would be nice. Usually it is easy to determine but with two MiLight Hubs I wonder which one I am looking at when making option changes. Maybe an underline of the current page being displayed or a title at top of each. Nice work. NodeLink has made 84 Network Resources redundant in my ISY for MiLight controls.
io_guy Posted July 21, 2016 Posted July 21, 2016 - I always send the On command - Will add the "dim before off" as an optional parameter on the off commands - Next release will bold the NodeLink selected device
larryllix Posted July 21, 2016 Posted July 21, 2016 - I always send the On command - Will add the "dim before off" as an optional parameter on the off commands - Next release will bold the NodeLink selected device OK. The dim before Off option may not be needed. There seems to an inherent delay built into the dimming somehow whereby the next command waits for the dimming to finish?? I don't know if your code is doing that but it also makes NodeLink wait to send a command to the second hub causing a distinct delay between responses on differing hubs. If this delay persists, I can just send dim commands from ISY before the Offs, like this.= no dim before Off option needed. Colours.off - [ID 004E][Parent 00C5] If $sGathRm.colours is $cMODE.OFF Then Set 'Gathering Room / ML1' to 10% Set 'Gathering Room / ML2' to 10% Resource 'Hue.off(all)' Set 'Gathering Room / ML1' All Off Set 'Gathering Room / ML2' All Off Else - No Actions - (To add one, press 'Action') Works just fine and I am using this technique before every colour change anyway so treating Off similarly is not a problem. We won't need the remote switch for the dim before Off option, in that case. OTOH if the delay is built into the NodeLink driver and is taken out, the dim before off delay would be needed. Removing other delays may make the two hub switching much faster and look more synchronised. Another question arises in NodeLink Web interface. The resend is labeled. "UDP Resend Count" Is that the total number of sends or the number of resends? I tried 0 in the resend count and it still works but bulbs end up with different colours and weird things. I have to assume it sends once then but maybe not all parts of the complete sequence???
Xathros Posted July 21, 2016 Author Posted July 21, 2016 This is working out very nicely guys! So much better having direct program access to these. Thanks so much to both of you for the development and testing work! -Xathros
io_guy Posted July 21, 2016 Posted July 21, 2016 Larry, you're reading into the code way too much. 0 resend means just that. It doesn't change the functionality, it only sends once. Just enable verbose log on the device page and you'll see everything I send.
larryllix Posted July 21, 2016 Posted July 21, 2016 Larry, you're reading into the code way too much. 0 resend means just that. It doesn't change the functionality, it only sends once. Just enable verbose log on the device page and you'll see everything I send. Thanks! That's as I suspected on the resend.
io_guy Posted July 23, 2016 Posted July 23, 2016 OK. The dim before Off option may not be needed. There seems to an inherent delay built into the dimming somehow whereby the next command waits for the dimming to finish?? I don't know if your code is doing that but it also makes NodeLink wait to send a command to the second hub causing a distinct delay between responses on differing hubs. Larry, What did you decide here? Not understanding the comment on the second hub delay. Each MiLight NodeLink device runs on a separate thread and does not wait for the other.
larryllix Posted July 23, 2016 Posted July 23, 2016 Larry, What did you decide here? Not understanding the comment on the second hub delay. Each MiLight NodeLink device runs on a separate thread and does not wait for the other. I don't think I need any Dim before Off option at all. This can be done with ISY Dim, then Off if desired. See following post. Not answering you last question yet. I will experiment with that again and watch the detailed log. However, I have found another quirk. This only applies to Hub/All group commands. I haven't tried it with individual groups. We seem to have two different ways of setting colour only. The one method doesn't put out any code from NodeLink if the level% parameter is blanked in the programming pulldowns. Like this This line does put out code if the level% parameter is included and not blanked out in the menus. Possibly one command option (maybe color only) could be eliminated as they will put out the same code anyway if the level% is blanked and not included.
larryllix Posted July 23, 2016 Posted July 23, 2016 More. One Hub only. Bug: The Hub/All Off command sends All On only. 2016-07-23 03:04:08 - MiLight: Data Sent (65,0,85) [mlight1] I was quite sure this was working before but always sent for two hubs??? My mistake: Can't read the fine print for code 66 vs 65.in the log. I have an idea for the Dim and delay before Off, option: Can we use the Dim to 0% to be Dim, delay for 700 msec, then send the Off ? This way, no visible options would be needed, but the user can still have all the control: Dim to 0% / Off with delay = one ISY line Dim Normally by using Dim to 10% - 100% All Off / Off as per normal for fast Off.
io_guy Posted July 23, 2016 Posted July 23, 2016 Makes sense, will do. I have the bug you listed in post 66 fixed.
larryllix Posted July 23, 2016 Posted July 23, 2016 Makes sense, will do. I have the bug you listed in post 66 fixed. Fabulous!!! Thanks!! I think there is not much we can do with the second hub delays. When the lights ramp up the ramp is quick and the time difference is apparent. Probably not avoidable due to some delays needed in the protocol after addressing group(s) of bulb(s). I dn;t know if I am just getting used to the delays or hey are getting quicker with practice. I think 0.5.8 helps a lot. When the bulbs ramp down it seems slower and the delay between hubs is not as apparent. Also when at 10% it isn't noticeable. If these MiLights had a settable longer ramp time, all this would disappear. In addition to the Dim 0% If the 0% can be changed to Off in the selection (10-100%) menu, or even if not, the Off could be changed to "Fast Off" wording to match Insteon styles. Just a thought. That may look too strange though...selecting On and then Off in the pulldown levels. I have noticed you repeat every UDP packet right after itself, instead of finishing the bunch, and then repeating. I didn't think it was supposed to work like that, but it seems to function quite well. I have had the odd miss with two hubs. The threading shows in the log as Hub UDP lines can become intertwined, at times. Seems to work OK, though. This may cause problems with individual light groups but then I assume the threading is only between Hubs being different Nodes. I am using one repeat as a trade off between more misses using 0, and too much delay. Did you get your bulbs ordered? I just ordered two more 5m strips. The prices have increased for most dealers. I bought most about $15 CAD last year. I have one 4' piece with a section (4 LEDs) of red missing.
io_guy Posted July 23, 2016 Posted July 23, 2016 Repeating each command independently is copied from the limitless sample code. It makes sense, because if the on command didn't work, the next are moot. Threading is separate hubs. Commands within a hub are synchronous. Off and fast off renaming won't be a problem. Haven't ordered my bulbs yet. Getting 3x 9w, look to be about $20 each.
larryllix Posted July 30, 2016 Posted July 30, 2016 Installed v0.5.9. Thanks1 The All On to 0% gives an immediate off as well as the All Off. I use mainly All commands for Off and mostly same colours throughout the room. Was the timer forgotten? Is there a new ISY profile file install to go with it? Addended: Individual group On to 0% turns the chosen group immediately and dims the rest of the Hub groups??? This may be the first time I have used Off with an individual group.
io_guy Posted July 30, 2016 Posted July 30, 2016 I might have screwed up what you wanted? On/Off: Immediate On/Dim 0: Dim to 10%, delay, turn off
larryllix Posted July 30, 2016 Posted July 30, 2016 I might have screwed up what you wanted? On/Off: Immediate On/Dim 0: Dim to 10%, delay, turn off Something weird going on with association of groups. I have tried this with the two hubs and waits between them to avoid interaction problems. If I use Set Group 1 On 0% then Group 1 goes Off immediately, then groups 2, 3 and 4 dim to 10% and stay. The other Hub does the same thing. Retested: Also Set All On 0% turns off all groups immediately. I see no Dim words. Is there a ISY profile update required?
io_guy Posted July 30, 2016 Posted July 30, 2016 Something weird going on with association of groups. I have tried this with the two hubs and waits between them to avoid interaction problems. If I use Set Group 1 On 0% then Group 1 goes Off immediately, then groups 2, 3 and 4 dim to 10% and stay. The other Hub does the same thing. Look at what the verbose log says is being sent.
larryllix Posted July 30, 2016 Posted July 30, 2016 Look at what the verbose log says is being sent. Top two lines from a Hub1 All On 0% (no dim delay seen, but chosen) Bottom four lines from a Group1 On 0% 2016-07-30 02:13:14 - MiLight: Data Sent (65,0,85) [mlight1] 2016-07-30 02:13:14 - MiLight: Data Sent (65,0,85) [mlight1] 2016-07-30 02:14:34 - MiLight: Data Sent (70,0,85) [mlight1] 2016-07-30 02:14:34 - MiLight: Data Sent (70,0,85) [mlight1] 2016-07-30 02:14:35 - MiLight: Data Sent (78,2,85) [mlight1] 2016-07-30 02:14:35 - MiLight: Data Sent (78,2,85) [mlight1]
Recommended Posts
Archived
This topic is now archived and is closed to further replies.