MrBill

I labeled the one in use, but didn't label the others. I suspect the reason they have jacks on the back was a thought "it might be good for something, why not?" You don't login as root in FreeBSD... you login as a user, admin in our case and use sudo, which admin does have permission to use. You can also 'sudo su' which will start a shell with the login name root, but that's not commonly used, mostly 'sudo ____' is used for commands that require elevated permissions. The concept is to eliminate accounts named root, which tend to be targets for hacks.. that said... i think the button pushing updates will undo most changes you could make with sudo... the idea being ease of support... they can tell you push the button X times to return the machine to a known state. You must have a later model! ??

I don't know whether @Michel Kohanim will weigh in on this or not. Usually however computers with multiple Ethernet ports are used for bridging different networks. In residential installations this doesn't happen often, but it could. In commercial installations it's somewhat common for secured networks where one jack is the internet connection and the others have to route traffic through the device with multiple networks so that that device can limit traffic and/or inspect packets in some way. Perhaps the thinking for Polisy having multiple networks was so multiple networks for iot devices could exist. For example if someone had 230 wifi lightbulbs (say in a church maybe ?.. someplace with lots of chandlers) one of those ports might be used to plug in a separate wifi network that doesn't really need direct access to anything but the ISY. I suspect the real reason they exist was the network card interface was chosen for other reason and happened to have multiple network capability and the design decision was made: "why limit capability? it might be useful someday" Check back in 2026 and see if there's software implementing any of them ? It would be nice if they would have been labeled Primary Ethernet, Expansion Ethernet port B, Expansion Ethernet Port C

I don't use this type of heartbeat program, but I took a look at the cookbook programs, and I can't see where it would send normal status. What is the value of the state variable for that leak sensor? If it's 1 then I suspect the program that looks like the one below is missing a "NOT" for that sensor. I prefer a much simpler single program per sensor for Insteon Wireless device heartbeats.

It works, I think it's @Bumbershoot that used it to take the ISY to the z-wave device for programming, instead of bring the z-wave device to the ISY... maybe he can add how to do it. The wiki doesn't mention much.

The network module existed before the portal. At that time there was only one way to buy it. $49 one time fee. The portal is a renewable subscription (not a one time fee) at about $1/month (there are different payment options). "Mobilinc Connect" and "ISY Portal" are two competing portal products. "portal" allows connection from outside your local network without opening router ports. It provides a cloud address as an entry point to your ISY, and your ISY is making an outgoing connection to let you in from the outside. There can only be one portal connected to the ISY at a time. Mobilinc Pro, Mobilinc HD, Mobilinc X and UD mobile are apps that run on your phone. Mobilinc products, the apps and Connect, are produced by a 3rd party, not universal-devices. Mobilinc Apps can be used with the ISY portal, however with Mobilinc X I believe there is a fee for doing it that way. UD Mobile and ISY portal are both products of Universal-Devices. likely California, maybe Texas. Most of the grid doesn't share info from the electric meter to customers devices, but there are a few places.

I"m glad you posted. All I've been able to post was that I knew X10 wasn't working in early versions of IoP and that I didn't know if that was a bug that had been corrected or it was deprecated. glad you had the answer to this, for some unknown reason last week X10 kept being brought up.

Zen17: https://www.getzooz.com/zooz-zen17-universal-relay/ 2 relays and 2 inputs

Right click either outlet at pick “restore device” and let the ISY rewrite the links. You can also try factory resetting the device then use the same procedure to rewrite the links to the device, right click and pick “restore device” also try a 15 second delay. you can also overlap scenes. Scene b can have the remote in it to just control that half the outlet. Scene A can have both outlets, and the timing then only needs one program controlling one scene.

I give locative “always” access, it’s not a huge drain on the battery. I never notice Locative on the list of heavy battery users. There’s three ways to use Pushover. The old method, which is the wiki link you posted. There are also two polyglot node servers, one is called Push and it is simpler and I believe free under PG3. Then @JimboAutomates created another that’s more feature rich called Notification. As far as I know Notification is the only method that will retry on some error conditions. I’m at the end of a long Comcastic cable in a rural area, it’s not uncommon for me to have some packet loss.i used to send some of my notifications to myself 3-ways, email, text and pushover about 99% of the time I’d receive them all, but sometimes one would get lost. After jimbo created notification I was finally able to rely on one method. Notification does retry when my crappy internet connection doesn’t work right. Neither Push, nor the ISY using Network Resources retry—the post the message and if it didn’t go out it doesn’t go out. geofences we’re broken from the release of iOS 15 until like February. Like 5-6 months. It didn’t just effect Locative users, it effected all iOS users for about 5-6 months. But thankfully it’s been fixed for a couple months now. It was Apples fault, and no could understand why the bug wasn’t getting more attention. There are numerous threads in this forum covering the issue.

Think I answered your other post, no need to double post here. I believe they’re expecting the shipment in June. They had a surge in sales, due to Smarthome’s demise.

I believe Michel posted the shipment arrives in June. They had a surge in Sales due to the demise of Smarthome.

I believe that is the $9 module. Help -> About - will show your active modules.

I’ve never used pushsafer, so I can’t say. I Google pushsafer and what I got was priced in euro’s by volume. pushover has no recurring fee’s. Buy the app once and you’re done. 30 day free trial. It’s instant delivery. I can’t find any negatives.

interesting, I don't have an entry for X10 only:

Yea you're not supposed to be adding an EZXRF10... I see the links you're using now... I think that appeared when you bought the $9 module.

go farther away... and/or there's a slight delay. Mine are set on the map to be at the edge of the driveway... Leaving the notifications don't trigger until the end of the block... (800 feet farther than the end of the drive.) Coming its closer to the expectation, they trigger just about in front of the house. Note: early versions of IOS 15 had broken GeoFences. Make sure your IOS is up to date. make a program like this one: bill - [ID 00F3][Parent 00F2] If 'Home / Bill iPhone' Occupied is True Then Resource 'Pushover.EnterBill' Else Resource 'Pushover.ExitBill' Substitute Notify for network resources if need be. so that you will get notified when it trips and then go for a drive, and see what happens.

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.