apostolakisl

Sadly, since nodelink is no longer supported and I can't get it to work on a pc refresh, I will be permanently removing it from ISY. What is the best way to do this? I believe it would be best to go to plugins/configure/01-20/01-islyink and open that window. And then delete it. I believe I will also need to go the nodes in the node tree and delete them there as well. Is this the correct process to ensure a clean removal? Thx.

If you can read a links table from the plm then you must have a proper com between it and ISY. So either the PLM is broken and can't communicate or all of your links are corrupt. With only 20 devices a links table of 115 seems like a number that is probably in range. Depends on how many scenes you have. If you have an extra device, something easy like a lamplinc that you can just plug in would be great. Anyway, power it up and see if you can add it to ISY. Put ISY into linking mode (push the double arrow swirly button at the top of the admin console) and then push/hold the set button on the device until it goes into linking mode. Since we have established that the plm and eisy are communicating, If it doesn't pop up on your screen, then the device is not communicating with the PLM. In summary, I would try a new plm. Plug it into eisy and do a "restore plm". Alternatively, you could do a factory reset on your current plm and then do a "restore plm". If memory serves, I believe you unplug the plm, let it fully power down, push/hold the set button while plugging it back in and keep holding until it does some beeping, maybe 15 seconds or something. If forget. I would also suggest a backup before messing around with any of this. Also, If you have newer switches that are part of a scene, when you press the switch to activate the scene, I am pretty sure it will blink the red led if it fails to talk to the PLM. I forget for sure all the reasons it blinks red, but I think that is one of them.

Red exclamation marks will only ever be next to devices, not programs, and it would be under the "main" tab, not the "program" tab. It means ISY failed to communicate with the device. If every device has this, then there is an issue with your PLM. I guess you ran diagnostics and did a "PLM Links Table" to get your count. 115 isn't a very big count, roughly how many Insteon devices and scenes do you have? If you haven't run a PLM links table, I would do so. This will read the links off of your PLM which will tell you for sure that your EISY is connected and that the PLM has actual links on it. You can try running a device links table and pick one of your devices. This will go out out to the device and read the links that are currently written to it. This may totally fail in your case since it seems nothing will communicate, but you can try. You can compare that to the links table that ISY expects to be there if it does read. The results of doing these things may help isolate the problem.

I would double the recommendation to put a dual band device (like a lamplinc) at the gate to increase the robustness of the Insteon signal. I do that for an old single band Insteon Synchrolinc that I don't really have a good alternative for (it keeps track of my washing machine so I know when it has finished). Alternatively, put a device out there that uses IP. I use webcontrol boards to do a lot of IO stuff and PG3 has a free plugin in for that. The only issue with webcontrol is that they are not wifi, so you either need to have ethernet run out there or you need a wifi to ethernet adapter. An example of what I use a webcontrol board is to run pool pumps. I also use it to track the pool water temp and air temp as it has 1-wire interface. But I have an ethernet wire run to my pool control area.

Would the Matter dongle be like a PLM for Matter devices? Accepting input from Matter devices and then "modeming" it into a language that ISY can accept. But not including any node formatting, such that UD would have to have programmed into ISY or into the dongle what all the various outputs messages mean. For example, ISY only knows how to populate all the nodes for an Insteon thermostat because UD programmed ISY to specifically accept that thermostat. Many of us remember when Insteon released the new motion sensor and didn't release any documentation and we all had to wait until UD was able to reverse engineer it so that ISY could create the node. Or, would the Matter protocol be standardized with a labeling language that describes all sorts of functionality generically covering everything. Such that anyone could create a device, follow the Matter protocol, and then ISY with the Matter dongle could recognize the device and tell ISY how to populate the node even if no one at UD had ever even heard of the device. Seems like it would have to be the latter since there could in the end by thousands or even 10's of thousands of Matter enabled devices out there. If UD had to set the details for each device, I don't see where this is much different than how it currently is using PG3.

Not what I mean. I mean, do you just enroll the device and then the node pops up, properly populated and functioning, no node server (PG3) required. As with an Insteon device.

theoretically, does a matter enabled ISY and a matter enabled device, natively integrate? Like an Insteon or Z-wave switch would?

I was looking at the new Honeywell x2s thermostat which is Matter enabled. Not sure how matter integrates into the ISY, but will this mean it is just plug and play?

Upon arming the system it did indeed register correctly. So I think I should be in business. I will have to give it a try now reverting back to a single program and eliminating the variable which I feel comfortable should work. Thx.

Just looking at stuff here. Nodelink monitored the dsc system but had everything as a status, no control values at all. Not sure how this all works with nodes, certainly understand with Insteon as it is part of the protocol, but when it comes to Envisalink or I suppose other 3rd part nodes, is this just a call on the person writing the node as to how to categorize the data it receives from the monitored device (Envisalink)?

"Partition disarmed" executed this morning correctly. This afternoon I will be able to tell if you "partition armed" executes correctly. System "ready" / "not ready" is showing appropriately as well on the partition with non-alarm zones. So far, looking good.

I installed it. I see control partition armed/disarmed. Is that the only change? Partition armed refers to armed stay or away?

Yes, control armed and control disarmed will totally solve my problem and will work using the else clause and will allow me to dump the variables as well as the programs that set the variables and have the action taken directly in the same program that monitors the alarm state. I believe that will take me back to how I had it running with nodelink. if system is switched armed or systme is not switched disarmed Then run if program for armed system Else run if program for disarmed system While ISY logic doesn't lend itself to a lot of "else" use, I manage to use quite a lot with great success. I use it tons in the following: "If device a is control switched on or device a is not control switched off." To allow a "then" and "else" to mirror actions taken at the switch in a single program. But I find other uses for it as well. It is a bit of fun with logic exercise to get it working. IF you need to put a beta for testing, I can install and test for you. Thank you.

What does "alarm triggered" even mean? I am trying to keep this simple so I don't get all twisted about in the future when I might need to make changes. Originally this all worked with 1 program and no variables. I think this will work to keep it down to one program running the variable where "1" indicates the system is armed. Perhaps I can ditch the variable, but I worry about the status armed away since all kinds of other states exist on that variable that will trigger this program when they change. MDPA Armed State Copy - [ID 011C][Parent 0177] If 'DSC PG3 / Keypad MDPA' is switched Alarm Restored Or 'DSC PG3 / Keypad MDPA' Partition State is not Armed Away Then $sDSC.MDPA.Armed.State = 0 Else $sDSC.MDPA.Armed.State = 1

I need to run the Else clause when armed. So what would you suggested for the "if" clause for that. "Triggered" is the other option, but I don't know what "triggered" means. "Is If 'DSC PG3 / Keypad MDPA' is switched Alarm Restored And 'DSC PG3 / Keypad MDPA' is not switched Alarm Triggered Then <Partition has been disarmed> Else <partition has been armed> Or perhaps mix and match status with control? If 'DSC PG3 / Keypad MDPA' is switched Alarm Restored And 'DSC PG3 / Keypad MDPA' is not armed away Then <Partition has been disarmed> Else <partition has been armed> I'm afraid any status change in the alarm will trigger the second program to run. That might be fine, I'd have to think about it. Maybe if I have to make it two programs?

The superfast and easy way to do it would be to plug an insteon lamp linc or any powered insteon device into the power and set an ISY program to query it every minute or whatever you like and if the query fails to send you a notification. @Guy Lavoie His idea of using an electromagnet and an Insteon open/close sensor was going to be my next suggestion until I saw he already posted it. You would get a near instant report of power outage that way. There are also lots of other ways as well. For example, I use wireless tags to monitor temps. If you use powered tags you can check them for going offline. I do this to make sure I haven't lost power to walkin fridge/freezer at my church. I have programs that check if the wireless tag goes more than a minute without a change to either the temp or humidity. Both of these change by at least .1 each update so if they don't change at all I know something is up. Both of these solutions of course require that your ISY and your routers/switches/internet keep working when power is lost.

Something must be wrong with your account. I opened a ticket last week and got a response in a few hours. We went back and forth four or five times in the next 24hours solving the problem and discussing a few other things. Benoit answered my ticket. @bmercier

I feel like you have a corrupt PLM and or corrupt links table in your ISY. Again, run the diagnostics on the PLM scene table. For example, I have 571 links on PLM with a good sized Insteon install. It sounds like you should have a similar number. I don't know how ISY would ever get a corrupted links table, but perhaps @Geddy remarks apply? I don't know, I have had ISY since the original 99i all the way through to now and never had ISY corrupt the links table. If you run diagnostics/links table on a single device, then hit the "compare" button, it will first read the actual links on the device, then compare to what ISY thinks should be on the device. They should match. If not, then either ISY has corrupt links database or the device does (or I suppose both could). If the scene works correctly when not controlled by ISY, then ISY would presumably have the corrupt tables. So, restoring the PLM from ISY would just be putting wrong links on the PLM. In which case, restoring an older backup of ISY from when it did work may be warranted. After restoring ISY, you would then restore the PLM from ISY which should put the proper links back to the PLM. I would not start restoring individual devices assuming the scene works when not going through ISY. You get an OK, because that is Echo telling you it talked to ISY successfully. It is not telling you that ISY talked to the PLM successfully. ISY could be communicating with the PLM fine, but if the links are corrupt in the PLM, it won't work. ISY never gets reported back device status from a scene. ISY ASSUMES the status of the devices after a scene event, regardless of whether ISY or another Insteon device triggered the scene. If you trigger a scene from outside of ISY, the scene command goes out over the network, the PLM receives that message and reports it to ISY. ISY has a copy of the links table and knows what SHOULD HAVE HAPPENED, and changes the status of all the devices to what should have happened, whether it did actually happen or not. When a scene is triggered, Insteon protocol does not allow for each device in the scene to report a status (ACK). Presumably because you would have a flood of traffic all at once. This is different from a single device. When you control a single device, the device does report (ACK) its status and ISY will update the status according to what the device actually said it did, not what ISY assumed it would do. If ISY sends out a single device command and ISY does not get an ACK, it will show the device as "failure to communicate". You will not ever get a "failure to communicate" when running a scene.

I would factory reset your new PLM, then restore from ISY. You can also check your PLM links table and compare it to the ISY links table. Under tools/diagnostics.

I assume when you say you lost your scenes, you mean that they aren't working when initiated from ISY. I have never heard of an entire Insteon install losing its scenes. By that I mean, if you have a scene linking say 4 Insteon devices together, then using one of those 4 devices to control the scene would still work regardless of ISY or the PLM. Scenes aren't native to ISY, they are native to Insteon. You could unplug ISY and your Insteon scenes would still all work between Insteon devices. A device, like ISY, when connected to a PLM becomes a defacto Insteon device. When you use ISY to create/modify a scene, ISY tells the PLM what you want and then the PLM creates all the Insteon links on all of the Insteon devices involved. The PLM ends up being a member of every scene. ISY is just the "boss" telling the PLM what to do, but the PLM is what actually does it. So suspect you have a PLM issue, not an ISY issue. ISY lets you restore all of the data that was on the PLM should your PLM die. This should put your ISY right back to normal.

try downloading the java uninstaller and completely remove java. then install fresh making sure you get the version talked about above. Java is just a PITA in my opinion. Can't wait for Benoit to get the web interface running.

It would be real nice if the "disarmed" output from envisalink was run through even if it is immediately followed by a status such as ready or not ready. I have it working by using a variable. But the main issue and I sent you a PM, is that the "ready" state is never happening on partition 1. It always shows whatever immediately proceeded the ready state. Regarding heartbeat. I am accostomed to that showing as alternating 1 and -1 and use a program that runs continuously in with a wait that gets reset by the value changing. How is this working? I see "panel connected" in the programming, is that just always 1 when connected and not really a "heartbeat" in the sense of a "beat" between 1 and -1?

When you say "it didn't work" what do you mean? If your browser gave you the security warning, that means it connected to something. I connect to my PG3x using lan ip address port 3000.

@Goose66 Still having issues with system status not updating. System was armed, my staff came in at 7:09 and it updated to entry delay. They disarmed but that did not register in the node. Logged into envisalink and it showed system ready. Restarted the node but it still shows entry delay. Not sure how the node is supposed to get updated but it sometimes fails. I never experienced that with nodelink so I don't think it has anything to do with envisalink or my panel. Using a variable to track armed states I seem to have worked out "disarmed" as a trigger, but only if the node accurately tracks system state. The water supply turns on when the system disarms via isy. This did not happen. The node showed the zone that tracks valve status as closed. I manually triggered the cmd output that opens the valve and the node registered the zone change. But still it shows entry delay. Edit. Just now another person entered the office and the node switched to not ready but never switched to ready after the door closed. Envisalink shows ready. So it seems like perhaps the node is not recognizing ready. OF NOTE: In that partition, I have several zones that are not alarm zones. Not sure if that would have anything to do with it. But of course DSC is programmed to know those are not alarm zones so it shows "ready" despite those zones being open. I kind of doubt this has anything to do with it since those zones were violated while the node said "entry delay" but envisalink showed "ready". Also of note: partition 2 does report "ready". To the best of my knowledge, partition 1 has never reported "ready".

Thanks for that. Not sure I want to do this as I am already using pgm outputs for other things. Since nodelink had right in the node server "disarmed" it seems like that should be something that the pg3 node can do as well. The disarmed item in nodelink worked perfectly for 12 years now. I just have a whole bunch of things that triggered on the system becoming disarmed. I tried "not armed away", but that didn't work because it didn't trigger on disarming, it triggered on entry delay. And putting two lines in there for "not armed away" and "not entry delay" doesn't work because many of my programs also run an else clause which would falsely trigger. I guess I may be able to make a state variable and use that to track disarmed vs armed status and use that to trigger the programs. But I would really prefer "disarmed" like nodelink.