apostolakisl

I would hold your horses here. I suspect you will see a lot of rapid developments in the days and weeks to come. Most of these tariffs will not last long, some may, but I think most won't. Deals will be struck. I wouldn't be surprised if a few of the tariffs stick, just to make examples of somebody, but I doubt it will be Canada. EDIT: Speak of the devil. The Mexico tariff just got settled, at least for a while, but probably long term.

<profiles> <profile family="10" id="3"> <files dir="editor"> <file name="portedit.xml"/> <file name="PORTEDIT.XML"/> </files> <files dir="nls"> <file name="EN_US.TXT"/> <file name="en_us.txt"/> </files> <files dir="nodedef"> <file name="portndef.xml"/> <file name="PORTNDEF.XML"/> </files> </profile> <profile family="10" id="4"> <files dir="nodedef"> <file name="nodedefs.xml"/> </files> <files dir="editor"> <file name="editors.xml"/> </files> <files dir="nls"> <file name="en_us.txt"/> </files> </profile> <profile family="10" id="5"> <files dir="editor"> <file name="custom.xml"/> <file name="editors.xml"/> </files> <files dir="nodedef"> <file name="nodedefs.xml"/> <file name="custom.xml"/> </files> <files dir="nls"> <file name="en_us.txt"/> </files> </profile> <profile family="10" id="6"> <files dir="nodedef"> <file name="nodedefs.xml"/> </files> <files dir="nls"> <file name="en_us.txt"/> </files> <files dir="editor"> <file name="editors.xml"/> </files> </profile> <profile family="10" id="7"> <files dir="editor"> <file name="editors.xml"/> </files> <files dir="nls"> <file name="en_us.txt"/> </files> <files dir="nodedef"> <file name="nodedefs.xml"/> </files> </profile> <profile family="10" id="8"> <files dir="nodedef"> <file name="nodedefs.xml"/> </files> <files dir="editor"> <file name="editors.xml"/> </files> <files dir="nls"> <file name="en_us.txt"/> </files> </profile> <profile family="10" id="9"> <files dir="nodedef"> <file name="nodedef.xml"/> </files> <files dir="editor"> <file name="editors.xml"/> </files> <files dir="nls"> <file name="en_us.txt"/> </files> </profile> <profile family="10" id="10"> <files dir="editor"> <file name="editors.xml"/> </files> <files dir="nodedef"> <file name="nodedefs.xml"/> </files> <files dir="nls"> <file name="en_us.txt"/> </files> </profile> <profile family="10" id="11"> <files dir="editor"> <file name="udmobile.xml"/> <file name="editors.xml"/> <file name="custom.xml"/> </files> <files dir="nls"> <file name="en_us.txt"/> </files> <files dir="nodedef"> <file name="nodedefs.xml"/> </files> </profile> <profile family="10" id="12"> <files dir="editor"> <file name="editors.xml"/> </files> <files dir="nls"> <file name="en_us.txt"/> </files> <files dir="nodedef"> <file name="nodedefs.xml"/> </files> </profile> <profile family="10" id="14"> <files dir="editor"> <file name="editors.xml"/> </files> <files dir="nodedef"> <file name="nodedefs.xml"/> </files> <files dir="nls"> <file name="en_us.txt"/> </files> </profile> <profile family="10" id="15"> <files dir="nls"> <file name="en_us.txt"/> </files> <files dir="editor"> <file name="editors.xml"/> </files> <files dir="nodedef"> <file name="nodedefs.xml"/> </files> </profile> <profile family="10" id="16"> <files dir="nodedef"> <file name="nodedefs.xml"/> </files> <files dir="editor"> <file name="custom.xml"/> <file name="editors.xml"/> </files> <files dir="nls"> <file name="en_us.txt"/> </files> </profile> <profile family="10" id="18"> <files dir="nodedef"> <file name="nodedefs.xml"/> </files> <files dir="editor"> <file name="editors.xml"/> </files> <files dir="nls"> <file name="en_us.txt"/> </files> </profile> <profile family="10" id="19"> <files dir="nls"> <file name="en_us.txt"/> </files> <files dir="editor"> <file name="editors.xml"/> </files> <files dir="nodedef"> <file name="nodedefs.xml"/> </files> </profile> <profile family="10" id="20"> <files dir="editor"> <file name="editors.xml"/> </files> <files dir="nodedef"> <file name="devices.xml"/> <file name="nodedefs.xml"/> </files> <files dir="nls"> <file name="en_us.txt"/> </files> </profile> <profile family="10" id="21"> <files dir="nls"> <file name="en_us.txt"/> </files> <files dir="editor"> <file name="editors.xml"/> </files> <files dir="nodedef"> <file name="nodedefs.xml"/> </files> </profile> <profile family="10" id="23"> <files dir="nls"> <file name="en_us.txt"/> </files> <files dir="nodedef"> <file name="nodedef.xml"/> </files> <files dir="editor"> <file name="editors.xml"/> </files> </profile> <profile family="10" id="24"> <files dir="nls"> <file name="en_us.txt"/> </files> <files dir="nodedef"> <file name="nodedefs.xml"/> </files> <files dir="editor"> <file name="editors.xml"/> </files> </profile> </profiles>

I sync'd already. It is webcontrol832 on PG3x. I had it sync'd to ioguys nodelink node for the webcontrol board but had to switch since that is not supported anymore. It worked fine with that node server.

What does this mean? Trying to set up to have a different icon depending on the state of the node. The display node is a PG3x node tracking the status of an output on my webcontrol board. When I click the icon, it runs a program that sets the state of several webcontrol outputs and displays the value of one particular output.

For lease. I guess they moved to a new secret lair.

You can run polyglot locally.

If you have orphan links, you may need to factory reset everything and start over. Or just ignore the orphan links if they cause you no trouble. Orphan links can be on the pLM only in which case restoring from ISY will clear them, but I have had orphan links that were in the ISY database. Many years ago I deleted everything and started from scratch and haven't had any issues since. But I have a lot more stuff now than I had then. 70 devices is a lot of devices to redo from scratch. And you would have to redo programs as well.

Oh man . .. I just spent a good bit of effort converting over to PG3 DSC and CAI webcontrol. I thought you had "retired" from this arena. The pg3x node for webcontrol worked out of the box, but I had to work with the DSC node author to get it to do what your node was doing. I had been running on a pc and I had an issue with the pc and needed to redo it. But I couldn't get nodelink to work after doing the pc redo. I would still love to have the nodelink files for pc if you could post them on a g-drive or something. Thx.

What device wouldn't go into linking mode? I have not heard of that ever being an issue short of the device being completely dead.

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?

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