MrBill

@dalter2 Here's a post Michel made awhile back that better puts this into perspective:

mms.att.net does have it's bad moments, recently it's been good but every now and then there will be weird 4-12 hour delays. As a result I usually send important messages via more than one service. The other method above using policy is to use the service Pushover. there are two (that I know of) nodeservers for that service, on is "Push" the other is "Notification". You can also use Network Resources to send messages via Pushover. Pushover is basically instantaneous most of the time, when I go out to get the mail my watch taps my wrist with the mailbox notification before the mailbox is even fully open. It's not perfect either tho, I've had very few messages that went missing, normally when I think to look at the ISY error log it's an https timeout on the pushover API (the wiki suggests 2000ms for timeout, IIRC mine are set at 4000ms for the network resource originated messages (which are still most of mine because they pre-date Polisy and I've never moved them). What is Pushover? Basically a service that lets you send push notifications to your phone via an API. The only fee they charge for small individual users is the one-time download of the app. (there is a free trial.)

the cost of a portal subscription isn't listed at @DennisC link... but it's very minimal, basically $1.00/month. $23.00/First Two Years $12.00/Year thereafter

are both devices are in the root folder? Maybe it's just the way i'm reading your wording too but if you're on the new device choosing "replace device" that's backward. You want to choose replace device on the OLD device and select the new device. and as per the question above, both devices must be in the top or root folder and not in any folders you created for grouping.

I have all insteon, no-z-wave... if I had to make the "what to start with" decision over again today I would seriously consider Lutron Caseta and/or Caseta Pro. I actually kind of dislike the look of caseta switches tho, they also have a limit on number of devices that I would need to evaluate. There's also Lutron RadioRA I'd have to think about. I like Insteon a lot but I also am one that believes they don't understand the market they are in, and because of that I worry about longevity. I don't like z-wave for lighting because you can't group things to operate at the same time. Those are my thoughts, but I've not researched other options because I have Insteon for literally everything except the garbage disposal.

I agree this happens... I almost now wish for a bigger file tho, the history available in mine is less than 24 hours meaning that if I want to look anything up I've gotta be on top of the situation. I don't use that log alot but it has come in handy in the last week figuring out why a light was randomly turning on (which is how I happen to know that mine only has 16-20 hours of information available now).

That's nodeserver specific and kind of a user preference too... I don't use that nodeserver, so I'll let @bpwwer give you better guidance since he wrote it. I just had a feeling when I read your post and his response that there was a disconnect about WHICH log was being spoken of....

If this statement is true, you have more programs than the ISY is designed to handle, which is 1024. I don't know what happans when you hit this limit. I do know that when you hit the node limit between non-pro and pro, someone has to guess that's the problem because there isn't a hard discrete error message stating it's time to upgrade.

@jukeman do you mean the nodeserver log, or the admin console log: Tools > Log ? Node servers certainly do blast alot of information into the ISY log, mines currently > 61k rows and covers less than 24 hours. If this is the log file you mean you'd need to slow down updates from the node server to slow the logfile buildup.

Use 10digitnum@mms.att.net instead. It’s not immune from delays either, but is usually better. As an added it benefit your messages arrive from your email address as opposed to the weird numbers .txt uses, also the Max message length is 1024 instead of breaking messages up.

I saw another v2.6 reference the other day... Just replying so I can tag @Brian H to make sure he saw too since he's our resident PLM repair expert.

I don't think your understanding Line noise and Signal suckers yet. It's not the copper wire. Some brands of bulbs and transformers generate specific powerline noise that blocks the signal. Other devices suck or absorb signal so that it can't make it to other parts of a circuit. Here's a wiki article of troubleshooting Insteon There's another thread I can't seem to find but copy and paste the following into google (without the quotes) "site:forum.universal-devices.com Noise Signal Suckers" there are quite a few related threads on how to locate the offenders.

I have a state variable $sDark that can have 3 values: 0 = Daytime, from sunrise to sunset 1 = Early Evening, Sunset to Bedtime 2 = Late night, Bedtime to Sunrise Bedtime when we are home is determined by a specific button press, if $sAway is set bedtime is a random number of minutes (up to 72) after 9:46pm A huge advantage to using a state variable is that for testing purposes it's very easy to shift to "Early evening" or "late night" mode at any given moment. For example I can manually change the variable right now to see how things work during a different time period. Most programs that occur at a time use a combination of $sDark and $sAway in their conditions instead. The Exception is there is a folder of lighting programs that run when $sAway mode is on... the programs in that folder all have there own timers to make a random 'someone is home' look. I did end up with an area specific variable also... $sDark.kitchen has very similar except that Early Evening occurs at Dinnertime, or Sunset (whichever comes first). "Dinner time" is either pressing a KPL button or saying "Alexa, it's dinner time". 0 = Daytime, from sunrise to sunset 1 = Early Evening, Sunset or "dinner time" to Bedtime 2 = Late night, Bedtime to Sunrise

I actually wondered that as I was typing, but excluded the thought because it really doesn't address the problem that OP illustrates in their final bullet: the cost of data... whether its limited calls per24 to an API somewhere, or as it seems in OPs example hardware pushing data to a single location (maybe I'm misunderstanding their example).

The ! means that the ISY didn't get a response when it tried to talk to the iolinc, It could mean a bad iolinc, but more than likely means that you have noise blocking the signal. Especially important with iolinc is that it is not a dual band device. To test you could bring the iolinc and plug it into the same circuit as the PLM or perhaps get out a long extension cord to do the same. " I threw every breaker and still doesn't work. " doesn't tell us exactly what you did. It also doesn't eliminate a noisy LED light bulb (or someother noise make / signal sucker) on the same circuit as the iolinc. Here's a detailed wiki page on Troubleshooting Insteon Communication Errors.

Right. That was basically my thoughts but not spelled out to the same level of detail. (half my thought is actually in the post replying to madcodger).... On the other hand tho I can definitely see the need to be able to somehow copy duplicate nodes between boxes (generic word on purpose), the perfect example of why: Polisy/Polyglot/ISY A is in the house, Polisy/Polyglot/ISY B is in the barn.... weather data comes from a website who's API requires a key and calls per 24h are limited, only one polyglot instance can be updated from the weather suppliers cloud but must somehow update another instance. So the $64,000 questions becomes should polyglot itself be able to cascade to more than one instance, or should there be a CopyNodes nodesever that handles multiple boxes..... ( I have no idea but like you say it's definitely something that needs to be included in the thought process) Thinking about it there's really need to go both directions, location B may have nodes that location A needs to know about.

I agree with @lilyoyo1 you have a noise issue. Specifically when the complaint is specifically about OFF being missed it usually means the the loads themselves are generating the line noise. They always turn on because the load doesn't generate noise when it's off, but when they time to turn off arrives there is line noise and the signal gets lost. With as many loads as you have here it may not be each load, for example there might be one load that is creating noise for several switches. Suspects are loads that have transformers or drivers. etc....which leaves open many type of bulbs themselves that have integrated electronics such as LEDs. Try leaving those turned off and see if you can turn off the other switches reliably.

it's not what you're looking for but there is this nodeserver: https://github.com/simplextech/udi-poly-isynet I don't know how much work would be required to get it to mirror more node type, but let's tag @simplextech and see what he thinks, there's been at least one other thread where a remote ISY in an outbuilding would be a good solution.

You're correct, a second instance of polyglot would be required. Polyglot holds credentials to the ISY that its updating, there is no provision for multiple ISY's in a single instance. Remember that someday in the future only one box will be needed Polisy, which will be running both Polyglot and ISY. What I can't understand is if you have migrated away from the platform because you didn't like it, why do you hang around this community? It's ok that the platform no longer meets your needs but why do find the need to take time to write paragraphs over and over about your dissatisfaction with the current state?

You're mistaken about who needs to issue a fix for this issue. Roomie Remote is a third party that has has not issued a new version supporting ISY's v5.x firmware. You might want to ask Roomie Remote Support or in the Roomie Remote User Forum if there are plans to support ISY V5. You also may be mistaken about your user demographics, but I have no data to disprove your 50% assumption. There are a few posts here but overall I don't think there is a huge cross-section of users.

Any chance something was touching something that shouldn't have? It sounds like you had a dead short that blew the triac in the dimmer, and blew itself open at the same time.

@vspete Which type of error? [UDSockets] RSub:30 error:6 or Net Module Rule: 4

That's awesome error log info, added to my notes. In this case, I'm going to bet that error isn't messing up subscriptions... it's an error all the same... I'm betting on the RSub 13: Error 6 or RSub 30: Error 6.... any idea what those mean?

Wes will get notified of this because it's posted in Mobilinc, he washed his hands of this issue long ago tho. As it turns out it seems to be more about ISY subscriptions getting confused because the admin console gets drug into the arena with the "Already subscribed" dialog box. The interesting thing is that Agave and ekeypad both seem to be immune and can even seem to help. Michel may be able to help more but I suspect the output from http://ISY-IP/rest/subscriptions might be a key. Now that we've got another person getting the error I wish @TrojanHorse would also log in. I also think this has more to do with information being posted into the ISY than outbound network resources, but I'm very interested in your theory about it being Networking module Rule 4.... I've tried to learn how to read the very cryptic error log in the past (in many cases the error table in the wiki doesn't tell you much more).

@vspete I don't think it's related to the UDQ queue full errors at startup/reboot (as signified by Start -5).... my system actually does still experience that condition. I suspect the culrpit is this type: Fri 2021/01/01 12:05:23 PM System -170001 [UDSockets] RSub:13 error:6 Fri 2021/01/01 12:05:23 PM System -170001 [UDSockets] RSub:30 error:6 Fri 2021/01/01 12:05:28 PM System -170001 [UDSockets] RSub:13 error:6 Fri 2021/01/01 12:05:28 PM System -170001 [UDSockets] RSub:30 error:6 but I don't know what that actually means....