smorgasbord
Members-
Posts
131 -
Joined
-
Last visited
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
smorgasbord's Achievements
Experienced (4/6)
4
Reputation
-
Yes, but those can only appear in the program IF construct, not as branching lines inside a program. And as I pointed out in the first post here, that IF block is auto-executed when the parameters inside it change (assuming it's not all INTEGER variables). You can force an IF to be executed via the RunIf() call, but then you've got two programs running essentially simultaneously, not in a single execution thread. BTW, I'm not complaining about the programming model, just asking questions, gaining knowledge and pointing out differences with "standard" programming models. I suspect I'm not the first "regular" programmer to come into this world. The ISY/EISY programming model makes sense given Automation is almost always a set of things to do when triggered by an event (which could include a time event), so I understand why these choices were made. My only real complaint is that the program debugging tools could be better. You can see current values of STATE and INTEGER variables (but not on the same screen at the same time), and you can see which programs are currently running, and now with the Notification Polyglot plug-in you can at least get a rudimentary "printf" type output to track what was run and what the variables were at that time, but there's no step-thru debugger, call log stack, etc.
-
I just wanted to come back and clarify that I had the terminology backwards. That is "re-entrant" means the program restarts (re-enters?) when called again. So, the programming model is re-entrant and the behavior I quoted above is what happens. That said, there apparently is no call stack and everything called appears to run in its own context/instance/thread/process. So, for us old C programmers, calling a subroutine means that subroutine starts to run, but the calling routine also continues to run, so there are no guarantees which thing in which routine gets called first. So, this is somewhat like parallel programming.
-
Since I'm also using YoLink devices, I don't have a need for my old ISY994i. I suppose I should just sell it on eBay?
-
OK, I guess the question is now that I've got a new one from the Insteon folks, should I get my older one refurbished/rebuilt so that I have a spare for the future? I did get another serial one just to keep my cabling intact.
-
OK @paulbates, got my new PLM and installed it, following @Techman's instructions. Went smoothly. And so far, all my insteon devices are working. Which means that outlet I replaced and chewed up in the process was probably still good after all. Is there any reason to keep my defective serial 2413S PLM, or toss it out with the outdated 2412S?
-
OK, I just ordered a new PLM. I'll report back when I get it. Thanks!
-
So, I have an old, barely used, PLM that is pre-dual band. It's labeled as an EZICOMM 5010K and called a "Insteon RS232/RS485 Adapter", but on the back the label reads: 2233-233 V1.7 1225 Is this a good-enough PLM for me to try it out, following the replacement instructions? I think I'll lose whatever RF the 2413S has, but I've got other dual band devices in the house. Might be worth trying before ordering a new PLM completely, no?
-
OK, and in trying to decide which PLM version to get. Since I've already spent the money on the special serial cable for the EISY, should I get the serial PLM. Or is it worth digging up a USB cable and getting a USB version of the PLM? USB to serial converters are well-known technology and I've been using a serial to USB converter for another application for a couple decades now....
-
I'm confused now. One set of instructions is for ISY only, the other for both, sort-of, and weird: Unplug ISY from the power outlet Unplug the PLM from EISY/POLISY and power outlet Connect the EISY/POLISY to the new PLM Plug the new PLM into a power outlet Plug ISY into a power outlet I'm also in a different situation since my ISY is in my desk drawer and I'm running EISY on my old PLM - following steps 1, 3, 4 and then instead of 5, plugging in my EISY. I don't understand step 2 at all - was my ISY plugged in but not usuing the PLM? Why would I ever have both plugged in at the same time? This is suggesting I have both the ISY and EISY plugged in. And if that's really so, to which unit am I connecting via the Launcher? And I'm also confused on backing up the programming vs Restore PLM / Delete PLM when there's no Backup PLM. I'm not sure why I need my old ISY anymore to replace the PLM I'm already running EISY on (and mostly working, just some devices sometimes can't be communicated with). If it matters, my ISY is a ISY-994i/IR. It doesn't say "PRO" so I'm guessing it's not a PRO version. I am lucky in that right now I'm down to only one battery-powered device (a motion sensor). Everything else is hardwired. I recently removed a motion sensor, replacing it with a YoLink one. Again, sorry for my confusion.
-
OK, some final questions then From where should I order a new PLM - shop.insteon.com? My PLM is within 5' of the EISY, but I already have the proper cable. Is the USB PLM somehow better/future proofed than keeping the serial? I do have a backup from my ISY, but I've made major changes to the programming since then. I'm unsure as to the order of backing up and restoring, here's my best guess, using the Admin Console: Backup my current EISY programming Restore the last ISY programming to the EISY on the old PLM Backup the PLM to a file using the Admin Console Replace the PLM with the new one Restore the PLM from the file Restore the EISY programming Does that sound right?
-
I did the unplug/replug PLM, but note I did it when upgrading to the EISY also. This time when rebooting the EISY I got a different device as not connecting (an IOLinc, which is dual-band). Also, I almost never get the same problems - different units are reporting as not connecting at different start ups. Sometimes while running, too, iirc. I have an outdoor outlet that I use as my bridge, not an Access Point, sorry. I just did the 4 tap test on it and the PLM was blinking green only. Some of the devices reporting as missing as battery powered (motion sensors). The Admin Console has options for backing and restoring the PLM. I've never done that. Should I reset the PLM? Not sure how the EISY uses it or anything it might hold, settings-wise. Here's the back of my PLM,
-
smorgasbord started following Issues connecting with Insteon devices
-
Upgraded my ISY-994i to eisy and things mostly work. However, on reboot I often get some pop-up error messages in the Admin Console: Cannot communicate With <<name of the sensor (6-digit Insteon address)>>. Please check connections. This is an intermittent problem. It happens to both battery powered and wired devices, including dual-band devices. My home isn't large, I do have an Access Point setup to bridge the electrical. Could I have a bad PLM? It's several years old (2413S). I have an older EXICOMM 5010K that I think is actually 2412S. When I upgraded from ISY to EISY I followed the steps (used a new cable bought with the EISY) which did not involve backing up or restoring anything on the PLM. Am I right to suspect the PLM? If so, what's my best fix? There are new ones being sold somewhere, right? TIA
-
What's the procedure for when I've added/removed YoLink devices? Just restart from the Polyglot Dashboard and then reboot the EISY?
-
Need clarification on From/To program running after boot
smorgasbord replied to smorgasbord's topic in eisy
Yes, I understand that part, which is why I think of a program's "If" condition as a "When" condition. Instead of: "if a control is switched on," I think: "When a control is switched on." That help me, might or might not help others. What I was talking about, and have since figured out, is about how the execution/call stack works. Turns out the ISY/EISY does NOT have a stack. When a first program calls a second program, that second program starts and runs in its own "instance" or "context" (to use C programmer nomenclature). More importantly, the first program does not stop and wait for the second program to finish and "return" to the first program. Instead, both programs are now running simultaneously (or as close as the OS can support). BTW, using the Notification plug-in to send numerous notifications to my UD Mobile app revealed a lot to me about how programs run on the EISY. -
Motion sensors set to ON Commands only, and there are no programs looking for a "switched Off." I also have about a 5 minute time-out so the motion sensor isn't constantly sending commands.