MrBill

the current version of locative still works fine with the portal. I'm using it. out of date info. you don't need IFTTT --- it sounds like you have locative set up correctly if you are seeing Enter and Exit events in the portal. Have you restarted the admin console? It requires a restart after the portal node server adds nodes to the ISY. Do you see your portal Node server nodes? The look like this in the device tree: (white background because I'm not using the default admin console theme). in the admin console. "Home" is whatever you named the node in Step 4

It looks like a https://smartenit.com/ model number (starts with EZ...), however it's not a current product of theirs. a PLM has X10 capabilities, an ISY994 will use them, not sure about IoP. Also not sure what you're doing that gives you that message.

reply to your ticket with this info. It sounds like your ISY isn't coming up at all. what are the front lights doing?

I have no idea, perhaps @bpwwer can explain. looks like it's the same version number as PG3.

the Current Releases section of the forum has a post each time there is a new release. Except PG3 whose release announcements are for some weird reason down with the PG3 stuff.... Subscribe to current releases announcements and the PG3 thread to be notified when a release is released.:

On a 994, you can send X10 commands from programs without the $9 module. What the $9 module adds is the ability to add X10 devices as nodes to the Device Tree. I know X10 didn't work on IoP in early versions, I don't recall if that was a bug, or if X10 support was deprecated in IoP.

I have several insteon battery devices in unheated places. I use plain of alkaline batteries and they do just fine in Missouri winters (including feb 2021 when we had that week of -10 avg with a low of -26).

1 insert new SD card 2 format 3 load the 4.9 firmware 4 restore backup. By the way... use the wiki instead of manualslib https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Replacing/Formatting_an_SD_Card but yes i've complained about that wiki page before. the process is still the same, but it's a microSD card of up to 32gb instead of an SD card, the rest is correct. the IP address might have changed, not sure if you're managing that with an IP address reservation. Can you see in your router what the IP should be?

It's actually a network resource, that publishes to the Node server named "Notificiation". Notification in turn re-publishes the message to Pushover.net which sends Push notifications to phones. It's fine to use Notify instead. In the end tho Pushover is the fastest and most reliable. I've tried every which way possible on notifications. Pushover can also be used without the Node server middleman, we did it this way before node servers. Pushover service is a 30 day free trial and a one time $4.95 charge for the app, otherwise free. Network resources are tedious to create if you have lots of devices. I use an excel spreadsheet to concatenate text so that the "body" portion of the NR is just a paste. If you'd like it have a copy I'll send it to you. The thing that you have to remember is that as soon as the IF body is satisfied AGAIN the currently running copy of the program (that is sitting in "wait 25 hours" state) ceases to exist and a new copy of the program begins to run... that's alot of words to say "the wait restarts when a heartbeat arrives." The purpose of the "loop" or adding the "Run Program 'hb.FrontDoor' (Then Path)" as the last line is to add a repeating nag. In theory, the program never gets to that line... it only gets there when a heartbeat is missed. Normally, the first heartbeat arrives.. the program immediately begins waiting 24 hours. As long as the next heartbeat arrives during that wait... the first program vanish and a new one starts -or- the wait restarts. the only time the lines under the wait line come into play is when the wait expires, at which time we add one to the missed counter, bounce out a notification, and then loop back to the top of the then body, so that this program never stops. Prior to adding that line to the program what would happen is a door would miss a heartbeat and I'd be (occupied, not home, etc) and I'd forget about it.. eventually I'd discover the sensor has a dead battery so ultimately I added the missed counter and the loop so that it was impossible to forget. for the most part this works great, because the sensors quit sending heartbeats before they are completely out of battery. After the heartbeat stops the sensor will still send Open/Close or On/Off for the door itself for quite awhile actually.. so when heartbeats stop it's not a battery emergency...the sensor will still do it's job, but it's time to replace the battery before the battery is dead. (btw, I noticed when i scrolled up the heartbeat program has 24 hours in the wait... I don't know if I mentioned but with the surface sensors use 25 or 26 hours for the wait, 24 is too short for those.) In my setup, each battery sensor has 3 integer variables. Missed heartbeats, battery days, and total transmission count. All are reset when the battery is changed. at one point I combined missed heartbeats and battery days into one variable by adding 1 for missed heartbeat and adding 1000 the same variable for each day... so that 245002 as the value meant 245 days and 2 missed heartbeats, but since they are only integer variables and not state variables I simplified and just used 3 variables.

correct.

I heeded the warning on button groups screen that you provided a screen shot of and never used button groups, but i assume so. in the case of my front lights at least one scene is On at any given time, that may be a bad example. You could add multiple buttons as scene controller for the same scene (just answer no to the "___ is already a controller, do you want to add it as a responder" question, then set one of the buttons as Non-toggle on, and the other as non-toggle off.

Create scenes. For example, my outside lights operate using 4 scenes: Day, Evening, Late night, Bright Each scene contains the same devices, AND the KPL buttons for the other 3 scenes. The button to turn the scene ON is a controller, the other scene buttons are responders. Set the KPL buttons as "non-toggle On" When I press Bright for example the other 3 buttons will be turned off as the actual lighting devices are set for bright mode. ("day" is known as day and not known as off, because there's an outdoor outlet that turns on in the daytime.) Late night is a repeat of the above with the last node as the controller. (note: It's an admin console screenshot, just without the blue background.)

open a ticket: support@universal-devices.com

honestly if @ctviggen1 just updated the ISY he probably went to a Polisy... nonetheless... I wouldn't spend money upgrading a 994's 300 series controller to a 500 so that you can use 700 series devices, that doesn't make sense at this point in the game. If someone want to start adding z-wave literally every piece should be 700 series. Save all your upgrade money and buy a Polisy if possible with a 700 series controller board.

There is an 8 button S in existence. You can also change faces from 6 to 8. (there's a short button pressing experience to switch the KP body for the alternate face.)

Check ebay for insteon. prices for items like 2477D are coming down due to the flooded market, some of the specialty items are still running high tho.

If you've previously had portal connected to this ISY use Help > Manage modules to get your portal tab back. If you've never had a portal subscription, Use help Purchase Modules. I think it's a $1 charge to add portal. Polisy comes with a 2 year subscription to the portal, but it must be manually redeemed. What you can do is use https://my.isy.io to start a free 30 day trial subscription. After that email support@universal-devices.com including your UUID number and tell then you have a new Polisy and need the 2 year subscription added. they will manually adjust the end date of your subscription.

@ARyder01 the reply by @DennisC just made me realize the problem here. Your My programs folder has a RED stripe. That tells me you have a FOLDER condition enabled on that folder. If a folder condition is False (yours is because it's RED, not GREEN) nothing below that in the tree will work. Even when run manually like @DennisC suggests. Folder conditions are unlike Program conditions in that anything below a false folder condition will never be seen, even if run manually or run by another program. I'd recommend staying away from folder conditions at the beginner and intermediate level, wait until you're really good at programming to use. They trip a lot of people up.

I didn't see this above, but it could be there because I just quickly scanned. The PLM must be powered up and connected before Polisy is booted or it will not be detected. Plug the PLM in wait at least 30 seconds for it to boot, make sure there is a solid green light... then start Polisy up.

Programs are always running. The IF statement will CONSTANTLY be evaluated to either True of False. The instant an IF statement becomes True it will begin to run the THEN statement, conversely the instant the IF statement becomes False it will begin to run the Else statement. Will and IF or then get interrupted while it's running? If it has a wait then yes it's possible the if statement will never complete. Consider this hypothetical program If Motion detector status is on Then Turn on light Wait 10 minutes Turn off light Else Nothing If the status of the motion detector becomes Off during the 10 minutes wait, the light never turns off, because the wait was interrupted. ------ If Motion detector status is on Then Turn on light Wait 10 minutes Turn off light Else Turn off light in this case we added turn off light to the else. If the motion detector turns off during the 10 minutes wait the iff will become false and the light will immediately turn off because of the else, or it will turn off after 10 minutes if motion is still on. -- The above is a bad example, because most of the motion sensors we use don't work exactly like that, and we'd use a different trigger called "Control" rather than "status" in a real motion sensor program. Control is a trigger, and senses the on or off state but doesn't reverse it's state. -- Programs such as schedules, are true during the scheduled period and false outside the scheduled period. If From Sunset to Sunrise (next day) then turn on porch light else turn off porch light --- There's also methods to ensure the program always completes even if the status of the if changes. Re-using the first example: Program ONE If Motion detector status is on Then Run Program TWO (then) Else (nothing) -- Program TWO if (blank) then disable Program ONE Turn on light Wait 10 minutes Turn off light enable Program ONE Else Nothing Using a method such as this allows the program to complete even if the status changes. So in summary, yes programs are always running and the IF is always being evaluated. If the program is paused by a wait statement, it's possible the program never completes.

Try deleting these temp files and see if that resolves your issue, probably just the 2nd and/or 3rd would do it, I usually just search udi_* in that Temp directory and nuke em all. find the following files in Java temp directory (on Windows: c:\Users\[Username]\AppData\Local\Temp) and delete them. Or, you can simply search the computer for udi_*.* file patterns: udi_tree.state udi_frame.state udi_pgm.state udi_finder.state udi_launcher.state

What is Catlight-Off Power Switch? Do you see it changing on the "Main" device tree as the state changes? You likely want "control" instead of "status", but status should work if the status is actually changing.

Open the Event Viewer window and set the dropdown to level 3. Also post the specific sensor you're dealing with, somone may have more info. You can sell them used on ebay for more than you paid at the moment.

@ISY4Me Disclaimer: I did quit reading a few posts ago, but if you have any 1011 icons to the left of any battery powered devices. Deal with that. It causes problems. @larryllix did mention it in his second reply. Unwritten instructions to battery devices reek havok on insteon communications, because the ISY keeps trying.

Probably copied from one of my examples. I like to restart the Then, so that if i don't deal with it today I'll get reminded tomorrow if the issue still exists. If it doesn't still exist (i.e. new heartbeat received) that resets the clock again and kills the nag. Some of my 2421's are horrible about dropping heartbeats.