apostolakisl
Members-
Posts
6780 -
Joined
-
Last visited
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
apostolakisl's Achievements
-
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.
-
Multiple Partitions and Zone Connected to keypads Not showin
apostolakisl replied to apostolakisl's topic in EnvisaLink-DSC
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.
-
Multiple Partitions and Zone Connected to keypads Not showin
apostolakisl replied to apostolakisl's topic in EnvisaLink-DSC
@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". -
Multiple Partitions and Zone Connected to keypads Not showin
apostolakisl replied to apostolakisl's topic in EnvisaLink-DSC
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. -
Multiple Partitions and Zone Connected to keypads Not showin
apostolakisl replied to apostolakisl's topic in EnvisaLink-DSC
@Goose66 For whatever reason, it has started reporting last user now. The cleaning crew showed up and their code reported. Perhaps it doesn't report the user until the exit delay is finished. I armed and disarmed without allowing it to finish the exit delay when testing. I still can't say about reporting "ready". I also rebooted polisy so maybe that did something. However, there is one thing that is really important to a bunch of my programs that seems to be missing. And that is status "disarmed". Is there any chance this could be added? I suppose I could go through and put "not armed" and "not exit delay" and not "entry delay" and not so on but that is really sloppy. Since nodelink had "disarmed" I assume that is something that is reported. Nodelink also had a heartbeat which was very helpful for me to know if something was going wrong with the system or internet or whatever. EDIT: Actually, I don't think it would work right using the "not" statements. I get notifications when the system specifically becomes disarmed from an armed state as well as turning the water on and some other things. thx -
Multiple Partitions and Zone Connected to keypads Not showin
apostolakisl replied to apostolakisl's topic in EnvisaLink-DSC
@Goose66 Thank you for the response. I missed where it said I had to configure the number of partitions/zones. I didn't have to do that with nodelink and just assumed it pulled it down. I added those and it appears to be good. When I am back onsite I will see about the last user and the status going back to ready. Currently the system is armed and it says that. But it says 0 for the last user. -
CAI webcontrol boards can accept multiple 1 wire temp sensors and there is a node for that. I have a CAI webcontrol running some of the pumps on my pool and a 1-wire thermometer monitoring the pool temp.
-
I had ioguy's nodelink running great on a pc for many years. Well, I had an issue with that PC and had to redo it. I am not able to reinstall nodelink and it doesn't seem like anyone has the answer for how to reinstall nodelink now that ioguy has taken the downloads offline. Anyway, I had to shorten password to 6 characters and now it connects. However, I have two partitions setup and a zone connected to a keypad and neither of those are showing up. I know that they can be controlled/queried because nodelink worked with all of that. Does this node not have the capacity to see these things or do I need to do something? EDIT: Also using the command outputs. but am not have any success. There is an "activate" but no "deactivate". I need to be able to turn the toggle the output on and off. EDIT 2: OK, it looks like the button "activate output" toggles the output. But the status always says "active" once you have hit the button the first time and never changes after that. EDIT 3: Also, I have noticed that the partition state is not updating to "ready". For example, I armed the system, it changed to "exit delay", then I disarmed the system, and it continued to say "exit delay". I then opened a door and it changed to "not ready", I closed the door, and it still says "not ready". EDIT 4: Also not getting the last arming/disarming user. I armed then disarmed it from the keypad and it continue to say "0". @Goose66
-
I updated the node today and now I am getting an accurate percent on the battery.
-
I had a PC issue and had to redo the PC that was running nodelink. I never had any issues with nodelink and have 4 nodes on it and bunches of programs all integrated with those nodes. IOguy seems to have stopped supporting it. I copied my entire nodelink folder to a backup prior to reinstalling windows, but can't get it working after copying back to the redone pc. I was able to get a really old version of nodelink running but it is not linking to ISY properly. When I try to run the newer versions of nodelink I just get a flash of a cmd screen. I installed the latest .net from microsoft (.net 9.0 sdk). Anyone who could help me here with info on how to get this working I would much appreciate. I really don't want to go through the maze of programs and figure out how to redo it all and then debug it and so on. Below is what I get running the super old version of nodelink. It does link to the targets (DSC alarm panel, several webcontrol boards and the date program), but not to ISY. And I am using Polisy Thanks. 2025-01-12 14:30:45 - ISY NodeLink Server v0.9.34 started 2025-01-12 14:30:45 - OS: Microsoft Windows NT 10.0.19045.0 2025-01-12 14:30:45 - Web config server started (http://192.168.1.71:8090) 2025-01-12 14:30:47 - ISY Error: Web Error (FILE_NOT_FOUND) - Forbidden (profiles/family/10/profile/1/download/EDITOR/I_EDIT.XML) 2025-01-12 14:30:47 - ISY Error: Web Error (FILE_NOT_FOUND) - Forbidden (profiles/family/10/profile/1/download/NODEDEF/I_NDEFS.XML) 2025-01-12 14:30:47 - ISY Error: Web Error (FILE_NOT_FOUND) - Forbidden (profiles/family/10/profile/1/download/NLS/EN_US.TXT) 2025-01-12 14:30:47 - DSC: Repeater started on port 4025 [dsc1] 2025-01-12 14:30:47 - DSC: Connected to 192.168.2.141 [dsc1] 2025-01-12 14:30:47 - ISY Error: Web Error - NotFound (climate) 2025-01-12 14:30:47 - DSC: 5053CD[C][L] [dsc1] 2025-01-12 14:30:47 - DSC: 505 - Login Interaction (Password Requested) [dsc1] 2025-01-12 14:30:47 - DSC: EVL User Login - Password Sent [dsc1] 2025-01-12 14:30:47 - DSC: 5000052A[C][L]5051CB[C][L] [dsc1] 2025-01-12 14:30:47 - DSC: 500 - Command Acknowledge (005) [dsc1] 2025-01-12 14:30:47 - DSC: 505 - Login Interaction (Password Correct, Session Established) [dsc1] 2025-01-12 14:30:47 - DSC: Status Request Sent [dsc1] 2025-01-12 14:30:47 - DSC: Data Sent - 00191 [dsc1] 2025-01-12 14:30:47 - DSC TCP: Polling DSC [dsc1] 2025-01-12 14:30:47 - DSC: 50000126[C][L]61000128[C][L]60900231[C][L]6100032A[C][L]6100042B[C][L]6100052C[C][L]6100062D[C][L]60900736[C][L]6100082F[C][L]61000930[C][L]61001028[C][L]61001129[C][L]6100122A[C][L]6100132B[C][L]6100142C[C][L]6100152D[C][L]6100162E[C][L]6100172F[C][L]61001830[C][L]61001931[C][L]61002029[C][L]6100212A[C][L]6100222B[C][L]6100232C[C][L] [dsc1] 2025-01-12 14:30:47 - DSC: 500 - Command Acknowledge (001) [dsc1]