larryllix

The usual and safe way to circumvent triggers (the we need to star a process) from stopping the process is to creat two programs. -Use one (enabled) to see all the triggers and call the second program from it. -Use a second program with any further wanted conditions (maybe twoo different timers or processes) and a timer that ensures the job will complete. -Disable program Two from any trigger influence.

The logic is being continuously evaluated. If it ever become False Then stops running and Ese starts running. You could set a variable true/false and test that with Repeat While $sVariable = $cTrue You could use one program to initiate on a cyclic basis the other with conditions. You cannot have more than one condition is a Repeat While, though. BTW: The Repeat Every is a bt of misnomer. Your loop will happen every 2 hours and 10 minutes. 10 minutes is a lot of water once the ground gets wet! I did this years ago with an X10 system and used 3, 2 or 1 minutes, depending on the brightness in the house. Then I didn't cycle at all at nights. Grass grew so fast that a neighbour commented on the speed.

ewwwww. That does break the trigger concept for programs. Now we would have to write ISY code to compare parameters with a known/old value in a variable to detect a change. This doesn't sound like a workable solution for ISY logic. Does that mean every program based on a node will notify the user on Query All every night? In my case the value was triggering programs from REST input to those variables. Without a value change programs were running every time a REST value was inserted. That means with every usage of a REST/VAR/ command a series of programs in ISY will evaluate and run Then or Else, and no change is detected. EDIT:Read Michel'sl logic very carefully. (I didn't at first). This is actually a good testing feature. We can initiate programs manually right from the horse's mouth.

I found the same problem with State variables updating to the same value, back about v5.0.2, UDI reported to be fixing that one. What firmware version are you finding the status false trigger with?

OK. One thing I have found about these LEDenet controllers you should know up front. They take TCP protocol and that is not good with real time. That means that your router and/or driver software may do things like, - let packets passed each other so they get out of order, (this seems to be OK at higher speeds) - clump packets together to increase the throughput, (destroys smoothness of animation) - disconnect sockets, based on a timeout, and they take a part second (0.1-0.7) to reconnect again. They have to be constantly poked to remain fast responding (connected). I have found high speed animations look smooth and really slow animations are OK but medium speed animations can get out of order and sporadic. I suspect these controller tiny CPUs are busy doing some ramping etc. and they don't respond to the TCP requests fast enough. They should have been UDP protocol. I doubt these controllers will satisfy what you have done with DMX.

PDP-11? No PDP-8? Just a newbie!

Sorry for the confusion. I did a search on amazon.com for "Ledenet" and t comes back with all the parts you need, and I probably have ever had. They list the MiLight controllers as Ledenet devices, which I am fairly sure they are not, and the rest of the negatives are in my previous post. I have about 6 of them, as well as four bulbs and that takes two hubs. I switched over to the 5 channel LEDenet controllers now. Scott has the 4 channel (UFO) and now testing a 3 Channel unit from them. The MagicHouse UFO app does them all...but not the MiLights as they at NOT Ethernet WiFi. This one https://www.amazon.com/LEDENET-Wireless-Controller-Changing-Brightness/dp/B00MGTVOSA/ref=sr_1_34?ie=UTF8&qid=1493951950&sr=8-34&keywords=LEDENET

Thanks for showing up Scott. We thought that new car swallowed your HA intellect I was looking for NRs to operate the LEDenet devices to show this drooling N8huntsman, and I don't use them directly anymore and couldn't remember the parameters. Maybe a screenshot? @n8huntman. The MiLight units sold under LEDenet, by amazon.com, were never LEDenet AFAIK. They require a hub and despite what they say are not WiFi. The hub is a bridge to convert WiFi their proprietary 2.4Ghz signals but any resemblance of WiFi is false. They will not mix white with RGB. Different protocol and the hub is limited to four groups/addresses/controllers.

The communication is all one way...out of ISY.I was going to do a screen dump of a NR for you but I don't use any NR directly into the controllers anymore. My NR are aimed my RPi software and they do it. This allows me all on commands and a few others more easily from 4 NR, using variables. There is some discussion of the codes to do whatever colours your want in the other threads, We'll have to see if somebody else is using them directly still. I know Scott was. My fear is that with a binary NR you cannot use variable substitution and would need one NR for each colour as well a a few levels of white, high, med, dim, Off.. Not a big deal but it becomes about 10 NR for each controller. More clumsy than I like. The comm protocol is TCP. Do you have a RPi or programming experience?

The controller is the correct one. When you hook up the cable to the RGBWW terminals you may find R-G reversed. The last batch I got had those terminal reversed...or OTOH the firmware inside reversed. It's very easy to swap two wires on the cable when you wire them. Due to the delicacy of the wires, I stripped them longer, tinned them, and terminated them. then I folded the power and RGBWW cable back past the controller and white vinyl taped it to the case. The wall panel looks like it would do the trick and dual purpose for DMX serial connections also. More study would be required on that one. I just use the MagicHouse app on my Android phone for setup. The only time I really used the app is, after a factory rest on the devices they throw out their own SSID. You connect to that, run the app and set your house SSID and password into it, Then the SSID goes away and the app connects via your house SSID. I run my house RGBWW strips (I have 4 partials and 1 whole 5m over/under cabinets) from one Insteon SwichLinc dimmer via ISY. Mostly white 100%, bright, medium, dim. The colours get used for parties and mode setting for occasions and movies late at nights. Right now I have 10 reels of RGBWW on those controllers on a board for a furture pinwheel animation. I have written most of the code for them on a RPi3. Started on my RPi1 but that functions as a Node Server for ISY and I kept bugging it. I have most of my animations written and working and now just making mood lists to supervise the animation sequences. It runs from a 4 key mini-remote and also a duplicate screen from Tasker on any android machine. My suggestion. Order one from amazon, at their high price, and see if you can do anything with it using NR and then order a bunch on ebay for a much cheaper price. You have to really look around. Once they became ppopular the price went from $9 to $40 for some vendors. You should be able to see a list of parts in another thread I posted. What part of the world are you in?

It was an attempt at a pundle. I thought you would be right on top of V5. Have a look as this usage for the repeat while.... http://forum.universal-devices.com/topic/18921-v5-averaging-using-only-the-best-values/

Oh yeah. I am buried knee deep in lights and controllers here. Building a 23 strip animation controller for a tent ceiling. There are a few threads on this but the MagicHouse UFO = 4 channel, Scott is expereimenting with a 3 channel version right now. The ones I have found the best is the LEDenet 5 channel, (look for music controller). This is the same company as the ones above. They have RGBWW/CW outputs and can mix white with colours. Most can't like MiLights. I have bunch of them too. I woud avoid them. The Network Module inside ISY can control them without any other hardware. I have written python3 software for my RPi 1 I call NR bridge that can act as a bridge to do more things but it still takes the NR module to command it. The best part is the LEDenet (MagicHouse) brand is WiFi and no hub is required. MiLights demand a hub that can only control four "groups" FYI: The RGBWW 5050 strips run about $15, controllers $11-35 , then you need a PS 12v @ 3-5A $10, barrel plug adapter cable $1.50, 5 pin adapter cable to wire into the controllers = 10/$5. Oh yeah. Don't try to sticky a run of lights upside down. They just fall off every time. get the silicone clamps and tiny screws every 12" or less. 100/$5 All prices are Canadian and aproximate. NR, software and help all available here on the forum. This summer and fall I will have a surplus of these things I may want to get rid of.

Sure, but I am waiting for logic line enable trigger options first, well at least for a repeating while

Add an "end" to the pulldown menu list of times was suggested before. Repeat X times ...do something Repeat End Like any other language you have to learn the syntax and then use it.

Just your old fashioned "repeat until" loop that's been around for many years. Fairly standard, only with a few different words. The until is just repeat 1 (once). Totally intuitive, but intuitive is only relative to your experience. We weren't born programming via a keyboard. QWERTY? Really? I have used many different styles of languages. There is no "intuitive". There is no standard style of repeat. The admin console even indents the contents for you so you now where it begins and ends (even without those words Mr. Pascal). That is way past where I started programming. Now for the syntax quirk. You should love this one. ..."Repeat 1 times" doesn't repeat the loop at all. It only executes it once. Have a good one!

So if I read you correctly, the hardware at each end ie. PLM / ISY is wired differently to accomodate a cable, with identical pin numbers wired together. Is that not what you are calling "straight-through"? This is the way the original Ethernet hubs and switches were wired, but the cables would never be able to connect two hubs together, or two computers together. That was the "other" cable required with Tx wired to Rx. It was a mess for a while, and I think this has been since straightened out, similar to RS232 cables. Tx and Rx are always crossed or all connectors have auto crossover capabilities. As much as I have wired a few thousand RJ45 connectors, by hand for a fibre WAN system, I really have never studied the connection purposes of the pinouts.

Are the signal levels RS232 or logic levels? That would determine the capability of the signals. We know you can't connect Tx to Tx so something has to switch the connections. This means a straight through cable isn't going to work the same way as a real RS232 cable always needs pins 2 and 3 cross wired. (Tx to Rx, both directions) Sent from a tiny keyboard. Response may be brief.

Interesting. Although I have had a few Insteon comm failures, I have no repeaters, phase couplers, filters, or other devices that are not directly being used. I have two OutBack inverters running at all times with some Insteon running from their supplies, and my PLM plugged in right beside them.

I have found all decent Zwave devices are much more expensive than Insteon devices. People do their own bait and switch though. They look at the cheap Zwave devices that don't support status reporting or repeat etc., get enthused, and then upsell themselves the expensive ones because they are actually useful in a HA system. Next thing is a grid of repeater devices due to the RF only range. All looked good in the sales flyers when they sold off the bottom end devices.

I think B on both ends would twist the signals. To be straight through IIRC it takes B on one end and A on the other. ISY Tx = PLM Rx ISY Rx = PLM Tx B to B may connect Tx to Tx and Rx to Rx Since serial ports don't usually auto change connection function, like many Ethernet ports now, it probably shouldn't work.

If the heat pump is new I would ask the company to come back and tell them it is causing electrical noise on your system. They may have some simple fixes for it like.. Re-tighten some connections they did Install some toroids on the feeding conductors. Install MOVs across the feeding circuits. Install a whole 240v filter on the 240v and/or 120v. Use a disturbance/harmonic analyser to actually analyse the problem. My guess is this will cause you more problems down the road and may be combined with another newer noise maker and then it will get really hard to fix.

Just another thought.... I figure you know this, but the mechanical heat pump stats had two contacts, and the heat pump was set the highest temperature. A few degrees lower the back up heat contact would cut in, and usually some had an option to stop the heat-pump when the backup ran, or run both simultaneously. The two contact outputs are not confusing the issue of reporting differential I hope. This seems a little out-of-whack for a AC run stat. It's not like they need to save the batteries by reporting too often.

Some of us spent all our money earlier and aren't so lucky to have the latest units. It would be interesting to find out if the large reporting exception rule applies from the last update after a query. IOW: If the last temperature sent to ISY was 72F and you query it and it sends 74F, will the next report be at 76F (72+4) or 78F (74+4)? That would seem that a query before critical usage would be necessary each time. Trouble with that logic is that you don't know the time is critical until the stat reports in. duh! Another thought: Is there a time period report that the stat reports whatever it has every X minute/hours, regardless, or from the last report? Surely, SH would have gained some high level protocol intelligence by now.

If you are referring to the 2441(Z)TH Insteon thermostats, mine report in about every 1.5 degrees C.The local operation works on the resolution you see on the screen (0.5c) You cannot query the temperature from the stats. everything else, but not the temp. On just batteries you can't query anything IIRC.

The connectors on one end may be the wrong polarity style (A or . Most Ethernet will work with either cable style but serial won't.