apostolakisl

You can open ISY Tools/Diagnostics/Event Viewer and set it to level 3. This will show all communications that ISY sees on the network. You have to have it open, though, it will not show you what happened before you opened it. So I would turn it on this evening around 9pm and see what you get.

I don't know about "no plm" firmware. But you can just run ISY with a plm then "delete plm" and it will no longer run in safe mode. This does not erase the plm, it just removes it from ISY. So you can just "borrow" your PLM from polisy then return it when done. I used a super old ISY 99i as the IR relay since it is otherwise useless. See my post on how to make an old ISY into a IR relay using network resources.

Not sure I can use this without some changes. I got my Tesla and then immediately went on vacation. I left the car with 90% charge but did not have it plugged in. About 10 days into my vacation I thought to see how my Tesla was doing. the battery was at 35%! It was losing roughly 5% per day just sitting there. I shut off the node server, and over the next 10 days it might have lost 1 or 2% more. In short, the node server seems to keep the car in a state of energy sucking that is pretty significant.

Odds are very high that, as mentioned, you just need to completely clear java. Just type " configure java" in your windows search box and the first choice should be just that. In the first window that opens, you'll see "temporary internet files", click on "settings" in that section. Then in the box that opens, click "delete files", in that box, check all 3 options, then click "ok". Now click on this link https://isy.universal-devices.com/start.jnlp to download the ISY launcher. It will install an icon on your desktop for future access. The first time you run it, it will open straight up. It should find your ISY. If it doesn't find you ISY, then something is up with your network. But you can still enter the IP manually and it should work unless you have it fire-walled. For example, I have to enter the IP manually when I am running over my VPN connection, but otherwise, it comes up on its own. If you do have to enter it manually for whatever reason, it will remember it the next time, so unless your ISY changes address, you are set. Downside is every time you do a windows update, soon to follow you will need to do a java update. At which point, you have to repeat the process. I'm not a fan of java, but once you realize what needs to be done, it isn't but 20 seconds or so.

@stevehoytThat smart splitter looks easy, but for $500 I think I could do it for free. I already have CAI webcontrol boards which I can hook up to my AC units to know when they are running and I can do that in the attic. At that point, assuming the node server can tell the car to charge or pause charging, I just need to write a program on ISY. I haven't seen the node server working yet since it seems as though I actually have to have the car before the nodes will install. So, I'm not 100% that the node server can start/stop charging. Can you confirm that the node server can do that?

Thanks for the info. Directly in front of my parking spot at the office are my AC units. When I bought the space, I re-did the AC and went from 4 units to 3 units. So I already have a 50 amp circuit just sitting there doing nothing. I don't actually drive that many miles. My current car is a CTS-V, is 11 year old and only has 65,000 miles on it. We have largely used my wife's car for the bulk of driving, but perhaps that will change after I get this car. Back in the day I thought 558 hp was impressive. Now it is 1000+hp or I'm going home. Anyway, I have always loved the wolf in sheep clothing car. . . the 4 day family sedan that kicks ***. Probably talking about a few bucks/month, but whatever, I have to charge it somewhere and being a HA junkie, I just want to do it. The cost of the car itself dwarfs the cost of the electricity, so it is kind of joke, but again, whatever. Basically, I just need the node server to give me control of the charging. To tell the car to start and stop charging. Not sure if you have to keep the car awake to do that. Doesn't seem like keeping the computers in the car on should have much power draw, but what do I know, I don't yet own it.

It would only matter on command, not response. The max kw is based on a running 15 minute average, so even if there were a short delay of something under a minute, it would not likely affect the 15 minute running average much. I need to figure out the best method for getting the trigger data into ISY. It is 3 phase and Sense, which I use at home, doesn't do 3 phase. So I need to figure out a different way. Right off, I know I could use a webcontrol board and just monitor the AC units with that and only charge when they are idle. Though I might never charge the car the way this summer is going.

My new Tesla is finally arriving next week after a 6 month wait. This is my first Tesla. I was looking at charging at the office where I am on a kw + kwh billing system. In other words, your worst 15 minutes of wattage during the month determines about 2/3 of the bill and kwh is only ~5c each. So, my thought was, to only let the Tesla charge when my wattage was low so it only cost me 5 cents/kwh and doesn't bump up my high watt level. It sounds like this node could help. Basically, I would like to tell the car to charge whenever certain conditions are met. Either I monitor my overall power usage, or just monitor the big draw items, like AC units, and only charge when they are idle. Anyone have thoughts on this?

I may be wrong on this. I swear it used to be that true/false status of a program would only trigger another program when it changes status. But I just checked in a very old 3.3.10 ISY firmware and it triggers every time regardless of whether the status changed or stayed the same. @larryllix

Yes, I just tested this and you are correct. Something has changed, a program used to only be a trigger upon changing status, now it is a trigger every time it runs regardless of if it changes. I just recently switched over to IoP and will need to look over my programs. I have had a few things happen that I wasn't sure why they happened and this might be a reason. But also, what Mr. Bill said. That fixes the problem and also solves hysteresis issues which very well may happen.

Mr. Bill addressed this as I would have. No need for a Boolean state variable ever because it just mirrors the state of the program and functions identically as a trigger for any program that references it. In your second post it looks like you stated you "couldn't do that". But you are mistaken. My guess is you need to put some hysteresis in there. Trouble likely is that temp is bouncing around. 79.9, 87.0, 79.9 etc. Each time it does that it will get you a new notification. Program 1 If temp is >=87 Then disable program 1 Else blank Program 2 If temp is < 79.5 Then enable program 1 Program 3 If program 1 is true Then do what you want Probably should do a "run at startup" on 1 and 2 as well. EDIT: After looking at this a second, I realized you don't need program 3. You can put your notification into program 1 then clause prior to the disable line.

If you restore from ISY and you still have incorrect behavior, that is a dead giveaway. Detecting orphan links is much more difficult since they don't create bad behavior, but they do take up space. Orphan links require a very good knowledge of how to read the links table. You could take a random sampling of devices, record their links, then delete/reinstall the devices and see if you get the same set of links.

Factory reset/restore PLM will make the PLM links the same as ISY's internal database. So bad links will only exist on the PLM if they exist in ISY, which can happen. The only way to get rid of bad links in ISY is to delete the devices that have bad links. This means starting over from scratch on those devices, need to manually put them back into programs and scenes.

Link counts get screwed up with any comm on the system. Have to do them while you are out of the house and programs disabled.

@shunsader I have had this happen before. ISY actually had wrong links in its table, so resetting and restoring did not fix the issue. Had to delete the device from ISY, factory reset, then reinstall it on ISY. Hopefully you don't have the device linked up to extensively. I have had this happen a couple of times. In one instance I had a light in my daughter's bedroom that somehow started controlling our breakfast room lights. Seeing as my daughter turning her bedroom light on was in no way an event that you would have any idea about in the breakfast room, we were very much wondering what was causing.

I have never had a PG2 node that was used in a scene. Always just programs. I assumed that when you deleted a PG2 node server that it would kill any scene associations, so you have confirmed that. Really need to figure a way to migrate to PG3 without having to do any reconfiguring.

Yes, if you use the same slot, the nodes will drop back in to programs and stuff as they were in PG2. You must delete the node in PG2 first, then create the node in PG3 using the same slot. If you restore from a PG2 backup into PG3, then it will bring over your node settings. I believe the best way to do this is. 1) Make a backup of PG2. 2) Delete from PG2 all of the nodes that are either free or you paid for in PG3 3) Restore the PG2 backup into PG3 (there is a button for that). PG3 will install from the backup nodes that are eligible based on payment or lack of need to pay. So any nodes that are free in PG3 that you have in your PG2 install, must be moved over using this technique. Otherwise, you will end up having the same free nodes both on PG2 and PG3 and then it is screwy.

No special receiver. Any dual band device is going to do that. The video shows version 1.05, which I had multiples of and all behaved exactly like the video. I don't know why newer versions would behave any differently, but I can't say having never owned any other version. Certainly the sending of an "on" when getting wet and an "off" when dried would never change.

Here is a video of adding a leak sensor and then confirming its function. If you do these things and don't get this result, then you may just have a bad leak sensor. I would start by deleting it from ISY, factory reset device, then add back to ISY as shown and test as shown. If ISY finds and writes to the device without leaving the 1011 message, then you do not have a communication issue. I can not really comment to much on the nature of the various batteries discussed. Mine worked fine with a regular alkaline aa battery from energizer.

I do something very similar with Elk outputs. Turn unused outputs on/off as "flags" or "binary variable" or "true/false state" "Boolean" logic or whatever you want to call them. I can't say I have ever done a blank program in ISY, but I do have a number with blank then/else clauses. For example, I have a program called "dark outside" that runs true at sunset and false at sunrise. You could have a blank "if" as well and use other programs to trigger a "run then"/"run else" to set the state, but I would just put whatever logic the other program was using directly into the "if" section. But perhaps you might have a system of organization where you wanted to keep the logic separate from the flag. EDIT: Also do it with unused outputs on my CAI webctontrol boards.

If I were to wager a guess, I would say enabling/disabling a program uses less resources than running a program, even a simple one. There is nothing to test, no logic to process, you're just setting a flag that says "ignore program". I'm pretty sure you could fill all of ISY's memory up with disabled programs and it wouldn't slow anything down, but I can't say for certain. Personally, I don't really see that either program format is better or worse than the other from a readability standpoint. The enable/disable style doesn't require any knowledge of ISY triggering rules which to an ISY newbie might make it easier. One minor flaw in the disable style is that if power goes off while one is disabled (after the lights have been turned on) and then restored after 11pm, the next day it will run the previous day's program again. Which if it just happened on the exact day in the spring or fall that you crossed that threshold time, your light would turn on at a very slightly wrong time. Unlikely to happen and even more importantly, wouldn't matter if it did in this application.

I remember that as well. Later I wrote probably the single most variable intensive set of programs ever to track time and date. ISY for a very long time had no way do something as simple as say "every May 18th". You had to go in and enter May 18 2022, May 18 2023, May 18 2024, etc. Or every other day, or on even days, or whatever.

Yes and no. I have no idea how resource intensive various tasks are for ISY, but the first solution only runs a single program each day. All other options run 2 programs each day.

You are speaking of things that have nothing to do with setting a state variable as either 1 or 0. You also haven't posted programs. Post the programs and I will show you how you don't need the 0/1 variable and in fact how they will be easier to follow.

No, you don't see it. It is a one to one relationship. Program true = Variable 1 Program false = Variable 0 Whatever the program is, the variable is the same. There is no need for the variable . . . EDIT: Go ahead and write a set of programs that you think need a Boolean state variable, and I will re-do it without the variable and the programs will have fewer lines of code, no variable, and will be easier to track back.