apostolakisl

But it is. @MrBill has an experience that I have also seen and I have seen it on this forum elsewhere. I suspect that the rf and PLC feed the same processor and noise on the PLC overwhelms and crashes it. Kind of like a DOS attack. I would be interested to know what happens if @MrBill uses a device that is on the problem phase that is linked to a device on the non-problem phase. Assuming the issue is overwhelmed processing of the input, then output should be unaffected and radio from the device on the noisy phase should still control a device not overwhelmed by bad input on the non-noisy phase. Then test the opposite.

It isn't hard to prove a device is working on RF. Like many of us here, I have a bench test jig for my Insteon devices and it plugs into the wall. What I have done is plug it into a UPS that is itself unplugged and you now know if the device communicates, it must be by rf. And indeed, I have discovered a dead radio on a PLM that I recapped. No idea if I caused it when doing the recap or if it was unrelated. But anyway, 75 dual band devices, you can be pretty confident that unless the house is massive and the devices are all spread out, that the devices are, by and large, all in radio range.

@ase I agree, I had also expected that should SH go bankrupt, that it would be bought out of bankruptcy. It has to be, the protocol is not worthless and there are creditors that demand to get as much money back as possible. My hopes would be the following: 1) They do not abandon the current line. The backend hardware of the devices can be changed, but the look and feel of the current devices should stay, at least as an option. There are too many people out there who already have their homes filled with these devices who aren't going to want a mishmash of aesthetic looks. Furthermore, the current design blends very well with standard decora switches so you don't need to go 100% HA yet maintain a consistent look. 2) I would like to see them license. I think that licensing will ultimately bring about a bunch of new and exciting products. No matter how clever and imaginative the people at Insteon are, when you open up the protocol to the whole world, smart and creative people will start coming out of the woodwork with ideas that no one else ever considered. But I would like to see it done very carefully with a lot of testing requirements for the products. I don't want to see the protocol reputation diluted by a bunch of junk. In addition, licensing is a good way to increase cash flow with minimal increase in overhead. 3) I would like to see firmware upgradeable devices. The current devices appear to be upgradeable should you open them up and connect to the pads. Obviously they would never sanction that for an end user, but if they released the code as part of a way to program a new design, you probably could hack-it and upgrade the older devices. For new devices, it might be that you remove the faceplate and then there is a usb jack for flashing new firmware. I would rather not see any method that can be done over PLC or radio as it would be security threat. 4) Consider dropping the PLC, or at least allow it to be turned off. It is hard to know for sure, but I think noise on the power lines can drown out the radio signal. It seems that the radio and PLC share some internal processing and when there is noise it overwhelms the processor so that the radio comm is lost as well. It seems that the radio protocol is quite robust all on its own and that PLC is more legacy than anything. 5) Bring back all the specialty items. These are the items that have minimal sales, but land you the whole package. You might pick the Insteon protocol because it can integrate that unique device that no one else can, and then you buy 100 light switches. Certainly that worked for me, and I am guarding my io lincs, fan lincs, water sensors, and the like since I am not sure I will ever see new ones of those again. 6) And finally, for God's sake, embrace UD. The ISY controller is the only reason Insteon got as far as it did under the old management. I promise you, I would have dumped Insteon after my first purchase but for the ISY and I don't think I am unique in this at all.

sounds like you have 3 phase 120/208 which is very common in the US for light commercial. In other words, connect any of the 3 hots to neutral and you get 120v, cross any two hots and you get 208. Anyway, this power source is 100% compatible with USA rated items, assuming 60hz. Both my office and my church have this power configuration and I have Insteon at both locations. Most of the power is 120v, but we also have 3 phase AC units and single phase 208 to water heaters and such.

Not sure where the OP is, but in Europe at least, the 240v is single phase, not split phase. Interestingly, I just learned that in Europe on construction sites they do split phase 110v (two 180 degree legs of 55v). The 55v is generally too little voltage to get through skin and thus lowers risk of electrocution/injury at wet outdoor work sites. But it means they need 110v tools even though they won't work without the special work-site transformer. So anyway, it would seem to be that he needs a 240v to 120v transformer and would presumably then rely on radio for the PLM to work. I doubt the PLC works through a transformer.

I would say leave it alone. If you have the second gen dual band Insteon devices, they tend to last. And if you put high quality caps in your PLM, it is probably good for a long time as well. Might keep your eyes open for any good deals on used stuff as spares. But I am leaving my system alone, I have plenty of spares. Plus, I suspect someone will buy the Insteon technology sometime in the not too distant future and continue the product line.

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.

None of what you say has anything to do with the logic of your program. You are using time conditions to set a state variable. 100% of the time, the variable will match the true/false state of the program. Except on a power outage in which case your variable could be wrong whereas the program will be correct. The state-variable will be in the exact same state as the true/false status of the program. End of story. It is fully redundant. It is also a triggering event, the same as the state variable. It is a one-to-one copy. It would be no different than having 2 or 3 or 10 variables that are just copies of the fist one. I don't know how else to say this. All this stuff about what if the lights change or whatever is not setting the variable. That has nothing to do with it.

?? Seriously, that is your defense of your logic?