apostolakisl

Your program is not the reason for the error. It is your connection to your ISY. Try closing your connection to ISY and open a new session.

Two points 1) UD is making their own PLM. Not sure when it will be out. 2) You can fix your old PLM and make it better than factory. There is a thread in here about which capacitors to replace. Many success stories there, me included. PS, PLM's don't need to cost $160. It is literally that they saved a few pennies on cheap *** caps.

You should put a ticket in to UD. They will probably see this thread at some point also and give you further instruction. The only other thing is maybe the PLM is bad. You might try disconnecting it and trying to access ISY. You can log into ISY without a PLM, it just goes into "safe mode" of sorts.

Hopefully you have a recent backup of the ISY. A factory reset followed by a restore doesn't take all that long to do. Or, hopefully not needed, but a replacement unit can be restored.

I'm sure you've done a hard reboot. What led's are on? Try a different power supply. Try taking the memory card out and putting it back in.

With 5.0 firmware out, there may be some other options not yet known.

Ahh yes, good thought. Don't know if the OP has an Elk, but I do. You could so easily use an Elk relay to power cycle ISY with a power restore. But I don't have a generator, so no need here. My electricity so rarely goes out that a generator just seems pointless.

Maybe you can get UD to add a programatic way to push the "reoboot" button. I wouldn't think it would be that hard of an addition since you can already do a reboot from the GUI. The idea 2 I posted above has the advantage of being 100% programs. No need to buy anything or physically change anything. The only downside I see to it is that you have to regularly query a device which adds a bit of system traffic. Also, it may miss a short power outage and will have a bit of delay (depending on your chosen interval of query) before recognizing that power is back on.

I can think of 2 ways. 1) Reboot isy with catchup schedules checked. The trick is how to reboot isy when power is restored. You would need an external relay to power cycle the isy since I don't believe there is any programatic way to do it. Now the trick is how to get the relay to just kill power for 10 seconds to ISY when city power is restored. All I can think of here is some other logic device. I could get a webcontrol board to do it. 2) Another option might be to have a "run if" program that triggers all the programs that involve things on schedules. You would need to set ISY to continuously query a device that is not on the generator to detect when power is gone (like once per minute). When the device fails to respond set a state variable to say 2. Then when it does respond again, set it back to say 1. Then this can trigger your "run if" program "if state variable x is 1, then run if . . . ".

My system definitely does not fall under the "babysitting" category. It is more like the "beehive" category. If I leave it alone, it doesn't cause me any trouble and we both go about our business being quite productive. I guess there was that unprovoked swarming that occurred when my plm died per the usual cap issue. At times I have an insufferable desire to poke the nest, adding stuff or just changing stuff around. But anymore, the bees are pretty docile. I have learned how to put a little of that magic smoke in the air first. For the most part, I have got my system in a good place and I don't poke it anymore. The only thing I tend to do now is add or tweak programs as my needs change. This really doesn't cause any headaches.

I agree. You pretty much only lose stuff that a technician would care about. You could always keep your carrier thermostat and mount next to the unit itself and switch over to it when and if the need arises for those diagnostic and configuration features. Maybe once a year or something I access my system logs and stuff for curiosity sake. And that is about all the good it does me.

OK, so I can do things like 1) change the outside temp trigger for going to stage 2 2) check fault codes 3) check run times at high cool/low cool/high heat/low heat 4) enroll new devices in the system (like a heat recovery ventilator) 5) run diagnostic tests 6) read pressures in the plenum and stuff 7) see the temp at the condenser unit And some other stuff that my brain storming isn't remembering right now. Most of that stuff is actually hidden from the regular user, but I figured out the trick to get into all of that stuff. Still, it is almost useless to have access to any of that stuff.

That is common. As Teken said, you really just need to ask your hvac guy what it is your are installing before you can get much further.

Good Point. Although, speaking at least for Carrier, you don't have to use their proprietary bus. I have one of those carrier systems and you can install a conventional thermostat. However, you lose the ability to run the diagnostic and configuration tools from a thermostat. For whatever that is worth.

Are you sure you don't have a heat pump? It is rare to put in regular resistance electric heat since it is such an expensive way to make heat. You usually only see that where it almost is never cold enough to need heat.

If you say "5 wire" and you are talking about a 5 conductor low voltage wire all sheaved together in a single jacket, and it is controlling your heating and cooling, then you do not have line voltage going to your thermostat and most any thermostat will do the trick.

OK, my bad, I guess I knew last year that crossed from/to times don't trigger and somehow forgot. I swear at one point they did. the summary page shows a crossed from/to program has a scheduled run time, but it doesn't actually run despite saying it will.

That program will trigger at both 9:35 and 9:37 and be true both times, only because of the "or $cTrue is $cTrue". Without that clause it would run at both times and be false. As mentioned, if the variable is a state variable, then it will act as a trigger also whenever it changes. If it is integer, it will just sit idle waiting for some other trigger regardless of what happens to its value. Always the "From" time and the "to" time are triggers. If from time is after the to, then it will be false. If anything else triggers the program, that particular clause will be false always. Of course adding an "or" statement connecting a by definition true statement will in turn cause this program to always be true.

You don't need any crazy programming like that. Just If From Sunset To 6:30 pm same day Then Set lights on Else Set lights off The program runs twice, at sunset and at 6:30 pm It always runs false at 6:30 (lights turn off, if already off . .. nothing happens) It runs true at sunset if it is before 6:30 (lights turn on, or stay on if someone manually turned them on) It runs false at sunset if it is after 6:30 (lights turn off if they had been manually turned on, if already off, nothing happens) Just keep in mind that if you manually turned the lights on, this program will turn them off at sunset when it occurs after 6:30.

No, that is not correct. $ical.Holiday is getting set to 0 and the rest of the programs are being triggered simultaneously. A "then" clause is "atomic" meaning that all items get set into motion simultaneously. In my experimentation, variables get set instantly for all practical purposes so all of the "run" programs are seeing the variable as set in the same "then" clause. You can put the "then" clause in any order you want and the results will be the same. Of course a "wait" clause changes that. Your program is running, it is just that it is running false because $ical.Holiday was still 0 because New Years Day program had not changed it yet. The delay as mentioned should work. Another option would be to change "$ical.Holiday" to a state variable (or have 2 versions of it, state and integer) and then the program "Holiday changed to 1" will trigger itself.

What is triggering that program?

Your "if" section has only integer variables. Integer variables are not triggers. You need a trigger. Like if time is 6am and i.holiday is 1. Or, you can use state variables. That will trigger anytime the variable changes. Which probably means midnight here.

"Nesting" is done more or less like this If something Then Run program 2 (if) perhaps other stuff Else something Program 2 (disabled) If whatever Then whatever Else whatever

I wrote a second set of programs that uses simpler logic. See the link below. http://forum.universal-devices.com/topic/13750-i-wrote-a-new-date-variable-program/ For you, you would have an if clause that was something like If $i.month > 10 or $i.month < 4 Then do whatever.

Putting an always false statement like if 0 is 1 would push your run at startup to the else clause every time. It is 6 or half dozen, going with always true and filling out the "then" or always false and filling out the "else". But I would stick with going the true route, it just keeps the mind from spinning in circles. The basic jist is that "run at startup" is going to cause the "if" to evaluate. Really the only non-intuitive thing is that a blank "if" is evaluated as true.